Re: secmodel_register(9) API

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

On Mon,  5 Dec 2011 03:19:23 +0000 (UTC), yamt%mwd.biglobe.ne.jp@localhost 
wrote:
> > 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.

http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/secmodel/extensions/secmodel_extensions.c?annotate=1.1&only_with_tag=MAIN

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

Sure.

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
jeanyves.migeon%free.fr@localhost