On Thu, Jun 9, 2022 at 4:46 PM KP Singh <kpsingh@xxxxxxxxxx> wrote: > > BPF LSM currently has a default implementation for each LSM hooks which > return a default value defined in include/linux/lsm_hook_defs.h. These > hooks should have no functional effect when there is no BPF program > loaded to implement the hook logic. > > Some LSM hooks treat any return value of the hook as policy decision > which results in destructive side effects. > > This issue and the effects were reported to me by Jann Horn: > > For a system configured with CONFIG_BPF_LSM and the bpf lsm is enabled > (via lsm= or CONFIG_LSM) an unprivileged user can vandalize the system > by removing the security.capability xattrs from binaries, preventing > them from working normally: > > $ getfattr -d -m- /bin/ping > getfattr: Removing leading '/' from absolute path names > security.capability=0sAQAAAgAgAAAAAAAAAAAAAAAAAAA= > > $ setfattr -x security.capability /bin/ping > $ getfattr -d -m- /bin/ping > $ ping 1.2.3.4 > $ ping google.com > $ echo $? > 2 > > The above reproduces with: > > cat /sys/kernel/security/lsm > capability,apparmor,bpf Why is this bpf related? apparmor doesn't have that hook, while capability returns 0. So bpf's default==0 doesn't change the situation. Just cat /sys/kernel/security/lsm capability would reproduce the issue? what am I missing?
