On Tuesday, February 22, 2011 8:04:09 AM Steffen Klassert wrote: > On Wed, Feb 16, 2011 at 03:32:40PM -0500, Paul Moore wrote: > > On Mon, 2011-02-14 at 14:21 +0100, Steffen Klassert wrote: > > > As it is, it is not possible to check in the forwarding and > > > the postrouting hook whether a packet that is received via some > > > network interface is allowed to be forwarded via some other network > > > interface. With this patch we decode the security identifier on > > > selinux_xfrm_decode_session to the sid of the incoming interface, > > > if we have neither a secpath nor socket context, so this check is > > > possible now. Also set the sid to SECINITSID_KERNEL if we have none > > > of secpath, socket context and incoming interface as the packet > > > must be kernel generated in this case. > > > > > > Signed-off-by: Steffen Klassert <steffen.klassert@xxxxxxxxxxx> > > > > If you want to control which interface is allowed to forward to which > > other interface, you should use good ol' iptables, not SELinux. > > Well, I think the problem is that we can't use labled SA's on > packet forwarding. > > Consider the following: As it is, the sid of the labeled SA and the sid of > the flow must be identical. Say we receive a plain IP packet that should be > forwarded ... For this argument I'm assuming "plain IP packet" == "IP packet without a peer label associated with it". > ... IPsec transformed with a labeled SA. Okay, I think that is our disconnect right there. You are trying to send an unlabeled packet (peer label set to "unlabeled_t") over a labeled SA (peer label set to "foo_t") without any explicit relabel operation by the administrator. This is a Very Bad Thing. > Now __xfrm_route_forward() decodes the sid of the flow with > selinux_xfrm_decode_session(). This packet has neither a secpath nor socket > conext. So the sid of the flow is decoded to SECSID_NULL. I suppose we probably should set the flow's label in this case to SECINITSID_UNLABELED instead of SECSID_NULL, that would be more consistent ... although we would probably need to make sure we don't break anything in selinux_xfrm_state_pol_flow_match(). > Then selinux_xfrm_state_pol_flow_match() enforces the sid of SA and flow to > be identical. This in turn means, that the label of the SA must be > SECSID_NULL. Which makes sense to me. If you are forwarding unlabeled packets across an IPsec gateway, the IPsec gateway should establish SAs which are also unlabeled. > So I think we have to chane something if we want to use labeled SAs on > packet forwarding, or do I miss something here? I think so, look below. > With this patch we would decode the sid of the flow to the sid of the > receiving interface, so the used SA could have the same sid as the > receiving interface. I think the problem is that you believe the network interface's label becomes the peer label of unlabeled packets, that is not the case. If you want to provide a network peer label to unlabeled packets you need to use NetLabel's fallback labeling mechanism which applies peer labels to what would otherwise be unlabeled packets (see an example at the link below). I haven't (or can't remember) testing this in the case of labeled IPsec gateway connected to unlabeled, single label networks but I have tested it against a CIPSO gateway connected to unlabeled, single label networks. If it doesn't work for you in the labeled IPsec case, this would be a bug and something we would need to address. * http://paulmoore.livejournal.com/1758.html -- paul moore linux @ hp -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
