On 8/16/19 3:27 AM, Dominick Grift wrote:
As of systemd v243rc1 I have been noticing bpf prog_load and prog_run access checks for systemd --user instances (only if secure boot is disabled) I suspect that this is for IPAddressAllow/Deny= functionality. So i tried it out and I was not allowed to use the above due to lack of root-access. Then i read this: https://lore.kernel.org/linux-security-module/4F52274A-CD70-4261-A255-2C4A7E818141@xxxxxx/T/#t My question is: Is it expected that BPF prog_load and prog_run is checked when an *unprivileged* process, i suppose, tries to load and run bpf progs? Are prog_load and prog_run unprivileged operations?
They can be checked for processes that do not have CAP_SYS_ADMIN if that is what you are asking. This can occur either during bpf(2) system call processing if unprivileged_bpf_disabled is 0 (for prog_load and/or prog_run), or upon receiving a bpf prog fd from another process (for prog_run). It is possible that the specific operation will nonetheless fail due to a later CAP_SYS_ADMIN check applied for specific kinds of bpf programs. So it depends on the specifics.
Android policy appears to have changed over time, with netd originally allowed both prog_load and prog_run (but not sys_admin), and then later bpf program loading was migrated into a separate bpfloader process (with prog_load but not sys_admin) and netd was reduced to prog_run, and still later sys_admin was added to bpfloader to enable loading bpf programs with tracepoints. Similarly there has been an evolution in the handling of bpf maps.
