netdev - Re: More flexible BPF socket inet_lookup hooking after listening sockets are dispatched

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:   Thu, 21 Jan 2021 21:40:19 +0100
From:   Shanti Lombard <shanti@...dred.fr>
To:     Jakub Sitnicki <jakub@...udflare.com>
Cc:     Shanti Lombard née Bouchez-Mongardé 
        <shanti20210120@...dred.fr>,
        Alexei Starovoitov <alexei.starovoitov@...il.com>,
        bpf <bpf@...r.kernel.org>,
        Network Development <netdev@...r.kernel.org>,
        Martin KaFai Lau <kafai@...com>
Subject: Re: More flexible BPF socket inet_lookup hooking after listening
 sockets are dispatched

Le 2021-01-21 12:14, Jakub Sitnicki a écrit :
> On Wed, Jan 20, 2021 at 10:06 PM CET, Alexei Starovoitov wrote:
> 
> There is also documentation in the kernel:
> 
> https://www.kernel.org/doc/html/latest/bpf/prog_sk_lookup.html
> 

Thank you, I saw it, it's well written and very much explains it all.

> 
> Existing hook is placed before regular listening/unconnected socket
> lookup to prevent port hijacking on the unprivileged range.
> 

Yes, from the point of view of the BPF program. However from the point 
of view of a legitimate service listening on a port that might be 
blocked by the BPF program, BPF is actually hijacking a port bind.

That being said, if you install the BPF filter, you should know what you 
are doing.

>>> The suggestion above would work for my use case, but there is another
>>> possibility to make the same use cases possible : implement in BPF 
>>> (or
>>> allow BPF to call) the C and E steps above so the BPF program can
>>> supplant the kernel behavior. I find this solution less elegant and 
>>> it
>>> might not work well in case there are multiple inet_lookup BPF 
>>> programs
>>> installed.
> 
> Having a BPF helper available to BPF sk_lookup programs that looks up a
> socket by packet 4-tuple and netns ID in tcp/udp hashtables sounds
> reasonable to me. You gain the flexibility that you describe without
> adding code on the hot path.

True, if you consider that hot path should not be slowed down. It makes 
sense. However, for me, it seems the implementation would be more 
difficult.

Looking at existing BPF helpers 
<https://man7.org/linux/man-pages/man7/bpf-helpers.7.html> I found 
bpf_sk_lookup_tcp and bpf_sk_lookup_ucp that should yield a socket from 
a matching tuple and netns. If that's true and usable from within BPF 
sk_lookup then it's just a matter of implementing it and the kernel is 
already ready for such use cases.

Shanti