netdev - Re: netfilter: xt_bpf: ABI issue in xt_bpf_info

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] [day] [month] [year] [list]

Message-ID: <CAF=yD-Ldmk9mTC5rCxc8LSomNgvT5kPWFjDBvnSyX0EM-E6eFg@mail.gmail.com>
Date:   Wed, 13 Sep 2017 11:35:38 -0400
From:   Willem de Bruijn <willemdebruijn.kernel@...il.com>
To:     Jan Engelhardt <jengelh@...i.de>
Cc:     Shmulik Ladkani <shmulik@...f.io>,
        netfilter-devel <netfilter-devel@...r.kernel.org>,
        Pablo Neira Ayuso <pablo@...filter.org>,
        Network Development <netdev@...r.kernel.org>,
        Willem de Bruijn <willemb@...gle.com>,
        Rafael Buchbinder <rbk@...f.io>,
        Shmulik Ladkani <shmulik.ladkani@...il.com>, eyal@...f.io
Subject: Re: netfilter: xt_bpf: ABI issue in xt_bpf_info_v1?

On Wed, Sep 13, 2017 at 11:05 AM, Willem de Bruijn
<willemdebruijn.kernel@...il.com> wrote:
> On Wed, Sep 13, 2017 at 10:22 AM, Jan Engelhardt <jengelh@...i.de> wrote:
>>
>> On Wednesday 2017-09-13 15:24, Shmulik Ladkani wrote:
>>>
>>>One way to fix is to have iptables open the object (using the stored
>>>xt_bpf_info_v1->path), gaining a new process local fd for the object,
>>>just after getting the rules from IPT_SO_GET_ENTRIES.
>>>However we didn't see any other extensions doing something like that in
>>>iptables.
>
> The binary should call bpf_obj_get on the filepath each time. These are
> not regular files, but references to a pinned object in the bpf filesystem.
>
> Blindly passing back the fd received from the kernel is clearly wrong. I'm
> really surprised that I did not run into this problem when I wrote the
> feature.
>
>>>
>>>Another way to solve is to fix the ABI (or have a v2 one), that does NOT
>>>pass the fd from userspace, only the path of the pinned object.
>>>Then, 'bpf_mt_check_v1' will open the file from the given path in order
>>>to get the bpf_prog.
>>
>> But a path has a similar problem like a file descriptor - it is local to a
>> certain mount namespace.
>
> Because these are pinned objects in the bpf filesystem, and there is
> only one of those, it may be possible to lookup the object in the kernel
> without relying on a process-local view of mount points.

It would be preferable to fix this for the existing v1 users as well.

That said, the new bpf identifier feature allows passing a globally
unique id instead of a filepath.

>
>>
>> To load "large" blobs into the kernel, a pointer to user memory is a possible
>> option. The downside is that such extra data is not retrievable from the kernel
>> via the iptables setsockopts anymore - one could work around it with procfs, or
>> just let it be.
>>
>> https://sourceforge.net/p/xtables-addons/xtables-addons/ci/master/tree/extensions/xt_geoip.c
>> line 64+.