Re: [PATCH v5] vfs, security: Fix automount superblock LSM init problem, preventing NFS sb sharing

[Paul Moore <paul@paul-moore.com>]

On Fri, Nov 11, 2022 at 12:40 PM Paul Moore <paul@paul-moore.com> wrote:
> On Thu, Nov 10, 2022 at 6:09 AM David Howells <dhowells@redhat.com> wrote:
> >
> > When NFS superblocks are created by automounting, their LSM parameters
> > aren't set in the fs_context struct prior to sget_fc() being called,
> > leading to failure to match existing superblocks.
> >
> > Fix this by adding a new LSM hook to load fc->security for submount
> > creation when alloc_fs_context() is creating the fs_context for it.
> >
> > However, this uncovers a further bug: nfs_get_root() initialises the
> > superblock security manually by calling security_sb_set_mnt_opts() or
> > security_sb_clone_mnt_opts() - but then vfs_get_tree() calls
> > security_sb_set_mnt_opts(), which can lead to SELinux, at least,
> > complaining.
> >
> > Fix that by adding a flag to the fs_context that suppresses the
> > security_sb_set_mnt_opts() call in vfs_get_tree().  This can be set by NFS
> > when it sets the LSM context on the new superblock.
> >
> > The first bug leads to messages like the following appearing in dmesg:
> >
> >         NFS: Cache volume key already in use (nfs,4.2,2,108,106a8c0,1,,,,100000,100000,2ee,3a98,1d4c,3a98,1)
> >
> > Changes
> > =======
> > ver #5)
> >  - Removed unused variable.
> >  - Only allocate smack_mnt_opts if we're dealing with a submount.
> >
> > ver #4)
> >  - When doing a FOR_SUBMOUNT mount, don't set the root label in SELinux or
> >    Smack.
> >
> > ver #3)
> >  - Made LSM parameter extraction dependent on fc->purpose ==
> >    FS_CONTEXT_FOR_SUBMOUNT.  Shouldn't happen on FOR_RECONFIGURE.
> >
> > ver #2)
> >  - Added Smack support
> >  - Made LSM parameter extraction dependent on reference != NULL.
> >
> > Signed-off-by: David Howells <dhowells@redhat.com>
> > Fixes: 9bc61ab18b1d ("vfs: Introduce fs_context, switch vfs_kern_mount() to it.")
> > Fixes: 779df6a5480f ("NFS: Ensure security label is set for root inode)
> > Tested-by: Jeff Layton <jlayton@kernel.org>
> > Reviewed-by: Jeff Layton <jlayton@kernel.org>
> > Acked-by: Casey Schaufler <casey@schaufler-ca.com>
> > Acked-by: Christian Brauner (Microsoft) <brauner@kernel.org>
> > cc: Trond Myklebust <trond.myklebust@hammerspace.com>
> > cc: Anna Schumaker <anna@kernel.org>
> > cc: Alexander Viro <viro@zeniv.linux.org.uk>
> > cc: Scott Mayhew <smayhew@redhat.com>
> > cc: Jeff Layton <jlayton@kernel.org>
> > cc: Paul Moore <paul@paul-moore.com>
> > cc: linux-nfs@vger.kernel.org
> > cc: selinux@vger.kernel.org
> > cc: linux-security-module@vger.kernel.org
> > cc: linux-fsdevel@vger.kernel.org
> > Link: https://lore.kernel.org/r/165962680944.3334508.6610023900349142034.stgit@warthog.procyon.org.uk/ # v1
> > Link: https://lore.kernel.org/r/165962729225.3357250.14350728846471527137.stgit@warthog.procyon.org.uk/ # v2
> > Link: https://lore.kernel.org/r/165970659095.2812394.6868894171102318796.stgit@warthog.procyon.org.uk/ # v3
> > Link: https://lore.kernel.org/r/166133579016.3678898.6283195019480567275.stgit@warthog.procyon.org.uk/ # v4
> > Link: https://lore.kernel.org/r/217595.1662033775@warthog.procyon.org.uk/ # v5
> > ---
> >
> >  fs/fs_context.c               |    4 +++
> >  fs/nfs/getroot.c              |    1 +
> >  fs/super.c                    |   10 +++++---
> >  include/linux/fs_context.h    |    1 +
> >  include/linux/lsm_hook_defs.h |    1 +
> >  include/linux/lsm_hooks.h     |    6 ++++-
> >  include/linux/security.h      |    6 +++++
> >  security/security.c           |    5 ++++
> >  security/selinux/hooks.c      |   25 +++++++++++++++++++
> >  security/smack/smack_lsm.c    |   54 +++++++++++++++++++++++++++++++++++++++++
> >  10 files changed, 108 insertions(+), 5 deletions(-)
> >
> > diff --git a/fs/fs_context.c b/fs/fs_context.c
> > index 24ce12f0db32..22248b8a88a8 100644
> > --- a/fs/fs_context.c
> > +++ b/fs/fs_context.c
> > @@ -282,6 +282,10 @@ static struct fs_context *alloc_fs_context(struct file_system_type *fs_type,
> >                 break;
> >         }
> >
> > +       ret = security_fs_context_init(fc, reference);
> > +       if (ret < 0)
> > +               goto err_fc;
> > +
> >         /* TODO: Make all filesystems support this unconditionally */
> >         init_fs_context = fc->fs_type->init_fs_context;
> >         if (!init_fs_context)
> > diff --git a/fs/nfs/getroot.c b/fs/nfs/getroot.c
> > index 11ff2b2e060f..651bffb0067e 100644
> > --- a/fs/nfs/getroot.c
> > +++ b/fs/nfs/getroot.c
> > @@ -144,6 +144,7 @@ int nfs_get_root(struct super_block *s, struct fs_context *fc)
> >         }
> >         if (error)
> >                 goto error_splat_root;
> > +       fc->lsm_set = true;
> >         if (server->caps & NFS_CAP_SECURITY_LABEL &&
> >                 !(kflags_out & SECURITY_LSM_NATIVE_LABELS))
> >                 server->caps &= ~NFS_CAP_SECURITY_LABEL;
> > diff --git a/fs/super.c b/fs/super.c
> > index 8d39e4f11cfa..f200ae0549ca 100644
> > --- a/fs/super.c
> > +++ b/fs/super.c
> > @@ -1553,10 +1553,12 @@ int vfs_get_tree(struct fs_context *fc)
> >         smp_wmb();
> >         sb->s_flags |= SB_BORN;
> >
> > -       error = security_sb_set_mnt_opts(sb, fc->security, 0, NULL);
> > -       if (unlikely(error)) {
> > -               fc_drop_locked(fc);
> > -               return error;
> > +       if (!(fc->lsm_set)) {
> > +               error = security_sb_set_mnt_opts(sb, fc->security, 0, NULL);
> > +               if (unlikely(error)) {
> > +                       fc_drop_locked(fc);
> > +                       return error;
> > +               }
> >         }
>
> Thinking about all the different things that an LSM could do, would it
> ever be possible that a LSM would want the security_sb_set_mnt_opts()
> call to happen here?  I'm wondering if we are better off leaving it up
> to the LSM by passing the fs_context in the security_sb_set_mnt_opts()
> hook; those that want to effectively skip this call due to a submount
> setup already done in security_fs_context_init() can check the
> fs_context::purpose value in the security_sb_set_mnt_opts() hook.

Actually, we could probably also create a LSM specific flag in
fs_context::security to indicate that the setup has already been done.
That's probably a little safer than relying on fs_context::purpose in
the security_sb_set_mnt_opts() hook.

> Thoughts?

-- 
paul-moore.com