[redhat-lspp] Updated NetLabel patch

[Paul Moore]

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