lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 04 Feb 2014 12:05:06 +0100 From: Christophe Gouault <christophe.gouault@...nd.com> To: Steffen Klassert <steffen.klassert@...unet.com> CC: netdev@...r.kernel.org, Saurabh Mohan <saurabh.mohan@...tta.com> Subject: Re: [PATCH RFC v3 0/12] vti4: prepare namespace and interfamily support. On 01/30/2014 10:56 AM, Steffen Klassert wrote: > On Wed, Jan 29, 2014 at 11:55:40AM +0100, Christophe Gouault wrote: > [...] >> => there is no check that the forward vti security policy was >> enforced. >> > > Yes, that's true and this is a real problem. If we want to support > namespace transitions with vti, we can't know if a packet is going > to be forwarded or locally received in the other namespace. This means > that we don't know if we should enforce a input or a forward policy. > > All we can do here, is to enforce a input policy before we do the > namespace transition in the receive path. The patch below (on top > of the vti patchset) should do this. Hi Steffen, and thank you for the patch. I tested it within a single netns, then with cross-netns. Both work as follows: - all the vti SPs and SAs must be created in the "outer" netns. - only outbound and inbound vti policies are taken into account, not forward vti policies. in output: - a global SPD lookup is performed before entering the vti interface (in the inner netns). It can be bypassed by adding a policy such as: ip xfrm policy add dir out mark 0 dev vti1 - then a vti SPD lookup is performed with the vti interface (in the outer netns). in input: - a global inbound policy check is done (in the outer netns) on the IPsec packet by the vti interface. - then the packet is decrypted. - then a vti inbound policy check is done on the decrypted packet (in the outer netns). - then the packet device is set to the vti interface and its netns is changed to the inner netns. - finally, a global inbound/forward policy check is done on the plaintext packet (without security context), as if it has just arrived in plaintext from the network. > But this has the implication that forward policies do not make > much sense in combination with vti. This is a bit contrary to > traditional xfrm processing. But on the other hand, we receive > plaintext packets from the vti device so we should not check > for any IPsec processing that happened before we received the > packets via the vti device. Unfortunately, the inbound/forward policy checks do not take the inbound interface into account (__xfrm_decode_session does not properly fill in the iif field of the flowi), so in the last global policy check, there is no way of differentiating a plaintext packet directly received from the network from a plaintext packet that was processed by a vti interface. Intuitively, I would like to do the same as in output: add a policy that accepts packets received via a vti interface, and only check more closely other packets directly received from the network. Best Regards, Christophe. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists