Re: selinux: how to query if selinux is enabled

[Olga Kornievskaia <aglo@umich.edu>]

On Fri, Oct 9, 2020 at 10:08 AM Chuck Lever <chucklever@gmail.com> wrote:
>
>
>
> > On Oct 9, 2020, at 7:49 AM, Olga Kornievskaia <aglo@umich.edu> wrote:
> >
> > On Thu, Oct 8, 2020 at 9:03 PM Paul Moore <paul@paul-moore.com> wrote:
> >>
> >> ->On Thu, Oct 8, 2020 at 9:50 AM Olga Kornievskaia <aglo@umich.edu> wrote:
> >>> On Wed, Oct 7, 2020 at 9:07 PM Paul Moore <paul@paul-moore.com> wrote:
> >>>> On Wed, Oct 7, 2020 at 8:41 PM Olga Kornievskaia <aglo@umich.edu> wrote:
> >>>>> Hi folks,
> >>>>>
> >>>>> From some linux kernel module, is it possible to query and find out
> >>>>> whether or not selinux is currently enabled or not?
> >>>>>
> >>>>> Thank you.
> >>>>
> >>>> [NOTE: CC'ing the SELinux list as it's probably a bit more relevant
> >>>> that the LSM list]
> >>>>
> >>>> In general most parts of the kernel shouldn't need to worry about what
> >>>> LSMs are active and/or enabled; the simply interact with the LSM(s)
> >>>> via the interfaces defined in include/linux/security.h (there are some
> >>>> helpful comments in include/linux/lsm_hooks.h).  Can you elaborate a
> >>>> bit more on what you are trying to accomplish?
> >>>
> >>> Hi Paul,
> >>>
> >>> Thank you for the response. What I'm trying to accomplish is the
> >>> following. Within a file system (NFS), typically any queries for
> >>> security labels are triggered by the SElinux (or I guess an LSM in
> >>> general) (thru the xattr_handler hooks). However, when the VFS is
> >>> calling to get directory entries NFS will always get the labels
> >>> (baring server not supporting it). However this is useless and affects
> >>> performance (ie., this makes servers do extra work  and adds to the
> >>> network traffic) when selinux is disabled. It would be useful if NFS
> >>> can check if there is anything that requires those labels, if SElinux
> >>> is enabled or disabled.
> >>
> >> [Adding Chuck Lever to the CC line as I believe he has the most recent
> >> LSM experience from the NFS side - sorry Chuck :)]
> >>
> >> I'll need to ask your patience on this as I am far from a NFS expert.
> >>
> >> Looking through the NFS readdir/getdents code this evening, I was
> >> wondering if the solution in the readdir case is to simply tell the
> >> server you are not interested in the security label by masking out
> >> FATTR4_WORD2_SECURITY_LABEL in the nfs4_readdir_arg->bitmask in
> >> _nfs4_proc_readdir()?  Of course this assumes that the security label
> >> genuinely isn't needed in this case (and not requesting it doesn't
> >> bypass access controls or break something on the server side), and we
> >> don't screw up some NFS client side cache by *not* fetching the
> >> security label attribute.
> >>
> >> Is this remotely close to workable, or am I missing something fundamental?
> >>
> >
> > No this is not going to work, as NFS requires labels when labels are
> > indeed needed by the LSM. What I'm looking for is an optimization.
> > What we have is functionality correct but performance might suffer for
> > the standard case of NFSv4.2 seclabel enabled server and clients that
> > don't care about seclabels.
>
> Initial thought: We should ask linux-nfs for help with this.
> I've added them to the Cc: list.
>
> Olga, are you asking if the kernel NFS client module can somehow find
> out whether the rest of the kernel is configured to care about security
> labels before it forms an NFSv4 READDIR or LOOKUP request?

Yes exactly, but I'm having a hard time trying to figure out how to
use security_ismaclabel() function as has been suggested by Casey.

> I would certainly like to take the security label query out of every
> LOOKUP operation if that is feasible!

A LOOKUP doesn't add the seclabel query (by default) like READDIR does
(it's hard-coded in the xdr code). LOOKUP uses server's bitmask and
chooses the version without the seclabel bitmask because no label is
passed into it. It looks like LOOKUP just allocates a label in
nfs_lookup_revalidate_dentry().  So it's not driven by the something
that I see used by the xattr_handle example in the NFS code.

>
>
> --
> Chuck Lever
> chucklever@gmail.com
>
>
>