[redhat-lspp] Updated NetLabel patch

[Paul Moore]

Stephen Smalley wrote:
> On Wed, 2006-06-14 at 11:32 -0400, Paul Moore wrote:
>>This is the greater question of how to resolve all the networking hooks
>>and I have given up any opinions on how to best handle this ... as you
>>pointed out the NetLabel check is only done if the IPsec SA is not
>>labeled.  Would you prefer the NetLabel check to happen regardless (it's
>> an easy change to make)?
> 
> I'd be inclined to check whether there is also a CIPSO label, and if so,
> apply some permission check between the corresponding SID and the
> IPSEC-determined one to see whether they form a legal pairing (e.g. from
> a MLS POV, is the CIPSO label within the range of the IPSEC label, which
> could be written as a MLS constraint on that permission).  Then you
> could do multi-level traffic over a single SA via CIPSO labeling, while
> preserving a binding between the SA's security characteristics and the
> CIPSO label.
> 

I'll have to stare at the code a bit to figure out how to make that
work.  Although at some point in the future I would like to have the
option to attach the entire SELinux context to the packet using CIPSO
which might make things more interesting in this regard, perhaps not.

>>>I think we need to restructure this to retain encapsulation of xfrm and
>>>netlabel.
>>
>>Do you have any suggestions?
> 
> 
>>From the IPSEC/xfrm POV, the packet is still unlabeled, so I think you
> want to leave that check in the xfrm code (i.e. can we accept a packet
> that has no IPSEC/xfrm label on this socket?).  Then you separately
> apply your check (including potentially your , but do all of that in
> your own netlabel hook as with the xfrm check, not directly in
> selinux_sock_rcv_skb.  That goes against the theme of integrating them
> all together, but I think for now at least, we need to keep them
> orthogonal.

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;
		}
	}

	err = selinux_xfrm_sock_rcv_skb(sock_sid, skb);

out:	
	return err;
}

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

>>Argh, I knew somebody was going to complan - I just figured it would be
>>James ;)  I apologize in advance, but I have to ask, how hard are you
>>complaining?  Anything can of course be changed but I'm looking at some
>>already tough dates from RH for RHEL5 ...
> 
> The moral of the story is don't comment the dark corners of your code ;)
> I'm not hugely concerned about this particular point, although hopefully
> some improvements in the netlink handling will occur and that can be
> applied to your code as well.

Okay.  I guess I'll wait and see what happens.

> I'm not sure whether 2.6.18 is a
> realistic target for NetLabel; the merge window opens once 2.6.17 is
> released, but my impression is that what gets merged at that point is
> generally code that has already undergone wider review and testing in a
> subsystem tree, not code that was just developed.  It is more of an
> integration stage, with new development then getting queued up for the
> following (e.g. 2.6.19) release.  Part of the problem here as well is
> that you don't have much of a testing community for this particular bit
> of functionality.

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.

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.

>>The real need from my point of view is the call to
>>security_netlbl_socket_setsid() so that we can set the IP options
>>correctly for the accept()'ed socket.  I thought it also just made sense
>>to relabel the socket's SID as well to reflect the change.
>>
>>I can drop the change in the socket's SID but I think there should still
>>be some relabelto check before accept()'ing the socket.
> 
> Neither change makes sense to me.  The socket (and traffic sent on it)
> should be labeled based on the data originator, not the peer.  If I
> accept a socket from you, I shouldn't be able to reflect back your own
> security attributes to you when I reply (at least not without
> privilege).
> 

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?

-- 
paul moore
linux security @ hp