Subject: Re: Integrating securelevel and kauth(9)
To: None <>
From: YAMAMOTO Takashi <>
List: tech-kern
Date: 03/26/2006 19:45:24

> > 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.

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.