Subject: Re: Volunteers to test some kernel code...
To: Michael Graff <explorer@flame.org>
From: Brett Lymn <blymn@baea.com.au>
List: tech-kern
Date: 06/15/1999 10:05:09
According to Michael Graff:
>
>I'm just a little worried about the whole thing so far, mostly in
>scalability.
>

I know what you mean.  I was concerned about this somewhat initially
but after looking at my system (I am a software packrat) I found there
to be about 1000 executable files all up.  Some of those files are
actually links to other files so they will share dev/inode pairs,
duplicate dev/inode pairs are not entered into the in-kernel list.

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

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

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

This would allow more flexibility than I have at the moment.  The
downside is that it does mean that there may be filesystems on the
machine that will allow unsigned binaries to run which begs the
question of why bother since you can lock down the binaries just by
making them immutable without the need of doing any md5 evaluations.
The major selling point for what I have done is to prevent
unauthorised binaries being run at all.  Single user mode is still
your friend since that is, theoretically, the only way to make updates
to the system.

-- 
===============================================================================
Brett Lymn, Computer Systems Administrator, British Aerospace Australia
===============================================================================