netdev - Re: [PATCH nf-next 3/3] netfilter: Introduce egress 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] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 13 Mar 2020 15:55:26 +0100
From:   Pablo Neira Ayuso <pablo@...filter.org>
To:     Daniel Borkmann <daniel@...earbox.net>
Cc:     Lukas Wunner <lukas@...ner.de>,
        Jozsef Kadlecsik <kadlec@...filter.org>,
        Florian Westphal <fw@...len.de>,
        netfilter-devel@...r.kernel.org, coreteam@...filter.org,
        netdev@...r.kernel.org, Martin Mares <mj@....cz>,
        Dmitry Safonov <0x7f454c46@...il.com>,
        Thomas Graf <tgraf@...g.ch>,
        Alexei Starovoitov <ast@...nel.org>,
        David Miller <davem@...emloft.net>
Subject: Re: [PATCH nf-next 3/3] netfilter: Introduce egress hook

On Wed, Mar 11, 2020 at 03:05:16PM +0100, Daniel Borkmann wrote:
> On 3/11/20 12:59 PM, Lukas Wunner wrote:
> > Commit e687ad60af09 ("netfilter: add netfilter ingress hook after
> > handle_ing() under unique static key") introduced the ability to
> > classify packets on ingress.
> > 
> > Allow the same on egress.  Position the hook immediately before a packet
> > is handed to tc and then sent out on an interface, thereby mirroring the
> > ingress order.  This order allows marking packets in the netfilter
> > egress hook and subsequently using the mark in tc.  Another benefit of
> > this order is consistency with a lot of existing documentation which
> > says that egress tc is performed after netfilter hooks.
> > 
> > Egress hooks already exist for the most common protocols, such as
> > NF_INET_LOCAL_OUT or NF_ARP_OUT, and those are to be preferred because
> > they are executed earlier during packet processing.  However for more
> > exotic protocols, there is currently no provision to apply netfilter on
> > egress.  A common workaround is to enslave the interface to a bridge and
> 
> Sorry for late reply, but still NAK.

I agree Lukas use-case is very specific.

However, this is useful.

We have plans to support for NAT64 and NAT46, this is the right spot
to do this mangling. There is already support for the tunneling
infrastructure in netfilter from ingress, this spot from egress will
allow us to perform the tunneling from here. There is also no way to
drop traffic generated by dhclient, this also allow for filtering such
locally generated traffic. And many more.

Performance impact is negligible, Lukas already provided what you
asked for.

And more importantly:

I really think this patchset is _not_ interfering in your goals at all.