Re: [PATCH 05/10] selinux: selinux_xfrm_decode_session check for socket sid

[Steffen Klassert <steffen.klassert@secunet.com>]

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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.