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

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

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.

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"?

Getting rid of privilege and executable stacks is a feasible step
that will give us more.  Clever use of chflags and, perhaps a way
to do a hard lockdown of the executable PATH depending on the user
would be of quicker benefit, IMHO.