|Main Archive Page > Month Archives > selinux archives|
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?
> > 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
-- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to firstname.lastname@example.org with the words "unsubscribe selinux" without quotes as the message.