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 -- redhat-lspp mailing list [email protected] https://www.redhat.com/mailman/listinfo/redhat-lspp
