Re: Labeled networking packets

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

Joshua Brindle wrote:
> On Fri, 2006-09-22 at 10:47 -0400, Paul Moore wrote:
> 
>><snip>
>>
>>>This scheme has a new label that is negotiated by racoon and is used
>>
>>as
>>
>>>the subject label returned by getpeercon(), it is different from
>>
>>what we
>>
>>>are already doing. The rest would basically be the same, there would
>>
>>be
>>
>>>no reconciliation. The only thing I'm not sure of here is the
>>>interaction of the label negotiated by racoon and a cipso label. It
>>>almost seems like we need to disallow using them at the same time, I
>>>suspect people might not like this limitation though.
>>>
>>
>>Since all of the remote network labeling mechanisms, SA and NetLabel
>>labeling, are relatively new to Linux I think it's going to be hard to
>>say for certain how users will end up using them.  While similar in
>>that
>>both mechanisms allow remote packet labeling, they acomplish very
>>different goals so I think it is reasonable to expect users who need
>>remote network labeling to run both SA and NetLabel labels on the same
>>system.
> 
> so we need to define the limitations now before people start using them
> in unexpected ways.

No argument here.

>>Ignoring the secmark issue for a moment ...
> 
> there is no secmark issue, secmark isn't for labeling.

That's why I said to ignore it ;)

>>Resolving a SA label and a NetLabel label right now isn't too
>>difficult.
>> Currently we do two separate checks for each labeling mechanism.  If
>>we
>>wanted to consolidate the checks into one we could do as Stephen
>>originally suggested and check to make sure that the NetLabel label
>>falls within the range of the SA label and that the socket was allowed
>>to receive packets from the resulting combination (TE from the SA
>>context, MLS label from NetLabel).  This becomes a bit more
>>complicated
>>once NetLabel starts labeling packets with a full context but the
>>basics
>>would still apply I believe.
> 
> Right, that is all well and good as long as netlabel is MLS only. I
> don't think we should be making assumptions like checking that the
> netlabel is within the range of the SA label if there is ever an
> expectation of doing full contexts in netlabel.

That is reasonable.  I don't want to distract from the discussion going
on right now with a discussion about the pros/cons of NetLabel sending
full contexts, but I think it would be a good idea to stop thinking of
NetLabel just a CIPSO/MLS and instead think of it as a full context like
the IPsec/SA labeling mechanism.  With this in mind, perhaps we just
stick to having two separate access checks, one for SA labeling and one
for NetLabel labeling.  In a way it punts on the problem and pushes into
policy, but that may be the best option as policy is far more flexibile
than code.  After all, isn't this one of the main selling points of
TE/FLASK/SELinux?

> Further, I don't think we've fully understood each other yet. I don't
> want the SA label used for anything except permission checks. The SA
> label is the 'local socket' label for an association and isn't
> interesting at all. The label returned with getpeercon() should be a
> domain label that is negotiated by racoon.

I don't want to speak for the SA labeling, that's Venkat's baby.
However, I can speak for NetLabel and I think so far NetLabel does what
you want, if not perhaps we can agree on a change.

Currently NetLabel labels packets using the context of the socket
sending the packets, there is no transition.  In normal usage the
socket's context is derived from the domain, however, "SELinux aware"
applications using recent kernels have the ability to specify the
context of the socket and as a result the NetLabel context.

On the receive side, when using NetLabel the context returned by
getpeercon() is currently a combination of the receiving socket's
context and the NetLabel's MLS label.  For example:

 * receiving process's context: user_u:role_r:app_t
 * receiving socket's context:  user_u:role_r:app_t
 * NetLabel context:            ??????:??????:?????:s7:c8.c12
 * getpeercon() returns:        user_u:role_r:app_t:s7:c8.c12

This is done so that the returned context is suitable for a call to
setexeccon().  In the future once NetLabel supports full contexts then
getpeercon() will return the NetLabel context.

I believe this is what you are looking for, at least for the
"non-SELinux aware" set of applications.  Yes?

> I think we've mostly agreed that getpeercon() should be returning
> domains, now the question is how. Assuming the racoon thing works we can
> get one from ipsec, and netlabel obviously has a labeling scheme. If
> both are in use we have an ambiguous label which I think is an error, I
> don't think trying to reconcile both labels using a type_transition is
> the right way to go (domain_a->domain_b == new_domain?), I'm not even
> sure what the ramifications are there. 

Good point.  We could always have getpeercon() error out if both SA and
NetLabel labels are present.  It may not be ideal, but it's safe.

> Do you have a scenario where one might want both labeling schemes at the
> same time? Note that if you need netlabel (legacy os on the other side)
> and you also want ipsec for integrity then the isakmp negotiation would
> not include a context and netlabel would be used.

Honestly, I can't think of why you would want to use both SA and
NetLabel labeling on the same connection - that's just stupid :)
However, I can see users wanting to have then active on the same host,
imagine a SELinux box talking to both legacy Trusted OSs and other
SELinux boxes - this is the case I was talking about earlier.

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