[redhat-lspp] Re: Networking policy patch

[Joshua Brindle]

Venkat Yekkirala wrote:
>>
>>> +mlsconstrain association { recvfrom }
>>> +	((( l1 dom l2 ) and ( l1 domby h2 )) or
>>> +	 (( t1 == mlsnetreadtoclr ) and ( h1 dom l2 )) or
>>> +	 ( t1 == mlsnetread ) or
>>> +	 ( t2 == unlabeled_t ));
>>>       
>> Don't we want network_t instead of unlabeled_t?
>>     
>
> Actually, the above only applies to the compat_net case
> and there unlabeled_t is just fine.
>
>   
why isn't compat_net using the same default sid for associations?
> So, there are different MLS constraints (and policy) for
> the compat_net case as opposed to the new secmark controls.
>
>   
there shouldn't be, compat_net and secmark use different object classes 
(except association) and the behaviors should not conflict
> I guess you are planning to have one policy for compat_net
> and another for secmark?
>
>   
I'll let Chris comment here but I don't think that is ideal.
>>> +mlsconstrain association { sendto }
>>> +	(( l1 eq l2 ) and ( h1 eq h2 ));
>>>       
>> or (t2 == network_t) ?
>>     
>
> No. Not in the secmark case.
>   
If there are no ipsec associations at all it will default to 
network_t:SystemHigh-SystemLow so this would only allow domains that are 
SystemHigh-SystemLow to send plaintext? Not sure this is what we want

> <snip>
>>> +constrain association sendto
>>> +	( u1 == u2 and r1 == r2 and t1 == t2 );
>>>       
>> I talked with Joshua and we determined that there is a case were we
>> don't want this constraint (looking forward to policy management
>> server's use of labeled networking), so I've dropped it.
>>     
>
> The above constraint is necessary for the kernel portions of SELinux
> to work properly. In fact I was going to originally implement it in the
> kernel and when Darrel made me aware of the constraint framework and the
> benefits with avc caching, etc., I decided to use it.
>
>   
This completely disallows the use of setsockcreatecon() with labeled 
networking, not good.