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