netdev - Re: Commit 09e856d54bda5f288ef8437a90ab2b9b3eab83d1r "vrf: Reset skb conntrack connection on VRF rcv" breaks expected netfilter behaviour

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:   Wed, 13 Oct 2021 11:22:35 +0200
From:   Florian Westphal <fw@...len.de>
To:     Eugene Crosser <crosser@...rage.org>
Cc:     netdev@...r.kernel.org, netfilter-devel@...r.kernel.org,
        Lahav Schlesinger <lschlesinger@...venets.com>,
        David Ahern <dsahern@...nel.org>
Subject: Re: Commit 09e856d54bda5f288ef8437a90ab2b9b3eab83d1r "vrf: Reset skb
 conntrack connection on VRF rcv" breaks expected netfilter behaviour

Eugene Crosser <crosser@...rage.org> wrote:
> Maybe a better solution for stray conntrack entries would be to
> introduce finer control in netfilter? One possible idea would be to
> implement both "track" and "notrack" targets; then a working
> configuration would look like this:

'track' is hard to implement correctly because of RELATED traffic.

E.g. 'tcp dport 22 track' won't work correctly because icmp pmtu
won't be handled.

I'd suggest to try a conditional nf_ct_reset that keeps the conntrack
entry if its in another zone.

I can't think of another solution at the moment, the existing behaviour
of resetting conntrack entry for postrouting/output is too old,
otherwise the better solution IMO would be to keep that entry around on
egress if a NAT rewrite has been done. This would avoid the 'double snat'
problem that the 'reset on ingress' tries to solve.