Stephen Smalley wrote:
On Thu, 2007-12-06 at 16:23 -0500, Joshua Brindle wrote:
Stephen Smalley wrote:
On Thu, 2007-12-06 at 11:44 -0500, Joshua Brindle wrote:
Stephen Smalley wrote:
Overall, I have to wonder if we are really buying anything via
per-module capability declaration vs. per-policy. The only reason you
tried to make it per-module was you were trying to drop distinctions
between base and non-base, right? But maybe we shouldn't be so
concerned with having a notion of a base module even if we reduce the
differences between what is supported by base vs. non-base
At first that was my reason but after talking it seems like doing it in
base is bad for the same reason that allowing a single module to turn on
a cap is. Why should base be able to turn on the cap if all the other
modules aren't written wrt the cap?
Upgrade of base usually reflects a full policy update, whereas inserting
a random module does not. And if base doesn't work (e.g. doesn't have
the capabilities it requires), then the system likely won't boot or
function at all (modulo legacy rules). I'm more comfortable with
letting base dictate the policy capabilities than other modules.
I am not comfortable with base changing anything about other modules. If
base can turn on capabilities without regard to the modules being
installed then everything built as modules that uses network controls
(or whatever future caps affect) suddenly don't work. I also don't want
to just punt on this decision for now because we don't know the answer,
we'll have to answer it eventually if we successfully get rid of the
base vs. module distinction.
If you aren't comfortable with base enabling capabilities without regard
to the other modules, then you aren't comfortable with the union
proposal anymore. So where does that leave you? With Chris on the
intersection proposal? See my comments there.
That is correct, as a result of you guys convincing me that union as
wrong I also believe putting it in base is wrong. The intersection is
the most compelling to me so far, though it seems like no optimum
solutions exist. I'm wondering if caps are the right solution to the
problem at all..
When does base get updated? When we are updating the entire policy,
typically all in a single libsemanage transaction. At what time do we
want to gain new capabilities? When we are updating the entire policy.
What capabilities do we want audit2allow-generated modules to inherit?
The same as the base system policy.
Yes base gets updated when the entire policy is updated, that one is
fair. as for audit2allow, base system policy != base module.
Where would the policycap statements come from if we kept them
per-module? From the policy_module definition provided by...the base
policy against which the module was built.
policy_module is just a macro from refpolicy, it has nothing to do with
base vs. non-base.
Maybe I'm missing something but it all leads back to the base module
providing the definitions, and if we're moving toward link-time
expansion of interfaces, then they'll end up coming from the base module
at link time anyway then.
Well, interfaces aren't necessarily in base. corenetwork is in base by
necessity now because of limitations on the module language. When that
limitation goes away I'd hope corenetwork would not be in base. That
would leave base as basically object class definitions, which makes its
ability to determine the capabilities questionable since it won't even
have rules (the rules which determine with caps are actually in use)
As for base vs. non-base, I'm all for making non-base modules more
functional, but that doesn't mean that semodule -b is going away
(compatibility of user interfaces and all that) or that we can't retain
a notion of a special base module that defines certain policy-wide
properties (a useful thing, even if the rest of the policy is fully
modularized).
Chris says there will always be the concept of a base in refpolicy, that
is fine with me. What I want to get rid of us the code treating base
specially and this would be yet-another way we treat it specially that
would have to be removed later (and we'd have to figure out how to
handle it then anyway, we are just punting the decision for now.. boo )
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with
the words "unsubscribe selinux" without quotes as the message.
