Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
To:     Paul Moore <paul@paul-moore.com>,
        Olga Kornievskaia <aglo@umich.edu>
Cc:     Stephen Smalley <stephen.smalley.work@gmail.com>,
        Chuck Lever <chucklever@gmail.com>,
        Linux Security Module list 
        <linux-security-module@vger.kernel.org>,
        SElinux list <selinux@vger.kernel.org>,
        Linux NFS Mailing List <linux-nfs@vger.kernel.org>
References: <CAN-5tyETQWVphrgqWjcPrtTzHHyz5DGrRz741yPYRS9Byyd=3Q@mail.gmail.com>
 <CAHC9VhRP2iJqLWiBg46zPKUqxzZoUOuaA6FPigxOw7qubophdw@mail.gmail.com>
 <CAN-5tyFq775PeOOzqskFexdbCgK3Gk_XB2Yy80SRYSc7Pdj=CA@mail.gmail.com>
 <CAHC9VhTzO1z6NmYz6cOLg5OvJiyQXdH_VmLh4=+h1MrGXx36JQ@mail.gmail.com>
 <CAN-5tyGJxUZb5QdJ=fh+L-6rc2B-MhQbDcDkTZNAZAAJm9Q8YQ@mail.gmail.com>
 <FB6C74CE-5D9F-4469-A49B-93CC8A51D7D5@gmail.com>
 <CAN-5tyFQbfkiuno07C6Azc7RcF3z3qF3PP0FutFMD3raBgnQmA@mail.gmail.com>
 <CAEjxPJ7PoAG6f+gVdodx=6X8+_Z_WCFXAuxnpB8WmC1gTF4iQQ@mail.gmail.com>
 <CAN-5tyEy57xoqEbZAThZKHriJywx-5DMKBD5tsXwo5ccGwuctw@mail.gmail.com>
 <CAHC9VhQpCXFySZY42==KR57hfAkVLdS6mSAcp2UHn-GWjEfVLg@mail.gmail.com>
From:   Casey Schaufler <casey@schaufler-ca.com>
Subject: Re: selinux: how to query if selinux is enabled
Message-ID: <bc766b2b-d1f1-d767-579c-02e10ae32a9a@schaufler-ca.com>
Date:   Wed, 14 Oct 2020 09:30:56 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
 Thunderbird/78.3.2
MIME-Version: 1.0
In-Reply-To: <CAHC9VhQpCXFySZY42==KR57hfAkVLdS6mSAcp2UHn-GWjEfVLg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
Content-Length: 2775
Precedence: bulk

On 10/14/2020 8:57 AM, Paul Moore wrote:
> On Wed, Oct 14, 2020 at 10:37 AM Olga Kornievskaia <aglo@umich.edu> wro=
te:
>> On Tue, Oct 13, 2020 at 7:51 PM Stephen Smalley wrote:
>>> 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 modul=
e
>>> 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 hoo=
k
>>> 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".