On Fri, Oct 9, 2020 at 12:36 PM Olga Kornievskaia [off-list ref] wrote:

On Fri, Oct 9, 2020 at 10:08 AM Chuck Lever [off-list ref] wrote:

quoted

quoted

On Oct 9, 2020, at 7:49 AM, Olga Kornievskaia [off-list ref] wrote:

On Thu, Oct 8, 2020 at 9:03 PM Paul Moore [off-list ref] wrote:

quoted

->On Thu, Oct 8, 2020 at 9:50 AM Olga Kornievskaia [off-list ref] wrote:

quoted

On Wed, Oct 7, 2020 at 9:07 PM Paul Moore [off-list ref] wrote:

quoted

On Wed, Oct 7, 2020 at 8:41 PM Olga Kornievskaia [off-list ref] wrote:

quoted

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 suggest either introducing a new hook for your purpose, or
altering the existing one to support a form of query that isn't based
on a particular xattr name but rather just checking whether the module
supports/uses MAC labels at all.  Options: 1) NULL argument to the
existing hook indicates a general query (could hide a bug in the
caller, so not optimal), 2) Add a new bool argument to the existing
hook to indicate whether the name should be used, or 3) Add a new hook
that doesn't take any arguments.

quoted

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.