[redhat-lspp] Updated NetLabel patch

[Paul Moore]

Stephen Smalley wrote:
> On Wed, 2006-06-14 at 17:00 -0400, Paul Moore wrote:
>>After your previous mail and before this one, I changed the rcv_skb()
>>code a bit so that I dropped my changes to xfrm.c and rewrote the bottom
>>of selinux_socket_sock_rcv_skb() to look like this:
>>
>>	err = security_netlbl_skbuff_getsid(skb,
>>					    sock_sid,
>>					    &netlbl_sid);
>>	if (err)
>>		goto out;
>>
>>	if (netlbl_sid != SECSID_NULL &&
>>            netlbl_sid != SECINITSID_UNLABELED) {
>>		err = avc_has_perm(sock_sid,
>>				   netlbl_sid,
>>				   sock_class,
>>				   recv_perm,
>>				   &ad);
>>		if (err) {
>>			security_netlbl_skbuff_err(skb, err);
>>			goto out;
>>		}
>>	}
> 
> 
> I would think you could collapse the above into a single function call
> to netlabel, as with the xfrm call.  Something like:
> 	err = selinux_netlabel_sock_rcv_skb(sock_sid, sock_class, ad, skb);
> 	if (err)
> 		goto out;

That would make sense wouldn't it ;)

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

>>... it still uses relies on the xfrm unlabeled check but does so much
>>more cleanly then before.  Although it sounds like you want a separate
>>NetLabel unlabeled check; earlier patches had one but I dropped it due
>>to backward compatability concerns from RH (they didn't want to have to
>>force new policy with a new kernel).  Using sysctl variables was
>>mentioned but that still seems a bit awkward to me as this would be the
>>only LSM/SELinux sysctl variable (at least sysctl -a doesn't show
>>anything), but then again if that is the only solution left ...
> 
> No, we'd either use selinuxfs or a generic mechanism in the module for
> discovering the set of permissions understood by the policy and then
> bypassing checks that are not yet understood by the current policy.
> 

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.

>>I guess the other question that needs to be asked at some point is will
>>RH be willing to take the NetLabel patch for RHEL5 if it doesn't hit
>>2.6.18?  The gist I have gotten so far is "probably not" but I'm about
>>as qualified to make that call as I am to play on the US World Cup team.
>  
> Likewise for me ;)  I'd suspect that they might take it as long as it
> _is_ accepted for 2.6.19; the main issue is not wanting to have to
> maintain code that has no upstream potential forever, IIUC.  But I don't
> make the call obviously.
> 

I guess we should stick to writing code then :)

>>Okay, let me rewind a bit since I'm pretty sure I got the discussion a
>>bit out of whack.  Take the all to familiar telnet-being-run-from-xinetd
>>case as an example (using only MLS levels).  My understanding is that
>>the xinetd daemon runs from s0-s15 so while it is running at s0 it is
>>cleared up to s15, therefore it should be able to receive packets as
>>level s8 and assuming policy supports it (and xinetd gets patched) it
>>should be able to fork a telnetd instance at s8 to handle the incoming
>>traffic.
>>
>>The problem I am facing is how to set the IP options on the accept()'ed
>>socket to s8?
> 
> How is this being handled in the xfrm case (TCS folks cc'd)?  The
> parallel is selection of the appropriate outbound SA for an accept'd
> socket.
> 

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

>
> Where do you check that the socket is allowed to emit packets at that
> level?  What does it mean to dynamically switch the label of that socket
> when xinetd still holds a reference to it and can receive or generate
> traffic on it?
>  

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

-- 
paul moore
linux security @ hp