Re: [PATCH 0/3] secid reconciliation-v01: Repost patchset with up dates

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

Venkat Yekkirala wrote:
>>My main concern with these patches is that moving the 
>>NetLabel check out
>>of selinux_socket_sock_rcv_skb() and into 
>>selinux_skb_policy_check() (as
>>it is currently written) would force us to compare a packet's NetLabel
>>with either the IPsec label or the secmark label
> 
> Yes you would do these checks (while using a netlabel based off of the
> secmark at that point) to enforce flow control and when they succeed,
> you will copy netlabel into secmark.
> 
>>and not the socket's
>>label.
> 
> The socket Vs. secmark check that happens later in rcv_skb will in fact be
> looking at the cipso label that is by then a part of the secmark context.

So what you envison is that when an MLS label is found on a packet using
NetLabel the MLS label from the packet is attached to the secmark
context (replacing the existing MLS label, if any) and the resulting
context would be checked for a "flow_in" permission, yes?

Assuming the permission is granted the packet's secmark is replaced with
the updated context.  This updated secmark context would then be used in
sock_rcv_skb() to make an access decision, yes?

>> The ability to make access decisions based on the process
>>consuming the data and the data itself it one of the nicer 
>>qualities of
>>NetLabel in my opinion.
> 
> This nicer quality ends up being preserved as explained above :)

It wasn't clear to me from your patch or the "master plan" what you
intended to do with the NetLabel context.  I thought the "/* See if
CIPSO can flow in thru the current secmark here */" comment in your
patch was rather cryptic.

> We just need to get out of the mindset of viewing netlabel separately
> once we are past the reconciliation point.

Agreed.  Although to be honest, I think the NetLabel context can be
reconciled with the secmark and XFRM contexts just as easily using the
existing sock_rcv_skb() hook.  I guess I need to see where the
xfrm[4|6]_policy_check() hooks are called from in the stack to better
understand ...

-- 
paul moore
linux security @ hp