Unprivileged BPF disabled (kernel.unprivileged_bpf_disabled >= 1) is the default in most cases now; when set, the BPF system call is blocked for users without CAP_BPF/CAP_SYS_ADMIN. In some use cases prior to having unpriviliged_bpf_disabled set to >= 1 however, it made sense to split activities between capability-requiring ones - such as program load+attach - and those that might not require capabilities such as reading perf/ringbuf events, reading or updating BPF map configuration etc. One example of this sort of approach is a service that loads a BPF program, and a user-space program that, after it has been loaded, interacts with it via pinned maps. Such a split model is not possible with unprivileged BPF disabled, since even those activities such as map interactions, retrieving map information from pinned paths etc are blocked to unprivileged users. However, granting CAP_BPF to such unprivileged users is quite a big hammer, allowing them to do pretty much anything with BPF. This very rough RFC explores the idea - with CONFIG_BPF_UNPRIV_MAP_ACCESS=y - of allowing unprivileged processes to retrieve and work with a restricted set of BPF maps. See patch 1 for the restrictions on BPF cmd and map type. Note that permission checks on maps are still enforced, so it's still possible to prevent unwanted interference by unprivileged users by pinning a map and setting permissions to prevent access. CONFIG_BPF_UNPRIV_MAP_ACCESS defaults to n, preserving current behaviour of blocking all BPF syscall commands. Discussion on the bpf mailing list already alluded to this idea [1], though it's possible I misinterpreted it. There are other ways to achieve this goal I suspect; for example a BPF LSM program attached to security_bpf() could weed out the disallowed commands, so setting unprivileged_bpf_disabled=0 + BPF LSM could support a wider range of policies (not sure if we could easily determine map types in that case though). However, as a starting point I just wanted to see if others see this as an issue, and if so how best to solve it in the general case. Thanks! [1] https://lore.kernel.org/bpf/CAADnVQLTBhCTAx1a_nev7CgMZxv1Bb7ecz1AFRin8tHmjPREJA@xxxxxxxxxxxxxx/ Alan Maguire (2): bpf: with CONFIG_BPF_UNPRIV_MAP_ACCESS=y, allow unprivileged access to BPF maps selftests/bpf: add tests verifying unpriv bpf map access kernel/bpf/Kconfig | 15 ++ kernel/bpf/syscall.c | 57 ++++- tools/testing/selftests/bpf/config | 1 + .../bpf/prog_tests/unpriv_map_access.c | 194 ++++++++++++++++++ .../bpf/progs/test_unpriv_map_access.c | 81 ++++++++ 5 files changed, 347 insertions(+), 1 deletion(-) create mode 100644 tools/testing/selftests/bpf/prog_tests/unpriv_map_access.c create mode 100644 tools/testing/selftests/bpf/progs/test_unpriv_map_access.c -- 2.27.0
