tech-kern archive

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

Re: secmodel_register(9) API

On Mon,  5 Dec 2011 03:19:23 +0000 (UTC), 
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.

Yep, saw that. Thanks.

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.

I sent a wrong old patch. See the secmodel_extensions:is_securelevel_above() function.

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
can you explain your criteria?


kauth(9) hides all the credentials behind "opaque" types, like kauth_cred_t. What is found behind is implementation-defined. Nowadays, uid_t/euid_t model is used.

secmodel_suser() expresses the policy bound to the super-user (ie. all operations that root - everything with uid 0 - is allowed to perform). That is: _just_ super-user. Nothing more.

=== curtain ===

curtain is a security measure that restricts the information accessible to any given user to the objects it currently "owns", ownership being known by the credentials attached to this object. Note that the "credentials" is still an opaque "type" here, and should not assume whether it represents an uid, label, or role.

However, secmodel_suser(9) _does_ make that assumption (credentials being UIDs), which contradicts the original intent of curtain.

For convenience, curtain may allow specific credentials to gather information for all objects, and not just the ones a user owns. When suser is loaded, thes credentials are those corresponding to root. But in the event that suser is replaced by another secmodel, modifying secmodel_extensions to cope with this new shiny secmodel is pretty trivial. While with the "old" design, you would have to reimplement curtain in this secmodel first, by copy/pasting it from suser.

=== user_set_cpu_affinity ===

This is pretty much the same as curtain. That feature allows user to control CPU affinity, regardless of their credential implementation. The user_set_cpu_affinity just says that any user has the right modify the affinity of the LWPs it owns.

All these sysctl have requirements on the alteration of their value when securelevel is above 0. Basically, you can remove rights to users, but cannot grant them more any more (unless you did so before raising level). That implies that securelevel is present, but alas, anyone is free not to use/load securelevel module. Hence, we have to provide a way to cope with this: here comes secmodel_eval(9).

Hope this made everything more clear. Don't hesitate if you have more questions.

Jean-Yves Migeon

Home | Main Index | Thread Index | Old Index