David Laight wrote:

> While I can see the benefit of having multiple bits, I don't see why
> the 'securelevel' stuff ever needs to depend on curproc [1].

It doesn't. The usage of curproc in the example was to illustrate that
we should be passing the credentials of the users making the request.

> Neither can I see why you are suggesting this needs to be checked via
> some listening service, and not be a simple bitmask check.

The "listener" is kauth(9) terminology for a "callback", which is how
kauth(9) works: every scope has a list of callbacks that are called
whenever an authorization request on that scope. The actual check, as
I've shown, is done via a bitmask check.

One of the reasons I'm creating a scope and integrating securelevel
with kauth(9) is that this will allow us later to build more
sophisticated security models with little effort. One of the purposes
of using the kauth(9) framework is exactly that -- once it's well
integrated in the system, we can build on top of it anything we want,
easily allowing our users to choose between a traditional Unix security
model, capabilities, or MAC policies, because all authorization requests
are handled in a single location.

> There is a suggestion that this might involve a double process switch....
> I worry about the performance costs of this, and the fact that callers
> may not be in a position where sleeping is valid.

I'll admit that I'm not sure where you see a possibility for a double
process switch to happen so before I can comment on it you'll have to
elaborate a bit more.

> [1] splitting 'suser()' into multiple bits is a separate problem, made
> worse by the necessity for 'suid' binaries and trusted path.
> Not to say that it wouldn't be worthwhile.

NetBSD is not the first OS to suggest changes as described above.

First, if using the traditional Unix security model, then all these bits
that were once suser() calls will, eventually, end up in a check for the
effective user-id.

As for the second issue -- the set-id mode bit will remain set, but will
have affect only in the traditional Unix security model. Otherwise, we
will have to store the required privileges (or "capabilities") of the
program in its extended attributes. This, however, is something that *I*
do not plan on implementing, which is why I haven't suggested yet any
design of a capabilities system.

Root retains its "powers" even with the suggested changes (either
kauth(9) or the ones to securelevel), but we have the framework to
easily take them away. :)

Hope this helps,

-e.

-- 
Elad Efrat