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.

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.

Thor