On Sun, 3 Jun 2001, Brett Lymn wrote:

> Uhhhhh I did something that was almost akin to this about a year ago
> (I had not heard of Stephanie until just now).  What I did was have an
> in kernel list of md5 hashes associated with executables.  When an
> exec was done the md5 hash of the on disk executable was evaluated and
> compared with the in kernel one.  If the hashes matched then the exec
> proceeded.  If it did not match it would either just log the event or
> refuse execution depending on the secure level.  My patches would not
> only prevent an unknown executable from running (depending on the
> secure level) but also would refuse to run a trojan'ed copy of a
> binary on the trusted path.  Not only this, my patch would allow you
> to have shell scripts using a particular shell interpreter but
> _prevent_you_running_the_interpreter_directly_ so if you had
> /usr/local/bin/perl you could run perl scripts (as long as they had a
> valid md5 hash) but attempting to invoke /usr/local/bin/perl from the
> command line would fail.  The major flaws of what I have done (and, at
> a cursory look, Stephanie shares these faults):
> 
> 1) evil code can still be run by buffer overflowing an allowed program
> and then mmap'ing in evil cracker code and jumping in to it.
> 
> 2) the scheme only works properly for static binaries, if you can
> overwrite a system library then you are hosed.
> 
> I believe I can fix both of these holes with some changes to mmap and
> maybe open (hacking the open call has some other interesting side
> effects such as being able to validate arbitrary files for
> correctness).

One thing you might try is making it a layered file system. All you have
to do is add your checks to the VOP_ACCESS routine, and maybe the mmap one
too. I'm willing to give you tips on how to do this.

The advantage of using a file system is that you have to hack into a lot
fewer code points - the kernel already asks the FS if it can execute a
file. :-)

Take care,

Bill