[redhat-lspp] Updated NetLabel patch

[Stephen Smalley]

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