On Fri, 2007-11-30 at 09:38 -0500, Joshua Brindle wrote: > Stephen Smalley wrote: > > On Thu, 2007-11-29 at 18:24 -0500, Joshua Brindle wrote: > > > >> Stephen Smalley wrote: > >> > >>> On Thu, 2007-11-29 at 14:27 -0500, tmiller@xxxxxxxxxx wrote: > >>> > >>> > >>>> This is a reworking of the peersid capability patch Joshua sent out > >>>> a few weeks ago. This version requires added explicit declaration of > >>>> capabilities in the policy. > >>>> > >>>> I've used the same strings that Paul's kernel diff used (there is > >>>> currently just a single capability). > >>>> > >>>> Note that capability declarations are not limited to base.conf / > >>>> policy.conf as we would like to eventually get rid of the base vs. module > >>>> distinction. > >>>> > >>>> > >>> Taking the union of the capabilities at link time seems worrisome to me. > >>> I'd be more inclined to require equivalence or take the intersection. > >>> > >>> > >>> > >> I strongly disagree. My vision was to be able to add a capability to the > >> policy by inserting a policy module that enables the capability (and has > >> associated policy). Making them an intersection or equivalence would > >> require one to update every single module just to add a capability (or > >> at least update the base if it is considered authoritative, which I was > >> also trying to avoid). > >> > > > > Joshua - think about it. Let's say I write a policy module based on the > > new peer checks, and my base module was written in terms of the old > > network checks. Now I link them together and get a policy that tells > > the kernel to use the new peer checks. Voila! My base policy breaks > > horrendously. > > > That is why I said the module being inserted would have the associated > policy. That seems to violate modularity/encapsulation. > I don't believe policyrep is going to have a concept of base so > we'd just be delaying the inevitable by restricting it to base now. It isn't a base vs. non-base issue. You can certainly have every module declare the capabilities it requires/expects. But taking the union is unsafe. Module foo doesn't know what the rest of the modules on the system expect or what rules they contain. Requiring equivalence is the safest approach. -- 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.
