In message <44249754.5040403@NetBSD.org>, Elad Efrat writes:
>Jonathan Stone wrote:
>
>> addresses my point in any way whatsoever.  Perhaps you'd care to
>> explain how any of the text below relates to the *INITIAL* confidence
>> in your replacement code? 
>
>The code is on NetBSD's CVS, publicly available, you can download it
>(the kauth(9) subsystem is just one file, kern/kern_auth.c) and have
>a look.
>
>There is really no other answer to your question. Obviously, code that
>has existed for years will gain more confidence than new code that
>exists for less than a month.

Ah, I see: you answer by not answering.  Then would you agree that
it's fair for me to state that that you did *NOT*, in fact, speak to
my concerns?  Despite your claim to the contrary, that:

  >While I can certainly understand your concern, there is an aspect you
  >did overlook in my proposal. :)

Elad, can you try again to show me just exactly what you think I've
overlooked?

Or alternatively, would you care to address the issue of how to
replace the aspects of securelevel (guaranteeed-revocation, for a
well-defined monotonic set, for all proceses now and forevermore) in
your proposal?

Because, so far, both Thor and I (both fairly expert at building
hardened, secure systems using (amongst other features) securelevels)
aren't seeing at all how to accomplish that, not in anything remotely
like an equivalent, easily-explained, *provably* secure way.

To quote Thor:

TLS> If we're going to do that, I think we need to combine "fine-grained knobs"
TLS> with a concept of "run levels", so that one can have masks that are
TLS> applied at each run level.  Without that, there are things it's easy to
TLS> do with the securelevel framework (and easy to prove correct) that are
TLS> hard to do in the new system.
TLS>
TLS> Actually, didn't we thrash out something like this in our email
TLS> conversation a few months ago?  I have the vague recollection that
TLS> we discussed it, but not where we ended up.