Subject: Re: verified executable kernel modification committed
To: Chuck Yerkes <chuck+nbsd@2002.snew.com>
From: Bill Studenmund <wrstuden@netbsd.org>
List: tech-security
Date: 11/01/2002 11:55:49
On Fri, 1 Nov 2002, Chuck Yerkes wrote:

> Quoting Bill Studenmund (wrstuden@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
that'd mean you'd have to load all of them at once, so the kernel could
verify the key.

> > 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).

How so? Doing this would let you, but not require you to, verify a binary
back to the "Official" source. I'd expect it would also be reasonable to
set things up so you could sign things yourself. So you could make sure
that the binaries you run are the ones you expect to run.

> While these seems like a neat idea, without having a dedicated
> specialized processor to provide the sig, it's going to be burdensome.
> Is Seagate about to give use disks that can say "here's the file
> and, by the way, here's the MD5 sum of it"?

Your comments indicate to me we'd be verifying hashes a lot more often
that the thread has implied. I don't think it's going to be as bad as you
describe.

Take care,

Bill