Re: secmodel_register(9) API

[Jean-Yves Migeon <jeanyves.migeon%free.fr@localhost>]

On Tue, 29 Nov 2011 11:13:01 +0000 (UTC), yamt%mwd.biglobe.ne.jp@localhost 
wrote:
> > Reviews before merge welcome. If nobody raises his voice, I'll 
> > proceed
> > to commit it at the end of the week.
>
> i hesitate to complicate kauth related locking rules, given that it's
> already broken.  have you checked if it's safe for these listeners 
> sleep?
> (rw_enter can sleep.)

I would say yes; the current patch uses secmodel_eval(9) for "curtain" 
mode, and its only applicable to kauth(9) listeners for:
- socket "cansee" KAUTH_REQ_NETWORK_SOCKET_CANSEE
- process KAUTH_REQ_PROCESS_CANSEE_{ARGS,ENTRY,OPENFILES}.

All these listeners should have process context, so may sleep.

Perhaps I can put pserialize(9) to good use there. Updates to 
secmodel(9) are not expected to happen that much often... You want me to 
have a look? That would make it lock-free even from softints.

> i thought the purpose of these secmodels are localize the knowledge 
> of
> suser, securelevel, etc.  secmodel_eval seems contradict.

Exactly, that's the point. See below.

> if anyone outside of the securelevel secmodel really needs to query
> securelevel, doesn't it mean the variable just ought to be exported
> in a normal way?

"normal way" is quite difficult to define in the context of modules 
dynamic loading.

Consider user_set_cpu_affinity: if the sysctl cannot be set any more 
when securelevel is above or below a threshold, checking for the 
securelevel variable means that this sysctl has a strong dependency on 
securelevel (or else, it won't be able to get the variable). So if you 
want to still provide this sysctl but without having securelevel loaded, 
you are screwed: it's part of this module.

There are orthogonal requirements there: secmodels define a security 
policy, but there are situations where one would like to allow certain 
operations (different from default policy), but without putting a strong 
requirement on a specific secmodel(9). having to load securelevel just 
to provide this sysctl is non sense.

Same goes for suser (which controls rights for superuser): 
curtain/usermounts are not really a suser policy, rather an extension 
from it. Hence the secmodel_extensions stuff.

--
Jean-Yves Migeon
jeanyves.migeon%free.fr@localhost