netdev - Re: [PATCH v3] vrf: Fix conntrack-dnat conflict in vrf-device PREROUTING hook

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] [day] [month] [year] [list]

Message-ID: <20190115065648.2m3agatlsgi42un3@salvia>
Date:   Tue, 15 Jan 2019 07:56:48 +0100
From:   Pablo Neira Ayuso <pablo@...filter.org>
To:     Florian Westphal <fw@...len.de>
Cc:     wenxu@...oud.cn, netdev@...r.kernel.org, dsahern@...il.com,
        netfilter-devel@...r.kernel.org
Subject: Re: [PATCH v3] vrf: Fix conntrack-dnat conflict in vrf-device
 PREROUTING  hook

On Mon, Jan 14, 2019 at 11:15:10PM +0100, Florian Westphal wrote:
> Pablo Neira Ayuso <pablo@...filter.org> wrote:
> > On Sat, Jan 12, 2019 at 08:03:19AM +0800, wenxu@...oud.cn wrote:
> > > From: wenxu <wenxu@...oud.cn>
> > > 
> > > In the ip_rcv the skb go through the PREROUTING hook first,
> > > Then jump in vrf device go through the same hook again.
> > > When conntrack dnat work with vrf, there will be some conflict for rules.
> > > Because the package go through the hook twice with different nf status
> > 
> > Then, the first hook applies NAT, while the second is simply ignored.
> 
> Yes, but re-entry occurs with munged addresses in case DNAT was applied.
> I'm not sure about this patch either though.
> 
> If vrf is used, then it seems its enough to add a 'meta iifname vr+ accept'
> rule to prevent false matches/re-invocation.

Then this is a misconfiguration issue.

> If the name isn't enough, I think we should consider extending meta to
> query 'interface is vrf' so userspace can add the 'don't re-do entire
> ruleset for vrf' policy itself.

This sounds good, this problem is solved via policy.

> I am not sure kernel should auto-enforce bypass based on conntrack
> state, there is no precedence for this and I don't like
> arbitrarily-chosen behaviour.

Agreed.