Subject: Re: Volunteers to test some kernel code...
To: Brett Lymn <email@example.com>
From: Michael Graff <firstname.lastname@example.org>
Date: 06/14/1999 17:14:15
email@example.com (Brett Lymn) writes:
> According to Michael Graff:
> >How about the additional requirement that hashed binaries are
> I had a look at this before my flight this morning. It looks like it
> is an easy fix - if the file has a signature and it is being opened
> for write then error. I was planning to flush the cached evaluated
> signature on write anyway but preventing writes to signed files
> obviates this. An interesting side note is that if you included
> non-executable files in the signature list then they would be made
> immutable as well - the actual signature file would be a good start :-)
I'm just a little worried about the whole thing so far, mostly in
Perhaps this is a better solution?
At the secure level you propose, disks are already read-only,
/dev/kmem is read only, etc. Disks cannot be mounted. Why not make
the signature on exec a filesystem requirement, and store the
signatures in the filesystem itself, loaded as needed on initial
access to the file?
This would sort of fit in line with no-setuid flags, etc. In fact,
there could be some way to say "no setuid unless signed" or something
These flags are then filesystem dependent (which is what I would like)
and would fit more in line with "if you want to bypass this, single
user mode is your friend."