Stephen Smalley wrote: > On Thu, 2006-06-15 at 14:13 -0400, Paul Moore wrote: >>Stephen Smalley wrote: >>>On Thu, 2006-06-15 at 12:22 -0400, Paul Moore wrote: >>>>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. > > > I don't think so. xinetd has to accept the new connection before it can > get the peer context, so the new connection socket is always created in > xinetd's context. Plus fork doesn't change contexts - fork isn't a new > subject operation in truth, as the child process inherits everything > from the parent; you can't control the inheritance of state or the > initialization of the new subject meaningfully, which is why we do our > context transitions upon execve. >
Sorry, I typed fork when I mean fork-and-exec, I understand why you wouldn't want to do a context transition on a fork. I guess I need to look at the xinetd sources as well as Trent's xinetd patch one more time as I didn't remember xinetd doing an accept(). I thought xinetd just setup a socket and waited for a select() to fire for the socket and then did the fork-and-exec. If that isn't the case then this is really going to require some thought ... -- paul moore linux security @ hp -- redhat-lspp mailing list [email protected] https://www.redhat.com/mailman/listinfo/redhat-lspp
