Re: SELinux Networking Enhancements

[Paul Moore <paul.moore@hp.com>]

Venkat Yekkirala wrote:
>>Ok, I think I'm beginning to get it (I'm a bit slow lately 
>>:\).. You are
>>defining a condition where iptables will call into the security server
> 
> Correct.
> 
>>using the packet label (either secmark or external, how do 
>>you decide?)
> 
> Both.

If we use secfilter to do access controls for both internal and external
labeling using the same class/permission I think we might have a problem similar
to what we ran into with the secid reconciliation approach: internal labeling
mechanisms (SECMARK) assign labels based on packet properties while the external
mechanisms (XFRM, NetLabel) assign labels based on the sending socket's context.

>>With these 
>>filter rules if
>>they aren't in place the policy becomes less restrictive (right?)..
> 
> We could also be restrictive or leave it up to the policy entirely.

More explanation please.

I don't understand how secfilter could be made restrictive in the same manner as
SECMARK.  How can you know if the netfilter rules are missing?  What would you
compare the loaded netfilter rules against?  I guess you could compare them
against something maintained inside the SELinux security server, but I think you
would need to put some rather invasive hooks into the netfilter management code
to ensure that the required secfilter netfilter rules are not subverted.

-- 
paul moore
linux security @ hp

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