RE: [PATCH 0/3] secid reconciliation-v01: Repost patchset with up dates
> 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? You got it. > > >> 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. That was a test for you :) > > > 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. Nope. That won't work for forwarded traffic. > I guess I need to see where the > xfrm[4|6]_policy_check() hooks are called from in the stack to better > understand ... You are on the right path here. - 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
Re: [PATCH 0/3] secid reconciliation-v01: Repost patchset with up dates
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
RE: [PATCH 0/3] secid reconciliation-v01: Repost patchset with up dates
> 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. > 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 :) We just need to get out of the mindset of viewing netlabel separately once we are past the reconciliation point. - 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
Re: [PATCH 0/3] secid reconciliation-v01: Repost patchset with up dates
James Morris wrote: > On Fri, 25 Aug 2006, Venkat Yekkirala wrote: >>>I like these changes, but wondering why you haven't supplied >>>code for the >>>outbound case ? >> >>The code for the outbound is still in the works. I hope to have it >>out in a week or so. > > Ok, I guess we should wait until then before incorporating the patches > (also, for Paul Moore to return and comment re. CIPSO). 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 and not the socket's label. 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. Like James, I'd also like to see the outbound side too. -- 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
RE: [PATCH 0/3] secid reconciliation-v01: Repost patchset with up dates
On Fri, 25 Aug 2006, Venkat Yekkirala wrote: > > I like these changes, but wondering why you haven't supplied > > code for the > > outbound case ? > > > > > > - James > > The code for the outbound is still in the works. I hope to have it > out in a week or so. Ok, I guess we should wait until then before incorporating the patches (also, for Paul Moore to return and comment re. CIPSO). - James -- James Morris <[EMAIL PROTECTED]> - 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
RE: [PATCH 0/3] secid reconciliation-v01: Repost patchset with up dates
> I like these changes, but wondering why you haven't supplied > code for the > outbound case ? > > > - James The code for the outbound is still in the works. I hope to have it out in a week or so. - 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
