Thread (21 messages) 21 messages, 5 authors, 2020-05-12

Re: [PATCH v5 bpf-next 2/3] bpf: implement CAP_BPF

From: Jordan Glover <hidden>
Date: 2020-05-12 12:50:17
Also in: bpf, netdev

On Tuesday, May 12, 2020 2:36 AM, Alexei Starovoitov [off-list ref] wrote:
On Mon, May 11, 2020 at 05:12:10PM -0700, sdf@google.com wrote:
quoted
On 05/08, Alexei Starovoitov wrote:
quoted
From: Alexei Starovoitov ast@kernel.org
[..]
@@ -3932,7 +3977,7 @@ SYSCALL_DEFINE3(bpf, int, cmd, union bpf_attr
__user *, uattr, unsigned int, siz
union bpf_attr attr;
int err;
quoted
-   if (sysctl_unprivileged_bpf_disabled && !capable(CAP_SYS_ADMIN))

-   if (sysctl_unprivileged_bpf_disabled && !bpf_capable())
    return -EPERM;
    This is awesome, thanks for reviving the effort!
One question I have about this particular snippet:
Does it make sense to drop bpf_capable checks for the operations
that work on a provided fd?
Above snippet is for the case when sysctl switches unpriv off.
It was a big hammer and stays big hammer.
I certainly would like to improve the situation, but I suspect
the folks who turn that sysctl knob on are simply paranoid about bpf
and no amount of reasoning would turn them around.
Without CAP_BPF, sysctl was the only option to keep you safe from flow
of bpf vulns. You didn't had to be paranoid about that.

Jordan
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help