[prev in list] [next in list] [prev in thread] [next in thread] 

List:       selinux
Subject:    Re: [PATCH] selinux: fix the default socket labeling in sock_graft()
From:       Paul Moore <pmoore () redhat ! com>
Date:       2014-07-10 20:57:10
Message-ID: 1897757.g23DVqLUrV () sifl
[Download RAW message or body]

On Thursday, July 10, 2014 03:57:15 PM Stephen Smalley wrote:
> On 07/10/2014 03:47 PM, Paul Moore wrote:
> > On Thursday, July 10, 2014 01:45:55 PM Stephen Smalley wrote:
> >> It seems a bit fragile though and certainly doesn't align with the
> >> sock_graft hook documentation anymore.  Wondering if we should assert
> >> that sksec->sid is not SECINITSID_UNLABELED in the inet/inet6/unix case
> >> (i.e. that sksec->sid has been set prior to copying it to isec->sid) ...
> > 
> > Now that I'm changing the code I'm wondering if we could ever arrive at a
> > situation where sksec->sid would legitimately end up as
> > SECINITSID_UNLABELED in selinux_sock_graft().  In the normal case of no
> > labeled networking, the sksec->sid label should end up as SECSID_NULL so
> > I'm not to worried about that, but if would you get the
> > SECINITSID_UNLABELED SID if you fed "...:unlabeled_t:..." into
> > security_secctx_to_secid()?  I'm pretty sure the answer is "no", but I
> > haven't looked at that code in a while.
> 
> Yes, you can get back an initial SID from security_secctx_to_secid() if
> the context string matches.  In what scenario would sksec->sid be set to
> the result of security_secctx_to_secid() on a context string though, and
> from where would that context string originate?  At most we only copy
> the MLS attributes of the peer label, right?

Yes, my apologies, I wasn't think through the full process to the MLS 
attribute copy.

Regardless, I suppose I'm still a bit leery of adding the assertion in the 
AF_INET/AF_INET6/AF_UNIX case, especially since that code has been there for 
years now without problem (I know, famous last words).  I don't have a problem 
adding an assertion in the other, default case.

-- 
paul moore
security and virtualization @ redhat

_______________________________________________
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.
[prev in list] [next in list] [prev in thread] [next in thread]