In message <442487A6.1060000@NetBSD.org>Elad Efrat writes
>jonathan@dsg.stanford.edu wrote:
>
>> Indeed, and this touches on an important point often overlooked by
>> proposers of change: namely, the *confidence* in a given implementation.
>> 
>> Years-old implementations like securelevel many not be shiny or sexy;
>> but because they _are_ years-old, they've had many eyes look over
>> them.  Several bugs have been identified and fixed.  Both the
>> technique and the implemntation is well-understood in the wider
>> security community (e.g., by third-party security labs certifying
>> for governmnet use.) 
>> 
>> The upshot is that, for people who rely on existing security-releated
>> features to meet those levels of confidence, *NO* new feature is an
>> actual substitute for the existing features. By definition, the
>> ``new'' feature is not a substitute for the ``old'' feature until the
>> new-ness has worn off, the "new"code has become well reviewed,
>> well-understood, and widely-trusted.
>
>While I can certainly understand your concern, there is an aspect you
>did overlook in my proposal. :)

Elad, If you really think so, please point out what any specific
item(s) you think I overlooked.  I ask because because I've read the
paragraphs below three times now, and *NONE* of what you 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? Or to concerns, as per Thor's over whether
it's an effective replacment for securelevels?

In fact, your comments makes me fairly confident that you haven't
grasped my point at all.


>At the moment, the kernel has many ways for doing things that belong
>in the same area: for example, some parts of the kernel call suser(),
>other parts simply check for euid zero, others care about egid and
>group membership. Securelevel is yet another interface in the kernel
>for doing more-or-less the same things -- checking if an operation is
>allowed or not given a certain system context.
>
>One of the benefits we get from using the kauth(9) framework is that
>the code used across the kernel to do all those things, and more, is
>centralized and contained. So even though it's "new" code that hasn't
>been reviewed as much as the code it replaces, the process of reviewing
>it is a lot easier for others.
>
>Instead of checking a single variable throughout the kernel, we hide
>that internal detail from the kernel, and change all references to
>issue a request for the requested privilege(s). The listener receiving
>the request and its context can do whatever you want -- match it
>against the securelevel variable, matching against the securelevel
>bitmask, or even dispatch the request to a userland daemon to make a
>decision. This is all hidden from the caller -- who's just interested
>in knowing if it can do what it wants or not.
>
>To me, and I'm sure that to others as well, the BSD securelevel is just
>a hack. Sure, it's a long-time reviewed hack that may come in handy to
>do certain things quickly -- but it's still a hack, and as such, I think
>that in the long-term we'll only benefit from replacing it, and other
>parts of the kernel, with a consistent interface that is better
>understood. (compare "if securelevel > 1" and "if this user can do this
>operation")

Elad: just which point of this do you think I overlooked?
Just which part addresses my comments?


All I can take from it is to begin to suspect that you haven't
understood either my comment, or Thor's commment.  Being able to test
on a fine-grained basis for

	"can this particular  user (or process) can do some particular operation"

is *NOT*, repeat *NOT* a replacement for a system-wide knob which can
forbids a monotonically-increasing set of operations to *ALL* users,
irrespective of uids or inherited capabilities or ... whatever.

For me, and for Thor, the key feature is the ability to enforce
revocation, from *all* users or processes or whatever, *any* ability
to perform certian actions; and to be able to enforce such revocation
at certain well-defined points during system startup, and irrespective
of the prior ability of those users/groups/whatever. You may think
tha'ts a hack, but it's acutally a very useful tool for building hardened
secure systems.

The ability to enforce revocation, at specified points, is what Thor
is getting at with his "run-level" suggestion.  You're of course free
to denigrate the BSD-securelevel machinery by calling it a "hack"; but
you're going to have to provide a suitable replacment if you want your
proposal to be accepted as a substitute.

And please don't offer these nebulous "kauthd" callbacks as a
substitute, not until they've been well-audited and well-reviewed.



 


>> I don't  recall such a discussion... can you refresh my memory off-list?
>
>Thor is referring to a private discussion him and I had.

Since THor is suggesting that private discussion as a basis for
further work, perhaps he or you could summarize it here?