YAMAMOTO Takashi wrote:

quoted text
> the fact that "access raw memory" and "change firewall rule" are
> controlled by securelevel is not a good reason to put them into
> a single scope, IMO.

True. The reason I did put them into a single scope was that,
originally, I had intended for the "system" scope to be something
like Thor posted about -- collection of changes that might affect
the TCB.

We could, and perhaps even should, do this right by splitting it up
as you suggest.

When I first started some work on splitting up securelevel (before
I figured integrating it with kauth(9) would be the best thing to
do) I compiled a list of what securelevel really does. Most of the
list is divided to file-system related knobs (file flags and mounts),
kernel related knobs (LKMs, time adjustment, sysctl(9), corename),
raw memory access (/dev/mem and /dev/kmem), networking (packet filter
rules and net80211 modules), and process manipulation (via systrace,
ptrace, procfs -- or these also belong in kernel?). Also, there are
few securelevel impacts that are located in MD code that I haven't
yet checked out thoroughly.

So:

quoted text
> it's better to write listeners to check "securelevel" variable
> for appropriate scopes, rather than having a single scope gathering
> these random operations.
> ie. i think securelevel should be turned into listener(s), not a scope.

IIUC, you mean to create several listeners that would each be in charge
of making a decision for different "knobs", and defer requests
otherwise?

If so, to what scope should these listeners be attached to?

quoted text
> btw, it seems that you are proposing two different things in this mail.
> 	- adapt securelevel to kauth world
> 	- make securelevel a bitmap
> 
> i'm not sure if the latter is a good idea.
> why bother to complicate securelevel, while you can just have
> another listener to implement finer-grained access control?

It's not really "make securelevel a bitmap", but introduce a new
variable that'll store the information kauth(9) will refer to when a
request is made.

If now there's an "int securelevel" kernel code can check before
granting access to, say, open the raw memory device; if we are splitting
the knobs, we need a place to store the values for all these knobs.

Where else would information such as "modifications to the packet
filter rules are disallowed" will be kept? (granted, that's got to
do more with the security model used; let's assume "traditional Unix"
for the context ;)

...or am I not understanding you correctly?

-e.

-- 
Elad Efrat