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]
Message-ID: <LO0P265MB604061D3617058B2B07D534CE0A49@LO0P265MB6040.GBRP265.PROD.OUTLOOK.COM>
Date:   Mon, 20 Feb 2023 11:28:07 +0000
From:   David George <David.George@...hos.com>
To:     Herbert Xu <herbert@...dor.apana.org.au>,
        Sri Sakthi <srisakthi.s@...il.com>
CC:     "steffen.klassert@...unet.com" <steffen.klassert@...unet.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Srisakthi Subramaniam <Srisakthi.Subramaniam@...hos.com>,
        Vimal Agrawal <Vimal.Agrawal@...hos.com>
Subject: Re: xfrm: Pass on correct AF value to xfrm_state_find

Hi Herbert

>> This is because the policy selector on a nested policy
is matched against the inner-most flow, and not one level below
(don't ask me why, it was this way before I got here :)

Hah - okay this makes sense and I see now why the original change is problematic. We will end up having the same bad mismatched address family selector comparison.

>> In your case your ESP policy selector says that it has to be IPv6,
while the inner-most flow is IPv4.  That's why it doesn't work.

This makes sense to an extent. However, limitations on transport mode SAs prevent one having a selector address family that doesn't match the SA address family. Given this constraint, there is no configuration that will work for IPv6 IPcomp tunnel + IPv6 encrypt transport with IPv4 inner.

It seems like the address family limitation in the transport SA does not conform to the inner-most flow matching you described above.

>> Just because strongswan is doing it doesn't mean that it isn't
buggy.

To be fair to strongswan here, it might not be correct when considering the innards of the Linux implementation but it did work at the time; it is no longer possible to get that config working.

>> Either have no policy selector on the ESP SA, or have one that
actually matches the inner flow.

This doesn't work on transport SAs as I mentioned (see __xfrm_init_state()).

So as for a proper solution; I see the easiest is to relax the selector family check at "add" time for transport SAs and move relevant checks into the run time.

Another more hacky solution could be deal with the "all-wildcard" selector case as special. Though I'm not particularly fond of this.

What do you think?

Regards,
David George

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ