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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 19 Feb 2018 18:09:39 +0100
From:   Phil Sutter <phil@....cc>
To:     David Miller <davem@...emloft.net>
Cc:     laforge@...monks.org, fw@...len.de, 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

Hi David,

On Mon, Feb 19, 2018 at 10:31:39AM -0500, David Miller wrote:
> From: Harald Welte <laforge@...monks.org>
> Date: Mon, 19 Feb 2018 16:27:46 +0100
> 
> > On Mon, Feb 19, 2018 at 10:13:35AM -0500, David Miller 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.
> > 
> > Why is it practical to replace your kernel but not practical to replace
> > a small userspace tool running on top of it?
> 
> The container is just userspace components.  Those are really baked in
> and are never changing.

Which is a problem per se. Cheap hardware routers are a good example of
why business models which tend to get customers stuck with old software
have such dramatic effects at least in matters of security.

> The hosting element, on the other hand, can upgrade the kernel in that
> scenerio no problem.
> 
> This is how cloud hosting environments work.

What puzzles me about your argumentation is that you seem to propose for
the kernel to cover up flaws in userspace. Spinning this concept further
would mean that if there would be an old bug in iproute2 we should think
of adding a workaround to rtnetlink interface in kernel because
containers will keep the old iproute2 binary? Or am I (hopefully) just
missing your point?

Cheers, Phil