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:   Mon, 17 Apr 2023 15:01:26 -0700
From:   Benedict Wong <benedictwong@...gle.com>
To:     Martin Willi <martin@...ongswan.org>,
        Steffen Klassert <steffen.klassert@...unet.com>
Cc:     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

I believe I have a potential solution that caches the policy matches,
rather than clearing the secpath, which should allow for repeated
matches against a secpath entry, while allowing other already-matched
secpath entries to not need to match nested policies. That should
solve for the general case where the secpath gets checked against
policies multiple times (both in the forwarding case, as well as in
the nested transport mode in tunnel mode case.

Forgive my not knowing of convention; should I send that as a separate
patch, or append it as a reply to this thread?


On Thu, Apr 13, 2023 at 11:04 AM Benedict Wong <benedictwong@...gle.com> wrote:
>
> 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
> >