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@xxxxxxxxxxxxx To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx. To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
