Re: [patch 2/2] Peersid capability support

[Joshua Brindle <method@manicmethod.com>]

Stephen Smalley wrote:
> On Wed, 2007-11-07 at 15:50 -0500, Joshua Brindle wrote:
>   
>> plain text document attachment (peersid_cap.patch)
>> Peersid capability support, keys the peersid capability on the peer object class.
>>     
>
> I'm uneasy about this approach, as it is similar to what we originally
> tried for secmark - tying the compat_net setting to the presence of the
> packet class in the policy, except there we were doing it at policy load
> time.  As it turned out, we had policies that defined the packet class
> well before we had usable rule sets for them, and even if we had covered
> that angle, presence/absence of a class definition doesn't reflect
> policy writer intent (e.g. does he want legacy network controls or
> secmark irrespective of whether he is using a modern policy), so we went
> back to manual setting of compat_net.
>
>   

With the unknown perms support can we basically require that defining a 
class means using it? Unfortunately that means we have to defer adding 
newer classes until the support is put in for the older ones.

> What if the base.conf / policy.conf itself had an explicit declaration
> of the capabilities to be enabled?  We can certainly do sanity checks
> too (e.g. if they ask for this capability but haven't defined the
> requisite class, that's a bug in their policy), but that would let
> someone use the latest policy flask definitions but still select what
> they want to enable/disable explicitly, and no unwitting enabling of
> capabilities by side effect.
>
>   

I would also hate to add more base-only options as eventually I think 
we'd like to get rid of  (at least I would) the base altogether and get 
everything into modules, assuming we get the necessary infrastructure in 
place like kernel class discovery.

I'm not adverse to putting capabilities in the policy though, I just 
don't know if thats the only place where it is appropriate to put 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.