On Wed, Oct 14, 2020 at 12:31 PM Casey Schaufler <casey@xxxxxxxxxxxxxxxx> wrote:
> On 10/14/2020 8:57 AM, Paul Moore wrote:
> > 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);
> > }
>
> 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);
> }
Works for me.
> 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".
In the LSM stacking world that shouldn't matter to callers, right? Or
perhaps more correctly, if it matters to the caller which individual
LSM supports what feature then the caller is doing it wrong, right?
--
paul moore
www.paul-moore.com
