Christos Zoulas wrote:

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

Of course, the /etc/rd.d/securelevel script for systems with
multiple knobs will be changed to load sysctl.conf-like files with
customized settings made by the admin. We should supply skeleton
files with the possible knobs and provide documentation on the
meaning of each knob and what securelevel it used to belong to.

On systems with multiple knobs exposed, maintaining correlation
between the securelevel variable and the value(s) of these knobs
can be done similar to what David suggested, assuming that it will
set securelevel to 2, even if only one securelevel 2 knob was set.

quoted text
> How does going from multi-user to single user and back affect the mask?

I addressed this in my post.. in the case of traditional securelevel,
we don't need to worry about that. When we have multiple knobs, we would
save the state of securelevel, then set it to a predefined mask, say
SECURELEVEL_MASK_0 (or whatever). When returning back to multi-user, we
will restore the saved state.

Hope this answers your questions,

-e.

-- 
Elad Efrat