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

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

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

Hope this somewhat helps,

-e.

-- 
Elad Efrat