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

> >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?
> >
> 
> It does mean a bigger hit on the initial exec.  At the moment my
> userland code does the translation of the fingerprint hex string to
> binary and passes that into the kernel.  If scan the file on the first
> exec then there will need to be a scan of the file and then a
> conversion.  The alternative would be a db file but I am not sure how
> I would go about interacting with one of those at the kernel level.

I'd still rather see this added somewhere in the file header, or
somewhere in the file system itself, associated with the actual stored
file.  The loader would still do the initial hash, and compare it to
the stored hash.  If these are different, stop (why bother the kernel
with bad data?).  If the unsigned hash passes, send the unsigned and
signed hash to the kernel, let it sign the unsigned half, and verify
the kernel-signed to the retreived-signed hash.

> >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.
> >
> 
> There could be - admittedly my aim has been to lock down the entire
> system rather than protecting one class of file (e.g. setuid).

Well, that is just an option to me.  Right now there are:

	noexec
	nosetuid

I propose adding:

	no-unsigned-exec
	no-unsigned-setuid

which mimics these, just needing a signed binary in either case.

--Michael