headers
Bill Studenmund | 1 Nov 2002 01:39
Picon

Re: verified executable kernel modification committed

On Thu, 31 Oct 2002, Brett Lymn wrote:

> On Wed, Oct 30, 2002 at 09:26:34AM -0500, Perry E. Metzger wrote:
> >
> > What prevents them from also altering the fingerprints?
> >
>
> either chflags or ro media.  To be honest, this is part that needs
> work.  The loading of the fingerprints is something I consider that
> needs work to improve the security of the mechanism.

Or use public/private key signing, and code the public keys into the
kernel.

One other thing we could do is come up with "Official" keys. So that you
could use a signed set of fingerprints that were generated on the build
machine which made the release.

So then all you have to do is trust the builders. :-)

> > So, again, why is this better/different from an immutable flag?

With the above, you can have a trail of verification. With the immutable
flag, you can't do any back-tracking to the build. Yes, you could download
a build and hash everything then, but that's an extra step. The immutable
flag itself won't help.

Take care,

Bill
(Continue reading)

Permalink | Reply | 0 comments |
headers
Brett Lymn | 1 Nov 2002 06:22
Picon

Re: verified executable kernel modification committed

On Wed, Oct 30, 2002 at 09:05:25AM +1100, Luke Mewburn wrote:
> 
> At a minimum, the control program (and associated examples) should be
> "veriexecctl" or something like that (instead of "verifiedexec_load").
> As for the kernel option name, that's probably OK.
> 

I agree... unless there are any howls of pain, I shall change
verifiedexec_load to be veriexecctl this weekend.

--

-- 
Brett Lymn
Permalink | Reply | 0 comments |
headers
Dries Schellekens | 1 Nov 2002 15:06

Re: verified executable kernel modification committed

On Fri, 1 Nov 2002, Brett Lymn wrote:

> On Thu, Oct 31, 2002 at 02:54:36PM +0100, Dries Schellekens wrote:
> >
> > I disagree. Brian added k5 (Binary Integrity Verification) in May 2002.
> > Read the design notes at
> > http://www.innu.org/~brian/Stephanie/dist/Stephanie-3.1/doc/DESIGN.k5
> >
>
> That does not match this:
>
> <http://www.innu.org/~brian/Stephanie/>
>
> nor does it match Brian's statements to me (unless I misinterpreted
> them).  It is a shame that he does not have time to work on the new
> design.

Huh? Binary integrity verification (k5) is a feature added to the
Stephanie version for OpenBSD 3.1; it was not in the version for OpenBSD
3.0 (http://www.packetfactory.net/Projects/stephanie/).

It is idd true that Brian no longer has time to work on Stephanie.

Cheers,

Dries
--

-- 
Dries Schellekens
email: gwyllion <at> ulyssis.org
(Continue reading)

Permalink | Reply | 0 comments |
headers
Todd Vierling | 1 Nov 2002 16:29
Picon
Favicon

Re: tar ignores filenames that contain `..'

On Thu, 31 Oct 2002, David Laight wrote:

: Since the actual problem is that following a symlink might take
: you outside the current directory hierarchy, why not make pax
: chroot to the current directory before reading the archive?

You have to do it as root.  You can't support -C properly.

And, last but not least, `suddenly' followed symlinks simply Should Not
Happen in a regular archive, regardless of where the link points.  Hence the
reason that my pax-mods proposals say nothing about whether the symlinks
contain "../" or start with "/".

Restricting pax from following extant symlinks by default, while providing
an option to allow it, should *not* affect any of its expected normal
behavior.

--

-- 
-- Todd Vierling <tv <at> pobox.com>
Permalink | Reply | 0 comments |
headers
Chuck Yerkes | 1 Nov 2002 20:10

Re: verified executable kernel modification committed

Quoting Bill Studenmund (wrstuden <at> netbsd.org):
> On Thu, 31 Oct 2002, Brett Lymn wrote:
> > On Wed, Oct 30, 2002 at 09:26:34AM -0500, Perry E. Metzger wrote:
> > > What prevents them from also altering the fingerprints?
> >
> > either chflags or ro media.  To be honest, this is part that needs
Which mitigates the problem.  I trust that binaries on RO media
won't be changed.

> > work.  The loading of the fingerprints is something I consider that
> > needs work to improve the security of the mechanism.
> 
> Or use public/private key signing, and code the public keys into the kernel.

Oh that will be nice.  Any idea how often some of these executables
run?  Back when I *did* run accounting, /bin files on a busy system
often ran hundreds of times per minute.  Web sites might make that
far far larger.

That's fine - they get cached into memory, life is good.  Now you
want to run really expensive cryptographic hashs/sigs on these?  I
have some fond memories of BSD on a Vax 11/750, but speed is not
one of them.

> One other thing we could do is come up with "Official" keys. So that you
> could use a signed set of fingerprints that were generated on the build
> machine which made the release.
For those that use pre-built binaries.  This makes the advantages of
Open Source fade a bit (though most of the Linux users do this, I find).
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bill Studenmund | 1 Nov 2002 20:55
Picon

Re: verified executable kernel modification committed

On Fri, 1 Nov 2002, Chuck Yerkes wrote:

> Quoting Bill Studenmund (wrstuden <at> netbsd.org):
> > On Thu, 31 Oct 2002, Brett Lymn wrote:
> > > On Wed, Oct 30, 2002 at 09:26:34AM -0500, Perry E. Metzger wrote:
> > > work.  The loading of the fingerprints is something I consider that
> > > needs work to improve the security of the mechanism.
> >
> > Or use public/private key signing, and code the public keys into the kernel.
>
> Oh that will be nice.  Any idea how often some of these executables
> run?  Back when I *did* run accounting, /bin files on a busy system
> often ran hundreds of times per minute.  Web sites might make that
> far far larger.
>
> That's fine - they get cached into memory, life is good.  Now you
> want to run really expensive cryptographic hashs/sigs on these?  I
> have some fond memories of BSD on a Vax 11/750, but speed is not
> one of them.

Uhm, read the thread please.

The md5 hash is calculated the first time a program is loaded. The hash is
kept in-core with the vnode. As long as the node stays in-core, the hash
is still cached. Thus we aren't hashing everything every time we run.

As for signing, my thought was you'd only need to look at the signing of a
hash when it's loaded. i.e. at boot. Also, I think it'd make sense to sign
a bunch of the hashes at once. Say all of base.tgz or all of comp.tgz.
That way you aren't spending a lot of time on signing. Note I realize
(Continue reading)

Permalink | Reply | 0 comments |
headers
Thor Lancelot Simon | 1 Nov 2002 22:03

Re: verified executable kernel modification committed

On Fri, Nov 01, 2002 at 11:55:49AM -0800, Bill Studenmund wrote:
> 
> Uhm, read the thread please.
> 
> The md5 hash is calculated the first time a program is loaded. The hash is
> kept in-core with the vnode. As long as the node stays in-core, the hash
> is still cached. Thus we aren't hashing everything every time we run.

This, to me, is the major flaw of this mechanism.  Files come in and out
of our kernel in pages; even if you validate the whole thing at startup,
there's just nothing whatsoever preventing someone from shuffling a page
out under your feet so that the next time it comes in, it'll be different.

Implementing per-page hashes in the vnodepager would seem to be the only way
to really get this right; without it, honestly, I trust a simple if statement
about the schg bit quite a bit more than a bulky hash-validation mechanism
that's vulnerable to all of the same attacks.  Note that adjusting the
semantics of the schg bit so that it did the other things this code does
(e.g. the special cases for interpreters, libraries, etc.) would be quick,
easy, and end up with a system that was no _less_ secure than one using
this cached-hash mechanism and, arguably, simply because of the smaller
amount of code involved, probably _more_ secure.

Using signatures opens up other possibilities, for instance the possibility
of allowing appropriately-signed executables to do things like replace the
hash list or adjust the file flags.  Then you'd really have something useful;
but used for the current purpose, the verified exec code really seems to offer
only the dubious advantage of great complexity when compared to the existing
file flags mechanism.  It would seem to offer the advantage that it can be
used with filesystems that don't support flags, like NFS, but that's actually
(Continue reading)

Permalink | Reply | 21 comments |
headers
Seth Kurtzberg | 2 Nov 2002 02:44

Re: verified executable kernel modification committed

All,

I've been watching this thread with interest.  If nothing else, it has
been a very interesting exposition about exactly why these issues are
hard to deal with.

There was one parenthetical statement, I believe by Chuck Yerkes, that
touched on something I've been exploring.  It was said in jest, but I
believe it contains the germ of an effective idea.  I'm talking about
his comment about retrieving an MD5 sum from a disk driver when you
retrieve the data.

It is possible, I believe, that to achieve these aims without
sacrificing too much performance will require some hardware.  (Don't
flame on me because of the difference of opinion about the performance
impact; I'm not claiming superior knowledge and I have no dog in this
fight.  :)   )

However, there may be some flaws in my concept so I'm throwing the idea
out for all the security mavens to attack.  (Any security concept should
be exposed to such attacks.)

Specifically, I've been working on a fairly simple device that can be
placed between an IDE drive and an IDE cable.  (There's nothing specific
to IDE here; it is just the mostly commonly used interface at the
moment.)  This device has a table, stored in non-volatile memory, which
marks physical disk blocks as read-only.  Then, any write request for
one of these blocks never arrives at the drive.

Now, this clearly has many of the same problems discussed on this
(Continue reading)

Permalink | Reply | 4 comments |
headers
Brett Lymn | 2 Nov 2002 10:39
Picon

Re: verified executable kernel modification committed

On Fri, Nov 01, 2002 at 04:03:16PM -0500, Thor Lancelot Simon wrote:
> 
> This, to me, is the major flaw of this mechanism.  Files come in and out
> of our kernel in pages; even if you validate the whole thing at startup,
> there's just nothing whatsoever preventing someone from shuffling a page
> out under your feet so that the next time it comes in, it'll be different.
>

Oh yes there is.  If we take the common case of the hard disk is
physically located in the computer (not everyone has a SAN for root
yet) then you have physical security of the disk.  The kernel mediates
writes to the disk.  At securelevel 2 writes to the raw disk are
disallowed.  My code blocks writes to files with a fingerprint, even
if it did not you would get a ETXTBUSY trying to write a file that is
being executed.  How can a page get shuffled behind the kernel's back?

> Implementing per-page hashes in the vnodepager would seem to be the only way
> to really get this right;

that bloats the signatures to one per page... that can add up to a lot
of fingerprints - I doubt if it would be tenable and I am dubious that
it would buy you anything but more overhead.

> without it, honestly, I trust a simple if statement
> about the schg bit quite a bit more than a bulky hash-validation mechanism
> that's vulnerable to all of the same attacks.
>

Actually, the code to do this is very short.  The routines for the
major part, the hash evaluation, were already part of the kernel.
(Continue reading)

Permalink | Reply | 15 comments |
headers
Brett Lymn | 3 Nov 2002 11:23
Picon

Re: verified executable kernel modification committed

On Fri, Nov 01, 2002 at 11:10:00AM -0800, Chuck Yerkes wrote:
> 
> For those that use pre-built binaries.  This makes the advantages of
> Open Source fade a bit (though most of the Linux users do this, I find).
>

Not at all.  You could always sign your own fingerprints.  What it
does do is help mitigate the chicken-and-egg situation of how do you
know that the code you are using to do the signing is able to be
trusted.  The decision, as Bill pointed out, is whether or not you
trust the builders.

> 
> In my paranoia days when I had to put up a very important web site
> for a bank, using SunOS 4, I put all the binaries on disks pinned
> readonly.  Data - checked hourly and overwritten entirely every day,
> was on R/W disks.  These days I'd mount those nosuid,noexec,nodev.
> 

Yes, been there, done that.

> While these seems like a neat idea, without having a dedicated
> specialized processor to provide the sig, it's going to be burdensome.
>

No.  As I said in my original announcement there is no detectable
impact on the system, perhaps on a slower processor the impact may be
noticable - the slowest I tested verified exec on was a p120 laptop.
I would be interested in hearing about results on slower machines.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane