From: YAMAMOTO Takashi (yamtmwd.biglobe.ne.jp)
Date: Sat Mar 25 2006 - 13:40:33 CST

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

> > i meant, eg. you can write an listener like the following and
> > register it to KAUTH_SCOPE_PROCESS scope, to replace securelevel checks
> > in sys_ptrace() and process_checkioperm().
> >
> > int
> > securelevel_process_listener_callback(....)
> > {
> > switch () {
> > case KAUTH_PROCESS_CANPTRACE:
> > case KAUTH_PROCESS_CANIO:
> > if (p == initproc && securelevel > -1) {
> > return KAUTH_RESULT_DENY;
> > }
> > }
> > return KAUTH_RESULT_DEFER;
> > }
>
> But you lose the ability to set custom knobs, as was already previously
> discussed... (because you have only one securelevel variable, and not
> where to store indication on which knobs are raised or not)

sorry, i think i missed the previous discussion.
can you give me a pointer to it? was it in this thread?
i'm not sure what's "custom knobs".

> Another consideration is that the number of listeners can directly
> affect the performance of an authorization request for a given scope.
> That said, we might want to add the "KAUTH_PROCESS_CANIO", for example,
> to the default listener for the process scope, instead of creating a new
> listener for securelevel-related operations.

maybe.
because coalescing listeners is merely an optimization,
it's better to postpone it until we measure performance impacts, i guess.

> > for the case of "filter rule modification", you can write another listener for
> > the scope which covers the operation.
> > yes, you need to create an appropriate scope, i think.
>
> Yes, a network scope.. and, as a side-note, I'm pretty sure we could use
> kauth(9) to do what pfil(9) is doing now, but this is a rather critical
> part that'll have to go under some serious performance tests if we ever
> think in that direction. :)

i'm pretty sure it's an abuse of the interface. :)

YAMAMOTO Takashi

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]