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

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

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

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

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

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.