[LTP] [PATCH v4 1/2] core: add tst_selinux_enabled() utility

[Stephen Smalley]

On Wed, Jul 23, 2025 at 8:46 AM Stephen Smalley
<stephen.smalley.work@gmail.com> wrote:
>
> On Wed, Jul 23, 2025 at 8:43 AM Andrea Cervesato
> <andrea.cervesato@suse.com> wrote:
> >
> > On 7/23/25 2:41 PM, Petr Vorel wrote:
> > > Hi all,
> > >
> > >> On 7/22/25 2:06 PM, Petr Vorel wrote:
> > >>> +++ lib/tst_security.c
> > >>> @@ -107,7 +107,7 @@ int tst_selinux_enabled(void)
> > >>>    {
> > >>>     int res = 0;
> > >>> -   if (tst_is_mounted(SELINUX_PATH))
> > >>> +   if (access(SELINUX_STATUS_PATH, F_OK) == 0)
> > >>>             res = 1;
> > >>>     tst_res(TINFO, "SELinux enabled: %s", res ? "yes" : "no");
> > >> This is more or less what I was doing at the beginning, but Cyril suggested
> > >> this approach which is more similar to libselinux. Please, check v3.
> > > Sure :). FYI I did check v3 before replying to v4 (I always try to get to the
> > > context looking into older versions, I also noted v3 in one of my replies :)).
> > >
> > > And yes, I think you were right, that's why I raised my concern again.
> > >
> > > But ok, to quote it here Cyril's reply in v3:
> > > https://lore.kernel.org/ltp/aG5v6enhdqFGgiBj@yuki.lan/
> > >
> > >       > +     if (access(SELINUX_PATH, F_OK) == 0 && !tst_dir_is_empty(SELINUX_PATH, 0))
> > >       > +             res = 1;
> > >
> > >       Maybe we we can do tst_is_mounted(SELINUX_PATH) here instead. At least
> > >       that seems to be what is_selinux_enabled() seems to be doing.
> > > ---
> > >
> > > Enabled SELinux means both /sys/fs/selinux/enforce and mounted /sys/fs/selinux/.
> > > I even checked to boot kernel with SELinux compiled in but disabled in the
> > > command line via 'security=selinux selinux=0 enforcing=0' and the result is
> > > expected: no /sys/fs/selinux directory.
> > >
> > > Both ways of checking are OK, just "access(SELINUX_STATUS_PATH, F_OK) == 0" is
> > > the quickest way (given test requires just SELinux enabled, not enforcing mode).
> > >
> > > This can be changed before merge. Or, feel free to keep the original version as
> > > it also works.
> > >
> > > Kind regards,
> > > Petr
> > >
> > >> - Andrea
> >
> > Ok thanks, I was also thinking that maybe we can verify if certain LSMs
> > are enabled via /sys/kernel/security/lsm . At the moment we only check
> > for selinux, but eventually we can also verify if apparmor is enabled by
> > looking at the list in that file. WDYT?
>
> If this is testing for the listxattr bug, then you can only test for
> LSMs that implement their own xattr, which would be SELinux and Smack.
> AppArmor doesn't implement an xattr, at least not upstream.

To be more precise, the bug is only triggerable for LSMs that
implement the listsecurity LSM hook (to return a synthesized security
xattr regardless of whether one is set in the filesystem), which are
only SELinux and Smack.