* RE: [PATCH v4 1/2] NetLabel: secid reconciliation support @ 2006-10-04 16:59 ` Venkat Yekkirala 0 siblings, 0 replies; 33+ messages in thread From: Venkat Yekkirala @ 2006-10-04 16:59 UTC (permalink / raw) To: paul.moore, netdev, selinux; +Cc: eparis, jmorris, sds, Venkat Yekkirala > @@ -3714,19 +3714,34 @@ static int selinux_skb_flow_in(struct sk > if (skb->dev == &loopback_dev) > return 1; > > + if (skb->secmark) > + loc_sid = skb->secmark; > + else > + loc_sid = SECINITSID_NETMSG; > + > err = selinux_xfrm_decode_session(skb, &xfrm_sid, 0); > BUG_ON(err); > - > - err = avc_has_perm(xfrm_sid, skb->secmark? : SECINITSID_NETMSG, > - SECCLASS_PACKET, > - PACKET__FLOW_IN, NULL); > + err = selinux_netlbl_skb_sid(skb, > + xfrm_sid ? xfrm_sid : loc_sid, > + &nlbl_sid); > if (err) > goto out; > > - if (xfrm_sid) > - skb->secmark = xfrm_sid; > + if (nlbl_sid) > + ext_sid = nlbl_sid; > + else > + ext_sid = xfrm_sid; There's a problem here in that it would require 2 different policies depending on whether one is using netlabel or xfrm. Specifically, in the absence of matching iptables contexts (secmark), the skb here will get: - 0 (xfrm case) - network_t (netlabel) This has implications for getpeercon() where it would - fail with ENOPROTOOPT (xfrm case) - returns network_t (netlabel) I would still argue that the nature of the domain being carried by the packet is still unlabeled_t as implied by the null secmark. While I view secmark/point as specifying BOTH a flow control point and a default domain (incidentally using the same label more because of implementation constrainst), I view network_t as purely a flow control point. But I also realize there can be equally forceful arguments for what this patch does. What does the community think? We need to resolve it one way or the other unless the above differences in behavior are desired or somehow accounted for in policy and apps. > + > + err = avc_has_perm(ext_sid, > + loc_sid, > + SECCLASS_PACKET, > + PACKET__FLOW_IN, > + NULL); > + if (err) > + goto out; > > - /* See if NetLabel can flow in thru the current secmark here */ > + if (ext_sid) > + skb->secmark = ext_sid; > > out: > return err ? 0 : 1; > -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. ^ permalink raw reply [flat|nested] 33+ messages in thread
* RE: [PATCH v4 1/2] NetLabel: secid reconciliation support @ 2006-10-04 16:59 ` Venkat Yekkirala 0 siblings, 0 replies; 33+ messages in thread From: Venkat Yekkirala @ 2006-10-04 16:59 UTC (permalink / raw) To: paul.moore, netdev, selinux; +Cc: eparis, jmorris, sds, Venkat Yekkirala > @@ -3714,19 +3714,34 @@ static int selinux_skb_flow_in(struct sk > if (skb->dev == &loopback_dev) > return 1; > > + if (skb->secmark) > + loc_sid = skb->secmark; > + else > + loc_sid = SECINITSID_NETMSG; > + > err = selinux_xfrm_decode_session(skb, &xfrm_sid, 0); > BUG_ON(err); > - > - err = avc_has_perm(xfrm_sid, skb->secmark? : SECINITSID_NETMSG, > - SECCLASS_PACKET, > - PACKET__FLOW_IN, NULL); > + err = selinux_netlbl_skb_sid(skb, > + xfrm_sid ? xfrm_sid : loc_sid, > + &nlbl_sid); > if (err) > goto out; > > - if (xfrm_sid) > - skb->secmark = xfrm_sid; > + if (nlbl_sid) > + ext_sid = nlbl_sid; > + else > + ext_sid = xfrm_sid; There's a problem here in that it would require 2 different policies depending on whether one is using netlabel or xfrm. Specifically, in the absence of matching iptables contexts (secmark), the skb here will get: - 0 (xfrm case) - network_t (netlabel) This has implications for getpeercon() where it would - fail with ENOPROTOOPT (xfrm case) - returns network_t (netlabel) I would still argue that the nature of the domain being carried by the packet is still unlabeled_t as implied by the null secmark. While I view secmark/point as specifying BOTH a flow control point and a default domain (incidentally using the same label more because of implementation constrainst), I view network_t as purely a flow control point. But I also realize there can be equally forceful arguments for what this patch does. What does the community think? We need to resolve it one way or the other unless the above differences in behavior are desired or somehow accounted for in policy and apps. > + > + err = avc_has_perm(ext_sid, > + loc_sid, > + SECCLASS_PACKET, > + PACKET__FLOW_IN, > + NULL); > + if (err) > + goto out; > > - /* See if NetLabel can flow in thru the current secmark here */ > + if (ext_sid) > + skb->secmark = ext_sid; > > out: > return err ? 0 : 1; > ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH v4 1/2] NetLabel: secid reconciliation support 2006-10-04 16:59 ` Venkat Yekkirala @ 2006-10-04 18:45 ` Paul Moore -1 siblings, 0 replies; 33+ messages in thread From: Paul Moore @ 2006-10-04 18:45 UTC (permalink / raw) To: Venkat Yekkirala; +Cc: netdev, selinux, eparis, jmorris, sds Venkat Yekkirala wrote: >>@@ -3714,19 +3714,34 @@ static int selinux_skb_flow_in(struct sk >> if (skb->dev == &loopback_dev) >> return 1; >> >>+ if (skb->secmark) >>+ loc_sid = skb->secmark; >>+ else >>+ loc_sid = SECINITSID_NETMSG; >>+ >> err = selinux_xfrm_decode_session(skb, &xfrm_sid, 0); >> BUG_ON(err); >>- >>- err = avc_has_perm(xfrm_sid, skb->secmark? : SECINITSID_NETMSG, >>- SECCLASS_PACKET, >>- PACKET__FLOW_IN, NULL); >>+ err = selinux_netlbl_skb_sid(skb, >>+ xfrm_sid ? xfrm_sid : loc_sid, >>+ &nlbl_sid); >> if (err) >> goto out; >> >>- if (xfrm_sid) >>- skb->secmark = xfrm_sid; >>+ if (nlbl_sid) >>+ ext_sid = nlbl_sid; >>+ else >>+ ext_sid = xfrm_sid; > > > There's a problem here in that it would require 2 different policies > depending on whether one is using netlabel or xfrm. Specifically, in > the absence of matching iptables contexts (secmark), the skb here > will get: > > - 0 (xfrm case) > - network_t (netlabel) Perhaps I'm reading it the wrong way, but I didn't quite follow your comment. In an effort to bring some clarity to all of this here are all of the possibile combinations that I can see using the code above (feel free to correct me if I made a mistake): * SECMARK, XFRM, NetLabel present xfrm_sid = <full context from xfrm> loc_sid = <full context from secmark> nlbl_sid = <xfrm_sid te ctx, netlabel mls ctx> ext_sid = nlbl_sid final skb->secmark = avc_ok : ext_sid ? unchanged * SECMARK, XFRM present xfrm_sid = <full context from xfrm> loc_sid = <full context from secmark> nlbl_sid = SECSID_NULL/0 ext_sid = xfrm_sid final skb->secmark = avc_ok : ext_sid ? unchanged * SECMARK, NetLabel present xfrm_sid = SECSID_NULL/0 loc_sid = <full context from secmark> nlbl_sid = <secmark te ctx, netlabel mls ctx> ext_sid = nlbl_sid final skb->secmark = avc_ok : ext_sid ? unchanged * XFRM, NetLabel present xfrm_sid = <full context from xfrm> loc_sid = SECINITSID_NETMSG nlbl_sid = <xfrm_sid te ctx, netlabel mls ctx> ext_sid = nlbl_sid final skb->secmark = avc_ok : ext_sid ? unchanged * XFRM present xfrm_sid = <full context from xfrm> loc_sid = SECINITSID_NETMSG nlbl_sid = SECSID_NULL/0 ext_sid = xfrm_sid final skb->secmark = avc_ok : ext_sid ? unchanged * NetLabel present xfrm_sid = SECSID_NULL/0 loc_sid = SECSID_NULL/0 nlbl_sid = <SECINITSID_NETMSG te ctx, netlabel mls ctx> ext_sid = nlbl_sid final skb->secmark = avc_ok : ext_sid ? unchanged * Nothing xfrm_sid = SECSID_NULL/0 loc_sid = SECSID_NULL/0 nlbl_sid = SECSID_NULL/0 ext_sid = xfrm_sid final skb->secmark = avc_ok : ext_sid ? unchanged > This has implications for getpeercon() where it would > > - fail with ENOPROTOOPT (xfrm case) > - returns network_t (netlabel) > > I would still argue that the nature of the domain being carried by > the packet is still unlabeled_t as implied by the null secmark. While > I view secmark/point as specifying BOTH a flow control point and a > default domain (incidentally using the same label more because of > implementation constrainst), I view network_t as purely a flow control > point. > > But I also realize there can be equally forceful arguments for what this > patch does. I know the two of us have talked about this before on the mail lists, but I don't believe anyone else has ever made a comment in this regard. I tend to feel rather strongly that when using just NetLabel on a connection you shouldn't see an "unlabeled_t" type as I feel that the connotation associated with this type is misleading, even though from a TE point of view there may be an argument made that it is appropriate. > What does the community think? We need to resolve it one way or the > other unless the above differences in behavior are desired or somehow > accounted for in policy and apps. I agree - I'd like to hear what others (namely Stephen Smalley, James Morris and all of the Tresys folks <past and present>) have to say on this issue. -- paul moore linux security @ hp -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH v4 1/2] NetLabel: secid reconciliation support @ 2006-10-04 18:45 ` Paul Moore 0 siblings, 0 replies; 33+ messages in thread From: Paul Moore @ 2006-10-04 18:45 UTC (permalink / raw) To: Venkat Yekkirala; +Cc: netdev, selinux, eparis, jmorris, sds Venkat Yekkirala wrote: >>@@ -3714,19 +3714,34 @@ static int selinux_skb_flow_in(struct sk >> if (skb->dev == &loopback_dev) >> return 1; >> >>+ if (skb->secmark) >>+ loc_sid = skb->secmark; >>+ else >>+ loc_sid = SECINITSID_NETMSG; >>+ >> err = selinux_xfrm_decode_session(skb, &xfrm_sid, 0); >> BUG_ON(err); >>- >>- err = avc_has_perm(xfrm_sid, skb->secmark? : SECINITSID_NETMSG, >>- SECCLASS_PACKET, >>- PACKET__FLOW_IN, NULL); >>+ err = selinux_netlbl_skb_sid(skb, >>+ xfrm_sid ? xfrm_sid : loc_sid, >>+ &nlbl_sid); >> if (err) >> goto out; >> >>- if (xfrm_sid) >>- skb->secmark = xfrm_sid; >>+ if (nlbl_sid) >>+ ext_sid = nlbl_sid; >>+ else >>+ ext_sid = xfrm_sid; > > > There's a problem here in that it would require 2 different policies > depending on whether one is using netlabel or xfrm. Specifically, in > the absence of matching iptables contexts (secmark), the skb here > will get: > > - 0 (xfrm case) > - network_t (netlabel) Perhaps I'm reading it the wrong way, but I didn't quite follow your comment. In an effort to bring some clarity to all of this here are all of the possibile combinations that I can see using the code above (feel free to correct me if I made a mistake): * SECMARK, XFRM, NetLabel present xfrm_sid = <full context from xfrm> loc_sid = <full context from secmark> nlbl_sid = <xfrm_sid te ctx, netlabel mls ctx> ext_sid = nlbl_sid final skb->secmark = avc_ok : ext_sid ? unchanged * SECMARK, XFRM present xfrm_sid = <full context from xfrm> loc_sid = <full context from secmark> nlbl_sid = SECSID_NULL/0 ext_sid = xfrm_sid final skb->secmark = avc_ok : ext_sid ? unchanged * SECMARK, NetLabel present xfrm_sid = SECSID_NULL/0 loc_sid = <full context from secmark> nlbl_sid = <secmark te ctx, netlabel mls ctx> ext_sid = nlbl_sid final skb->secmark = avc_ok : ext_sid ? unchanged * XFRM, NetLabel present xfrm_sid = <full context from xfrm> loc_sid = SECINITSID_NETMSG nlbl_sid = <xfrm_sid te ctx, netlabel mls ctx> ext_sid = nlbl_sid final skb->secmark = avc_ok : ext_sid ? unchanged * XFRM present xfrm_sid = <full context from xfrm> loc_sid = SECINITSID_NETMSG nlbl_sid = SECSID_NULL/0 ext_sid = xfrm_sid final skb->secmark = avc_ok : ext_sid ? unchanged * NetLabel present xfrm_sid = SECSID_NULL/0 loc_sid = SECSID_NULL/0 nlbl_sid = <SECINITSID_NETMSG te ctx, netlabel mls ctx> ext_sid = nlbl_sid final skb->secmark = avc_ok : ext_sid ? unchanged * Nothing xfrm_sid = SECSID_NULL/0 loc_sid = SECSID_NULL/0 nlbl_sid = SECSID_NULL/0 ext_sid = xfrm_sid final skb->secmark = avc_ok : ext_sid ? unchanged > This has implications for getpeercon() where it would > > - fail with ENOPROTOOPT (xfrm case) > - returns network_t (netlabel) > > I would still argue that the nature of the domain being carried by > the packet is still unlabeled_t as implied by the null secmark. While > I view secmark/point as specifying BOTH a flow control point and a > default domain (incidentally using the same label more because of > implementation constrainst), I view network_t as purely a flow control > point. > > But I also realize there can be equally forceful arguments for what this > patch does. I know the two of us have talked about this before on the mail lists, but I don't believe anyone else has ever made a comment in this regard. I tend to feel rather strongly that when using just NetLabel on a connection you shouldn't see an "unlabeled_t" type as I feel that the connotation associated with this type is misleading, even though from a TE point of view there may be an argument made that it is appropriate. > What does the community think? We need to resolve it one way or the > other unless the above differences in behavior are desired or somehow > accounted for in policy and apps. I agree - I'd like to hear what others (namely Stephen Smalley, James Morris and all of the Tresys folks <past and present>) have to say on this issue. -- paul moore linux security @ hp ^ permalink raw reply [flat|nested] 33+ messages in thread
* RE: [PATCH v4 1/2] NetLabel: secid reconciliation support @ 2006-10-04 19:53 ` Venkat Yekkirala 0 siblings, 0 replies; 33+ messages in thread From: Venkat Yekkirala @ 2006-10-04 19:53 UTC (permalink / raw) To: Stephen Smalley, Paul Moore Cc: Venkat Yekkirala, netdev, selinux, eparis, jmorris > On Wed, 2006-10-04 at 15:27 -0400, Paul Moore wrote: > > Venkat Yekkirala wrote: > > >> * XFRM present > > >> > > >> xfrm_sid = <full context from xfrm> > > >> loc_sid = SECINITSID_NETMSG > > >> nlbl_sid = SECSID_NULL/0 > > >> ext_sid = xfrm_sid > > >> final skb->secmark = avc_ok : ext_sid ? unchanged As noted subsequently, I actually meant to refer to the below instead of the XFRM case above: * Nothing xfrm_sid = SECSID_NULL/0 loc_sid = SECSID_NULL/0 nlbl_sid = SECSID_NULL/0 ext_sid = xfrm_sid final skb->secmark = avc_ok : ext_sid ? unchanged > > >> > > >> * NetLabel present > > >> > > >> xfrm_sid = SECSID_NULL/0 > > >> loc_sid = SECSID_NULL/0 > > >> nlbl_sid = <SECINITSID_NETMSG te ctx, netlabel mls ctx> > > >> ext_sid = nlbl_sid > > >> final skb->secmark = avc_ok : ext_sid ? unchanged > > > > > > I was referring to the differences in what getpeercon would > > > return in the above 2 scenarios. > > > > > > In the xfrm case: final skb->secmark would be 0 > resulting in getpeercon > > > to return EPROTONOOPT > > > > In the "XFRM present" case above if the access is allowed (avc_ok is > > true) then the final skb->secmark value is going to be set > to the value > > of ext_sid which is the xfrm_sid. Any calls made to > getpeercon() would > > return success with the context matching xfrm_sid. > > > > I have a hunch we are still on different pages here ... > > > > > In the NetLabel case: final skb->secmark would be > network_t resulting in > > > getpeercon to return network_t > > > > Yep, and I understand you would like to see it as > unlabeled_t. I think > > we both have valid arguments for either case and we are > just waiting to > > hear from others. > > I don't understand the argument for network_t, and it seems to violate > our goals of 1) having consistent policy regardless of > network labeling > mechanism, and 2) having getpeercon() always return a subject > label that > can be used as a basis for avc_has_perm() and setexeccon() calls. But in the case where there's no domain info, but a cipso label, getpeercon will fail (EPROTONOOPT). Do I rememember that Paul was trying to use a special SID to use as a base sid in this case? -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. ^ permalink raw reply [flat|nested] 33+ messages in thread
* RE: [PATCH v4 1/2] NetLabel: secid reconciliation support @ 2006-10-04 19:53 ` Venkat Yekkirala 0 siblings, 0 replies; 33+ messages in thread From: Venkat Yekkirala @ 2006-10-04 19:53 UTC (permalink / raw) To: Stephen Smalley, Paul Moore Cc: Venkat Yekkirala, netdev, selinux, eparis, jmorris > On Wed, 2006-10-04 at 15:27 -0400, Paul Moore wrote: > > Venkat Yekkirala wrote: > > >> * XFRM present > > >> > > >> xfrm_sid = <full context from xfrm> > > >> loc_sid = SECINITSID_NETMSG > > >> nlbl_sid = SECSID_NULL/0 > > >> ext_sid = xfrm_sid > > >> final skb->secmark = avc_ok : ext_sid ? unchanged As noted subsequently, I actually meant to refer to the below instead of the XFRM case above: * Nothing xfrm_sid = SECSID_NULL/0 loc_sid = SECSID_NULL/0 nlbl_sid = SECSID_NULL/0 ext_sid = xfrm_sid final skb->secmark = avc_ok : ext_sid ? unchanged > > >> > > >> * NetLabel present > > >> > > >> xfrm_sid = SECSID_NULL/0 > > >> loc_sid = SECSID_NULL/0 > > >> nlbl_sid = <SECINITSID_NETMSG te ctx, netlabel mls ctx> > > >> ext_sid = nlbl_sid > > >> final skb->secmark = avc_ok : ext_sid ? unchanged > > > > > > I was referring to the differences in what getpeercon would > > > return in the above 2 scenarios. > > > > > > In the xfrm case: final skb->secmark would be 0 > resulting in getpeercon > > > to return EPROTONOOPT > > > > In the "XFRM present" case above if the access is allowed (avc_ok is > > true) then the final skb->secmark value is going to be set > to the value > > of ext_sid which is the xfrm_sid. Any calls made to > getpeercon() would > > return success with the context matching xfrm_sid. > > > > I have a hunch we are still on different pages here ... > > > > > In the NetLabel case: final skb->secmark would be > network_t resulting in > > > getpeercon to return network_t > > > > Yep, and I understand you would like to see it as > unlabeled_t. I think > > we both have valid arguments for either case and we are > just waiting to > > hear from others. > > I don't understand the argument for network_t, and it seems to violate > our goals of 1) having consistent policy regardless of > network labeling > mechanism, and 2) having getpeercon() always return a subject > label that > can be used as a basis for avc_has_perm() and setexeccon() calls. But in the case where there's no domain info, but a cipso label, getpeercon will fail (EPROTONOOPT). Do I rememember that Paul was trying to use a special SID to use as a base sid in this case? ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH v4 1/2] NetLabel: secid reconciliation support 2006-10-04 19:53 ` Venkat Yekkirala @ 2006-10-04 20:08 ` Paul Moore -1 siblings, 0 replies; 33+ messages in thread From: Paul Moore @ 2006-10-04 20:08 UTC (permalink / raw) To: Venkat Yekkirala; +Cc: Stephen Smalley, netdev, selinux, eparis, jmorris Venkat Yekkirala wrote: >>On Wed, 2006-10-04 at 15:27 -0400, Paul Moore wrote: >> >>>Venkat Yekkirala wrote: >>> >>>>>* XFRM present >>>>> >>>>> xfrm_sid = <full context from xfrm> >>>>> loc_sid = SECINITSID_NETMSG >>>>> nlbl_sid = SECSID_NULL/0 >>>>> ext_sid = xfrm_sid >>>>> final skb->secmark = avc_ok : ext_sid ? unchanged > > > As noted subsequently, I actually meant to refer to the below > instead of the XFRM case above: > > * Nothing > > xfrm_sid = SECSID_NULL/0 > loc_sid = SECSID_NULL/0 > nlbl_sid = SECSID_NULL/0 > ext_sid = xfrm_sid > final skb->secmark = avc_ok : ext_sid ? unchanged > > >>>>>* NetLabel present >>>>> >>>>> xfrm_sid = SECSID_NULL/0 >>>>> loc_sid = SECSID_NULL/0 >>>>> nlbl_sid = <SECINITSID_NETMSG te ctx, netlabel mls ctx> >>>>> ext_sid = nlbl_sid >>>>> final skb->secmark = avc_ok : ext_sid ? unchanged >>>> >>>>I was referring to the differences in what getpeercon would >>>>return in the above 2 scenarios. >>>> >>>>In the xfrm case: final skb->secmark would be 0 >> >>resulting in getpeercon >> >>>>to return EPROTONOOPT >>> >>>In the "XFRM present" case above if the access is allowed (avc_ok is >>>true) then the final skb->secmark value is going to be set >> >>to the value >> >>>of ext_sid which is the xfrm_sid. Any calls made to >> >>getpeercon() would >> >>>return success with the context matching xfrm_sid. >>> >>>I have a hunch we are still on different pages here ... >>> >>> >>>>In the NetLabel case: final skb->secmark would be >> >>network_t resulting in >> >>>>getpeercon to return network_t >>> >>>Yep, and I understand you would like to see it as >> >>unlabeled_t. I think >> >>>we both have valid arguments for either case and we are >> >>just waiting to >> >>>hear from others. >> >>I don't understand the argument for network_t, and it seems to violate >>our goals of 1) having consistent policy regardless of >>network labeling >>mechanism, and 2) having getpeercon() always return a subject >>label that >>can be used as a basis for avc_has_perm() and setexeccon() calls. > > But in the case where there's no domain info, but a cipso label, > getpeercon will fail (EPROTONOOPT). Do I rememember that Paul was > trying to use a special SID to use as a base sid in this case? [I'm replying to both Stephen and Venkat here as the email is coming in faster than I can type :)] In the current non-secid world, if the connection is NetLabel labeled, the sock_rcv_skb() LSM hook uses SECINITSID_NETMSG as the base_sid and the recvfrom permission to control access. Calls to getpeercon() on a NetLabel connection use the socket's SID as the base_sid and the network traffic's MLS label. In the latest secid world, when there is only NetLabel labeling present on the connection SECINITSID_NETMSG is used as the base_sid for the final skb->secmark value as determined by the flow_in() LSM hook with the MLS label being set to match the NetLabel on the packet. Calls to getpeercon() will use the secmark value of the packet when the connection is establishes (in *all* cases) so getpeercon() in the NetLabel only case will succeed and return the value determined above. -- paul moore linux security @ hp -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH v4 1/2] NetLabel: secid reconciliation support @ 2006-10-04 20:08 ` Paul Moore 0 siblings, 0 replies; 33+ messages in thread From: Paul Moore @ 2006-10-04 20:08 UTC (permalink / raw) To: Venkat Yekkirala; +Cc: Stephen Smalley, netdev, selinux, eparis, jmorris Venkat Yekkirala wrote: >>On Wed, 2006-10-04 at 15:27 -0400, Paul Moore wrote: >> >>>Venkat Yekkirala wrote: >>> >>>>>* XFRM present >>>>> >>>>> xfrm_sid = <full context from xfrm> >>>>> loc_sid = SECINITSID_NETMSG >>>>> nlbl_sid = SECSID_NULL/0 >>>>> ext_sid = xfrm_sid >>>>> final skb->secmark = avc_ok : ext_sid ? unchanged > > > As noted subsequently, I actually meant to refer to the below > instead of the XFRM case above: > > * Nothing > > xfrm_sid = SECSID_NULL/0 > loc_sid = SECSID_NULL/0 > nlbl_sid = SECSID_NULL/0 > ext_sid = xfrm_sid > final skb->secmark = avc_ok : ext_sid ? unchanged > > >>>>>* NetLabel present >>>>> >>>>> xfrm_sid = SECSID_NULL/0 >>>>> loc_sid = SECSID_NULL/0 >>>>> nlbl_sid = <SECINITSID_NETMSG te ctx, netlabel mls ctx> >>>>> ext_sid = nlbl_sid >>>>> final skb->secmark = avc_ok : ext_sid ? unchanged >>>> >>>>I was referring to the differences in what getpeercon would >>>>return in the above 2 scenarios. >>>> >>>>In the xfrm case: final skb->secmark would be 0 >> >>resulting in getpeercon >> >>>>to return EPROTONOOPT >>> >>>In the "XFRM present" case above if the access is allowed (avc_ok is >>>true) then the final skb->secmark value is going to be set >> >>to the value >> >>>of ext_sid which is the xfrm_sid. Any calls made to >> >>getpeercon() would >> >>>return success with the context matching xfrm_sid. >>> >>>I have a hunch we are still on different pages here ... >>> >>> >>>>In the NetLabel case: final skb->secmark would be >> >>network_t resulting in >> >>>>getpeercon to return network_t >>> >>>Yep, and I understand you would like to see it as >> >>unlabeled_t. I think >> >>>we both have valid arguments for either case and we are >> >>just waiting to >> >>>hear from others. >> >>I don't understand the argument for network_t, and it seems to violate >>our goals of 1) having consistent policy regardless of >>network labeling >>mechanism, and 2) having getpeercon() always return a subject >>label that >>can be used as a basis for avc_has_perm() and setexeccon() calls. > > But in the case where there's no domain info, but a cipso label, > getpeercon will fail (EPROTONOOPT). Do I rememember that Paul was > trying to use a special SID to use as a base sid in this case? [I'm replying to both Stephen and Venkat here as the email is coming in faster than I can type :)] In the current non-secid world, if the connection is NetLabel labeled, the sock_rcv_skb() LSM hook uses SECINITSID_NETMSG as the base_sid and the recvfrom permission to control access. Calls to getpeercon() on a NetLabel connection use the socket's SID as the base_sid and the network traffic's MLS label. In the latest secid world, when there is only NetLabel labeling present on the connection SECINITSID_NETMSG is used as the base_sid for the final skb->secmark value as determined by the flow_in() LSM hook with the MLS label being set to match the NetLabel on the packet. Calls to getpeercon() will use the secmark value of the packet when the connection is establishes (in *all* cases) so getpeercon() in the NetLabel only case will succeed and return the value determined above. -- paul moore linux security @ hp ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH v4 1/2] NetLabel: secid reconciliation support 2006-10-04 20:08 ` Paul Moore (?) @ 2006-10-04 20:27 ` Stephen Smalley 2006-10-04 20:52 ` Paul Moore -1 siblings, 1 reply; 33+ messages in thread From: Stephen Smalley @ 2006-10-04 20:27 UTC (permalink / raw) To: Paul Moore; +Cc: Venkat Yekkirala, selinux, eparis, jmorris (also dropping netdev, as this isn't relevant there) On Wed, 2006-10-04 at 16:08 -0400, Paul Moore wrote: > Venkat Yekkirala wrote: > >>On Wed, 2006-10-04 at 15:27 -0400, Paul Moore wrote: > >> > >>>Venkat Yekkirala wrote: > >>> > >>>>>* XFRM present > >>>>> > >>>>> xfrm_sid = <full context from xfrm> > >>>>> loc_sid = SECINITSID_NETMSG > >>>>> nlbl_sid = SECSID_NULL/0 > >>>>> ext_sid = xfrm_sid > >>>>> final skb->secmark = avc_ok : ext_sid ? unchanged > > > > > > As noted subsequently, I actually meant to refer to the below > > instead of the XFRM case above: > > > > * Nothing > > > > xfrm_sid = SECSID_NULL/0 > > loc_sid = SECSID_NULL/0 > > nlbl_sid = SECSID_NULL/0 > > ext_sid = xfrm_sid > > final skb->secmark = avc_ok : ext_sid ? unchanged > > > > > >>>>>* NetLabel present > >>>>> > >>>>> xfrm_sid = SECSID_NULL/0 > >>>>> loc_sid = SECSID_NULL/0 > >>>>> nlbl_sid = <SECINITSID_NETMSG te ctx, netlabel mls ctx> > >>>>> ext_sid = nlbl_sid > >>>>> final skb->secmark = avc_ok : ext_sid ? unchanged > >>>> > >>>>I was referring to the differences in what getpeercon would > >>>>return in the above 2 scenarios. > >>>> > >>>>In the xfrm case: final skb->secmark would be 0 > >> > >>resulting in getpeercon > >> > >>>>to return EPROTONOOPT > >>> > >>>In the "XFRM present" case above if the access is allowed (avc_ok is > >>>true) then the final skb->secmark value is going to be set > >> > >>to the value > >> > >>>of ext_sid which is the xfrm_sid. Any calls made to > >> > >>getpeercon() would > >> > >>>return success with the context matching xfrm_sid. > >>> > >>>I have a hunch we are still on different pages here ... > >>> > >>> > >>>>In the NetLabel case: final skb->secmark would be > >> > >>network_t resulting in > >> > >>>>getpeercon to return network_t > >>> > >>>Yep, and I understand you would like to see it as > >> > >>unlabeled_t. I think > >> > >>>we both have valid arguments for either case and we are > >> > >>just waiting to > >> > >>>hear from others. > >> > >>I don't understand the argument for network_t, and it seems to violate > >>our goals of 1) having consistent policy regardless of > >>network labeling > >>mechanism, and 2) having getpeercon() always return a subject > >>label that > >>can be used as a basis for avc_has_perm() and setexeccon() calls. > > > > But in the case where there's no domain info, but a cipso label, > > getpeercon will fail (EPROTONOOPT). Do I rememember that Paul was > > trying to use a special SID to use as a base sid in this case? > > [I'm replying to both Stephen and Venkat here as the email is coming in > faster than I can type :)] > > In the current non-secid world, if the connection is NetLabel labeled, > the sock_rcv_skb() LSM hook uses SECINITSID_NETMSG as the base_sid and > the recvfrom permission to control access. Calls to getpeercon() on a > NetLabel connection use the socket's SID as the base_sid and the network > traffic's MLS label. So if xinetd calls getpeercon(), it gets a context with type "xinetd_t" (from its own socket) and the MLS label of the client? > In the latest secid world, when there is only NetLabel labeling present > on the connection SECINITSID_NETMSG is used as the base_sid for the > final skb->secmark value as determined by the flow_in() LSM hook with > the MLS label being set to match the NetLabel on the packet. Calls to > getpeercon() will use the secmark value of the packet when the > connection is establishes (in *all* cases) so getpeercon() in the > NetLabel only case will succeed and return the value determined above. So if xinetd calls getpeercon(), it gets a context with type "network_t" (if using netmsg) or "unlabeled_t" (if using unlabeled) and the MLS label of the client? So what's the issue with using SECINITSID_UNLABELED instead? It isn't equivalent to SECSID_NULL. Is that the source of confusion? Note btw that the current xinetd patch won't work well with any of the above, e.g. ftpd shouldn't run in any of xinetd_t, network_t, or unlabeled_t. And if xinetd takes the alternative approach I suggested, then the TE portion of the peer context is completely irrelevant. Meanwhile, for e.g. a networked policy management daemon, none of these domains is likely to get past the avc_has_perm() check. Which is what we'd want, since we don't know anything about the real domain of the client. But the first case (return local socket's domain) is a bit frightening - I can see policy allowing a domain to act on itself, and not expecting that to permit arbitrary clients of unknown domain to do likewise. -- Stephen Smalley National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH v4 1/2] NetLabel: secid reconciliation support 2006-10-04 20:27 ` Stephen Smalley @ 2006-10-04 20:52 ` Paul Moore 2006-10-04 21:12 ` Steve Grubb 0 siblings, 1 reply; 33+ messages in thread From: Paul Moore @ 2006-10-04 20:52 UTC (permalink / raw) To: Stephen Smalley; +Cc: Venkat Yekkirala, selinux, eparis, jmorris, Steve Grubb Stephen Smalley wrote: > (also dropping netdev, as this isn't relevant there) > > On Wed, 2006-10-04 at 16:08 -0400, Paul Moore wrote: > >>Venkat Yekkirala wrote: >> >>>>On Wed, 2006-10-04 at 15:27 -0400, Paul Moore wrote: >>>> >>>> >>>>>Venkat Yekkirala wrote: >>>>> >>>>> >>>>>>>* XFRM present >>>>>>> >>>>>>> xfrm_sid = <full context from xfrm> >>>>>>> loc_sid = SECINITSID_NETMSG >>>>>>> nlbl_sid = SECSID_NULL/0 >>>>>>> ext_sid = xfrm_sid >>>>>>> final skb->secmark = avc_ok : ext_sid ? unchanged >>> >>> >>>As noted subsequently, I actually meant to refer to the below >>>instead of the XFRM case above: >>> >>> * Nothing >>> >>> xfrm_sid = SECSID_NULL/0 >>> loc_sid = SECSID_NULL/0 >>> nlbl_sid = SECSID_NULL/0 >>> ext_sid = xfrm_sid >>> final skb->secmark = avc_ok : ext_sid ? unchanged >>> >>> >>> >>>>>>>* NetLabel present >>>>>>> >>>>>>> xfrm_sid = SECSID_NULL/0 >>>>>>> loc_sid = SECSID_NULL/0 >>>>>>> nlbl_sid = <SECINITSID_NETMSG te ctx, netlabel mls ctx> >>>>>>> ext_sid = nlbl_sid >>>>>>> final skb->secmark = avc_ok : ext_sid ? unchanged >>>>>> >>>>>>I was referring to the differences in what getpeercon would >>>>>>return in the above 2 scenarios. >>>>>> >>>>>>In the xfrm case: final skb->secmark would be 0 >>>> >>>>resulting in getpeercon >>>> >>>> >>>>>>to return EPROTONOOPT >>>>> >>>>>In the "XFRM present" case above if the access is allowed (avc_ok is >>>>>true) then the final skb->secmark value is going to be set >>>> >>>>to the value >>>> >>>> >>>>>of ext_sid which is the xfrm_sid. Any calls made to >>>> >>>>getpeercon() would >>>> >>>> >>>>>return success with the context matching xfrm_sid. >>>>> >>>>>I have a hunch we are still on different pages here ... >>>>> >>>>> >>>>> >>>>>>In the NetLabel case: final skb->secmark would be >>>> >>>>network_t resulting in >>>> >>>> >>>>>>getpeercon to return network_t >>>>> >>>>>Yep, and I understand you would like to see it as >>>> >>>>unlabeled_t. I think >>>> >>>> >>>>>we both have valid arguments for either case and we are >>>> >>>>just waiting to >>>> >>>> >>>>>hear from others. >>>> >>>>I don't understand the argument for network_t, and it seems to violate >>>>our goals of 1) having consistent policy regardless of >>>>network labeling >>>>mechanism, and 2) having getpeercon() always return a subject >>>>label that >>>>can be used as a basis for avc_has_perm() and setexeccon() calls. >>> >>>But in the case where there's no domain info, but a cipso label, >>>getpeercon will fail (EPROTONOOPT). Do I rememember that Paul was >>>trying to use a special SID to use as a base sid in this case? >> >>[I'm replying to both Stephen and Venkat here as the email is coming in >>faster than I can type :)] >> >>In the current non-secid world, if the connection is NetLabel labeled, >>the sock_rcv_skb() LSM hook uses SECINITSID_NETMSG as the base_sid and >>the recvfrom permission to control access. Calls to getpeercon() on a >>NetLabel connection use the socket's SID as the base_sid and the network >>traffic's MLS label. > > So if xinetd calls getpeercon(), it gets a context with type > "xinetd_t" (from its own socket) and the MLS label of the client? Yep. >>In the latest secid world, when there is only NetLabel labeling present >>on the connection SECINITSID_NETMSG is used as the base_sid for the >>final skb->secmark value as determined by the flow_in() LSM hook with >>the MLS label being set to match the NetLabel on the packet. Calls to >>getpeercon() will use the secmark value of the packet when the >>connection is establishes (in *all* cases) so getpeercon() in the >>NetLabel only case will succeed and return the value determined above. > > So if xinetd calls getpeercon(), it gets a context with type > "network_t" (if using netmsg) or "unlabeled_t" (if using unlabeled) and > the MLS label of the client? Yep. > So what's the issue with using SECINITSID_UNLABELED instead? It isn't > equivalent to SECSID_NULL. Is that the source of confusion? My only concern with using SECINITSID_UNLABELED was that the string context representation would show up as "unlabeled_t" which I think is somehwat misleading. Venkat and I have had several discussions about this on the mailing lists and we were just waiting for someone else to comment on the issue. > Note btw that the current xinetd patch won't work well with any of the > above, e.g. ftpd shouldn't run in any of xinetd_t, network_t, or > unlabeled_t. And if xinetd takes the alternative approach I suggested, > then the TE portion of the peer context is completely irrelevant. I think we are all in agreement that the current xinetd patch is broken. Hopefully Steve Grubb will have fix it soon (I just added him as a CC). > Meanwhile, for e.g. a networked policy management daemon, none of these > domains is likely to get past the avc_has_perm() check. Which is what > we'd want, since we don't know anything about the real domain of the > client. But the first case (return local socket's domain) is a bit > frightening - I can see policy allowing a domain to act on itself, and > not expecting that to permit arbitrary clients of unknown domain to do > likewise. Okay, I'll change NetLabel to use the SECINITSID_UNLABELED SID as the base_sid for pretty much everything when there is no TE information available from SECMARK or XFRM. -- paul moore linux security @ hp -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH v4 1/2] NetLabel: secid reconciliation support 2006-10-04 20:52 ` Paul Moore @ 2006-10-04 21:12 ` Steve Grubb 2006-10-04 22:03 ` Joe Nall 2006-10-04 22:18 ` Linda Knippers 0 siblings, 2 replies; 33+ messages in thread From: Steve Grubb @ 2006-10-04 21:12 UTC (permalink / raw) To: Paul Moore; +Cc: Stephen Smalley, Venkat Yekkirala, selinux, eparis, jmorris On Wednesday 04 October 2006 16:52, Paul Moore wrote: > I think we are all in agreement that the current xinetd patch is broken. > Hopefully Steve Grubb will have fix it soon (I just added him as a CC). In my opinion, this should be in bugzilla. This is the first I heard of xinetd being broken. LSPP issues that need quick solutions like this can get lost in mail. -Steve -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH v4 1/2] NetLabel: secid reconciliation support 2006-10-04 21:12 ` Steve Grubb @ 2006-10-04 22:03 ` Joe Nall 2006-10-04 22:43 ` Paul Moore 2006-10-04 22:18 ` Linda Knippers 1 sibling, 1 reply; 33+ messages in thread From: Joe Nall @ 2006-10-04 22:03 UTC (permalink / raw) To: Stephen Smalley, Paul Moore Cc: Venkat Yekkirala, SE Linux, eparis, James Morris, Steve Grubb On Oct 4, 2006, at 4:12 PM, Steve Grubb wrote: > On Wednesday 04 October 2006 16:52, Paul Moore wrote: >> I think we are all in agreement that the current xinetd patch is >> broken. >> Hopefully Steve Grubb will have fix it soon (I just added him as >> a CC). > > In my opinion, this should be in bugzilla. This is the first I > heard of xinetd > being broken. LSPP issues that need quick solutions like this can > get lost in > mail. Using Eric's kernel and rawhide xinetd, I get what I expect from this simple test - [joe@mls user_u:user_r:user_t:SystemLow ~]$ telnet localhost test Trying 127.0.0.1... Connected to localhost.localdomain (127.0.0.1). Escape character is '^]'. uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm), 6(disk),10(wheel) context=user_u:user_r:user_t:SystemLow Connection closed by foreign host. [joe@mls user_u:user_r:user_t:SystemLow ~]$ newrole -l S-S ... [joe@mls user_u:user_r:user_t:SECRET ~]$ telnet localhost test Trying 127.0.0.1... Connected to localhost.localdomain (127.0.0.1). Escape character is '^]'. uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm), 6(disk),10(wheel) context=user_u:user_r:user_t:SECRET Where /etc/xinetd.d/test is service test { flags = LABELED socket_type = stream wait = no user = root group = root server = /usr/bin/id log_on_failure += USERID disable = no } Can anyone provide a simple test that demonstrates how xinetd is broken? joe -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH v4 1/2] NetLabel: secid reconciliation support 2006-10-04 22:03 ` Joe Nall @ 2006-10-04 22:43 ` Paul Moore 0 siblings, 0 replies; 33+ messages in thread From: Paul Moore @ 2006-10-04 22:43 UTC (permalink / raw) To: Joe Nall Cc: Stephen Smalley, Venkat Yekkirala, SE Linux, eparis, James Morris, Steve Grubb Joe Nall wrote: > On Oct 4, 2006, at 4:12 PM, Steve Grubb wrote: > > >>On Wednesday 04 October 2006 16:52, Paul Moore wrote: >> >>>I think we are all in agreement that the current xinetd patch is >>>broken. >>> Hopefully Steve Grubb will have fix it soon (I just added him as >>>a CC). >> >>In my opinion, this should be in bugzilla. This is the first I >>heard of xinetd >>being broken. LSPP issues that need quick solutions like this can >>get lost in >>mail. > > > Using Eric's kernel and rawhide xinetd, I get what I expect from this > simple test - > > [joe@mls user_u:user_r:user_t:SystemLow ~]$ telnet localhost test > Trying 127.0.0.1... > Connected to localhost.localdomain (127.0.0.1). > Escape character is '^]'. > uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm), > 6(disk),10(wheel) context=user_u:user_r:user_t:SystemLow > Connection closed by foreign host. > > [joe@mls user_u:user_r:user_t:SystemLow ~]$ newrole -l S-S > ... > [joe@mls user_u:user_r:user_t:SECRET ~]$ telnet localhost test > Trying 127.0.0.1... > Connected to localhost.localdomain (127.0.0.1). > Escape character is '^]'. > uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm), > 6(disk),10(wheel) context=user_u:user_r:user_t:SECRET Handling of loopback is a special case when using the secid patches, the behavior you are seeing is expected. > Can anyone provide a simple test that demonstrates how xinetd is broken? Try telneting into a remote host and note the context that in.telnetd is running on the remote machine. -- paul moore linux security @ hp -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH v4 1/2] NetLabel: secid reconciliation support 2006-10-04 21:12 ` Steve Grubb 2006-10-04 22:03 ` Joe Nall @ 2006-10-04 22:18 ` Linda Knippers 1 sibling, 0 replies; 33+ messages in thread From: Linda Knippers @ 2006-10-04 22:18 UTC (permalink / raw) To: Steve Grubb Cc: Paul Moore, Stephen Smalley, Venkat Yekkirala, selinux, eparis, jmorris Steve Grubb wrote: > On Wednesday 04 October 2006 16:52, Paul Moore wrote: > >>I think we are all in agreement that the current xinetd patch is broken. >> Hopefully Steve Grubb will have fix it soon (I just added him as a CC). > > > In my opinion, this should be in bugzilla. This is the first I heard of xinetd > being broken. LSPP issues that need quick solutions like this can get lost in > mail. I just filed https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=209379 -- ljk -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. ^ permalink raw reply [flat|nested] 33+ messages in thread
* RE: [PATCH v4 1/2] NetLabel: secid reconciliation support 2006-10-04 19:53 ` Venkat Yekkirala (?) (?) @ 2006-10-04 20:12 ` Stephen Smalley -1 siblings, 0 replies; 33+ messages in thread From: Stephen Smalley @ 2006-10-04 20:12 UTC (permalink / raw) To: Venkat Yekkirala; +Cc: Paul Moore, selinux, eparis, jmorris On Wed, 2006-10-04 at 15:53 -0400, Venkat Yekkirala wrote: > > On Wed, 2006-10-04 at 15:27 -0400, Paul Moore wrote: > > > Venkat Yekkirala wrote: > > > >> * XFRM present > > > >> > > > >> xfrm_sid = <full context from xfrm> > > > >> loc_sid = SECINITSID_NETMSG > > > >> nlbl_sid = SECSID_NULL/0 > > > >> ext_sid = xfrm_sid > > > >> final skb->secmark = avc_ok : ext_sid ? unchanged > > As noted subsequently, I actually meant to refer to the below > instead of the XFRM case above: > > * Nothing > > xfrm_sid = SECSID_NULL/0 > loc_sid = SECSID_NULL/0 > nlbl_sid = SECSID_NULL/0 > ext_sid = xfrm_sid > final skb->secmark = avc_ok : ext_sid ? unchanged > > > > >> > > > >> * NetLabel present > > > >> > > > >> xfrm_sid = SECSID_NULL/0 > > > >> loc_sid = SECSID_NULL/0 > > > >> nlbl_sid = <SECINITSID_NETMSG te ctx, netlabel mls ctx> > > > >> ext_sid = nlbl_sid > > > >> final skb->secmark = avc_ok : ext_sid ? unchanged > > > > > > > > I was referring to the differences in what getpeercon would > > > > return in the above 2 scenarios. > > > > > > > > In the xfrm case: final skb->secmark would be 0 > > resulting in getpeercon > > > > to return EPROTONOOPT > > > > > > In the "XFRM present" case above if the access is allowed (avc_ok is > > > true) then the final skb->secmark value is going to be set > > to the value > > > of ext_sid which is the xfrm_sid. Any calls made to > > getpeercon() would > > > return success with the context matching xfrm_sid. > > > > > > I have a hunch we are still on different pages here ... > > > > > > > In the NetLabel case: final skb->secmark would be > > network_t resulting in > > > > getpeercon to return network_t > > > > > > Yep, and I understand you would like to see it as > > unlabeled_t. I think > > > we both have valid arguments for either case and we are > > just waiting to > > > hear from others. > > > > I don't understand the argument for network_t, and it seems to violate > > our goals of 1) having consistent policy regardless of > > network labeling > > mechanism, and 2) having getpeercon() always return a subject > > label that > > can be used as a basis for avc_has_perm() and setexeccon() calls. > > But in the case where there's no domain info, but a cipso label, > getpeercon will fail (EPROTONOOPT). Do I rememember that Paul was > trying to use a special SID to use as a base sid in this case? Why does getpeercon fail in that case? SECSID_NULL != SECINITSID_UNLABELED, even if they end up mapping to the same context. -- Stephen Smalley National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. ^ permalink raw reply [flat|nested] 33+ messages in thread
* RE: [PATCH v4 1/2] NetLabel: secid reconciliation support @ 2006-10-04 19:37 ` Venkat Yekkirala 0 siblings, 0 replies; 33+ messages in thread From: Venkat Yekkirala @ 2006-10-04 19:37 UTC (permalink / raw) To: Paul Moore, Venkat Yekkirala; +Cc: netdev, selinux, eparis, jmorris, sds > >> * XFRM present > >> > >> xfrm_sid = <full context from xfrm> > >> loc_sid = SECINITSID_NETMSG > >> nlbl_sid = SECSID_NULL/0 > >> ext_sid = xfrm_sid > >> final skb->secmark = avc_ok : ext_sid ? unchanged Actually, I meant to cite the following instead of the above: * Nothing xfrm_sid = SECSID_NULL/0 loc_sid = SECSID_NULL/0 nlbl_sid = SECSID_NULL/0 ext_sid = xfrm_sid final skb->secmark = avc_ok : ext_sid ? unchanged > >> > >> * NetLabel present > >> > >> xfrm_sid = SECSID_NULL/0 > >> loc_sid = SECSID_NULL/0 > >> nlbl_sid = <SECINITSID_NETMSG te ctx, netlabel mls ctx> > >> ext_sid = nlbl_sid > >> final skb->secmark = avc_ok : ext_sid ? unchanged > > > > I was referring to the differences in what getpeercon would > > return in the above 2 scenarios. > > > > In the xfrm case: final skb->secmark would be 0 > resulting in getpeercon > > to return EPROTONOOPT > > In the "XFRM present" case above if the access is allowed (avc_ok is > true) then the final skb->secmark value is going to be set to > the value > of ext_sid which is the xfrm_sid. Any calls made to > getpeercon() would > return success with the context matching xfrm_sid. You are right, but I was actually referring to the "Nothing" case above. > > I have a hunch we are still on different pages here ... > > > In the NetLabel case: final skb->secmark would be network_t > resulting in > > getpeercon to return network_t > > Yep, and I understand you would like to see it as > unlabeled_t. I think > we both have valid arguments for either case and we are just > waiting to > hear from others. > > -- > paul moore > linux security @ hp > -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. ^ permalink raw reply [flat|nested] 33+ messages in thread
* RE: [PATCH v4 1/2] NetLabel: secid reconciliation support @ 2006-10-04 19:37 ` Venkat Yekkirala 0 siblings, 0 replies; 33+ messages in thread From: Venkat Yekkirala @ 2006-10-04 19:37 UTC (permalink / raw) To: Paul Moore, Venkat Yekkirala; +Cc: netdev, selinux, eparis, jmorris, sds > >> * XFRM present > >> > >> xfrm_sid = <full context from xfrm> > >> loc_sid = SECINITSID_NETMSG > >> nlbl_sid = SECSID_NULL/0 > >> ext_sid = xfrm_sid > >> final skb->secmark = avc_ok : ext_sid ? unchanged Actually, I meant to cite the following instead of the above: * Nothing xfrm_sid = SECSID_NULL/0 loc_sid = SECSID_NULL/0 nlbl_sid = SECSID_NULL/0 ext_sid = xfrm_sid final skb->secmark = avc_ok : ext_sid ? unchanged > >> > >> * NetLabel present > >> > >> xfrm_sid = SECSID_NULL/0 > >> loc_sid = SECSID_NULL/0 > >> nlbl_sid = <SECINITSID_NETMSG te ctx, netlabel mls ctx> > >> ext_sid = nlbl_sid > >> final skb->secmark = avc_ok : ext_sid ? unchanged > > > > I was referring to the differences in what getpeercon would > > return in the above 2 scenarios. > > > > In the xfrm case: final skb->secmark would be 0 > resulting in getpeercon > > to return EPROTONOOPT > > In the "XFRM present" case above if the access is allowed (avc_ok is > true) then the final skb->secmark value is going to be set to > the value > of ext_sid which is the xfrm_sid. Any calls made to > getpeercon() would > return success with the context matching xfrm_sid. You are right, but I was actually referring to the "Nothing" case above. > > I have a hunch we are still on different pages here ... > > > In the NetLabel case: final skb->secmark would be network_t > resulting in > > getpeercon to return network_t > > Yep, and I understand you would like to see it as > unlabeled_t. I think > we both have valid arguments for either case and we are just > waiting to > hear from others. > > -- > paul moore > linux security @ hp > ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH v4 1/2] NetLabel: secid reconciliation support 2006-10-04 19:37 ` Venkat Yekkirala @ 2006-10-04 19:52 ` Paul Moore -1 siblings, 0 replies; 33+ messages in thread From: Paul Moore @ 2006-10-04 19:52 UTC (permalink / raw) To: Venkat Yekkirala; +Cc: netdev, selinux, eparis, jmorris, sds Venkat Yekkirala wrote: >>>>* XFRM present >>>> >>>> xfrm_sid = <full context from xfrm> >>>> loc_sid = SECINITSID_NETMSG >>>> nlbl_sid = SECSID_NULL/0 >>>> ext_sid = xfrm_sid >>>> final skb->secmark = avc_ok : ext_sid ? unchanged > > Actually, I meant to cite the following instead of the above: > > * Nothing > > xfrm_sid = SECSID_NULL/0 > loc_sid = SECSID_NULL/0 > nlbl_sid = SECSID_NULL/0 > ext_sid = xfrm_sid > final skb->secmark = avc_ok : ext_sid ? unchanged Okay, thanks, I think I understand your point now. Let me try to restate just to make sure. Take two cases: the first being no labeling at all, the second being only NetLabel ... * Nothing xfrm_sid = SECSID_NULL/0 loc_sid = SECSID_NULL/0 nlbl_sid = SECSID_NULL/0 ext_sid = xfrm_sid final skb->secmark = avc_ok : ext_sid ? unchanged * NetLabel xfrm_sid = SECSID_NULL/0 loc_sid = SECSID_NULL/0 nlbl_sid = <SECINITSID_NETMSG te ctx, netlabel mls ctx> ext_sid = nlbl_sid final skb->secmark = avc_ok : ext_sid ? unchanged In the "Nothing" case the final skb->secmark is set to SECSID_NULL/0; getpeercon() should return an error. In the "NetLabel" case the final skb->secmark is set using the TE portions of SECINITSID_NETMSG and the MLS label of the NetLabel packet; getpeercon() will succeed. I understand in the "NetLabel" case above you think the TE portion of the final skb->secmark value should come from SECSID_NULL/SECINITSID_UNLABELED/0, but do you also want getpeercon() to return an error in the "NetLabel" case? I think that's a bad idea as it will made it *extremely* difficult for applications to determine the MLS label of a connection using NetLabel. >>>>* NetLabel present >>>> >>>> xfrm_sid = SECSID_NULL/0 >>>> loc_sid = SECSID_NULL/0 >>>> nlbl_sid = <SECINITSID_NETMSG te ctx, netlabel mls ctx> >>>> ext_sid = nlbl_sid >>>> final skb->secmark = avc_ok : ext_sid ? unchanged >>> >>>I was referring to the differences in what getpeercon would >>>return in the above 2 scenarios. >>> >>>In the xfrm case: final skb->secmark would be 0 >> >>resulting in getpeercon >> >>>to return EPROTONOOPT >> >>In the "XFRM present" case above if the access is allowed (avc_ok is >>true) then the final skb->secmark value is going to be set to >>the value >>of ext_sid which is the xfrm_sid. Any calls made to >>getpeercon() would >>return success with the context matching xfrm_sid. > > > You are right, but I was actually referring to the "Nothing" > case above. > > >>I have a hunch we are still on different pages here ... >> >> >>>In the NetLabel case: final skb->secmark would be network_t >> >>resulting in >> >>>getpeercon to return network_t >> >>Yep, and I understand you would like to see it as >>unlabeled_t. I think >>we both have valid arguments for either case and we are just >>waiting to >>hear from others. >> >>-- >>paul moore >>linux security @ hp >> -- paul moore linux security @ hp -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH v4 1/2] NetLabel: secid reconciliation support @ 2006-10-04 19:52 ` Paul Moore 0 siblings, 0 replies; 33+ messages in thread From: Paul Moore @ 2006-10-04 19:52 UTC (permalink / raw) To: Venkat Yekkirala; +Cc: netdev, selinux, eparis, jmorris, sds Venkat Yekkirala wrote: >>>>* XFRM present >>>> >>>> xfrm_sid = <full context from xfrm> >>>> loc_sid = SECINITSID_NETMSG >>>> nlbl_sid = SECSID_NULL/0 >>>> ext_sid = xfrm_sid >>>> final skb->secmark = avc_ok : ext_sid ? unchanged > > Actually, I meant to cite the following instead of the above: > > * Nothing > > xfrm_sid = SECSID_NULL/0 > loc_sid = SECSID_NULL/0 > nlbl_sid = SECSID_NULL/0 > ext_sid = xfrm_sid > final skb->secmark = avc_ok : ext_sid ? unchanged Okay, thanks, I think I understand your point now. Let me try to restate just to make sure. Take two cases: the first being no labeling at all, the second being only NetLabel ... * Nothing xfrm_sid = SECSID_NULL/0 loc_sid = SECSID_NULL/0 nlbl_sid = SECSID_NULL/0 ext_sid = xfrm_sid final skb->secmark = avc_ok : ext_sid ? unchanged * NetLabel xfrm_sid = SECSID_NULL/0 loc_sid = SECSID_NULL/0 nlbl_sid = <SECINITSID_NETMSG te ctx, netlabel mls ctx> ext_sid = nlbl_sid final skb->secmark = avc_ok : ext_sid ? unchanged In the "Nothing" case the final skb->secmark is set to SECSID_NULL/0; getpeercon() should return an error. In the "NetLabel" case the final skb->secmark is set using the TE portions of SECINITSID_NETMSG and the MLS label of the NetLabel packet; getpeercon() will succeed. I understand in the "NetLabel" case above you think the TE portion of the final skb->secmark value should come from SECSID_NULL/SECINITSID_UNLABELED/0, but do you also want getpeercon() to return an error in the "NetLabel" case? I think that's a bad idea as it will made it *extremely* difficult for applications to determine the MLS label of a connection using NetLabel. >>>>* NetLabel present >>>> >>>> xfrm_sid = SECSID_NULL/0 >>>> loc_sid = SECSID_NULL/0 >>>> nlbl_sid = <SECINITSID_NETMSG te ctx, netlabel mls ctx> >>>> ext_sid = nlbl_sid >>>> final skb->secmark = avc_ok : ext_sid ? unchanged >>> >>>I was referring to the differences in what getpeercon would >>>return in the above 2 scenarios. >>> >>>In the xfrm case: final skb->secmark would be 0 >> >>resulting in getpeercon >> >>>to return EPROTONOOPT >> >>In the "XFRM present" case above if the access is allowed (avc_ok is >>true) then the final skb->secmark value is going to be set to >>the value >>of ext_sid which is the xfrm_sid. Any calls made to >>getpeercon() would >>return success with the context matching xfrm_sid. > > > You are right, but I was actually referring to the "Nothing" > case above. > > >>I have a hunch we are still on different pages here ... >> >> >>>In the NetLabel case: final skb->secmark would be network_t >> >>resulting in >> >>>getpeercon to return network_t >> >>Yep, and I understand you would like to see it as >>unlabeled_t. I think >>we both have valid arguments for either case and we are just >>waiting to >>hear from others. >> >>-- >>paul moore >>linux security @ hp >> -- paul moore linux security @ hp ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH v4 1/2] NetLabel: secid reconciliation support 2006-10-04 19:52 ` Paul Moore (?) @ 2006-10-04 20:09 ` Stephen Smalley 2006-10-04 20:21 ` Paul Moore -1 siblings, 1 reply; 33+ messages in thread From: Stephen Smalley @ 2006-10-04 20:09 UTC (permalink / raw) To: Paul Moore; +Cc: Venkat Yekkirala, selinux, eparis, jmorris On Wed, 2006-10-04 at 15:52 -0400, Paul Moore wrote: > Venkat Yekkirala wrote: > >>>>* XFRM present > >>>> > >>>> xfrm_sid = <full context from xfrm> > >>>> loc_sid = SECINITSID_NETMSG > >>>> nlbl_sid = SECSID_NULL/0 > >>>> ext_sid = xfrm_sid > >>>> final skb->secmark = avc_ok : ext_sid ? unchanged > > > > Actually, I meant to cite the following instead of the above: > > > > * Nothing > > > > xfrm_sid = SECSID_NULL/0 > > loc_sid = SECSID_NULL/0 > > nlbl_sid = SECSID_NULL/0 > > ext_sid = xfrm_sid > > final skb->secmark = avc_ok : ext_sid ? unchanged > > Okay, thanks, I think I understand your point now. Let me try to > restate just to make sure. > > Take two cases: the first being no labeling at all, the second being > only NetLabel ... > > * Nothing > > xfrm_sid = SECSID_NULL/0 > loc_sid = SECSID_NULL/0 > nlbl_sid = SECSID_NULL/0 > ext_sid = xfrm_sid > final skb->secmark = avc_ok : ext_sid ? unchanged > > * NetLabel > > xfrm_sid = SECSID_NULL/0 > loc_sid = SECSID_NULL/0 > nlbl_sid = <SECINITSID_NETMSG te ctx, netlabel mls ctx> > ext_sid = nlbl_sid > final skb->secmark = avc_ok : ext_sid ? unchanged > > In the "Nothing" case the final skb->secmark is set to SECSID_NULL/0; > getpeercon() should return an error. In the "NetLabel" case the final > skb->secmark is set using the TE portions of SECINITSID_NETMSG and the > MLS label of the NetLabel packet; getpeercon() will succeed. ...but return a context that isn't a subject label. > I understand in the "NetLabel" case above you think the TE portion of > the final skb->secmark value should come from > SECSID_NULL/SECINITSID_UNLABELED/0, but do you also want getpeercon() to > return an error in the "NetLabel" case? I think that's a bad idea as it > will made it *extremely* difficult for applications to determine the MLS > label of a connection using NetLabel. It doesn't need to fail in that case, no. But it should return a subject label. From a TE pov, the subject label is "unlabeled_t", i.e. no labeling information available. From the MLS pov, you have your CIPSO label. Why "network_t" instead? -- Stephen Smalley National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH v4 1/2] NetLabel: secid reconciliation support 2006-10-04 20:09 ` Stephen Smalley @ 2006-10-04 20:21 ` Paul Moore 2006-10-04 20:39 ` Stephen Smalley 0 siblings, 1 reply; 33+ messages in thread From: Paul Moore @ 2006-10-04 20:21 UTC (permalink / raw) To: Stephen Smalley; +Cc: Venkat Yekkirala, selinux, eparis, jmorris Stephen Smalley wrote: > On Wed, 2006-10-04 at 15:52 -0400, Paul Moore wrote: > >>Venkat Yekkirala wrote: >> >>>>>>* XFRM present >>>>>> >>>>>> xfrm_sid = <full context from xfrm> >>>>>> loc_sid = SECINITSID_NETMSG >>>>>> nlbl_sid = SECSID_NULL/0 >>>>>> ext_sid = xfrm_sid >>>>>> final skb->secmark = avc_ok : ext_sid ? unchanged >>> >>>Actually, I meant to cite the following instead of the above: >>> >>> * Nothing >>> >>> xfrm_sid = SECSID_NULL/0 >>> loc_sid = SECSID_NULL/0 >>> nlbl_sid = SECSID_NULL/0 >>> ext_sid = xfrm_sid >>> final skb->secmark = avc_ok : ext_sid ? unchanged >> >>Okay, thanks, I think I understand your point now. Let me try to >>restate just to make sure. >> >>Take two cases: the first being no labeling at all, the second being >>only NetLabel ... >> >> * Nothing >> >> xfrm_sid = SECSID_NULL/0 >> loc_sid = SECSID_NULL/0 >> nlbl_sid = SECSID_NULL/0 >> ext_sid = xfrm_sid >> final skb->secmark = avc_ok : ext_sid ? unchanged >> >> * NetLabel >> >> xfrm_sid = SECSID_NULL/0 >> loc_sid = SECSID_NULL/0 >> nlbl_sid = <SECINITSID_NETMSG te ctx, netlabel mls ctx> >> ext_sid = nlbl_sid >> final skb->secmark = avc_ok : ext_sid ? unchanged >> >>In the "Nothing" case the final skb->secmark is set to SECSID_NULL/0; >>getpeercon() should return an error. In the "NetLabel" case the final >>skb->secmark is set using the TE portions of SECINITSID_NETMSG and the >>MLS label of the NetLabel packet; getpeercon() will succeed. > > ...but return a context that isn't a subject label. The alternative is to go back to having getpeercon() return the socket's TE context with the NetLabel's MLS label - would that be better? Or do you want it to use SECINITSID_UNLABELED for the TE context? I would prefer the socket's TE context but if I'm the only one that thinks that way I'll cave on the issue. >>I understand in the "NetLabel" case above you think the TE portion of >>the final skb->secmark value should come from >>SECSID_NULL/SECINITSID_UNLABELED/0, but do you also want getpeercon() to >>return an error in the "NetLabel" case? I think that's a bad idea as it >>will made it *extremely* difficult for applications to determine the MLS >>label of a connection using NetLabel. > > It doesn't need to fail in that case, no. But it should return a > subject label. From a TE pov, the subject label is "unlabeled_t", i.e. > no labeling information available. From the MLS pov, you have your > CIPSO label. Why "network_t" instead? The reason for using "network_t" is becuase that is what Venkat is assigning to the SECINITSID_NETMSG SID and that is what the NetLabel secid patches currently use for a TE context when there is no other TE information available, i.e. no SECMARK, no XFRM. -- paul moore linux security @ hp -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH v4 1/2] NetLabel: secid reconciliation support 2006-10-04 20:21 ` Paul Moore @ 2006-10-04 20:39 ` Stephen Smalley 2006-10-04 20:53 ` Paul Moore 0 siblings, 1 reply; 33+ messages in thread From: Stephen Smalley @ 2006-10-04 20:39 UTC (permalink / raw) To: Paul Moore; +Cc: Venkat Yekkirala, selinux, eparis, jmorris On Wed, 2006-10-04 at 16:21 -0400, Paul Moore wrote: > Stephen Smalley wrote: > > On Wed, 2006-10-04 at 15:52 -0400, Paul Moore wrote: > > > >>Venkat Yekkirala wrote: > >> > >>>>>>* XFRM present > >>>>>> > >>>>>> xfrm_sid = <full context from xfrm> > >>>>>> loc_sid = SECINITSID_NETMSG > >>>>>> nlbl_sid = SECSID_NULL/0 > >>>>>> ext_sid = xfrm_sid > >>>>>> final skb->secmark = avc_ok : ext_sid ? unchanged > >>> > >>>Actually, I meant to cite the following instead of the above: > >>> > >>> * Nothing > >>> > >>> xfrm_sid = SECSID_NULL/0 > >>> loc_sid = SECSID_NULL/0 > >>> nlbl_sid = SECSID_NULL/0 > >>> ext_sid = xfrm_sid > >>> final skb->secmark = avc_ok : ext_sid ? unchanged > >> > >>Okay, thanks, I think I understand your point now. Let me try to > >>restate just to make sure. > >> > >>Take two cases: the first being no labeling at all, the second being > >>only NetLabel ... > >> > >> * Nothing > >> > >> xfrm_sid = SECSID_NULL/0 > >> loc_sid = SECSID_NULL/0 > >> nlbl_sid = SECSID_NULL/0 > >> ext_sid = xfrm_sid > >> final skb->secmark = avc_ok : ext_sid ? unchanged > >> > >> * NetLabel > >> > >> xfrm_sid = SECSID_NULL/0 > >> loc_sid = SECSID_NULL/0 > >> nlbl_sid = <SECINITSID_NETMSG te ctx, netlabel mls ctx> > >> ext_sid = nlbl_sid > >> final skb->secmark = avc_ok : ext_sid ? unchanged > >> > >>In the "Nothing" case the final skb->secmark is set to SECSID_NULL/0; > >>getpeercon() should return an error. In the "NetLabel" case the final > >>skb->secmark is set using the TE portions of SECINITSID_NETMSG and the > >>MLS label of the NetLabel packet; getpeercon() will succeed. > > > > ...but return a context that isn't a subject label. > > The alternative is to go back to having getpeercon() return the socket's > TE context with the NetLabel's MLS label - would that be better? Or do > you want it to use SECINITSID_UNLABELED for the TE context? > > I would prefer the socket's TE context but if I'm the only one that > thinks that way I'll cave on the issue. As noted in my other email, that seems the least desirable option, because the application will see that as meaning that its peer is operating in the same domain as itself, whereas we don't know the peer's domain at all. This in turn could lead to passing a userspace permission check incorrectly. > >>I understand in the "NetLabel" case above you think the TE portion of > >>the final skb->secmark value should come from > >>SECSID_NULL/SECINITSID_UNLABELED/0, but do you also want getpeercon() to > >>return an error in the "NetLabel" case? I think that's a bad idea as it > >>will made it *extremely* difficult for applications to determine the MLS > >>label of a connection using NetLabel. > > > > It doesn't need to fail in that case, no. But it should return a > > subject label. From a TE pov, the subject label is "unlabeled_t", i.e. > > no labeling information available. From the MLS pov, you have your > > CIPSO label. Why "network_t" instead? > > The reason for using "network_t" is becuase that is what Venkat is > assigning to the SECINITSID_NETMSG SID and that is what the NetLabel > secid patches currently use for a TE context when there is no other TE > information available, i.e. no SECMARK, no XFRM. And what distinction do you intend to make based on this type versus unlabeled_t? They should both yield a failure whenever an application attempts to use them as a subject label, since neither has any permissions (other than a sigchld one for unlabeled_t to init_t for reaping of processes whose labels were invalidated by a policy reload). Do you anticipate allowing permissions to network_t in some situation? -- Stephen Smalley National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH v4 1/2] NetLabel: secid reconciliation support 2006-10-04 20:39 ` Stephen Smalley @ 2006-10-04 20:53 ` Paul Moore 0 siblings, 0 replies; 33+ messages in thread From: Paul Moore @ 2006-10-04 20:53 UTC (permalink / raw) To: Stephen Smalley; +Cc: Venkat Yekkirala, selinux, eparis, jmorris Stephen Smalley wrote: > On Wed, 2006-10-04 at 16:21 -0400, Paul Moore wrote: > >>Stephen Smalley wrote: >> >>>On Wed, 2006-10-04 at 15:52 -0400, Paul Moore wrote: >>> >>>>Venkat Yekkirala wrote: >>>> >>>>>>>>* XFRM present >>>>>>>> >>>>>>>>xfrm_sid = <full context from xfrm> >>>>>>>>loc_sid = SECINITSID_NETMSG >>>>>>>>nlbl_sid = SECSID_NULL/0 >>>>>>>>ext_sid = xfrm_sid >>>>>>>>final skb->secmark = avc_ok : ext_sid ? unchanged >>>>> >>>>>Actually, I meant to cite the following instead of the above: >>>>> >>>>>* Nothing >>>>> >>>>> xfrm_sid = SECSID_NULL/0 >>>>> loc_sid = SECSID_NULL/0 >>>>> nlbl_sid = SECSID_NULL/0 >>>>> ext_sid = xfrm_sid >>>>> final skb->secmark = avc_ok : ext_sid ? unchanged >>>> >>>>Okay, thanks, I think I understand your point now. Let me try to >>>>restate just to make sure. >>>> >>>>Take two cases: the first being no labeling at all, the second being >>>>only NetLabel ... >>>> >>>>* Nothing >>>> >>>> xfrm_sid = SECSID_NULL/0 >>>> loc_sid = SECSID_NULL/0 >>>> nlbl_sid = SECSID_NULL/0 >>>> ext_sid = xfrm_sid >>>> final skb->secmark = avc_ok : ext_sid ? unchanged >>>> >>>>* NetLabel >>>> >>>> xfrm_sid = SECSID_NULL/0 >>>> loc_sid = SECSID_NULL/0 >>>> nlbl_sid = <SECINITSID_NETMSG te ctx, netlabel mls ctx> >>>> ext_sid = nlbl_sid >>>> final skb->secmark = avc_ok : ext_sid ? unchanged >>>> >>>>In the "Nothing" case the final skb->secmark is set to SECSID_NULL/0; >>>>getpeercon() should return an error. In the "NetLabel" case the final >>>>skb->secmark is set using the TE portions of SECINITSID_NETMSG and the >>>>MLS label of the NetLabel packet; getpeercon() will succeed. >>> >>>...but return a context that isn't a subject label. >> >>The alternative is to go back to having getpeercon() return the socket's >>TE context with the NetLabel's MLS label - would that be better? Or do >>you want it to use SECINITSID_UNLABELED for the TE context? >> >>I would prefer the socket's TE context but if I'm the only one that >>thinks that way I'll cave on the issue. > > As noted in my other email, that seems the least desirable option, > because the application will see that as meaning that its peer is > operating in the same domain as itself, whereas we don't know the peer's > domain at all. This in turn could lead to passing a userspace > permission check incorrectly. > >>>>I understand in the "NetLabel" case above you think the TE portion of >>>>the final skb->secmark value should come from >>>>SECSID_NULL/SECINITSID_UNLABELED/0, but do you also want getpeercon() to >>>>return an error in the "NetLabel" case? I think that's a bad idea as it >>>>will made it *extremely* difficult for applications to determine the MLS >>>>label of a connection using NetLabel. >>> >>> >>>It doesn't need to fail in that case, no. But it should return a >>>subject label. From a TE pov, the subject label is "unlabeled_t", i.e. >>>no labeling information available. From the MLS pov, you have your >>>CIPSO label. Why "network_t" instead? >> >>The reason for using "network_t" is becuase that is what Venkat is >>assigning to the SECINITSID_NETMSG SID and that is what the NetLabel >>secid patches currently use for a TE context when there is no other TE >>information available, i.e. no SECMARK, no XFRM. > > And what distinction do you intend to make based on this type versus > unlabeled_t? They should both yield a failure whenever an application > attempts to use them as a subject label, since neither has any > permissions (other than a sigchld one for unlabeled_t to init_t for > reaping of processes whose labels were invalidated by a policy reload). > Do you anticipate allowing permissions to network_t in some situation? > I think all this gets resolved by making the change to the unlabeled SID as described in my last email. -- paul moore linux security @ hp -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. ^ permalink raw reply [flat|nested] 33+ messages in thread
* RE: [PATCH v4 1/2] NetLabel: secid reconciliation support @ 2006-10-04 19:02 ` Venkat Yekkirala 0 siblings, 0 replies; 33+ messages in thread From: Venkat Yekkirala @ 2006-10-04 19:02 UTC (permalink / raw) To: Paul Moore, Venkat Yekkirala; +Cc: netdev, selinux, eparis, jmorris, sds > * XFRM present > > xfrm_sid = <full context from xfrm> > loc_sid = SECINITSID_NETMSG > nlbl_sid = SECSID_NULL/0 > ext_sid = xfrm_sid > final skb->secmark = avc_ok : ext_sid ? unchanged > > * NetLabel present > > xfrm_sid = SECSID_NULL/0 > loc_sid = SECSID_NULL/0 > nlbl_sid = <SECINITSID_NETMSG te ctx, netlabel mls ctx> > ext_sid = nlbl_sid > final skb->secmark = avc_ok : ext_sid ? unchanged I was referring to the differences in what getpeercon would return in the above 2 scenarios. In the xfrm case: final skb->secmark would be 0 resulting in getpeercon to return EPROTONOOPT In the NetLabel case: final skb->secmark would be network_t resulting in getpeercon to return network_t > > * Nothing > > xfrm_sid = SECSID_NULL/0 > loc_sid = SECSID_NULL/0 > nlbl_sid = SECSID_NULL/0 > ext_sid = xfrm_sid > final skb->secmark = avc_ok : ext_sid ? unchanged > > > This has implications for getpeercon() where it would > > > > - fail with ENOPROTOOPT (xfrm case) > > - returns network_t (netlabel) > > > > I would still argue that the nature of the domain being carried by > > the packet is still unlabeled_t as implied by the null > secmark. While > > I view secmark/point as specifying BOTH a flow control point and a > > default domain (incidentally using the same label more because of > > implementation constrainst), I view network_t as purely a > flow control > > point. > > > > But I also realize there can be equally forceful arguments > for what this > > patch does. > > I know the two of us have talked about this before on the mail lists, > but I don't believe anyone else has ever made a comment in > this regard. > I tend to feel rather strongly that when using just NetLabel on a > connection you shouldn't see an "unlabeled_t" type as I feel that the > connotation associated with this type is misleading, even > though from a > TE point of view there may be an argument made that it is appropriate. > > > What does the community think? We need to resolve it one way or the > > other unless the above differences in behavior are desired > or somehow > > accounted for in policy and apps. > > I agree - I'd like to hear what others (namely Stephen Smalley, James > Morris and all of the Tresys folks <past and present>) have to say on > this issue. > > -- > paul moore > linux security @ hp > -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. ^ permalink raw reply [flat|nested] 33+ messages in thread
* RE: [PATCH v4 1/2] NetLabel: secid reconciliation support @ 2006-10-04 19:02 ` Venkat Yekkirala 0 siblings, 0 replies; 33+ messages in thread From: Venkat Yekkirala @ 2006-10-04 19:02 UTC (permalink / raw) To: Paul Moore, Venkat Yekkirala; +Cc: netdev, selinux, eparis, jmorris, sds > * XFRM present > > xfrm_sid = <full context from xfrm> > loc_sid = SECINITSID_NETMSG > nlbl_sid = SECSID_NULL/0 > ext_sid = xfrm_sid > final skb->secmark = avc_ok : ext_sid ? unchanged > > * NetLabel present > > xfrm_sid = SECSID_NULL/0 > loc_sid = SECSID_NULL/0 > nlbl_sid = <SECINITSID_NETMSG te ctx, netlabel mls ctx> > ext_sid = nlbl_sid > final skb->secmark = avc_ok : ext_sid ? unchanged I was referring to the differences in what getpeercon would return in the above 2 scenarios. In the xfrm case: final skb->secmark would be 0 resulting in getpeercon to return EPROTONOOPT In the NetLabel case: final skb->secmark would be network_t resulting in getpeercon to return network_t > > * Nothing > > xfrm_sid = SECSID_NULL/0 > loc_sid = SECSID_NULL/0 > nlbl_sid = SECSID_NULL/0 > ext_sid = xfrm_sid > final skb->secmark = avc_ok : ext_sid ? unchanged > > > This has implications for getpeercon() where it would > > > > - fail with ENOPROTOOPT (xfrm case) > > - returns network_t (netlabel) > > > > I would still argue that the nature of the domain being carried by > > the packet is still unlabeled_t as implied by the null > secmark. While > > I view secmark/point as specifying BOTH a flow control point and a > > default domain (incidentally using the same label more because of > > implementation constrainst), I view network_t as purely a > flow control > > point. > > > > But I also realize there can be equally forceful arguments > for what this > > patch does. > > I know the two of us have talked about this before on the mail lists, > but I don't believe anyone else has ever made a comment in > this regard. > I tend to feel rather strongly that when using just NetLabel on a > connection you shouldn't see an "unlabeled_t" type as I feel that the > connotation associated with this type is misleading, even > though from a > TE point of view there may be an argument made that it is appropriate. > > > What does the community think? We need to resolve it one way or the > > other unless the above differences in behavior are desired > or somehow > > accounted for in policy and apps. > > I agree - I'd like to hear what others (namely Stephen Smalley, James > Morris and all of the Tresys folks <past and present>) have to say on > this issue. > > -- > paul moore > linux security @ hp > ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH v4 1/2] NetLabel: secid reconciliation support 2006-10-04 19:02 ` Venkat Yekkirala @ 2006-10-04 19:27 ` Paul Moore -1 siblings, 0 replies; 33+ messages in thread From: Paul Moore @ 2006-10-04 19:27 UTC (permalink / raw) To: Venkat Yekkirala; +Cc: netdev, selinux, eparis, jmorris, sds Venkat Yekkirala wrote: >> * XFRM present >> >> xfrm_sid = <full context from xfrm> >> loc_sid = SECINITSID_NETMSG >> nlbl_sid = SECSID_NULL/0 >> ext_sid = xfrm_sid >> final skb->secmark = avc_ok : ext_sid ? unchanged >> >> * NetLabel present >> >> xfrm_sid = SECSID_NULL/0 >> loc_sid = SECSID_NULL/0 >> nlbl_sid = <SECINITSID_NETMSG te ctx, netlabel mls ctx> >> ext_sid = nlbl_sid >> final skb->secmark = avc_ok : ext_sid ? unchanged > > I was referring to the differences in what getpeercon would > return in the above 2 scenarios. > > In the xfrm case: final skb->secmark would be 0 resulting in getpeercon > to return EPROTONOOPT In the "XFRM present" case above if the access is allowed (avc_ok is true) then the final skb->secmark value is going to be set to the value of ext_sid which is the xfrm_sid. Any calls made to getpeercon() would return success with the context matching xfrm_sid. I have a hunch we are still on different pages here ... > In the NetLabel case: final skb->secmark would be network_t resulting in > getpeercon to return network_t Yep, and I understand you would like to see it as unlabeled_t. I think we both have valid arguments for either case and we are just waiting to hear from others. -- paul moore linux security @ hp -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH v4 1/2] NetLabel: secid reconciliation support @ 2006-10-04 19:27 ` Paul Moore 0 siblings, 0 replies; 33+ messages in thread From: Paul Moore @ 2006-10-04 19:27 UTC (permalink / raw) To: Venkat Yekkirala; +Cc: netdev, selinux, eparis, jmorris, sds Venkat Yekkirala wrote: >> * XFRM present >> >> xfrm_sid = <full context from xfrm> >> loc_sid = SECINITSID_NETMSG >> nlbl_sid = SECSID_NULL/0 >> ext_sid = xfrm_sid >> final skb->secmark = avc_ok : ext_sid ? unchanged >> >> * NetLabel present >> >> xfrm_sid = SECSID_NULL/0 >> loc_sid = SECSID_NULL/0 >> nlbl_sid = <SECINITSID_NETMSG te ctx, netlabel mls ctx> >> ext_sid = nlbl_sid >> final skb->secmark = avc_ok : ext_sid ? unchanged > > I was referring to the differences in what getpeercon would > return in the above 2 scenarios. > > In the xfrm case: final skb->secmark would be 0 resulting in getpeercon > to return EPROTONOOPT In the "XFRM present" case above if the access is allowed (avc_ok is true) then the final skb->secmark value is going to be set to the value of ext_sid which is the xfrm_sid. Any calls made to getpeercon() would return success with the context matching xfrm_sid. I have a hunch we are still on different pages here ... > In the NetLabel case: final skb->secmark would be network_t resulting in > getpeercon to return network_t Yep, and I understand you would like to see it as unlabeled_t. I think we both have valid arguments for either case and we are just waiting to hear from others. -- paul moore linux security @ hp ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH v4 1/2] NetLabel: secid reconciliation support 2006-10-04 19:27 ` Paul Moore @ 2006-10-04 19:45 ` Stephen Smalley -1 siblings, 0 replies; 33+ messages in thread From: Stephen Smalley @ 2006-10-04 19:45 UTC (permalink / raw) To: Paul Moore; +Cc: Venkat Yekkirala, netdev, selinux, eparis, jmorris On Wed, 2006-10-04 at 15:27 -0400, Paul Moore wrote: > Venkat Yekkirala wrote: > >> * XFRM present > >> > >> xfrm_sid = <full context from xfrm> > >> loc_sid = SECINITSID_NETMSG > >> nlbl_sid = SECSID_NULL/0 > >> ext_sid = xfrm_sid > >> final skb->secmark = avc_ok : ext_sid ? unchanged > >> > >> * NetLabel present > >> > >> xfrm_sid = SECSID_NULL/0 > >> loc_sid = SECSID_NULL/0 > >> nlbl_sid = <SECINITSID_NETMSG te ctx, netlabel mls ctx> > >> ext_sid = nlbl_sid > >> final skb->secmark = avc_ok : ext_sid ? unchanged > > > > I was referring to the differences in what getpeercon would > > return in the above 2 scenarios. > > > > In the xfrm case: final skb->secmark would be 0 resulting in getpeercon > > to return EPROTONOOPT > > In the "XFRM present" case above if the access is allowed (avc_ok is > true) then the final skb->secmark value is going to be set to the value > of ext_sid which is the xfrm_sid. Any calls made to getpeercon() would > return success with the context matching xfrm_sid. > > I have a hunch we are still on different pages here ... > > > In the NetLabel case: final skb->secmark would be network_t resulting in > > getpeercon to return network_t > > Yep, and I understand you would like to see it as unlabeled_t. I think > we both have valid arguments for either case and we are just waiting to > hear from others. I don't understand the argument for network_t, and it seems to violate our goals of 1) having consistent policy regardless of network labeling mechanism, and 2) having getpeercon() always return a subject label that can be used as a basis for avc_has_perm() and setexeccon() calls. -- Stephen Smalley National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH v4 1/2] NetLabel: secid reconciliation support @ 2006-10-04 19:45 ` Stephen Smalley 0 siblings, 0 replies; 33+ messages in thread From: Stephen Smalley @ 2006-10-04 19:45 UTC (permalink / raw) To: Paul Moore; +Cc: Venkat Yekkirala, netdev, selinux, eparis, jmorris On Wed, 2006-10-04 at 15:27 -0400, Paul Moore wrote: > Venkat Yekkirala wrote: > >> * XFRM present > >> > >> xfrm_sid = <full context from xfrm> > >> loc_sid = SECINITSID_NETMSG > >> nlbl_sid = SECSID_NULL/0 > >> ext_sid = xfrm_sid > >> final skb->secmark = avc_ok : ext_sid ? unchanged > >> > >> * NetLabel present > >> > >> xfrm_sid = SECSID_NULL/0 > >> loc_sid = SECSID_NULL/0 > >> nlbl_sid = <SECINITSID_NETMSG te ctx, netlabel mls ctx> > >> ext_sid = nlbl_sid > >> final skb->secmark = avc_ok : ext_sid ? unchanged > > > > I was referring to the differences in what getpeercon would > > return in the above 2 scenarios. > > > > In the xfrm case: final skb->secmark would be 0 resulting in getpeercon > > to return EPROTONOOPT > > In the "XFRM present" case above if the access is allowed (avc_ok is > true) then the final skb->secmark value is going to be set to the value > of ext_sid which is the xfrm_sid. Any calls made to getpeercon() would > return success with the context matching xfrm_sid. > > I have a hunch we are still on different pages here ... > > > In the NetLabel case: final skb->secmark would be network_t resulting in > > getpeercon to return network_t > > Yep, and I understand you would like to see it as unlabeled_t. I think > we both have valid arguments for either case and we are just waiting to > hear from others. I don't understand the argument for network_t, and it seems to violate our goals of 1) having consistent policy regardless of network labeling mechanism, and 2) having getpeercon() always return a subject label that can be used as a basis for avc_has_perm() and setexeccon() calls. -- Stephen Smalley National Security Agency ^ permalink raw reply [flat|nested] 33+ messages in thread
* RE: [PATCH v4 1/2] NetLabel: secid reconciliation support @ 2006-10-04 17:09 ` Venkat Yekkirala 0 siblings, 0 replies; 33+ messages in thread From: Venkat Yekkirala @ 2006-10-04 17:09 UTC (permalink / raw) To: Venkat Yekkirala, 'paul.moore@hp.com', 'netdev@vger.kernel.org', 'selinux@tycho.nsa.gov' Cc: 'eparis@redhat.com', 'jmorris@namei.org', 'sds@tycho.nsa.gov' > > @@ -3714,19 +3714,34 @@ static int selinux_skb_flow_in(struct sk > > if (skb->dev == &loopback_dev) > > return 1; > > > > + if (skb->secmark) > > + loc_sid = skb->secmark; > > + else > > + loc_sid = SECINITSID_NETMSG; > > + > > err = selinux_xfrm_decode_session(skb, &xfrm_sid, 0); > > BUG_ON(err); > > - > > - err = avc_has_perm(xfrm_sid, skb->secmark? : SECINITSID_NETMSG, > > - SECCLASS_PACKET, > > - PACKET__FLOW_IN, NULL); > > + err = selinux_netlbl_skb_sid(skb, > > + xfrm_sid ? xfrm_sid : loc_sid, > > + &nlbl_sid); > > if (err) > > goto out; > > > > - if (xfrm_sid) > > - skb->secmark = xfrm_sid; > > + if (nlbl_sid) > > + ext_sid = nlbl_sid; > > + else > > + ext_sid = xfrm_sid; > > There's a problem here in that it would require 2 different policies > depending on whether one is using netlabel or xfrm. Specifically, in > the absence of matching iptables contexts (secmark), as well as any external labeling via ipsec/NetLabel, > the skb here > will get: > > - 0 (xfrm case) > - network_t (netlabel) > > This has implications for getpeercon() where it would > > - fail with ENOPROTOOPT (xfrm case) > - returns network_t (netlabel) > > I would still argue that the nature of the domain being carried by > the packet is still unlabeled_t as implied by the null secmark. While > I view secmark/point as specifying BOTH a flow control point and a > default domain (incidentally using the same label more because of > implementation constrainst), I view network_t as purely a flow control > point. > > But I also realize there can be equally forceful arguments > for what this > patch does. > > What does the community think? We need to resolve it one way or the > other unless the above differences in behavior are desired or somehow > accounted for in policy and apps. > > > + > > + err = avc_has_perm(ext_sid, > > + loc_sid, > > + SECCLASS_PACKET, > > + PACKET__FLOW_IN, > > + NULL); > > + if (err) > > + goto out; > > > > - /* See if NetLabel can flow in thru the current secmark here */ > > + if (ext_sid) > > + skb->secmark = ext_sid; > > > > out: > > return err ? 0 : 1; > > > -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. ^ permalink raw reply [flat|nested] 33+ messages in thread
* RE: [PATCH v4 1/2] NetLabel: secid reconciliation support @ 2006-10-04 17:09 ` Venkat Yekkirala 0 siblings, 0 replies; 33+ messages in thread From: Venkat Yekkirala @ 2006-10-04 17:09 UTC (permalink / raw) To: Venkat Yekkirala, 'paul.moore@hp.com', 'netdev@vger.kernel.org', 'selinux@tycho.nsa.gov' Cc: 'eparis@redhat.com', 'jmorris@namei.org', 'sds@tycho.nsa.gov' > > @@ -3714,19 +3714,34 @@ static int selinux_skb_flow_in(struct sk > > if (skb->dev == &loopback_dev) > > return 1; > > > > + if (skb->secmark) > > + loc_sid = skb->secmark; > > + else > > + loc_sid = SECINITSID_NETMSG; > > + > > err = selinux_xfrm_decode_session(skb, &xfrm_sid, 0); > > BUG_ON(err); > > - > > - err = avc_has_perm(xfrm_sid, skb->secmark? : SECINITSID_NETMSG, > > - SECCLASS_PACKET, > > - PACKET__FLOW_IN, NULL); > > + err = selinux_netlbl_skb_sid(skb, > > + xfrm_sid ? xfrm_sid : loc_sid, > > + &nlbl_sid); > > if (err) > > goto out; > > > > - if (xfrm_sid) > > - skb->secmark = xfrm_sid; > > + if (nlbl_sid) > > + ext_sid = nlbl_sid; > > + else > > + ext_sid = xfrm_sid; > > There's a problem here in that it would require 2 different policies > depending on whether one is using netlabel or xfrm. Specifically, in > the absence of matching iptables contexts (secmark), as well as any external labeling via ipsec/NetLabel, > the skb here > will get: > > - 0 (xfrm case) > - network_t (netlabel) > > This has implications for getpeercon() where it would > > - fail with ENOPROTOOPT (xfrm case) > - returns network_t (netlabel) > > I would still argue that the nature of the domain being carried by > the packet is still unlabeled_t as implied by the null secmark. While > I view secmark/point as specifying BOTH a flow control point and a > default domain (incidentally using the same label more because of > implementation constrainst), I view network_t as purely a flow control > point. > > But I also realize there can be equally forceful arguments > for what this > patch does. > > What does the community think? We need to resolve it one way or the > other unless the above differences in behavior are desired or somehow > accounted for in policy and apps. > > > + > > + err = avc_has_perm(ext_sid, > > + loc_sid, > > + SECCLASS_PACKET, > > + PACKET__FLOW_IN, > > + NULL); > > + if (err) > > + goto out; > > > > - /* See if NetLabel can flow in thru the current secmark here */ > > + if (ext_sid) > > + skb->secmark = ext_sid; > > > > out: > > return err ? 0 : 1; > > > ^ permalink raw reply [flat|nested] 33+ messages in thread
* [PATCH 0/2] [PATCH 0/2] Updated NetLabel/secid-reconciliation bits and a bugfix @ 2006-10-04 15:46 paul.moore 2006-10-04 15:46 ` paul.moore 0 siblings, 1 reply; 33+ messages in thread From: paul.moore @ 2006-10-04 15:46 UTC (permalink / raw) To: netdev, selinux; +Cc: eparis, jmorris, sds, vyekkirala This patchset includes an update to the NetLabel/secid-reconciliation patch, replacing my "v3" patch from earlier this week, and a bugfix patch to cure a race condition found during testing this week. The bugfix patch does not rely on the secid patches and should be merged regardless as it fixes a bug which has been around since the very first NetLabel patches (not sure why I didn't see this sooner). -- paul moore linux security @ hp -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. ^ permalink raw reply [flat|nested] 33+ messages in thread
* [PATCH v4 1/2] NetLabel: secid reconciliation support 2006-10-04 15:46 [PATCH 0/2] [PATCH 0/2] Updated NetLabel/secid-reconciliation bits and a bugfix paul.moore @ 2006-10-04 15:46 ` paul.moore 0 siblings, 0 replies; 33+ messages in thread From: paul.moore @ 2006-10-04 15:46 UTC (permalink / raw) To: netdev, selinux; +Cc: eparis, jmorris, sds, vyekkirala, Paul Moore This patch provides the missing NetLabel support to the secid reconciliation patchset. Signed-off-by: Paul Moore <paul.moore@hp.com> --- security/selinux/hooks.c | 104 +++++++++++++++++---------- security/selinux/include/objsec.h | 1 security/selinux/include/selinux_netlabel.h | 28 +++---- security/selinux/ss/services.c | 106 ++++++++++------------------ 4 files changed, 121 insertions(+), 118 deletions(-) Index: net-2.6/security/selinux/hooks.c =================================================================== --- net-2.6.orig/security/selinux/hooks.c +++ net-2.6/security/selinux/hooks.c @@ -3465,6 +3465,10 @@ static int selinux_sock_rcv_skb_compat(s goto out; } + err = selinux_netlbl_sock_rcv_skb(sock_sid, sock_class, skb, ad); + if (err) + goto out; + err = selinux_xfrm_sock_rcv_skb(sock_sid, skb, ad); out: @@ -3501,10 +3505,7 @@ static int selinux_socket_sock_rcv_skb(s else err = avc_has_perm(sksec->sid, skb->secmark, SECCLASS_PACKET, PACKET__RECV, &ad); - if (err) - goto out; - err = selinux_netlbl_sock_rcv_skb(sksec, skb, &ad); out: return err; } @@ -3527,11 +3528,8 @@ static int selinux_socket_getpeersec_str peer_sid = ssec->peer_sid; } else if (isec->sclass == SECCLASS_TCP_SOCKET) { - peer_sid = selinux_netlbl_socket_getpeersec_stream(sock); - if (peer_sid == SECSID_NULL) { - ssec = sock->sk->sk_security; - peer_sid = ssec->peer_sid; - } + ssec = sock->sk->sk_security; + peer_sid = ssec->peer_sid; if (peer_sid == SECSID_NULL) { err = -ENOPROTOOPT; goto out; @@ -3573,13 +3571,13 @@ static int selinux_socket_getpeersec_dgr if (sock && (sock->sk->sk_family == PF_UNIX)) selinux_get_inode_sid(SOCK_INODE(sock), &peer_secid); else if (skb) { - peer_secid = selinux_netlbl_socket_getpeersec_dgram(skb); - if (peer_secid == SECSID_NULL) { - if (selinux_compat_net) + if (selinux_compat_net) { + peer_secid = selinux_netlbl_socket_getpeersec_dgram( + skb); + if (peer_secid == SECSID_NULL) peer_secid = selinux_socket_getpeer_dgram(skb); - else - peer_secid = skb->secmark; - } + } else + peer_secid = skb->secmark; } if (peer_secid == SECSID_NULL) @@ -3641,13 +3639,11 @@ static int selinux_inet_conn_request(str u32 newsid; u32 peersid; - newsid = selinux_netlbl_inet_conn_request(skb, sksec->sid); - if (newsid != SECSID_NULL) { - req->secid = newsid; - return 0; - } - if (selinux_compat_net) { + err = selinux_netlbl_skb_sid(skb, sksec->sid, &peersid); + if (err == 0 && peersid != SECSID_NULL) + goto out; + err = selinux_xfrm_decode_session(skb, &peersid, 0); BUG_ON(err); @@ -3659,6 +3655,7 @@ static int selinux_inet_conn_request(str } else peersid = skb->secmark; +out: err = security_sid_mls_copy(sksec->sid, peersid, &newsid); if (err) return err; @@ -3700,6 +3697,9 @@ static void selinux_req_classify_flow(co static int selinux_skb_flow_in(struct sk_buff *skb, unsigned short family) { u32 xfrm_sid; + u32 nlbl_sid; + u32 ext_sid; + u32 loc_sid; int err; if (selinux_compat_net) @@ -3714,19 +3714,34 @@ static int selinux_skb_flow_in(struct sk if (skb->dev == &loopback_dev) return 1; + if (skb->secmark) + loc_sid = skb->secmark; + else + loc_sid = SECINITSID_NETMSG; + err = selinux_xfrm_decode_session(skb, &xfrm_sid, 0); BUG_ON(err); - - err = avc_has_perm(xfrm_sid, skb->secmark? : SECINITSID_NETMSG, - SECCLASS_PACKET, - PACKET__FLOW_IN, NULL); + err = selinux_netlbl_skb_sid(skb, + xfrm_sid ? xfrm_sid : loc_sid, + &nlbl_sid); if (err) goto out; - if (xfrm_sid) - skb->secmark = xfrm_sid; + if (nlbl_sid) + ext_sid = nlbl_sid; + else + ext_sid = xfrm_sid; + + err = avc_has_perm(ext_sid, + loc_sid, + SECCLASS_PACKET, + PACKET__FLOW_IN, + NULL); + if (err) + goto out; - /* See if NetLabel can flow in thru the current secmark here */ + if (ext_sid) + skb->secmark = ext_sid; out: return err ? 0 : 1; @@ -3740,21 +3755,29 @@ static int selinux_skb_flow_out(struct s return 1; if (!skb->secmark) { + struct sk_security_struct *sksec = skb->sk->sk_security; u32 xfrm_sid; + u32 nlbl_sid; selinux_skb_xfrm_sid(skb, &xfrm_sid); + err = selinux_netlbl_skb_sid(skb, + xfrm_sid ? xfrm_sid : sksec->sid, + &nlbl_sid); + if (err) + goto out; - if (xfrm_sid) + if (nlbl_sid) + skb->secmark = nlbl_sid; + else if (xfrm_sid) skb->secmark = xfrm_sid; - else if (skb->sk) { - struct sk_security_struct *sksec = skb->sk->sk_security; + else if (skb->sk) skb->secmark = sksec->sid; - } } err = avc_has_perm(skb->secmark, nf_secid, SECCLASS_PACKET, PACKET__FLOW_OUT, NULL); +out: return err ? 0 : 1; } @@ -3903,17 +3926,24 @@ static unsigned int selinux_ip_postroute family, addrp, len); else { if (!skb->secmark) { + struct sk_security_struct *sksec = + skb->sk->sk_security; u32 xfrm_sid; + u32 nlbl_sid; selinux_skb_xfrm_sid(skb, &xfrm_sid); - - if (xfrm_sid) + err = selinux_netlbl_skb_sid(skb, + xfrm_sid ? xfrm_sid : sksec->sid, + &nlbl_sid); + if (err) + goto out; + + if (nlbl_sid) + skb->secmark = nlbl_sid; + else if (xfrm_sid) skb->secmark = xfrm_sid; - else if (skb->sk) { - struct sk_security_struct *sksec = - skb->sk->sk_security; + else if (skb->sk) skb->secmark = sksec->sid; - } } err = avc_has_perm(skb->secmark, SECINITSID_NETMSG, SECCLASS_PACKET, PACKET__FLOW_OUT, &ad); Index: net-2.6/security/selinux/include/objsec.h =================================================================== --- net-2.6.orig/security/selinux/include/objsec.h +++ net-2.6/security/selinux/include/objsec.h @@ -102,7 +102,6 @@ struct sk_security_struct { u32 sid; /* SID of this object */ u32 peer_sid; /* SID of peer */ #ifdef CONFIG_NETLABEL - u16 sclass; /* sock security class */ enum { /* NetLabel state */ NLBL_UNSET = 0, NLBL_REQUIRE, Index: net-2.6/security/selinux/include/selinux_netlabel.h =================================================================== --- net-2.6.orig/security/selinux/include/selinux_netlabel.h +++ net-2.6/security/selinux/include/selinux_netlabel.h @@ -42,17 +42,17 @@ int selinux_netlbl_socket_post_create(st int sock_family, u32 sid); void selinux_netlbl_sock_graft(struct sock *sk, struct socket *sock); -u32 selinux_netlbl_inet_conn_request(struct sk_buff *skb, u32 sock_sid); -int selinux_netlbl_sock_rcv_skb(struct sk_security_struct *sksec, +int selinux_netlbl_sock_rcv_skb(u32 sock_sid, + u16 sock_class, struct sk_buff *skb, struct avc_audit_data *ad); -u32 selinux_netlbl_socket_getpeersec_stream(struct socket *sock); u32 selinux_netlbl_socket_getpeersec_dgram(struct sk_buff *skb); void selinux_netlbl_sk_security_init(struct sk_security_struct *ssec, int family); void selinux_netlbl_sk_clone_security(struct sk_security_struct *ssec, struct sk_security_struct *newssec); int selinux_netlbl_inode_permission(struct inode *inode, int mask); +int selinux_netlbl_skb_sid(struct sk_buff *skb, u32 base_sid, u32 *sid); #else static inline void selinux_netlbl_cache_invalidate(void) { @@ -72,24 +72,14 @@ static inline void selinux_netlbl_sock_g return; } -static inline u32 selinux_netlbl_inet_conn_request(struct sk_buff *skb, - u32 sock_sid) -{ - return SECSID_NULL; -} - -static inline int selinux_netlbl_sock_rcv_skb(struct sk_security_struct *sksec, +static inline int selinux_netlbl_sock_rcv_skb(u32 sock_sid, + u16 sock_class, struct sk_buff *skb, struct avc_audit_data *ad) { return 0; } -static inline u32 selinux_netlbl_socket_getpeersec_stream(struct socket *sock) -{ - return SECSID_NULL; -} - static inline u32 selinux_netlbl_socket_getpeersec_dgram(struct sk_buff *skb) { return SECSID_NULL; @@ -114,6 +104,14 @@ static inline int selinux_netlbl_inode_p { return 0; } + +static inline int selinux_netlbl_skb_sid(struct sk_buff *skb, + u32 base_sid, + u32 *sid) +{ + *sid = SECSID_NULL; + return 0; +} #endif /* CONFIG_NETLABEL */ #endif Index: net-2.6/security/selinux/ss/services.c =================================================================== --- net-2.6.orig/security/selinux/ss/services.c +++ net-2.6/security/selinux/ss/services.c @@ -51,6 +51,7 @@ #include "selinux_netlabel.h" extern void selnl_notify_policyload(u32 seqno); +extern int selinux_compat_net; unsigned int policydb_loaded_version; static DEFINE_RWLOCK(policy_rwlock); @@ -2454,7 +2455,6 @@ void selinux_netlbl_sk_security_init(str void selinux_netlbl_sk_clone_security(struct sk_security_struct *ssec, struct sk_security_struct *newssec) { - newssec->sclass = ssec->sclass; if (ssec->nlbl_state != NLBL_UNSET) newssec->nlbl_state = NLBL_REQUIRE; else @@ -2476,11 +2476,8 @@ int selinux_netlbl_socket_post_create(st int sock_family, u32 sid) { - struct inode_security_struct *isec = SOCK_INODE(sock)->i_security; struct sk_security_struct *sksec = sock->sk->sk_security; - sksec->sclass = isec->sclass; - if (sock_family != PF_INET) return 0; @@ -2500,24 +2497,23 @@ int selinux_netlbl_socket_post_create(st */ void selinux_netlbl_sock_graft(struct sock *sk, struct socket *sock) { - struct inode_security_struct *isec = SOCK_INODE(sock)->i_security; struct sk_security_struct *sksec = sk->sk_security; struct netlbl_lsm_secattr secattr; u32 nlbl_peer_sid; - sksec->sclass = isec->sclass; - if (sk->sk_family != PF_INET) return; - netlbl_secattr_init(&secattr); - if (netlbl_sock_getattr(sk, &secattr) == 0 && - selinux_netlbl_secattr_to_sid(NULL, - &secattr, - sksec->sid, - &nlbl_peer_sid) == 0) - sksec->peer_sid = nlbl_peer_sid; - netlbl_secattr_destroy(&secattr, 0); + if (selinux_compat_net) { + netlbl_secattr_init(&secattr); + if (netlbl_sock_getattr(sk, &secattr) == 0 && + selinux_netlbl_secattr_to_sid(NULL, + &secattr, + sksec->sid, + &nlbl_peer_sid) == 0) + sksec->peer_sid = nlbl_peer_sid; + netlbl_secattr_destroy(&secattr, 0); + } sksec->nlbl_state = NLBL_REQUIRE; @@ -2528,32 +2524,6 @@ void selinux_netlbl_sock_graft(struct so } /** - * selinux_netlbl_inet_conn_request - Handle a new connection request - * @skb: the packet - * @sock_sid: the SID of the parent socket - * - * Description: - * If present, use the security attributes of the packet in @skb and the - * parent sock's SID to arrive at a SID for the new child sock. Returns the - * SID of the connection or SECSID_NULL on failure. - * - */ -u32 selinux_netlbl_inet_conn_request(struct sk_buff *skb, u32 sock_sid) -{ - int rc; - u32 peer_sid; - - rc = selinux_netlbl_skbuff_getsid(skb, sock_sid, &peer_sid); - if (rc != 0) - return SECSID_NULL; - - if (peer_sid == SECINITSID_UNLABELED) - return SECSID_NULL; - - return peer_sid; -} - -/** * selinux_netlbl_inode_permission - Verify the socket is NetLabel labeled * @inode: the file descriptor's inode * @mask: the permission mask @@ -2593,7 +2563,8 @@ int selinux_netlbl_inode_permission(stru /** * selinux_netlbl_sock_rcv_skb - Do an inbound access check using NetLabel - * @sksec: the sock's sk_security_struct + * @sock_sid: the socket's SID + * @sock_class: the socket's class * @skb: the packet * @ad: the audit data * @@ -2603,7 +2574,8 @@ int selinux_netlbl_inode_permission(stru * error. * */ -int selinux_netlbl_sock_rcv_skb(struct sk_security_struct *sksec, +int selinux_netlbl_sock_rcv_skb(u32 sock_sid, + u16 sock_class, struct sk_buff *skb, struct avc_audit_data *ad) { @@ -2618,7 +2590,7 @@ int selinux_netlbl_sock_rcv_skb(struct s if (netlbl_sid == SECINITSID_UNLABELED) return 0; - switch (sksec->sclass) { + switch (sock_class) { case SECCLASS_UDP_SOCKET: recv_perm = UDP_SOCKET__RECVFROM; break; @@ -2629,9 +2601,9 @@ int selinux_netlbl_sock_rcv_skb(struct s recv_perm = RAWIP_SOCKET__RECVFROM; } - rc = avc_has_perm(sksec->sid, + rc = avc_has_perm(sock_sid, netlbl_sid, - sksec->sclass, + sock_class, recv_perm, ad); if (rc == 0) @@ -2642,25 +2614,6 @@ int selinux_netlbl_sock_rcv_skb(struct s } /** - * selinux_netlbl_socket_getpeersec_stream - Return the connected peer's SID - * @sock: the socket - * - * Description: - * Examine @sock to find the connected peer's SID. Returns the SID on success - * or SECSID_NULL on error. - * - */ -u32 selinux_netlbl_socket_getpeersec_stream(struct socket *sock) -{ - struct sk_security_struct *sksec = sock->sk->sk_security; - - if (sksec->peer_sid == SECINITSID_UNLABELED) - return SECSID_NULL; - - return sksec->peer_sid; -} - -/** * selinux_netlbl_socket_getpeersec_dgram - Return the SID of a NetLabel packet * @skb: the packet * @@ -2686,4 +2639,27 @@ u32 selinux_netlbl_socket_getpeersec_dgr return peer_sid; } + +/** + * selinux_netlbl_skb_sid - Calculate the NetLabel SID of a packet + * @skb: the packet + * @base_sid: the SELinux SID to use as a context for MLS only attributes + * @sid: the SID + * + * Description: + * Call the NetLabel mechanism to get the security attributes of the given + * packet and use those attributes to determine the correct context/SID to + * assign to the packet. Returns zero on success, negative values on failure. + * + */ +int selinux_netlbl_skb_sid(struct sk_buff *skb, u32 base_sid, u32 *sid) +{ + int rc; + + rc = selinux_netlbl_skbuff_getsid(skb, base_sid, sid); + if (rc == 0 && *sid == SECINITSID_UNLABELED) + *sid = SECSID_NULL; + + return rc; +} #endif /* CONFIG_NETLABEL */ -- paul moore linux security @ hp -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. ^ permalink raw reply [flat|nested] 33+ messages in thread
* [PATCH v4 1/2] NetLabel: secid reconciliation support @ 2006-10-04 15:46 ` paul.moore 0 siblings, 0 replies; 33+ messages in thread From: paul.moore @ 2006-10-04 15:46 UTC (permalink / raw) To: netdev, selinux; +Cc: eparis, jmorris, sds, vyekkirala, Paul Moore [-- Attachment #1: netlabel-secid_support --] [-- Type: text/plain, Size: 13804 bytes --] This patch provides the missing NetLabel support to the secid reconciliation patchset. Signed-off-by: Paul Moore <paul.moore@hp.com> --- security/selinux/hooks.c | 104 +++++++++++++++++---------- security/selinux/include/objsec.h | 1 security/selinux/include/selinux_netlabel.h | 28 +++---- security/selinux/ss/services.c | 106 ++++++++++------------------ 4 files changed, 121 insertions(+), 118 deletions(-) Index: net-2.6/security/selinux/hooks.c =================================================================== --- net-2.6.orig/security/selinux/hooks.c +++ net-2.6/security/selinux/hooks.c @@ -3465,6 +3465,10 @@ static int selinux_sock_rcv_skb_compat(s goto out; } + err = selinux_netlbl_sock_rcv_skb(sock_sid, sock_class, skb, ad); + if (err) + goto out; + err = selinux_xfrm_sock_rcv_skb(sock_sid, skb, ad); out: @@ -3501,10 +3505,7 @@ static int selinux_socket_sock_rcv_skb(s else err = avc_has_perm(sksec->sid, skb->secmark, SECCLASS_PACKET, PACKET__RECV, &ad); - if (err) - goto out; - err = selinux_netlbl_sock_rcv_skb(sksec, skb, &ad); out: return err; } @@ -3527,11 +3528,8 @@ static int selinux_socket_getpeersec_str peer_sid = ssec->peer_sid; } else if (isec->sclass == SECCLASS_TCP_SOCKET) { - peer_sid = selinux_netlbl_socket_getpeersec_stream(sock); - if (peer_sid == SECSID_NULL) { - ssec = sock->sk->sk_security; - peer_sid = ssec->peer_sid; - } + ssec = sock->sk->sk_security; + peer_sid = ssec->peer_sid; if (peer_sid == SECSID_NULL) { err = -ENOPROTOOPT; goto out; @@ -3573,13 +3571,13 @@ static int selinux_socket_getpeersec_dgr if (sock && (sock->sk->sk_family == PF_UNIX)) selinux_get_inode_sid(SOCK_INODE(sock), &peer_secid); else if (skb) { - peer_secid = selinux_netlbl_socket_getpeersec_dgram(skb); - if (peer_secid == SECSID_NULL) { - if (selinux_compat_net) + if (selinux_compat_net) { + peer_secid = selinux_netlbl_socket_getpeersec_dgram( + skb); + if (peer_secid == SECSID_NULL) peer_secid = selinux_socket_getpeer_dgram(skb); - else - peer_secid = skb->secmark; - } + } else + peer_secid = skb->secmark; } if (peer_secid == SECSID_NULL) @@ -3641,13 +3639,11 @@ static int selinux_inet_conn_request(str u32 newsid; u32 peersid; - newsid = selinux_netlbl_inet_conn_request(skb, sksec->sid); - if (newsid != SECSID_NULL) { - req->secid = newsid; - return 0; - } - if (selinux_compat_net) { + err = selinux_netlbl_skb_sid(skb, sksec->sid, &peersid); + if (err == 0 && peersid != SECSID_NULL) + goto out; + err = selinux_xfrm_decode_session(skb, &peersid, 0); BUG_ON(err); @@ -3659,6 +3655,7 @@ static int selinux_inet_conn_request(str } else peersid = skb->secmark; +out: err = security_sid_mls_copy(sksec->sid, peersid, &newsid); if (err) return err; @@ -3700,6 +3697,9 @@ static void selinux_req_classify_flow(co static int selinux_skb_flow_in(struct sk_buff *skb, unsigned short family) { u32 xfrm_sid; + u32 nlbl_sid; + u32 ext_sid; + u32 loc_sid; int err; if (selinux_compat_net) @@ -3714,19 +3714,34 @@ static int selinux_skb_flow_in(struct sk if (skb->dev == &loopback_dev) return 1; + if (skb->secmark) + loc_sid = skb->secmark; + else + loc_sid = SECINITSID_NETMSG; + err = selinux_xfrm_decode_session(skb, &xfrm_sid, 0); BUG_ON(err); - - err = avc_has_perm(xfrm_sid, skb->secmark? : SECINITSID_NETMSG, - SECCLASS_PACKET, - PACKET__FLOW_IN, NULL); + err = selinux_netlbl_skb_sid(skb, + xfrm_sid ? xfrm_sid : loc_sid, + &nlbl_sid); if (err) goto out; - if (xfrm_sid) - skb->secmark = xfrm_sid; + if (nlbl_sid) + ext_sid = nlbl_sid; + else + ext_sid = xfrm_sid; + + err = avc_has_perm(ext_sid, + loc_sid, + SECCLASS_PACKET, + PACKET__FLOW_IN, + NULL); + if (err) + goto out; - /* See if NetLabel can flow in thru the current secmark here */ + if (ext_sid) + skb->secmark = ext_sid; out: return err ? 0 : 1; @@ -3740,21 +3755,29 @@ static int selinux_skb_flow_out(struct s return 1; if (!skb->secmark) { + struct sk_security_struct *sksec = skb->sk->sk_security; u32 xfrm_sid; + u32 nlbl_sid; selinux_skb_xfrm_sid(skb, &xfrm_sid); + err = selinux_netlbl_skb_sid(skb, + xfrm_sid ? xfrm_sid : sksec->sid, + &nlbl_sid); + if (err) + goto out; - if (xfrm_sid) + if (nlbl_sid) + skb->secmark = nlbl_sid; + else if (xfrm_sid) skb->secmark = xfrm_sid; - else if (skb->sk) { - struct sk_security_struct *sksec = skb->sk->sk_security; + else if (skb->sk) skb->secmark = sksec->sid; - } } err = avc_has_perm(skb->secmark, nf_secid, SECCLASS_PACKET, PACKET__FLOW_OUT, NULL); +out: return err ? 0 : 1; } @@ -3903,17 +3926,24 @@ static unsigned int selinux_ip_postroute family, addrp, len); else { if (!skb->secmark) { + struct sk_security_struct *sksec = + skb->sk->sk_security; u32 xfrm_sid; + u32 nlbl_sid; selinux_skb_xfrm_sid(skb, &xfrm_sid); - - if (xfrm_sid) + err = selinux_netlbl_skb_sid(skb, + xfrm_sid ? xfrm_sid : sksec->sid, + &nlbl_sid); + if (err) + goto out; + + if (nlbl_sid) + skb->secmark = nlbl_sid; + else if (xfrm_sid) skb->secmark = xfrm_sid; - else if (skb->sk) { - struct sk_security_struct *sksec = - skb->sk->sk_security; + else if (skb->sk) skb->secmark = sksec->sid; - } } err = avc_has_perm(skb->secmark, SECINITSID_NETMSG, SECCLASS_PACKET, PACKET__FLOW_OUT, &ad); Index: net-2.6/security/selinux/include/objsec.h =================================================================== --- net-2.6.orig/security/selinux/include/objsec.h +++ net-2.6/security/selinux/include/objsec.h @@ -102,7 +102,6 @@ struct sk_security_struct { u32 sid; /* SID of this object */ u32 peer_sid; /* SID of peer */ #ifdef CONFIG_NETLABEL - u16 sclass; /* sock security class */ enum { /* NetLabel state */ NLBL_UNSET = 0, NLBL_REQUIRE, Index: net-2.6/security/selinux/include/selinux_netlabel.h =================================================================== --- net-2.6.orig/security/selinux/include/selinux_netlabel.h +++ net-2.6/security/selinux/include/selinux_netlabel.h @@ -42,17 +42,17 @@ int selinux_netlbl_socket_post_create(st int sock_family, u32 sid); void selinux_netlbl_sock_graft(struct sock *sk, struct socket *sock); -u32 selinux_netlbl_inet_conn_request(struct sk_buff *skb, u32 sock_sid); -int selinux_netlbl_sock_rcv_skb(struct sk_security_struct *sksec, +int selinux_netlbl_sock_rcv_skb(u32 sock_sid, + u16 sock_class, struct sk_buff *skb, struct avc_audit_data *ad); -u32 selinux_netlbl_socket_getpeersec_stream(struct socket *sock); u32 selinux_netlbl_socket_getpeersec_dgram(struct sk_buff *skb); void selinux_netlbl_sk_security_init(struct sk_security_struct *ssec, int family); void selinux_netlbl_sk_clone_security(struct sk_security_struct *ssec, struct sk_security_struct *newssec); int selinux_netlbl_inode_permission(struct inode *inode, int mask); +int selinux_netlbl_skb_sid(struct sk_buff *skb, u32 base_sid, u32 *sid); #else static inline void selinux_netlbl_cache_invalidate(void) { @@ -72,24 +72,14 @@ static inline void selinux_netlbl_sock_g return; } -static inline u32 selinux_netlbl_inet_conn_request(struct sk_buff *skb, - u32 sock_sid) -{ - return SECSID_NULL; -} - -static inline int selinux_netlbl_sock_rcv_skb(struct sk_security_struct *sksec, +static inline int selinux_netlbl_sock_rcv_skb(u32 sock_sid, + u16 sock_class, struct sk_buff *skb, struct avc_audit_data *ad) { return 0; } -static inline u32 selinux_netlbl_socket_getpeersec_stream(struct socket *sock) -{ - return SECSID_NULL; -} - static inline u32 selinux_netlbl_socket_getpeersec_dgram(struct sk_buff *skb) { return SECSID_NULL; @@ -114,6 +104,14 @@ static inline int selinux_netlbl_inode_p { return 0; } + +static inline int selinux_netlbl_skb_sid(struct sk_buff *skb, + u32 base_sid, + u32 *sid) +{ + *sid = SECSID_NULL; + return 0; +} #endif /* CONFIG_NETLABEL */ #endif Index: net-2.6/security/selinux/ss/services.c =================================================================== --- net-2.6.orig/security/selinux/ss/services.c +++ net-2.6/security/selinux/ss/services.c @@ -51,6 +51,7 @@ #include "selinux_netlabel.h" extern void selnl_notify_policyload(u32 seqno); +extern int selinux_compat_net; unsigned int policydb_loaded_version; static DEFINE_RWLOCK(policy_rwlock); @@ -2454,7 +2455,6 @@ void selinux_netlbl_sk_security_init(str void selinux_netlbl_sk_clone_security(struct sk_security_struct *ssec, struct sk_security_struct *newssec) { - newssec->sclass = ssec->sclass; if (ssec->nlbl_state != NLBL_UNSET) newssec->nlbl_state = NLBL_REQUIRE; else @@ -2476,11 +2476,8 @@ int selinux_netlbl_socket_post_create(st int sock_family, u32 sid) { - struct inode_security_struct *isec = SOCK_INODE(sock)->i_security; struct sk_security_struct *sksec = sock->sk->sk_security; - sksec->sclass = isec->sclass; - if (sock_family != PF_INET) return 0; @@ -2500,24 +2497,23 @@ int selinux_netlbl_socket_post_create(st */ void selinux_netlbl_sock_graft(struct sock *sk, struct socket *sock) { - struct inode_security_struct *isec = SOCK_INODE(sock)->i_security; struct sk_security_struct *sksec = sk->sk_security; struct netlbl_lsm_secattr secattr; u32 nlbl_peer_sid; - sksec->sclass = isec->sclass; - if (sk->sk_family != PF_INET) return; - netlbl_secattr_init(&secattr); - if (netlbl_sock_getattr(sk, &secattr) == 0 && - selinux_netlbl_secattr_to_sid(NULL, - &secattr, - sksec->sid, - &nlbl_peer_sid) == 0) - sksec->peer_sid = nlbl_peer_sid; - netlbl_secattr_destroy(&secattr, 0); + if (selinux_compat_net) { + netlbl_secattr_init(&secattr); + if (netlbl_sock_getattr(sk, &secattr) == 0 && + selinux_netlbl_secattr_to_sid(NULL, + &secattr, + sksec->sid, + &nlbl_peer_sid) == 0) + sksec->peer_sid = nlbl_peer_sid; + netlbl_secattr_destroy(&secattr, 0); + } sksec->nlbl_state = NLBL_REQUIRE; @@ -2528,32 +2524,6 @@ void selinux_netlbl_sock_graft(struct so } /** - * selinux_netlbl_inet_conn_request - Handle a new connection request - * @skb: the packet - * @sock_sid: the SID of the parent socket - * - * Description: - * If present, use the security attributes of the packet in @skb and the - * parent sock's SID to arrive at a SID for the new child sock. Returns the - * SID of the connection or SECSID_NULL on failure. - * - */ -u32 selinux_netlbl_inet_conn_request(struct sk_buff *skb, u32 sock_sid) -{ - int rc; - u32 peer_sid; - - rc = selinux_netlbl_skbuff_getsid(skb, sock_sid, &peer_sid); - if (rc != 0) - return SECSID_NULL; - - if (peer_sid == SECINITSID_UNLABELED) - return SECSID_NULL; - - return peer_sid; -} - -/** * selinux_netlbl_inode_permission - Verify the socket is NetLabel labeled * @inode: the file descriptor's inode * @mask: the permission mask @@ -2593,7 +2563,8 @@ int selinux_netlbl_inode_permission(stru /** * selinux_netlbl_sock_rcv_skb - Do an inbound access check using NetLabel - * @sksec: the sock's sk_security_struct + * @sock_sid: the socket's SID + * @sock_class: the socket's class * @skb: the packet * @ad: the audit data * @@ -2603,7 +2574,8 @@ int selinux_netlbl_inode_permission(stru * error. * */ -int selinux_netlbl_sock_rcv_skb(struct sk_security_struct *sksec, +int selinux_netlbl_sock_rcv_skb(u32 sock_sid, + u16 sock_class, struct sk_buff *skb, struct avc_audit_data *ad) { @@ -2618,7 +2590,7 @@ int selinux_netlbl_sock_rcv_skb(struct s if (netlbl_sid == SECINITSID_UNLABELED) return 0; - switch (sksec->sclass) { + switch (sock_class) { case SECCLASS_UDP_SOCKET: recv_perm = UDP_SOCKET__RECVFROM; break; @@ -2629,9 +2601,9 @@ int selinux_netlbl_sock_rcv_skb(struct s recv_perm = RAWIP_SOCKET__RECVFROM; } - rc = avc_has_perm(sksec->sid, + rc = avc_has_perm(sock_sid, netlbl_sid, - sksec->sclass, + sock_class, recv_perm, ad); if (rc == 0) @@ -2642,25 +2614,6 @@ int selinux_netlbl_sock_rcv_skb(struct s } /** - * selinux_netlbl_socket_getpeersec_stream - Return the connected peer's SID - * @sock: the socket - * - * Description: - * Examine @sock to find the connected peer's SID. Returns the SID on success - * or SECSID_NULL on error. - * - */ -u32 selinux_netlbl_socket_getpeersec_stream(struct socket *sock) -{ - struct sk_security_struct *sksec = sock->sk->sk_security; - - if (sksec->peer_sid == SECINITSID_UNLABELED) - return SECSID_NULL; - - return sksec->peer_sid; -} - -/** * selinux_netlbl_socket_getpeersec_dgram - Return the SID of a NetLabel packet * @skb: the packet * @@ -2686,4 +2639,27 @@ u32 selinux_netlbl_socket_getpeersec_dgr return peer_sid; } + +/** + * selinux_netlbl_skb_sid - Calculate the NetLabel SID of a packet + * @skb: the packet + * @base_sid: the SELinux SID to use as a context for MLS only attributes + * @sid: the SID + * + * Description: + * Call the NetLabel mechanism to get the security attributes of the given + * packet and use those attributes to determine the correct context/SID to + * assign to the packet. Returns zero on success, negative values on failure. + * + */ +int selinux_netlbl_skb_sid(struct sk_buff *skb, u32 base_sid, u32 *sid) +{ + int rc; + + rc = selinux_netlbl_skbuff_getsid(skb, base_sid, sid); + if (rc == 0 && *sid == SECINITSID_UNLABELED) + *sid = SECSID_NULL; + + return rc; +} #endif /* CONFIG_NETLABEL */ -- paul moore linux security @ hp ^ permalink raw reply [flat|nested] 33+ messages in thread
end of thread, other threads:[~2006-10-04 22:43 UTC | newest] Thread overview: 33+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2006-10-04 16:59 [PATCH v4 1/2] NetLabel: secid reconciliation support Venkat Yekkirala 2006-10-04 16:59 ` Venkat Yekkirala 2006-10-04 18:45 ` Paul Moore 2006-10-04 18:45 ` Paul Moore -- strict thread matches above, loose matches on Subject: below -- 2006-10-04 19:53 Venkat Yekkirala 2006-10-04 19:53 ` Venkat Yekkirala 2006-10-04 20:08 ` Paul Moore 2006-10-04 20:08 ` Paul Moore 2006-10-04 20:27 ` Stephen Smalley 2006-10-04 20:52 ` Paul Moore 2006-10-04 21:12 ` Steve Grubb 2006-10-04 22:03 ` Joe Nall 2006-10-04 22:43 ` Paul Moore 2006-10-04 22:18 ` Linda Knippers 2006-10-04 20:12 ` Stephen Smalley 2006-10-04 19:37 Venkat Yekkirala 2006-10-04 19:37 ` Venkat Yekkirala 2006-10-04 19:52 ` Paul Moore 2006-10-04 19:52 ` Paul Moore 2006-10-04 20:09 ` Stephen Smalley 2006-10-04 20:21 ` Paul Moore 2006-10-04 20:39 ` Stephen Smalley 2006-10-04 20:53 ` Paul Moore 2006-10-04 19:02 Venkat Yekkirala 2006-10-04 19:02 ` Venkat Yekkirala 2006-10-04 19:27 ` Paul Moore 2006-10-04 19:27 ` Paul Moore 2006-10-04 19:45 ` Stephen Smalley 2006-10-04 19:45 ` Stephen Smalley 2006-10-04 17:09 Venkat Yekkirala 2006-10-04 17:09 ` Venkat Yekkirala 2006-10-04 15:46 [PATCH 0/2] [PATCH 0/2] Updated NetLabel/secid-reconciliation bits and a bugfix paul.moore 2006-10-04 15:46 ` [PATCH v4 1/2] NetLabel: secid reconciliation support paul.moore 2006-10-04 15:46 ` paul.moore
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.