During last relaxation of bpf syscall's capabilities checks ([0]), the model of FD-based ownership was established: if process through whatever means got FD for some BPF object (map, prog, etc), it should be able to perform operations on this object without extra CAP_SYS_ADMIN or CAP_BPF capabilities. It seems like we missed a few cases, though, in which we are still enforcing extra caps for no good reason, even though operations are not really unsafe and/or do not require any system-wide capabilities: - BPF_MAP_FREEZE command; - GET_NEXT_ID family of commands; - GET_INFO_BY_FD command has extra bpf_capable()-based sanitization. This patch set is removing these unnecessary checks. MAP_FREEZE and INFO_BY_FD are deviating from the "if you own FD, you can work with BPF object". GET_NEXT_ID is a completely safe and unprivileged operation that returns just IDs of BPF objects. One still needs to go through CAP_SYS_ADMIN-guarded GET_FD_BY_ID command to get ahold of FD to do any operation on corresponding BPF object. As such, it seems completely safe to drop CAP_SYS_ADMIN checks for GET_NEXT_ID. [0] https://lore.kernel.org/all/1652970334-30510-2-git-send-email-alan.maguire@xxxxxxxxxx/ Andrii Nakryiko (3): bpf: drop unnecessary bpf_capable() check in BPF_MAP_FREEZE command bpf: don't require CAP_SYS_ADMIN for getting NEXT_ID bpf: don't require bpf_capable() for GET_INFO_BY_FD kernel/bpf/syscall.c | 23 ++++--------------- .../bpf/prog_tests/unpriv_bpf_disabled.c | 15 ++---------- 2 files changed, 7 insertions(+), 31 deletions(-) -- 2.34.1
