Re: [PATCH 7/7] secid reconciliation-v03: Enforcement for SELinux

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

Venkat Yekkirala wrote:
>>>>While I don't see any explicit mention of it in the documentation or
>>>>your comments, I assume we would want a flow_out check for 
>>>>NetLabel here
>>>>as well?
>>>
>>> 
>>>I don't believe we do. By this time, the packet is or 
>>
>>should already be
>>
>>>carrying the CIPSO/NetLabel option which should already be 
>>
>>the right one
>>
>>>(derived from the socket or flow as appropriate), but you 
>>
>>would want to
>>
>>>audit the code to make sure. IOW, the label option in the 
>>
>>IP header should
>>
>>>already be reflecting the secmark on the skb. But again, 
>>
>>you may want to
>>
>>>audit the code to make sure.
>>
>>In the case above I am concerned about the situation where the
>>skb->secmark == 0 and there is a IPv4 option (i.e. it is NetLabel
>>labeled) on the packet.

It's unfortunate that you cut out the code in your reply.

> Where we initialize the secmark should be immaterial from the NetLabel
> point of view. The kernel mechanisms should assure that the IP option
> reflects the MLS portion (or a label in the SA range) elsewhere.

Yep, I agree.

> In any
> case, a flow_out check doesn't make sense since the IP option and the
> secmark are (should be) mirroring each other and there's in actuality
> no "flow out" happening; they are just 2 representation of the SAME label.

Well, reading the code I see that if the secmark is zero upon entering
the function you query the XFRM subsystem to query the SA label and set
the secmark accordingly, yes?  All I am suggesting is that we do the
same thing for NetLabel.

Please see the mail I sent earlier with the code in it to address James'
concerns, this has a proposed solution for the flow_out case.

> Your suggestion as to adjusting the secmark per the IP option might be
> fraught with danger since, in certain cases, I believe, you just return
> the incoming options in the outgoing packet (timewait, openreq, etc.?),
> and there's no assurance that that's a valid enough option that you can
> retrieve a sid with it, correct?

As implemented in the code snippets I sent earlier the generated
NetLabel SID would reflect the secmark as determined by the IPsec label
and the IP options on the packet.  I believe this is what we want as the
resulting secmark value would directly represent the security attributes
of the packet.

-- 
paul moore
linux security @ hp