On Thu, 2006-06-15 at 12:22 -0400, Paul Moore wrote: > > BTW, you are overloading the meaning of recv_msg permissions above. > > Although I suppose the port-based ones are going away due to secmark. I > > suppose there is no overlap in the type space. > > Yes, but it seems like a logical extension to the recv_msg permission. > I can add a new permission if it makes sense (I'm a little unclear as to > which you would prefer).
I suppose it is ok for now. > 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 > 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/ -- Stephen Smalley National Security Agency -- redhat-lspp mailing list [email protected] https://www.redhat.com/mailman/listinfo/redhat-lspp
