Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: secmodel_register(9) API

On Tue, 29 Nov 2011 11:13:01 +0000 (UTC), 
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:

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

Home | Main Index | Thread Index | Old Index