Re: Labeled networking packets

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

Venkat Yekkirala wrote:
>>>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.
> 
> This we have attempted to do via transitions.

Yep, I got that, I think everybody got that.  However, I think this
discussion has demonstrated that not everyone believes the transitions
as they are implemented in the current secid reconciliation patches is
the right approach.  Maybe it's an issue of not understanding, maybe I'm
just confused ... (maybe I need to stop responding to email and do some
some real work <g>).

Personally, I don't have any strong feelings for any particular
implementation.  My main concern is that we arrive at a solution that
works for both the generic SELinux TE users as well as the legacy MLS users.

>>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.
> 
> But how would you then make sure a secret cipso didn't arrive thru a
> TopSecret SA?

First, I think this is what I would call a "smack the user" problem.
However, if somebody really wanted to use both SA and NetLabel labeling
on the same connection I think the important thing is that we control
the flow of data to the socket, not the SA, as the socket is the
endpoint of the communcation channel from a users point of view.  With
this in mind, having access checks against the SA/socket and the
NetLabel/socket would ensure that the user doesn't receive any data they
shouldn't - even if the remote labels don't reconcile with each other.

>>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.
> 
> That would mean you would have separate policies.

What's wrong with that?  We have that already and I suspect we will for
the foreseeable future.

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