YAMAMOTO Takashi wrote:

quoted text
> 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)

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.

quoted text
> 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. :)

-e.

-- 
Elad Efrat