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

On Tue, May 12, 2020 at 12:50:05PM +0000, Jordan Glover wrote:

On Tuesday, May 12, 2020 2:36 AM, Alexei Starovoitov [off-list ref] wrote:

quoted

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.

In the year 2020 there were three verifier bugs that could have been exploited
through unpriv. All three were found by new kBdysch fuzzer. In 2019 there was
nothing. Not because people didn't try, but because syzbot fuzzer reached its
limit. This cap_bpf will help fuzzers find a new set of bugs.

The pace of bpf development is accelerating, so there will be more bugs found
and introduced in the verifier. Folks that run the very latest kernel are
taking that risk along with the risk associated with other new kernel features.
Yet other features don't have sysctls to disable them.