On Wed, Oct 14, 2020 at 8:11 PM Paul Moore <paul@xxxxxxxxxxxxxx> wrote:
>
> 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?
Hi folks,
I would like to resurrect this discussion and sorry for a delayed
response. I'm a little bit unsure about the suggested approach of
adding something like selinux_func_query_vfs() call where selinux has
such a function. What happens when selinux is configured to be
"disabled" wouldn't this call still return the same value as when it
is configured as "permissive or enforcing"?
Thank you.
>
> --
> paul moore
> www.paul-moore.com
