Re: Labeled networking packets

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

Venkat Yekkirala wrote:
>>>Ignoring the secmark issue for a moment ...
>>
>>there is no secmark issue, secmark isn't for labeling.
>  
> It IS FOR LABELING as far as MLS is concerned.

Perhaps we are just overloading the term "labeling".  It kinda sounds
like the non-MLS folks want to be able to distinguish between "remote
labeling", i.e. SA or NetLabel, and "local labeling", i.e. secmark.  I
realize that there are certain users who don't care to make that
distinction because they can put a certain level of trust in the
physical network configuration.  However, considering the flexibility of
SELinux in general I think any built-in assumption is going to upset
someone.  I think the best idea is to arrive at some sort of policy
abstraction which would allow either of the behaviors listed above.

For handling incoming packets this may mean that we keep all of the
packet labeling mechanisms separate, allowing each to have it's own
permission check.

For dealing with getpeercon() issues perhaps we only allow "remote
labeled" contexts to be reported by default, but if policy allows (yes,
we would need some sort of new allow rule or policy construct) the
"locally labeled" context could be used as a fallback.

I know it's not ideal for any one scenario, but I think it may be
flexibile enough to deal with all of them.

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