On Wed, May 18, 2022 at 4:21 PM Shung-Hsi Yu <shung-hsi.yu@xxxxxxxx> wrote: > > On Wed, May 18, 2022 at 02:34:20PM +0100, Alan Maguire wrote: > > With unprivileged BPF disabled, all cmds associated with the BPF syscall > > are blocked to users without CAP_BPF/CAP_SYS_ADMIN. However there are > > use cases where we may wish to allow interactions with BPF programs > > without being able to load and attach them. So for example, a process > > with required capabilities loads/attaches a BPF program, and a process > > with less capabilities interacts with it; retrieving perf/ring buffer > > events, modifying map-specified config etc. With all BPF syscall > > commands blocked as a result of unprivileged BPF being disabled, > > this mode of interaction becomes impossible for processes without > > CAP_BPF. > > > > As Alexei notes > > > > "The bpf ACL model is the same as traditional file's ACL. > > The creds and ACLs are checked at open(). Then during file's write/read > > additional checks might be performed. BPF has such functionality already. > > Different map_creates have capability checks while map_lookup has: > > map_get_sys_perms(map, f) & FMODE_CAN_READ. > > In other words it's enough to gate FD-receiving parts of bpf > > with unprivileged_bpf_disabled sysctl. > > The rest is handled by availability of FD and access to files in bpffs." > > > > So key fd creation syscall commands BPF_PROG_LOAD and BPF_MAP_CREATE > > are blocked with unprivileged BPF disabled and no CAP_BPF. > > > > And as Alexei notes, map creation with unprivileged BPF disabled off > > blocks creation of maps aside from array, hash and ringbuf maps. > > > > Programs responsible for loading and attaching the BPF program > > can still control access to its pinned representation by restricting > > permissions on the pin path, as with normal files. > > > > Signed-off-by: Alan Maguire <alan.maguire@xxxxxxxxxx> > > Acked-by: Yonghong Song <yhs@xxxxxx> > > Acked-by: Shung-Hsi Yu <shung-hsi.yu@xxxxxxxx> Acked-by: KP Singh <kpsingh@xxxxxxxxxx>
