[redhat-lspp] Updated NetLabel patch

[Paul Moore]

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