On Tue, May 12, 2020 at 12:50:05PM +0000, Jordan Glover wrote: > On Tuesday, May 12, 2020 2:36 AM, Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> wrote: > > > On Mon, May 11, 2020 at 05:12:10PM -0700, sdf@xxxxxxxxxx wrote: > > > > > On 05/08, Alexei Starovoitov wrote: > > > > > > > From: Alexei Starovoitov ast@xxxxxxxxxx > > > > [..] > > > > @@ -3932,7 +3977,7 @@ SYSCALL_DEFINE3(bpf, int, cmd, union bpf_attr > > > > __user *, uattr, unsigned int, siz > > > > union bpf_attr attr; > > > > int err; > > > > > > > - 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.
