[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), yamt%mwd.biglobe.ne.jp@localhost
Perhaps I can put pserialize(9) to good use there. Updates to
secmodel(9) are not expected to happen that much often... You want
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
securelevel (or else, it won't be able to get the variable). So if
want to still provide this sysctl but without having securelevel
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
operations (different from default policy), but without putting a
requirement on a specific secmodel(9). having to load securelevel
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
Same goes for suser (which controls rights for superuser):
curtain/usermounts are not really a suser policy, rather an
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
Main Index |
Thread Index |