On Sun, Nov 03, 2002 at 12:50:47PM -0500, Thor Lancelot Simon wrote:
> 
> So what?  All that complexity, and you get... the same guarantee, with all
> the same caveats, that you already had with file flags.
> 

Actually you get the fact that eventually you will get notified the
file has been overwritten, with file flags you will never know.

> 
> The obvious way: something else writes to the file either by exploiting the
> disksubr hole that allows writes to overlapping partitions,

ok.... so, how does file flags stop this?  How will you ever know this
has been done?

> or by writing
> locally (or from another client) on your NFS server.
>

Let us stop with the NFS now.  That is really just a blind alley - who
in their right mind is running NFS on a firewall/router or similar?
NFS is NOT secure what you are trying to do is nail a plank to a blob
of jello and then bitching because it won't work.

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

And, conversely, flags give you the same lack of guarantee.

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

No, that was not the intent.  What I meant by this is that the
building blocks were already there, I have just used them.  I
reiterate, my modifications are very small and easy to check.  Sure, I
trust the implementation of the md5/sha1 hashes - but so do other
parts of the kernel.

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

Like I said before - what I have done devolves down to a simple if in
the majority of cases.

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

No, I was not suggesting that at all.  What I was suggesting is that
the encryption of the container makes it difficult to tamper with the
contents of the container and still result in a valid container.  As I
said before though, I don't believe that NFS appropriate in a hostile
security environment.

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

OK - I think that what I am doing is using some words that have
different meanings to me - due to my work environment.  When I say
"assurance" is that the system can be audited to be running correctly,
this is not that you feel warm and fuzzy but that you can have an
external party analyse your logs for anomalies.  What flags cannot
give you is any visibility that something is wrong, you would never
know if someone modified a file - you just assume that because the
flags are applied then the file has never been modified, this is not
assurance this is blind faith.  Verifying the hash of the file gives
you a visible notification if a file has changed, this is an auditable
event and gives you an indication that security has been breached.

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

Show me how you gain assurance - by that meaning the ability to audit
the system for correctness.

> 
> , and that in a few areas, which I think I've outlined above, some of
> your reasoning about it is rather half-baked. 
>

No, what you are doing is beating me over the head with some mythical
flags modifications that will not provide any audit trail and telling
me that NFS is not secure (no surprise there).  I knew about flags
when I started what I have done, I still see the lack of any checking
that the file is not what you think it is is something that flags will
not be able to provide.

> ; actual signatures would be a
> good start, if you ask me;

Signing the hashes is something I will look at, doing signed binaries
is interesting but I see that has having some drawbacks too.

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

You may do that Thor but you need to be careful that you are sure of
all of what verified exec does.  At the moment you are focussing on
part of the capabilities and pointing out that file flags can do that,
this I will not dispute but I strongly believe that you are not
considering the other capabilities provided.

-- 
Brett Lymn