[LTP] [PATCH v4 1/2] core: add tst_selinux_enabled() utility
Petr Vorel
pvorel@suse.cz
Wed Jul 23 14:51:26 CEST 2025
Hi all,
> On 7/22/25 3:48 PM, Stephen Smalley wrote:
> > I guess my only question here is whether the tests all require SELinux
> > to be enforcing or if some of them are just exercising SELinux
> > functionality that would also pass when permissive. And whether you
> > care about testing that case.
> Hi Stephen,
> this particular reproducer doesn't need more than knowing a LSM is up and
> running, so we can trigger the bug on listxattr.
> In our case, we chosen SELinux because it's popular and this approach is
> more practical than checking every single LSM implementation in the system,
> verifying if it's enabled or not, no matter SELinux is configured in
> permissive or enforcing mode.
Thanks for info. Feel free to merge this as is and add support for other LSM
later. Either you send a patch later or please share what's needed to be done.
FYI with disabled SELinux and using other LSM
$ cat /proc/cmdline
... BOOT_IMAGE=/boot/vmlinuz-6.16.0-rc1-236-g8c6bc74c7f891-1.ga27462d-vanilla security=selinux selinux=0 enforcing=0 ima_policy=critical_data
cat /sys/kernel/security/lsm
lockdown,capability,landlock,yama,bpf,ima,evm
and with modified your test to not check for SELinux does not reproduce the bug:
# ./listxattr04
...
listxattr04.c:52: TPASS: listxattr() correctly read attributes length
I suppose at least capability, IMA, EVM and BPF aren't triggering it (there are
definitely used by the kernel). Maybe it requires AppArmor or use other LSM
(which might require their own kernel command line).
Because any LSM means any kernel would be vulnerable. If it's just SELinux and
AppArmor fewer kernels are affected.
Kind regards,
Petr
> - Andrea
More information about the ltp
mailing list