On Wed, Nov 4, 2020 at 9:21 AM Olga Kornievskaia <aglo@xxxxxxxxx> wrote:
> 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:
...
> > > > 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"?
Hello again.
To start, the non-LSM portion of the kernel shouldn't be calling
selinux_func_query_vfs() directly, it should call
security_func_query_vfs(); it would be up to the individual LSMs to
indicate to the LSM hooks layer what is required. If SELinux wasn't
built into the kernel, or was disabled at boot, I would expect that
the security_func_query_vfs() function would adjust to exclude the
SELinux requirements.
--
paul moore
www.paul-moore.com
