From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <45240B3B.3040603@hp.com> Date: Wed, 04 Oct 2006 15:27:55 -0400 From: Paul Moore MIME-Version: 1.0 To: Venkat Yekkirala Cc: netdev@vger.kernel.org, selinux@tycho.nsa.gov, eparis@redhat.com, jmorris@namei.org, sds@tycho.nsa.gov Subject: Re: [PATCH v4 1/2] NetLabel: secid reconciliation support References: <36282A1733C57546BE392885C0618592015CF939@chaos.tcs.tcs-sec.com> In-Reply-To: <36282A1733C57546BE392885C0618592015CF939@chaos.tcs.tcs-sec.com> Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov Venkat Yekkirala wrote: >> * XFRM present >> >> xfrm_sid = >> 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 = >> 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. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paul Moore Subject: Re: [PATCH v4 1/2] NetLabel: secid reconciliation support Date: Wed, 04 Oct 2006 15:27:55 -0400 Message-ID: <45240B3B.3040603@hp.com> References: <36282A1733C57546BE392885C0618592015CF939@chaos.tcs.tcs-sec.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netdev@vger.kernel.org, selinux@tycho.nsa.gov, eparis@redhat.com, jmorris@namei.org, sds@tycho.nsa.gov Return-path: Received: from atlrel6.hp.com ([156.153.255.205]:39404 "EHLO atlrel6.hp.com") by vger.kernel.org with ESMTP id S1750822AbWJDT16 (ORCPT ); Wed, 4 Oct 2006 15:27:58 -0400 To: Venkat Yekkirala In-Reply-To: <36282A1733C57546BE392885C0618592015CF939@chaos.tcs.tcs-sec.com> Sender: netdev-owner@vger.kernel.org List-Id: netdev.vger.kernel.org Venkat Yekkirala wrote: >> * XFRM present >> >> xfrm_sid = >> 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 = >> 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