[redhat-lspp] Updated NetLabel patch

[Stephen Smalley]

On Wed, 2006-06-14 at 11:32 -0400, Paul Moore wrote:
> See my earlier comments about re-basing the patch.  The only question I
> have is if I should add the NetLabel hooks to the compat() function as
> well as the new rcv_skb()?  I would think the safest thing to do would
> be to only add the NetLabel hooks to the new rcv_skb() but there is some
> question about RH providing SECMARK support in upcoming releases (i.e.
> packets would still flow through rcv_skb_compat()) ... do you have a
> strong opinion on this?

You only have to put it at the tail of the main sock_rcv_skb hook, like
the xfrm hook; the compat function is called by the main sock_rcv_skb
hook if compatibility mode is enabled, but only to perform the
netif/node/port checks.  The initial processing (SID extraction, parsing
skb) still happens in sock_rcv_skb, as does the xfrm hook call at the
end.  So you get coverage of both cases there.

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

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

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

-- 
Stephen Smalley
National Security Agency