YAMAMOTO Takashi wrote:

> i don't think splitting securelevel is a good way to achieve
> fine-grained control.  (see below)

But this is a discussion we *already had* and is not the subject of the
thread. What *you* think is irrelevant, because *you* are given the
choice to use whatever interface you want -- be it a single knob, or
multiple knobs.

We've been through that before. My initial post started with saying
something "as we agreed that some people *do* want it, here is how
everyone can be happy".

> TN mentions KAUTH_VNODE_WRITE_SECURITY/KAUTH_VNODE_NOIMMUTABLE, which
> is what we want, i guess.

The vnode scope is what Mac OS X uses to take the permission checks out
of each file-system specific code and into the VFS layer. We are not
implementing it just yet, so this is out of the question.

Since this is a single case, IF we do decide to implement what I
suggested, and WHEN we get around to have extended attributes working,
and IF we decide to have the vnode scope handle the permission/ACL
checks all in one place, and WHEN we get around to implementing that
too, I promise you that I'll take care of that bit. :)

But for now... let's not let *that* be the show-stopper..


> i don't think "tcb" is a good idea because some aspects of securelevel
> have more appropriate scopes.  and we already have "generic" scope for
> misc operations.

Yes, but I'm not sure these are "misc. operations"..

I'll give you two examples of operations: the first, is checking if
process A can "look into" process B. We use this check for things like
filtering ps and netstat output per-user. The second operation is "can
this process attach systrace to init". Obviously, this is a process
related operation, because the very act of attaching systrace (or
ptrace, for that matter) belongs -- clearly -- in the process scope.

However, I was suggesting a different point of view: there *is* a
difference between these two operations, the difference that justified
the creation of securelevel. While the first operation can cause little
harm to the system (so what if joeblow gets to see root owned
processes?), the second operation suggests that joeblow (or a
compromised root) could attach to init, manipulating it, compromising
the TCB.

This could very easily start an endless discussion. There is no right
answer for this one, I'm afraid. On one hand, we can have the
securelevel-related operations scattered across several scopes, possibly
even handled by different listeners (by playing with "defer"), where we
have to pay extra attention not to treat these as just operations that
are handled by, say, the generic or process scopes, but rather as
operations that if handled incorrectly can compromise the entire
machine.

Or, we could keep them all in one place, biting the bullet and preaching
on the mantra that "although they may be related to packet filter rules,
LKMs, or attaching to init", they all have the same common property of
being able to modify the TCB of the host --  and all are related to
either securelevel or (if we decide to implement) runlevel.

To be completely honest -- I don't think that *technically* it matters
what we choose to do. We'll get it right either way, I am just
presenting both sides of the coin.

It would be nice if other people voiced in on this matter so we can
move forward. :)

> i think one of the points of securelevel is being "a simple system
> global knob".

See above...

> anyway, we need to factor out a set of operations/scopes necessary for
> suser and securelevel.  ie. non trivial work :)

Can I assume that's an "okay" for the proposal, then? :)

> maybe you can use ISSUSER-like temporary placeholder for some aspects of
> securelevel which don't have approrpriate scopes for now.

That's not a valid suggestion, I think, because securelevel (or, the
traditional BSD securelevel model) does not care for "suser" or not.

> i'm not sure if it's much better than direct manipulation of
> securelevel variable, tho.

It is. :)

-e.

-- 
Elad Efrat