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 - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
