[redhat-lspp] Updated NetLabel patch

[Stephen Smalley]

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;

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.

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

> Yes, readiness for 2.6.18 has been a big fear of mine for a while now.
> I'm faced with a bit of a problem as I tend to feel very strongly that
> we need some form of labeled networking in the LSPP evaluation that is
> compatabile with existing infrastructure.  If we don't have it I think
> the integration of Linux/SELinux into existing trusted networks will be
> seriously hampered.  Although, I wasn't able to start work on it until
> early this year and as you pointed out the community who actually wants
> to see this patch succeed is rather small when compared to the larger
> Linux community.

It isn't so much an issue of who wants to see it succeed as it is a
matter of limited resources (in terms of people who are able, willing,
and have sufficient time to review and test it), a large and complex
body of code, the relative newness of that code, and a fair number of
other patches all competing for the same attention (e.g. MLS xfrm
changes, which are an extension of an already existing infrastructure
and a number of smaller patches that are much narrower in their scope).

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

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

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?
 
-- 
Stephen Smalley
National Security Agency