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 - 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