On Fri, Aug 16, 2019 at 12:35:09PM -0400, Stephen Smalley wrote: > 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 Yes I suppose that was what I was asking. According to an LWN article today unprivileged bpf is not going to happen. Thus i dontaudited these two since it does not work presently, and it is not going to work in the future. https://defensec.nl/gitweb/?p=dssp2.git;a=commitdiff;h=1ef329b09a3bee549cd08640663ba5e8ed9d3f56 Thanks > 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. -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 Dominick Grift
Attachment:
signature.asc
Description: PGP signature
