Re: [PATCH net] tcp: restrict SO_ATTACH_BPF to privileged users

[manjunath.b.patil@oracle.com]

Hi,
On 10/28/26 3:12 PM, Alexei Starovoitov wrote:
> On Wed, Oct 28, 2026 at 02: 58 PM Manjunath Patil <manjunath. b. patil@  
> oracle. com> wrote: > Commit 5d39580f68e6 ("tcp: restrict 
> SO_ATTACH_FILTER to priv users") > requires CAP_NET_ADMIN to attach a 
> classic BPF filter to a TCP socket. 
> 
> 
> On Wed, Oct 28, 2026 at 02:58 PM Manjunath Patil <manjunath.b.patil@oracle.com> wrote:
>> Commit 5d39580f68e6 ("tcp: restrict SO_ATTACH_FILTER to priv users")
>> requires CAP_NET_ADMIN to attach a classic BPF filter to a TCP socket.
>> However, a caller can still attach an eBPF socket filter through
>> SO_ATTACH_BPF without this capability. Both options install a filter
>> that runs on incoming TCP packets.
> 
> Nack.
> SO_ATTACH_FILTER takes insns that the caller wrote.
> SO_ATTACH_BPF takes a prog FD, and BPF_PROG_LOAD is the gate for it.
Thanks for the explanation. I overlooked this distinction and treated 
the different attachment checks as a missing permission check.

> unprivileged_bpf_disabled is 2 by default, so the load needs CAP_BPF.
> An admin who sets it to 0 allows every user to load socket filters.
> 
>> Disabling unprivileged BPF loading does not close this gap: a caller
>> that already holds a socket-filter program file descriptor can still
>> use SO_ATTACH_BPF.
> 
> That's not a gap. The FD is the permission.
> A process with CAP_BPF loads the prog and passes the FD to a process
> without caps.
My test loaded the socket-filter program as root, then retained its FD 
in a worker that dropped its capabilities. That exercises supported 
delegation; it does not establish a security bypass.

  See the comment in bpf_prog_load() and
> commit c8644cd0efe7 ("bpf: refine kernel.unprivileged_bpf_disabled behaviour").
> This patch breaks it. It also breaks a process that has CAP_BPF and
> doesn't have CAP_NET_ADMIN.
I agree. I am withdrawing this patch.

-Thanks,
Manjunath>
> pw-bot: cr
>