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: <alpine.DEB.2.11.1802192136280.14770@blackhole.kfki.hu>
Date:   Mon, 19 Feb 2018 22:30:26 +0100 (CET)
From:   Jozsef Kadlecsik <kadlec@...ckhole.kfki.hu>
To:     Florian Westphal <fw@...len.de>
cc:     David Miller <davem@...emloft.net>, daniel@...earbox.net,
        Harald Welte <laforge@...monks.org>, netdev@...r.kernel.org,
        netfilter-devel@...r.kernel.org, alexei.starovoitov@...il.com
Subject: Re: [PATCH RFC 0/4] net: add bpfilter

Hi David,

On Mon, 19 Feb 2018, Florian Westphal wrote:

> David Miller <davem@...emloft.net> wrote:
> > 
> > Florian, first of all, the whole "change the iptables binary" idea is
> > a non-starter.  For the many reasons I have described in the various
> > postings I have made today.
> > 
> > It is entirely impractical.

You stressed several times that container images, virtualization 
installations don't change - and that's exaggregation. Those are updated 
as well, and not only because security updates must be rolled out, but 
because new versions of softwares are requested.

You mentioned that the hosting part can upgrade the kernel - it means that 
enabling NFTABLES is also a non-issue when the new eBPF functionality is 
switched on, if that was missing.

> You suggest:
> 
> iptables -> setsockopt -> umh (xtables -> ebpf) -> kernel
> 
> How is this different from
> 
> iptables -> setsockopt -> umh (Xtables -> nftables -> kernel
> 
> ?
> EBPF can be placed within nftables either userspace or kernel,
> there is nothing that prevents this.

So why the second scenario suggested by Florian is not possible or must be 
avoided? It not only could keep the unmodified iptables in the container 
(if that's a must from some reason), but it would make possible to replace 
it later anytime with iptables-compat/nftables.

Best regards,
Jozsef
-
E-mail  : kadlec@...ckhole.kfki.hu, kadlecsik.jozsef@...ner.mta.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences
          H-1525 Budapest 114, POB. 49, Hungary