tech-security archive


Re: secmodel_register(9) API

On Tue, Nov 29, 2011 at 02:51:38AM +0100, Jean-Yves Migeon wrote:
> A few weeks back I tried adding a sysctl knob to allow users to control
> their CPU affinity. However, while implementing checks to restrict usage
> of this sysctl, I hit a limitation regarding secmodel(9): the current
> design cannot allow a secmodel to query the state/properties of other
> secmodels.

separate secmodels is to decouple the models and the decision making.

> So, when one wants to create sysctls that can only be changed when
> securelevel is below a certain level, you end up adding more hooks to
> secmodel_securelevel(9)...

need to be examined if they need updating.

> which is problematic, because the sysctl does
> not necessarily belong to this secmodel (consider curtain and suser, as
> an exemple).


> error = secmodel_eval("org.netbsd.secmodel.suser", "is-root",
>     cred, &isroot, NULL);

> This one asks the suser module if the user cred is assumed to be
> root when evaluated by suser module. If the module is present, it
> will respond. If absent, the call will return an error.

pulls the implementation details that the other secmodel is supposed
to hide and abstract away out into unrelated code again.  This is adding
back all the interdependencies and knowledge about internals that kauth
is supposed to abstract and hide.

be authorized.

needs to have a say on this action.  And it doesn't scale when bsd44

A to B.

> Args and command are arbitrarily defined; it's up to the secmodel(9)
> to explain what it expects.

function in a security context.

IMNHO this idea alone is reason enough to back this out and have it redesigned.

> Typical example is securelevel testing: when someone wants to know
> whether securelevel is raised above a certain level or not, the
> caller has to request this property to the secmodel_securelevel(9)
> module. Given that securelevel module may be absent from system's
> context (thus making access to the global "securelevel" variable
> impossible or unsafe), this API can cope with this absence and
> return an error.

wants to know whether securelevel is raised: secmodel_securelevel.

these credentials authorized to perform the action detailled in the
remaining argument?".

"nay" for the cases that it is interested in.


> wrote:
> 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
> if you want to still provide this sysctl but without having
> securelevel loaded, you are screwed: it's part of this module.

There is no need for the code that manages user_set_cpu_affinity to have
first place.

allowed to modify the variable bound to the sysctl name.

This is precisly the reason that the indirection level that kauth provides
has been introduced.

You are starting from false premises.

On Mon, Dec 05, 2011 at 11:01:50AM +0100, Jean-Yves Migeon wrote:
> 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.

One can also take a different view.  Putting the uid/euid/group data
directly into the struct kauth_cred can be seen as a performance
optimisation because the bsd44 model is standard and called so frequently.

Just as well the uid/euid/gid stuff could have been put into secmodel_bsd44
private specificdata attached to kauth_cred.

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

Eh?  What does the internal implementation details of secmodel_suser
have to do with curtain?

If curtain doesn't want to know about the internals of kauth_cred it
should do it's own user tracking and attach that data to kauth_cred's
fine for gaols.

> For convenience, curtain may allow specific credentials to gather
> information for all objects, and not just the ones a user owns.

Distinguishing credentials and giving some of them higher privileges
its own user tracking through kauth_cred's specificdata.

> When
> suser is loaded, thes credentials are those corresponding to root.

considers privileged for which operations.

If curtain wants to be truly independent of other secmodel's internal then
it needs to track itself which credentials it considers privileged.

If it isn't independ then there is no reason to invent an "API" on the
kauth level to mess with the other secmodels' internals.

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

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

This is not the right approach to think about this.

What you have is a requirement that changing sysctl variable that control
that behaviour (curtain and user_set_cpu_affinity) requires privilege.

How that privilege is granted and checked depends on the secmodels that
are currently active.

change these sysctl variables.

If securelevel is available that secmodel may restrict the operation
based on the setting of the securelevel variable.

Maybe it counts the demons in the users nose.


It is intentional that there is no strong coupling between secmodels.
and kauth_authorize is a much better interface for checking for privilege
than the proposed secmodel_eval.


Home | Main Index | Thread Index | Old Index