Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email email@example.com
Re: Integrating securelevel and kauth(9)
From: YAMAMOTO Takashi (yamtmwd.biglobe.ne.jp)
Date: Mon Mar 27 2006 - 04:57:51 CST
> > sorry again, can you privide a pointer?
> Are you serious? you already asked once on this thread for a pointer to
> an earlier discussion, and I gave it. If you read it, how are you asking
> for a "pointer" again?
i was not sure if you were referring to the same thread, so i asked.
i couldn't find any consensus about how to implement fine-grained control
in the thread.
> > do you mean, has it already been decided to split securelevel into
> > multiple knobs? even if so, it's orthogonal to kauth.
> Do you want me to repeat myself again?
> The current code NetBSD uses has suser() checks, euid checks,
> and securelevel checks. I'm suggesting to get rid of that mess, and
> implementing securelevel using a kauth(9) interface is one step in
> that direction.
i don't have any objection to implementing securelevel via kauth.
however, i don't think splitting securelevel is really related to it.
> > i understand there are people who want multiple knobs,
> > but i don't understand why it should be done by splitting securelevel.
> Then how are you intending on having the separation of knobs if all you
> have is a single raise-only integer?
you can have listeners for fine-grained knobs, in addition to securelevel
because the former is not a securelevel anymore, it's reasonable to
have separate listeners, IMO.
> > and not everyone seems happy.
> If not everyone are happy, then I will simply not do what I suggest.
> But I think you are wrong here too, because the discussion took itself
> to places like code size and performance and further enhancing what we
> have today by using run-levels, and was not tripped on "this is a bad
> idea". So saying "not everyone seems happy" is ignoring the fact that,
> at least as it seems to me, the *IDEA* of doing what I suggested was
> accepted, but people are interested on what implications it will have
> on size/performance etc.
at least i'm not happy, so "not everyone".
> > if "the proposal" means your original "system scope" proprosal, no.
> Hardly. The proposal is to integrate securelevel and kauth(9) as the
> subject of this way-to-long thread suggests. The mail you are replying
> to also implies, probably not clearly enough, that I am so tired of
> these pointless arguments over tiny things that don't matter (this is
> wa beyond bikeshed) that if you keep insisting on implementing these
> knobs in their supposedly-appropriate scopes I'll just agree so we can,
> for once, move forward.
do you mean my comments were pointless? sorry if so.
> I also asked that others comment on this issue as well so don't just
> have two opinions. That hasn't happened yet.
yes, let's wait for more opinions.
> > "it" here is "ISSUSER-like temporary placeholder" solution, right?
> To keep on kauth(9) terminology, that is *not* "ISSUSER-like", but
> rather kauth_authorize_foo() calls.
i meant it's ISSUSER-like just in the sense that it's a temporary placeholder.
let me restate my opinions.
- handling securelevel via kauth is fine.
- in kauth world, securelevel should be implemented as listeners for
- if you want fine-grained control ("multiple knobs"),
it should be another listener(s). splitting securelevel is not a right way.
(you might want to coalesce listeners to default one for performance.
it's fine, but it doesn't change the logical structure, i think.)
- i'm not sure if securelevel is a good target to shoot now.
it's better to tackle suser() first.