On Thu, 2007-12-06 at 15:02 -0500, Stephen Smalley wrote:
> On Thu, 2007-12-06 at 13:34 -0500, Christopher J. PeBenito wrote:
> > On Thu, 2007-12-06 at 11:48 -0500, Stephen Smalley wrote:
> > > On Thu, 2007-12-06 at 10:44 -0500, Christopher J. PeBenito wrote:
> > > > On Wed, 2007-12-05 at 16:41 -0500, Todd Miller wrote:
> > > > > Stephen Smalley wrote:
> > > > > > Yes, I'm still against (automatic, default) unioning of the
> > > > > > capabilities by the linker - that is clearly not a safe default.
> > > > > > semodule could possibly override that behavior based on an option
> > > > > > though, at which point the %post scriptlet in the policy rpm could
> > > > > > use that option if we wanted to force it w/o user intervention.
> > > > >
> > > > > What do we want the behavior of this option to be? As I see it we
> > > > > have two choices:
> > > > >
> > > > > 1) perform a union instead of requiring equivalence
> > > > >
> > > > > 2) add capabilities as needed to binary modules in the store.
> > > > >
> > > > > The advantage of 2) is that it would only need to happen once which
> > > > > makes it more "upgrade friendly".
> > > >
> > > > I now think that the answer is intersection (with a little change to the
> > > > userland design).
> > > >
> > > > 1. capabilities are enabled only if the policy _fully_ supports them
> > > > union: no
> > > > intersection: yes
> > > > equivalence: yes
> > > >
> > > > 2. modules with mismatched capability sets can be inserted (eg upgrade)
> > > > union: yes; all defined caps are enabled
> > > > intersection: yes; common caps are enabled (warnings on disabled caps)
> > > > equivalence: no
> > > >
> > > > 3. policy writing implication
> > > > union: only modules that care about the cap will enable it
> > > > intersection: all modules must enable it
> > > > equivalence: all modules must enable it
> > > >
> > > > Going along with this, I think the way caps are handled should be
> > > > augmented. There should be conditional blocks, which allows relevant
> > > > policy to be affected
> > > >
> > > > ifcap(fine_grained_netlink) {
> > > > allow foo_t self:netlink_selinux_socket create;
> > > > } else {
> > > > allow foo_t self:netlink_socket create;
> > > > }
> > > >
> > > > I don't imagine this will be a common case, so most of the time we
> > > > wouldn't be using the conditional part of the support. For the peersid
> > > > example, we'd just add the rules and turn on the capability in
> > > > refpolicy. If a 3rd party module doesn't have the capability, the
> > > > kernel checks turn off and we have a few extra rules, which doesn't
> > > > hurt.
> > >
> > > Supposing that we took the above approach, some questions remain:
> > > - Where do the policycap statements originate for each module? By
> > > explicit declaration within each individual module? By uniform
> > > inheritance from refpolicy for all modules via policy_module()? By
> > > selective inheritance from individual refpolicy interfaces as needed,
> > > e.g. picking up policycap network_peer_controls; from the refpolicy
> > > network interfaces?
> >
> > Most likely via policy_module().
>
> I don't see what we gain then from per-module capability sets vs.
> defining it once in base and using that - the per-module approach is
> more fragile and doesn't actually reflect the capabilities required by
> the module, just the capabilities known to the policy against which it
> was built. And if policy_module gets turned into a link-time expanded
> interface, it becomes the same thing as inheriting from base.
>
> > > - If we go with the first or the last options, what about modules that
> > > don't actually care about a given capability - e.g. a module that
> > > doesn't have any networking rules wouldn't pick up the
> > > network_peer_controls capability from a refpolicy interface nor would
> > > its author think to declare it, so the module would appear to not
> > > support the capability. We don't seem to have a way of distinguishing
> > > dont-care from disable.
> >
> > I would put forth that the idea of dont-care doesn't really exist. If
> > you know about it but don't care about it, whats the difference between
> > dont-care and enable? If you don't know about it, then you can't say
> > that you don't care, and making dont-care the default would be bad,
> > since that would tend towards enabling new caps, causing the problems
> > we're trying to avoid :)
>
> I was only asking in the case where the module author specifies the
> capabilities explicitly or picks them via specific refpolicy interfaces
> like the networking interfaces, as it seemed easy to envision that
> leading to incomplete specification due to certain capabilities not
> being relevant. In the case where we pick up from policy_module or
> inherit from the base, it wouldn't be an issue, as they would fully
> define the state for everything they know.
>
> > > - The intersection behavior assumes that new policy will always preserve
> > > compatibility with policies that lack newer capabilities by keeping
> > > around legacy rules in some form, even if conditional. Is that a
> > > reasonable restriction for policy maintenance?
> >
> > I suppose it depends on how people (ab)use the caps. Josh made the case
> > to me that some people might want to intentionally disable controls
> > because they don't care about them or they want to try to boost
> > performance (e.g. networking pieces).
> >
> > Beyond that, I suppose it depends on how far back we want to go. For
> > example, RHEL4 is ancient by SELinux standards, but its going to be
> > around for a long time, so we have some distro_rhel4 blocks in
> > refpolicy. Eventually RHEL4 will be out of support, and then we can
> > drop them. I don't have a problem with it, but I also don't know how
> > many and how fast we're going to gain caps.
> >
> > > How do we ultimately
> > > drop dead rules altogether?
> >
> > Move them out of conditionals? Or are you suggesting having a way to
> > make warnings into errors after a reasonable amount of upgrade time?
>
> Yes, having a way of dropping the legacy rules out of the policy and
> requiring that certain capabilities be present (not automatically
> disabled via intersection) in order for the update to succeed. So that
> refpolicy can periodically dump legacy rules out and proceed with the
> assumption that certain capabilities are guaranteed to be present.
>
> > > Will all such capabilities be amenable to
> > > such compatibility behavior?
> >
> > Good question. I forgot my crystal ball at home :( Will things beyond
> > permission changes be supported under this?
>
> Don't know either, just something to consider.
>
> > > - I'd tend to expect most users to not notice the disabled caps warning
> > > upon upgrade, so that means we'd have a fair number of users continuing
> > > to operate under the legacy controls indefinitely even after upgrading
> > > their policies to ones that would have supported the new capabilities.
> > > Is that reasonable?
> >
> > Perhaps Dan or some of the other RH people can comment on this, but I
> > was under the impression that unusual console messages tend to be
> > noticed.
>
> It would just be libsepol output upon running semodule from %post on a
> yum upgrade. Quite easily lost among the rest of the noise of a yum
> upgrade from one release to another.
I suppose the kernel could also emit a message when loading a policy
with fewer capabilities than the prior policy, but still, I'm a little
dubious about relying on that to get users to take any action.
--
Stephen Smalley
National Security Agency
--
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.
