Stephen Smalley wrote: > On Thu, 2006-06-15 at 12:22 -0400, Paul Moore wrote: >>Hmm. I haven't looked at the selinuxfs bits in much detail yet to even >>see how something like that would work but I'll look into it as that >>seems like a much better solution than the sysctl approach. > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=195238 >
Thanks for the link, I'll let the dust settle a bit before I write anything. >>I don't believe it is currently being addressed in the xfrm case either >>as it came up during the LSPP call two weeks ago. If I remember >>correctly they were planning on relabeling the socket too ... > > <snip> > >>I thought that protecting the relabel with a relabelto check would >>suffice to ensure that unwanted socket relabeling was protected. >>However, based on your comments I'm guessing that I'm not understanding >>something very fundamental here ... > > relabelfrom/relabelto are supposed to be process-to-object checks > applied upon setxattr (if setxattr were implemented for sockets), as > with files. The relationship between the old and new label would > typically be handled via a security_validate_transition() call in the > code and validatetrans constraints in the policy, not via relabelto. > > But relabeling is undesirable in general; it violates the tranquility > property and breaks your ability to reason about information flow in the > system. And automatic relabeling based on potentially untrustworthy > input is worse yet. > > http://beyondabstraction.net/2005/10/13/subject-object-tranquility/ > http://beyondabstraction.net/2005/11/07/subject-object-tranquility-part-2/ > Between the two links you just posted and a quick look at the xinetd sources I think I see the problem - when a socket is accept()'ed it takes the SID of the listening/parent socket, shouldn't it take the SID of the current task similar to when the parent socket is first created? If I am understanding everything correctly, this would allow the listen-fork-accept method of xinetd to work correctly and still maintain tranquility. -- paul moore linux security @ hp -- redhat-lspp mailing list [email protected] https://www.redhat.com/mailman/listinfo/redhat-lspp
