> On Oct 9, 2020, at 7:49 AM, Olga Kornievskaia <aglo@xxxxxxxxx> wrote: > > On Thu, Oct 8, 2020 at 9:03 PM Paul Moore <paul@xxxxxxxxxxxxxx> wrote: >> >> ->On Thu, Oct 8, 2020 at 9:50 AM Olga Kornievskaia <aglo@xxxxxxxxx> wrote: >>> On Wed, Oct 7, 2020 at 9:07 PM Paul Moore <paul@xxxxxxxxxxxxxx> wrote: >>>> On Wed, Oct 7, 2020 at 8:41 PM Olga Kornievskaia <aglo@xxxxxxxxx> 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? I would certainly like to take the security label query out of every LOOKUP operation if that is feasible! -- Chuck Lever chucklever@xxxxxxxxx
