All,

I've been watching this thread with interest.  If nothing else, it has
been a very interesting exposition about exactly why these issues are
hard to deal with.

There was one parenthetical statement, I believe by Chuck Yerkes, that
touched on something I've been exploring.  It was said in jest, but I
believe it contains the germ of an effective idea.  I'm talking about
his comment about retrieving an MD5 sum from a disk driver when you
retrieve the data.

It is possible, I believe, that to achieve these aims without
sacrificing too much performance will require some hardware.  (Don't
flame on me because of the difference of opinion about the performance
impact; I'm not claiming superior knowledge and I have no dog in this
fight.  :)   )

However, there may be some flaws in my concept so I'm throwing the idea
out for all the security mavens to attack.  (Any security concept should
be exposed to such attacks.)

Specifically, I've been working on a fairly simple device that can be
placed between an IDE drive and an IDE cable.  (There's nothing specific
to IDE here; it is just the mostly commonly used interface at the
moment.)  This device has a table, stored in non-volatile memory, which
marks physical disk blocks as read-only.  Then, any write request for
one of these blocks never arrives at the drive.

Now, this clearly has many of the same problems discussed on this
thread, and in some cases is impractical.  In a certain type of
installation, however, I believe it can be very effective.  If in a
given system the O/S is loaded once and doesn't change (or at least
changes infrequently), those disk blocks associated with files that
should never change can be made read-only.

This is really only of any use, from a security perspective, if the
configuration cannot be changed without physical access to the machine. 
In many cases, I think this is workable.  Clearly, in other cases, it is
not.

I invite comments.

On Fri, 2002-11-01 at 14:03, Thor Lancelot Simon wrote:
> On Fri, Nov 01, 2002 at 11:55:49AM -0800, Bill Studenmund wrote:
> > 
> > Uhm, read the thread please.
> > 
> > The md5 hash is calculated the first time a program is loaded. The hash is
> > kept in-core with the vnode. As long as the node stays in-core, the hash
> > is still cached. Thus we aren't hashing everything every time we run.
> 
> This, to me, is the major flaw of this mechanism.  Files come in and out
> of our kernel in pages; even if you validate the whole thing at startup,
> there's just nothing whatsoever preventing someone from shuffling a page
> out under your feet so that the next time it comes in, it'll be different.
> 
> Implementing per-page hashes in the vnodepager would seem to be the only way
> to really get this right; without it, honestly, I trust a simple if statement
> about the schg bit quite a bit more than a bulky hash-validation mechanism
> that's vulnerable to all of the same attacks.  Note that adjusting the
> semantics of the schg bit so that it did the other things this code does
> (e.g. the special cases for interpreters, libraries, etc.) would be quick,
> easy, and end up with a system that was no _less_ secure than one using
> this cached-hash mechanism and, arguably, simply because of the smaller
> amount of code involved, probably _more_ secure.
> 
> Using signatures opens up other possibilities, for instance the possibility
> of allowing appropriately-signed executables to do things like replace the
> hash list or adjust the file flags.  Then you'd really have something useful;
> but used for the current purpose, the verified exec code really seems to offer
> only the dubious advantage of great complexity when compared to the existing
> file flags mechanism.  It would seem to offer the advantage that it can be
> used with filesystems that don't support flags, like NFS, but that's actually
> not so, because the caching behaviour makes it too dangerous to use it across
> the network at all.
> 
> Thor
-- 
Seth Kurtzberg
M. I. S. Corp
480-661-1849
Pager 888-605-9296, or 6059296@skytel.com