> So:
quoted text
> 
> > it's better to write listeners to check "securelevel" variable
> > for appropriate scopes, rather than having a single scope gathering
> > these random operations.
> > ie. i think securelevel should be turned into listener(s), not a scope.
> 
> IIUC, you mean to create several listeners that would each be in charge
> of making a decision for different "knobs", and defer requests
> otherwise?
> 
> If so, to what scope should these listeners be attached to?

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;
	}

quoted text
> > btw, it seems that you are proposing two different things in this mail.
> > 	- adapt securelevel to kauth world
> > 	- make securelevel a bitmap
> > 
> > i'm not sure if the latter is a good idea.
> > why bother to complicate securelevel, while you can just have
> > another listener to implement finer-grained access control?
> 
> It's not really "make securelevel a bitmap", but introduce a new
> variable that'll store the information kauth(9) will refer to when a
> request is made.
> 
> If now there's an "int securelevel" kernel code can check before
> granting access to, say, open the raw memory device; if we are splitting
> the knobs, we need a place to store the values for all these knobs.
> 
> Where else would information such as "modifications to the packet
> filter rules are disallowed" will be kept? (granted, that's got to
> do more with the security model used; let's assume "traditional Unix"
> for the context ;)
> 
> ...or am I not understanding you correctly?

see the above example.
"int securelevel" should be enough to implement securelevel as a listener.

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.

YAMAMOTO Takashi