On Fri, Oct 9, 2020 at 10:08 AM Chuck Lever <chucklever@xxxxxxxxx> wrote: > > > > > 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? 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@xxxxxxxxx > > >
