I don't understand what the problems are. In any case, this does not
violate anything. The language used to describe the supposed issues
with the new API is ridiculous.
What the new API allows is interaction between secmodels that are
built by people who are not part of NetBSD and don't want their
secmodel to become part of NetBSD but do want to take advantage of
features in secmodels provided by NetBSD.
Personally I don't care if this stays or not. All I can say is that I
have not seen a single argument worthy of consideration against it and
I would strongly recommend to leave it in.
Please don't CC me any further emails about this.
Elad
On Mon, Dec 5, 2011 at 1:33 PM, Jean-Yves Migeon
jeanyves.mig...@free.fr wrote:
(I am CC'ing Elad, as we both worked on it)
On Mon, 5 Dec 2011 16:22:33 +0100, Christoph Badura wrote:
That is by design. The idea behind splitting the decision process into
separate secmodels is to decouple the models and the decision making.
I can't see how -- secmodels are responsible for the decision making, so we
cannot decouple these easily.
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)...
That is intentional. Every time a new control is added all the secmodels
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).
Uh, sysctls do not belong to a secmodel. Whatever that is supposed to
mean.
Okay, let's put that differently: enabling/disabling a security feature like
curtain has nothing to do with secmodel_suser(9) itself. Curtain is a
feature that says: only owners of an object can query information about
it. So securelevel, suser, or bsd44... do not intervene in this process,
_except_ when you are root (pragmatism always add exceptions). That's it.
But the am I root? evaluation is more an exception than the rule (a weak
dependency). Turning curtain into a full fledged suser extension because
there is one slight divergence is problematic.
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.
This so-called API is a complete perversion of the kauth system. It
pulls the implementation details that the other secmodel is supposed
to hide and abstract away out into unrelated code again.
That's weird: what you describe here is the situation before this patch:
curtain and usermount were planted inside a secmodel they do not belong to
(secmodel_suser is about making decisions about root's rights, not ordinary
users).
This is adding
back all the interdependencies and knowledge about internals that kauth
is supposed to abstract and hide.
That's precisely what we are trying to avoid.
Knowledge about internals were the de facto standard before: if you wanted
to have an extension which implements a policy (users can only see state of
their objects) with an explicit dependency on implementation internals (is
that user privileged?), you had to put the extension inside the secmodel(9)
that implements the privileged evaluation.
The problem with this is that it doesn't scale. You are just arbitrarily
moving the code around that needs to be modified when new actions need to
be authorized.
No; we are allowing secmodel(9) to expose evaluation logic (a question) to
other secmodels, so they can query for a result that depends on their
internals.
The ultimate decision remains in the hand of the one making the query.
Asking a question in the form of do you allow that action to happen? is a
plain miss-use of this API; that should indeed be done by kauth(9).
It doesn't scale in the case when a new secmodel is introduced that
needs to have a say on this action.
The evaluation API is not designed to accept hooks, nor shall it be. It's
meant for a secmodel(9) to query safely (as is: no symbol/run-time
dependency on code being loaded) a secmodel for internal state (are you in
this state?) or internal logic (given these credentials, do you consider
them privileged or not?).
And it doesn't scale when bsd44
or suser is replace with a secmodel that defines privilege other than
is-root.
It should not. If there's another secmodel that appears later that redefines
privilege, that secmodel will have to expose evaluation callback and let
the curtain extension handle it.
For the is-root case, the evaluation will return an error if the
secmodel_suser(9) is not loaded. The curtain extension will then make the
decision concerning this, and fallback to its default case.
IAW not even does this not scale from 1 to 2. It doesn't even scale from
A to B.
Args and command are
