hi,

> > you can always have a listener to check "costum knobs".
> 
> I'm not sure I follow. What would the listener check if there aren't
> separate bits (or whatever) that indicate the different knobs?

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

> > - "lkm" scope?
> > - "vfs namespace" scope for mount/unmount/etc?
> > - "machdep" scope?
> > - "specfs" scope for kmem and raw device?
> > - "immutable bit" thing should be a part of FILEOP or VNODE scope, maybe.
> > - misc things might be a part of existing "generic" scope.
> > 
> > it might not be worth to have fine-grained scopes for
> > slow operations like lkm and mount.
> 
> Some things that are worth saying here...
> 
> The vnode scope is used only for access control operations -- the
> permission checks that are now part of the file-system code -- because
> it's *very* heavily used. I suggest we trust Apple on this one and not
> attempt to add more things to it.
> 
> As for the other scopes, you see what kind of mess is created here? we
> introduce more scopes than actually necessary and over-complicate it.
> I assume we'll end up placing knobs for the "lkm", "machdep", "specfs"
> scopes and the misc. things in the generic scope. The fileop scope does
> not seem right for things like handling the immutable (and other) bits,
> so that'd probably go in generic as well.

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

> The "machdep" scope is actually more of a i386/amd64/xen scope; don't
> quote me on it but I think there is very minimal use -- if any -- of
> securelevel in other MD code.

yes, i agree it's a trade-off among some kind of cleaness, efficiency, etc.

	- performance critical scopes should be small as far as possible.
	- don't care much about others.

a possible concern; in future, we might introduce a performance critical
operation which semantically fits one of scopes which is not performance
critical today.

> So... it might be the case that introducing a new scope that can be
> called "system" (or, "TCB" :) to control the variety of knobs that might
> affect the TCB be worthwhile, after all...

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.

> > i don't think it's necessary to hurry up to create
> > scopes for this purpose because there's no need to convert
> > all securelevel checks at once.
> 
> This I don't agree with. As my original post on the thread said, there
> are going to be two ways for handling the securelevel implications: the
> "traditional" way and the "new" (multi-knobbed) way. If we change only
> parts of the code, we're dragging feet.

i think one of the points of securelevel is being "a simple system
global knob".  if you want fine-grained control, it shouldn't be done by
splitting securelevel, IMO.  you can have both of securelevel listener and
fine-graind access control listener.

> > it might be better to create scopes necessary for things currently using
> > suser first, and see if each aspects of securelevel fit into them,
> > because the former is more primary user of kauth.
> 
> That's an excellent suggestion. The amount of converted-suser() calls in
> the kernel is rather large, so if other developers are interested in
> helping to identify what privilege is requested in each of them we can
> achieve that faster.
> 
> I wouldn't want to think, however, that we'll hold with the securelevel
> work because of it. A large amount of the work is changing the
> references to securelevel to kauth(9) calls with the proper request,
> and for that we don't need to wait until all converted-suser() calls
> have more descriptive requests, IMHO. :)

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

maybe you can use ISSUSER-like temporary placeholder for some aspects of
securelevel which don't have approrpriate scopes for now.
i'm not sure if it's much better than direct manipulation of
securelevel variable, tho.

YAMAMOTO Takashi