Re: PATCH: peersid capability support

[Joshua Brindle <method@manicmethod.com>]

Stephen Smalley wrote:
> 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@tresys.com 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.
>   

Equivalence between every module? I don't see how this would possibly 
work in practice, how would audit2allow know what caps to include when 
it creates a new module? How would support for new caps come from a 
policy upgrade when there are local modules present that don't have them?



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