On Fri, Nov 01, 2002 at 04:03:16PM -0500, Thor Lancelot Simon wrote:
> 
> 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.
>

Oh yes there is.  If we take the common case of the hard disk is
physically located in the computer (not everyone has a SAN for root
yet) then you have physical security of the disk.  The kernel mediates
writes to the disk.  At securelevel 2 writes to the raw disk are
disallowed.  My code blocks writes to files with a fingerprint, even
if it did not you would get a ETXTBUSY trying to write a file that is
being executed.  How can a page get shuffled behind the kernel's back?
 
> Implementing per-page hashes in the vnodepager would seem to be the only way
> to really get this right;

that bloats the signatures to one per page... that can add up to a lot
of fingerprints - I doubt if it would be tenable and I am dubious that
it would buy you anything but more overhead.

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

Actually, the code to do this is very short.  The routines for the
major part, the hash evaluation, were already part of the kernel.
Most of the other code is simply checking a status flag in critical
paths.

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

In this case you could always resort to using cgd to encrypt a
container file on the NFS server and serve that to the client.

Bill has already mentioned this but it is a good point - it gives us
the capability of providing a mechanism providing assurance that what
you are running is "official code", it also gives you a visible audit
trail that your trusted computing base has not been modified.  Neither
of these things can be provided by changing the flags code.  Both are
important to people who do security.  Flags will never give you assurance.

-- 
Brett Lymn