In message <20060324225942.GA12096@panix.com>Thor Lancelot Simon writes
>On Fri, Mar 24, 2006 at 11:24:36PM +0200, Elad Efrat wrote:
>> Christos Zoulas wrote:
>> 
>> > If we assume that we are currently running at securelevel 1, and
>> > we add or remove a capability, we'll be in a situation where the
>> > securelevel variable will still be 1 but this will not match
>> > the original level 1 mask.
>> 
>> I'm sorry if that part of my mail wasn't clear, but the user will be
>> able to choose between "traditional securelevel model" and "fine-
>> grained knobs". In the latter case, kern.securelevel will have no
>> meaning in the NetBSD kernel at all -- there will no longer be
>> "security levels"; rather a collection of knobs you'll be able to
>> manipulate. The securelevel variable will exist only for [binary]
>> compatibility with third-party software/LKMs.
>
>If we're going to do that, I think we need to combine "fine-grained knobs"
>with a concept of "run levels", so that one can have masks that are
>applied at each run level.  Without that, there are things it's easy to
>do with the securelevel framework (and easy to prove correct) that are
>hard to do in the new system.

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.


(Repeated calls for not just a a devfs, but for devfs plus removal of
static in-filesystem special-device inodes, and their associated,
newfs/mknod-time, *statically auditable* perimsisions (e.g., for use
inside chroot() areas or "jails"), is one such case).

>Actually, didn't we thrash out something like this in our email
>conversation a few months ago?  I have the vague recollection that
>we discussed it, but not where we ended up.

I don't  recall such a discussion... can you refresh my memory off-list?