Venkat Yekkirala wrote:

quoted

quoted

quoted

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

quoted

carrying the CIPSO/NetLabel option which should already be 

the right one

quoted

(derived from the socket or flow as appropriate), but you 

would want to

quoted

audit the code to make sure. IOW, the label option in the 

IP header should

quoted

already be reflecting the secmark on the skb. But again, 

you may want to

quoted

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