Re: secmodel_register(9) API

[yamt%mwd.biglobe.ne.jp@localhost (YAMAMOTO Takashi)]

hi,

> 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.

if you are interested in, please.
see XXX in kauth_authorize_action_internal.

> 
>> 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.

i don't understand the example.
your diff doesn't seem to do secmodel_eval("securelevel") at all.

> 
> 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.

i don't understand what would be a suser policy and what would be an extension.
can you explain your criteria?

YAMAMOTO Takashi

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