netdev - Re: [PATCH ipsec v2] xfrm: Preserve xfrm interface secpath for packets forwarded

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 13 Apr 2023 11:04:05 -0700
From:   Benedict Wong <benedictwong@...gle.com>
To:     Martin Willi <martin@...ongswan.org>
Cc:     Steffen Klassert <steffen.klassert@...unet.com>,
        Eyal Birger <eyal.birger@...il.com>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        "David S . Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>, netdev@...r.kernel.org
Subject: Re: [PATCH ipsec v2] xfrm: Preserve xfrm interface secpath for
 packets forwarded

Not directly related to this change, but in testing these on a broader
swath of Android tests, we've found that my original change also
happens to break Transport-in-Tunnel mode (which attempts to match the
outer tunnel mode policy twice.). I wonder if it's worth just
reverting first, and going back to a previous iteration of the nested
policy checks that allows multiple lookups of the same
template/secpath pair.


On Wed, Apr 12, 2023 at 1:56 AM Martin Willi <martin@...ongswan.org> wrote:
>
> The commit referenced below clears the secpath on packets received via
> xfrm interfaces to support nested IPsec tunnels. This breaks Netfilter
> policy matching using xt_policy in the FORWARD chain, as the secpath
> is missing during forwarding. INPUT matching is not affected, as it is
> done before secpath reset.
>
> A work-around could use XFRM input interface matching for such rules,
> but this does not work if the XFRM interface is part of a VRF; the
> Netfilter input interface is replaced by the VRF interface, making a
> sufficient match for IPsec-protected packets difficult.
>
> So instead, limit the secpath reset to packets that are not using a
> XFRM forward policy. This should allow nested tunnels, but keeps the
> secpath intact on packets that are passed to Netfilter chains with
> potential IPsec policy matches.
>
> Fixes: b0355dbbf13c ("Fix XFRM-I support for nested ESP tunnels")
> Suggested-by: Eyal Birger <eyal.birger@...il.com>
> Signed-off-by: Martin Willi <martin@...ongswan.org>
> ---
> v1 -> v2: Use policy dir instead of flowi outif to check for forwarding
>
>  net/xfrm/xfrm_policy.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c
> index 5c61ec04b839..669c3c0880a6 100644
> --- a/net/xfrm/xfrm_policy.c
> +++ b/net/xfrm/xfrm_policy.c
> @@ -3745,7 +3745,7 @@ int __xfrm_policy_check(struct sock *sk, int dir, struct sk_buff *skb,
>                         goto reject;
>                 }
>
> -               if (if_id)
> +               if (if_id && dir != XFRM_POLICY_FWD)
>                         secpath_reset(skb);
>
>                 xfrm_pols_put(pols, npols);
> --
> 2.34.1
>