On 10/14/2020 8:57 AM, Paul Moore wrote:

On Wed, Oct 14, 2020 at 10:37 AM Olga Kornievskaia [off-list ref] wrote:

quoted

On Tue, Oct 13, 2020 at 7:51 PM Stephen Smalley wrote:

quoted

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.

Hi Stephen,

Yes it seems like current api lacks the needed functionality and what
you are suggesting is needed. Thank you for confirming it.

To add my two cents at this point, I would be in favor of a new LSM
hook rather than hijacking security_ismaclabel().  It seems that every
few years someone comes along and asks for a way to detect various LSM
capabilities, this might be the right time to introduce a LSM API for
this.

My only concern about adding such an API is it could get complicated
very quickly.  One nice thing we have going for us is that this is a
kernel internal API so we don't have to worry about kernel/userspace
ABI promises, if we decide we need to change the API at some point in
the future we can do so without problem.  For that reason I'm going to
suggest we do something relatively simple with the understanding that
we can change it if/when the number of users grow.

To start the discussion I might suggest the following:

#define LSM_FQUERY_VFS_NONE     0x00000000
#define LSM_FQUERY_VFS_XATTRS   0x00000001
int security_func_query_vfs(unsigned int flags);

... with an example SELinux implementation looks like this:

int selinux_func_query_vfs(unsigned int flags)
{
    return !!(flags & LSM_FQUERY_VFS_XATTRS);
}

Not a bad start, but I see optimizations and issues.

It would be really easy to collect the LSM features at module
initialization by adding the feature flags to struct lsm_info.
We could maintain a variable lsm_features in security.c that
has the cumulative feature set. Rather than have an LSM hook for
func_query_vfs we'd get

int security_func_query_vfs(void)
{
	return !!(lsm_features & LSM_FQUERY_VFS_XATTRS);
}

In either case there could be confusion in the case where more
than one security module provides the feature. NFS, for example,
cares about the SELinux "selinux" attribute, but probably not
about the Smack "SMACK64EXEC" attribute. It's entirely possible
that a bit isn't enough information to check about a "feature".