On Wed, Feb 23, 2011 at 04:16:38PM -0500, Paul Moore wrote: > > > > No, we don't have a secpath for outbound packets. The secpath is used to > > do a inbound policy check, check the used SA against their selectors etc. > > With these checks we ensure that the packet is transformed back to it's > > native form in the right way. That's not needed on outbound packets, > > so we don't record a secpath in this case. The lack of a outbound > > secpath was also the problem I mentioned in the introduction mail > > of the patchset. > > Be warned: most of this reply is just me tossing out ideas ... > > Okay, so basically selinux_xfrm_decode_session() is a total waste of time in > the output path, yes? Right. > > > > I think that's not possible too. The security_xfrm_decode_session() > > hook is used from within xfrm_decode_session(). This function > > is used in codepaths that are used for both, inbound and outbound > > processing (xfrm_lookup, xfrm_policy_check etc.). > > This makes me wonder if the LSM hook is even in the right place. > As security_xfrm_decode_session() should add the sid of the originating flow, I think it was was quite reasonable to place it to the function that constructs the flow. > > I _really_ think we need to split the inbound and outbound handling for xfrm. > I suppose we can always fall back to selecting the right path based on the > presence of a sec_path pointer, but I would rather see us get rid of an > unnecessary conditional. This would require some structural changes in the core IPsec code too. At first glance I don't see a good way to do this. Any suggestions? > > The inbound handling can stick with the logic in selinux_xfrm_decode_session() > but the outbound handling should follow similar logic to how we determine the > network peer label in selinux_ip_postroute(). > > 1. If we have a valid sk_security_stuct, use it. > 2. If we are forwarding the packet, call selinux_skb_peerlbl_sid(). > 3. If all else fails, use SECINITSID_KERNEL. > Sounds reasonable for outbound packets. But we have to be carefull on packet forwarding. selinux_skb_peerlbl_sid() gets the xfrm sid from selinux_xfrm_decode_session(). So if we receive a IPsec transformed packet and forward it, transformed back, we have a valid secpath and we use the sid of the SA as the peer label. If we receive a plain IP packet and forward it, IPsec transformed, we have no secpath. So we would stick with SECSID_NULL, even though it might be transformed with a labeled SA. I think the sid of the SA should be used as the peer label in this case too. -- 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.
