Subject: Re: kauth, securelevel, and "run levels"
To: None <email@example.com>
From: Elad Efrat <elad@NetBSD.org>
Date: 03/25/2006 21:13:03
Thor Lancelot Simon wrote:
> 1) We should factor out exactly what operations may allow persistent
> compromise, and produce a kauth mask that prohibits them. This
> should correspond to the old "security level 1", plus what should
> have gone into level 1, but went into level 2 because I was a dumbass.
Yes, we already talked about that. I gave you a list of implications of
securelevel (minus a few) so you can factor out the securelevels the way
you see fit -- did you do that? :)
I don't mind doing it myself, but simply because I'm sure we'll divide
the implications differently I prefer you go ahead and do it first.
> 2) We should implement, rather than this confusion of run-level and
> security-state in init, an ordered set of "run levels" implemented
> by init and the kernel cooperatively, so that if we're in "run level
> 0", we know that everything's been killed off and init has started
> with a fresh slate. Note that this would allow implementing intermediate
> or higher "run levels". That's important. See point 3.
Same as before, I ask you (or anyone else, for that matter) to provide
what you think should be the implications of each "run level".
> 3) We should make the kernel, at the transition into each "run level", set
> a specific permission mask that is the maximal set of permissions any
> process may have at that run level. The permission mask for any run
> level should be settable only at a lower run level.
I'll admit that I didn't quite understand what you are talking about
here. What do you mean by "maximal set of permissions any process may
have at that run level"? do we have something similar now? what kind
of permissions would these be? you kinda lost me with that one.
Also, available online are some files straight out of my "work in
progress" directory that contain securelevel references in the kernel as
well as what was an attempt to collect them all into understandable
The first being the references; egrep for '^(OK|XXX)' to get the actual
checks against securelevel in the kernel; the second is a header with
some of the checks as constants. (in the form of "SECLEV_LKM_LOAD", etc.)