On Wed, Oct 14, 2020 at 10:37 AM Olga Kornievskaia <aglo@xxxxxxxxx> wrote:
> 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 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);
}
--
paul moore
www.paul-moore.com
