From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <45241F61.6090709@hp.com> Date: Wed, 04 Oct 2006 16:53:53 -0400 From: Paul Moore MIME-Version: 1.0 To: Stephen Smalley Cc: Venkat Yekkirala , selinux@tycho.nsa.gov, eparis@redhat.com, jmorris@namei.org Subject: Re: [PATCH v4 1/2] NetLabel: secid reconciliation support References: <36282A1733C57546BE392885C0618592015CF961@chaos.tcs.tcs-sec.com> <45241108.5040303@hp.com> <1159992565.19176.240.camel@moss-spartans.epoch.ncsc.mil> <452417AE.3090203@hp.com> <1159994354.19176.267.camel@moss-spartans.epoch.ncsc.mil> In-Reply-To: <1159994354.19176.267.camel@moss-spartans.epoch.ncsc.mil> Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov 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 = >>>>>>>>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 = >>>> 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.