[redhat-lspp] Updated NetLabel patch

[Stephen Smalley]

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:
> >>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.

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.

-- 
Stephen Smalley
National Security Agency