Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp7598250pxb; Thu, 18 Feb 2021 14:41:46 -0800 (PST) X-Google-Smtp-Source: ABdhPJzQ4Jhzco/GxLGUzCcwQWAVSOWyN2LNAobmLuhK8aYeX7eGDE0n+mGD6VTzIPrSzJxQfO62 X-Received: by 2002:a17:906:80c3:: with SMTP id a3mr6180136ejx.486.1613688106101; Thu, 18 Feb 2021 14:41:46 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1613688106; cv=none; d=google.com; s=arc-20160816; b=BSXJ3upv/qfaQ/Ea7zcwBq4VbdcFU7vZFEgJNnRYl6Q8hoOUFBWOgv1YVMR8jvtQkm W1CB4TzzXhKgjBJo9VwhkFxoNtm8vPDmvoV5LrV2Uerx8j+uHMZ+0efbVyLN2gAHgeoX ++od5kh7BQmpyl0UF14SCBVq7z8K3L+I2qowp8VzaaKOX6vMu47RA7Jgvlzk2RS9U/vb tehGHJiTMLuBfKtHdU4EC8LS6yo32+yhRySEAuNRDCcEkT0L9zdZWutizDIDKq6ucOWt oNsyLqg0hLeu8dR7q+uzr/mcG3J+DMtRbP8SqPdIsh1q16y+pvVoos+IqVi41lXHtcnL tmkg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=cTCuvFfvg+RVGlmApliroe5RH99dNBSdy6kghqEKeKM=; b=yqvovHLs5iPIJWMbiznLluJWfkIxfNuMOtB6VcwPkd8TIAMbqQLup439YCclprW1MD pXn8rfDp675F2WuC8StMDqhncbH/rM0gk5t98zhwqZTFpk0fnd1EElzR9xkv4q+SUKNN 3vBkw34+T2yFecfPImrtnMtyqT+TqPTGoRINBMvmyc2XGd5rQwk8E6z61/x5hmwUkICT 6CMvdV312Q1kokXpYudbTjJlF3gmG1RPNAppba5TVsjqNlawFnmgfR/ABs7q7m0yFLir +q2qLqKD+0VLGENVZWA4fs0uNrF7wnEy7/O80ItLKBuVVvmQwjUduTSb579hJ+IluTss sElw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=TTRqCZit; spf=pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id gr13si4531044ejb.50.2021.02.18.14.41.14; Thu, 18 Feb 2021 14:41:46 -0800 (PST) Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=TTRqCZit; spf=pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229763AbhBRWkd (ORCPT + 99 others); Thu, 18 Feb 2021 17:40:33 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38540 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229649AbhBRWk2 (ORCPT ); Thu, 18 Feb 2021 17:40:28 -0500 Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [IPv6:2a00:1450:4864:20::62a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A9EABC061574; Thu, 18 Feb 2021 14:39:47 -0800 (PST) Received: by mail-ej1-x62a.google.com with SMTP id jt13so8440144ejb.0; Thu, 18 Feb 2021 14:39:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cTCuvFfvg+RVGlmApliroe5RH99dNBSdy6kghqEKeKM=; b=TTRqCZitzKXjbAYcKdh2EHw49afJposyH8zD2++2jW7hSIF7Ws+0DtKovdZLUzO9l6 iGyhjkcj+4p4MyMfu2eEQWNRxI9QEvs12dUa9DIP8t7Wee35FfbDmY6KQgLjaAq5umzr BoyHINLcOfXtqvCugu4LSd4u9Y9w85ZDKXBIg1eBAi8SBA/Sj+m1nLSzWnarSRbg3EZe Kh88mGVSdNGFgp1K93BeZI2sqv9brftT0+/F8GXPKYoqlWkyEZYUjJ8N/dJfOIMjujcA lSUDmhSIvjvBTVJbMxFtkPXJym7FFvw78RV40Uzs0rYr7rC8Ns68JFdk4YLrWR8l4Enk ovsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cTCuvFfvg+RVGlmApliroe5RH99dNBSdy6kghqEKeKM=; b=NRrluC30NtSDK3Cd6U8ArFyBYOseg4ZxvZesVwhG3RevPUh4rkXKGSms0vWqzeOVod IsJJJlnT6ZwAsMcGU429nT61D/2k4wCOQ0xIPNbc9QzujRFrni8lDm933i/psWwW1K+i sWJGR/ANS3hCMNLaLIXvFZgXV5c3XbQSHxmQimz7OvgtT4bP2J4WfCEmqMSskj0W/tIm 6OHLVaynb1vXCOKTURz/rKYRcNFN22c33Qu0IoUF4Fi8NIe5IKxjAcVavHiQgz7iK0pY iWJPBpdQWjg+VJvL5vaBmn2cztJ6AURZaDS2paPXIJhxFYg6y92uQ59zuZOy2rHJ89KU z+Vg== X-Gm-Message-State: AOAM530inlUQUHrhB0bolGvqNL/vyy8wFDH+Xg+ix6eK6RBpTRzPvz5p 4qCQza0gO/mdmL8vBZSwwG+L+NBxmPplFVZD0Dw= X-Received: by 2002:a17:907:35ca:: with SMTP id ap10mr6079157ejc.451.1613687986394; Thu, 18 Feb 2021 14:39:46 -0800 (PST) MIME-Version: 1.0 References: <20210218195046.19280-1-olga.kornievskaia@gmail.com> <20210218195046.19280-2-olga.kornievskaia@gmail.com> <7587df15-6f6f-3581-8bae-a648315cfae9@schaufler-ca.com> In-Reply-To: <7587df15-6f6f-3581-8bae-a648315cfae9@schaufler-ca.com> From: Olga Kornievskaia Date: Thu, 18 Feb 2021 17:39:35 -0500 Message-ID: Subject: Re: [PATCH v2 2/2] NFSv4 account for selinux security context when deciding to share superblock To: Casey Schaufler Cc: Trond Myklebust , Anna Schumaker , linux-nfs , Linux Security Module list , SElinux list Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org On Thu, Feb 18, 2021 at 5:07 PM Casey Schaufler wrote: > > On 2/18/2021 11:50 AM, Olga Kornievskaia wrote: > > From: Olga Kornievskaia > > > > Keep track of whether or not there was an selinux context mount > > options during the mount. > > This may be the intention, but it's not what the change you're > introducing here does. Can you explain why, as I must be doing something wrong? I'm familiar with NFS but not with Selinux and I thought I was doing the correct changes to the Selinux. If that's not the case would you share what has been done incorrectly. > > While deciding if the superblock can be > > shared for the new mount, check for if we had selinux context on > > the existing mount and call into selinux to tell if new passed > > in selinux context is compatible with the existing mount's options. > > You're describing how you expect the change to be used, not > what it does. If I am the author of a security module other > than SELinux (which, it turns out, I am) what would I use this > for? How might this change interact with my security module? > Is this something I might exploit? If I am the author of a > filesystem other than NFS (which I am not) should I be doing > the same thing? I'm not sure I'm understanding your questions. I'm solving a bug that exists when NFS interacts with selinux. This is really not a feature that I'm introducing. I thought it was somewhat descriptive with an example that if you want to mount with different security contexts but whatever you are mounting has a possibility of sharing the same superblock, we need to be careful and take security contexts that are being used by those mount into account to decide whether or not to share the superblock. Again I thought that's exactly what the commit states. A different security module, if it acts on security context, would have to have the same ability to compare if one context options are compatible with anothers. Another filesystem can decide if it wants to share superblocks based on compatibility of existing security context and new one. Is that what you are asking? > > > > > Previously, NFS wasn't able to do the following 2mounts: > > mount -o vers=4.2,sec=sys,context=system_u:object_r:root_t:s0 > > :/ /mnt > > mount -o vers=4.2,sec=sys,context=system_u:object_r:swapfile_t:s0 > > :/scratch /scratch > > > > 2nd mount would fail with "mount.nfs: an incorrect mount option was > > specified" and var log messages would have: > > "SElinux: mount invalid. Same superblock, different security > > settings for.." > > > > Signed-off-by: Olga Kornievskaia > > --- > > fs/nfs/fs_context.c | 3 +++ > > fs/nfs/internal.h | 1 + > > fs/nfs/super.c | 4 ++++ > > include/linux/nfs_fs_sb.h | 1 + > > 4 files changed, 9 insertions(+) > > > > diff --git a/fs/nfs/fs_context.c b/fs/nfs/fs_context.c > > index 06894bcdea2d..8067f055d842 100644 > > --- a/fs/nfs/fs_context.c > > +++ b/fs/nfs/fs_context.c > > @@ -448,6 +448,9 @@ static int nfs_fs_context_parse_param(struct fs_context *fc, > > if (opt < 0) > > return ctx->sloppy ? 1 : opt; > > > > + if (fc->security) > > + ctx->has_sec_mnt_opts = 1; > > + > > switch (opt) { > > case Opt_source: > > if (fc->source) > > diff --git a/fs/nfs/internal.h b/fs/nfs/internal.h > > index 62d3189745cd..08f4f34e8cf5 100644 > > --- a/fs/nfs/internal.h > > +++ b/fs/nfs/internal.h > > @@ -96,6 +96,7 @@ struct nfs_fs_context { > > char *fscache_uniq; > > unsigned short protofamily; > > unsigned short mountfamily; > > + bool has_sec_mnt_opts; > > > > struct { > > union { > > diff --git a/fs/nfs/super.c b/fs/nfs/super.c > > index 4034102010f0..0a2d252cf90f 100644 > > --- a/fs/nfs/super.c > > +++ b/fs/nfs/super.c > > @@ -1058,6 +1058,7 @@ static void nfs_fill_super(struct super_block *sb, struct nfs_fs_context *ctx) > > &sb->s_blocksize_bits); > > > > nfs_super_set_maxbytes(sb, server->maxfilesize); > > + server->has_sec_mnt_opts = ctx->has_sec_mnt_opts; > > } > > > > static int nfs_compare_mount_options(const struct super_block *s, const struct nfs_server *b, > > @@ -1174,6 +1175,9 @@ static int nfs_compare_super(struct super_block *sb, struct fs_context *fc) > > return 0; > > if (!nfs_compare_userns(old, server)) > > return 0; > > + if ((old->has_sec_mnt_opts || fc->security) && > > + security_sb_mnt_opts_compat(sb, fc->security)) > > + return 0; > > return nfs_compare_mount_options(sb, server, fc); > > } > > > > diff --git a/include/linux/nfs_fs_sb.h b/include/linux/nfs_fs_sb.h > > index 38e60ec742df..3f0acada5794 100644 > > --- a/include/linux/nfs_fs_sb.h > > +++ b/include/linux/nfs_fs_sb.h > > @@ -254,6 +254,7 @@ struct nfs_server { > > > > /* User namespace info */ > > const struct cred *cred; > > + bool has_sec_mnt_opts; > > }; > > > > /* Server capabilities */ >