netdev - Re: [PATCH RFC 0/4] net: add bpfilter

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: <20180219145314.GD6333@breakpoint.cc>
Date:   Mon, 19 Feb 2018 15:53:14 +0100
From:   Florian Westphal <fw@...len.de>
To:     David Miller <davem@...emloft.net>
Cc:     laforge@...monks.org, daniel@...earbox.net, netdev@...r.kernel.org,
        netfilter-devel@...r.kernel.org, alexei.starovoitov@...il.com
Subject: Re: [PATCH RFC 0/4] net: add bpfilter

David Miller <davem@...emloft.net> wrote:
> > How many of those wide-spread applications are you aware of?  The two
> > projects you have pointed out (docker and kubernetes) don't. As the
> > assumption that many such tools would need to be supported drives a lot
> > of the design decisions, I would argue one needs a solid empircal basis.
> 
> I see talk about "just replacing the iptables binary".
> 
> A long time ago in a galaxy far far away, that would be a reasonable
> scheme.  But that kind of approach won't work in the realities of
> today.
> 
> You aren't going to be able to replace the iptables binary in the tens
> of thousands of container images out there, nor the virtualization
> installations either.

Why would you have to?
iptables kernel parts are still maintained, its not dead code that
stands in the way.

We can leave it alone, in maintenance mode, just fine.

> Like it or not iptables ABI based filtering is going to be in the data
> path for many years if not a decade or more to come.  iptables is a
> victim of it's own success, like it or not :-) Yes, the ABI is
> terrible, but obviously it was useful enough for lots of people.

Sure, but looking at all the things that were added to iptables
to alleviate some of the issues (ipset for instance) show that we need a
meaningful re-design of how things work conceptually.

The umh helper translation that has been proposed could be applied to
transparently xlate iptables to nftables (or e.g. iptables compat32 to
iptables64), i.e. legacy binary talks to kernel, kernel invokes umh, umh
generates nftables netlink messages).

But I don't even see a need to do this, I don't think its an issue
to leave it in the tree even for another decade or more if needed be.