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:   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.

Powered by blists - more mailing lists