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