Thread (4 messages) 4 messages, 3 authors, 2022-11-19

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

From: Paul Moore <paul@paul-moore.com>
Date: 2022-11-11 17:43:48
Also in: linux-fsdevel, linux-nfs, lkml, selinux

On Fri, Nov 11, 2022 at 12:40 PM Paul Moore [off-list ref] wrote:
On Thu, Nov 10, 2022 at 6:09 AM David Howells [off-list ref] wrote:
quoted
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 <redacted>
cc: Anna Schumaker <anna@kernel.org>
cc: Alexander Viro <viro@zeniv.linux.org.uk>
cc: Scott Mayhew <redacted>
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/ (local) # v1
Link: https://lore.kernel.org/r/165962729225.3357250.14350728846471527137.stgit@warthog.procyon.org.uk/ (local) # v2
Link: https://lore.kernel.org/r/165970659095.2812394.6868894171102318796.stgit@warthog.procyon.org.uk/ (local) # v3
Link: https://lore.kernel.org/r/166133579016.3678898.6283195019480567275.stgit@warthog.procyon.org.uk/ (local) # v4
Link: https://lore.kernel.org/r/217595.1662033775@warthog.procyon.org.uk/ (local) # 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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help