blymn@baea.com.au (Brett Lymn) writes:

> According to Michael Graff:
> >
> >How about the additional requirement that hashed binaries are
> >immutable?
> >
> 
> 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
scalability.

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

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

--Michael