On Sat, Nov 02, 2002 at 08:09:29PM +1030, Brett Lymn wrote:
> 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

So what?  All that complexity, and you get... the same guarantee, with all
the same caveats, that you already had with file flags.

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

The obvious way: something else writes to the file either by exploiting the
disksubr hole that allows writes to overlapping partitions, or by writing
locally (or from another client) on your NFS server.  And don't say "at
securelevel 2, you can't do that!" because that gets you... hmmm... oh,
right, no more of a guarantee than you had with file flags at securelevel 2.

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

Well, it would buy you any kind of meaningful guarantee _at all_ when
executing from NFS, which would seem to be the only significant benefit
your scheme as it currently stands could offer over file flags.  But if
you want to toss that away and tell people to use encrypted blobs they
can't actually share with other machines in any meaningful way -- well,
okay, your code, your perogative.

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

Please don't take this wrong, but to me this reads an awful lot like
"well, it does the same thing as the code we already had, but because it
uses a cryptographic hash, it must be better".  Fundamentally, I do not
buy that.  Simpler is better.  Building additional complexity into the
security machinery, to achieve a purpose we've already achieved with a
single bit and a simple if statement, does not seem to me to be to be
the right thing to do, whether it happens to use a particular cryptographic
transform or not.

Code that's not there can't have bugs.

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

Yes, if there is only one client, and if you happen to trust data *encryption*
as cryptographically-strong *validation* of that data -- which has proven to
be a very serious mistake for many people in the past -- you could do that.

This, to me, is exemplary of ths same train of inexact reasoning that leads
to the fallacious result that, as currently implemented, the verified exec
code actually does any better job of guaranteeing that you're executing what
you think you are than the simple file flags mechanism did.

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

I don't believe that either of the major claims you make in the paragraph 
above are exactly true, though similar statements might be.

I really think you should sit down and whiteboard out somewhat more 
rigorously where you're trying to get to, what actual guarantees your
code provides in the real world, and what actual guarantees the simpler
code we already had in the kernel provided, or could provide with very
small modifications.  I think that you will find that under many of the
assumptions necessary to be able to make the kind of statements you want
to make about the utility of your code and what it guarantees, you will
find that the pre-existing mechanism was functionally equivalent.

I believe that verifying the system image is a reasonable, desirable, and
in some cases necessary thing to do.  I believe that your mechanism is a
good start, for that purpose.  I do, however, think that there are simpler --
and thus better -- ways to do some of what you're advocating people use it
for, and that in a few areas, which I think I've outlined above, some of
your reasoning about it is rather half-baked.  It's my suspicion that you
will then discover that to really provide additional benefit over what we
already have, you need to make some changes; actual signatures would be a
good start, if you ask me; but then again, it's not my code, so, ultimately,
all I can do is try to persuade you it should be a little bit different.

-- 
 Thor Lancelot Simon	                                      tls@rek.tjls.com
   But as he knew no bad language, he had called him all the names of common
 objects that he could think of, and had screamed: "You lamp!  You towel!  You
 plate!" and so on.              --Sigmund Freud