Received: by 2002:a25:e7d8:0:0:0:0:0 with SMTP id e207csp1703543ybh; Sun, 8 Mar 2020 10:48:02 -0700 (PDT) X-Google-Smtp-Source: ADFU+vtrnQyuS/dUrafrFFu1KTpvasH5KfVNcxDfwXCD0wtcGVn+KFH68LyKGLKNdAvWfm3sWi3j X-Received: by 2002:aca:bfc6:: with SMTP id p189mr9120075oif.21.1583689682121; Sun, 08 Mar 2020 10:48:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1583689682; cv=none; d=google.com; s=arc-20160816; b=dReOZGf3FG7kCL1iWFSoHWb1JIIo9t7nQ3Yfm9GZCQGWcKUAcvQ2y1BV4iN9eXXMWB 6Eihtq2wap3YlVCC+aSCXU3qKY0Tkfivk42afrWpxfFd6UYcGFhiGmE3C1fD5adG+KR5 qKsIuF84XToFZ6n9wvzxs4q+G/cuu+YnhhMyUlurWNUWW6vhWTXnONRSw0KnosSsykvC 5RqzRfzCgrqplBdjHaSEkD4v5/C5O4r0ho1TPW6rsRt8z/LeDWVBW7YRLehth2Ko/9aK XIEW4HFX5s+sJiArfK6bIYyFzD8HPPlt1tDGsFAdsH/xzZgwWqIL3WjZAtVoIeEkSPpX VoMw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:date:cc:to:from:subject :message-id:dkim-signature; bh=MgatK+4FHcWh3IlaOJnDEIMpRwe8HhketPCBA2Zzp+o=; b=FOsnIsstGqriSlpvlgVkdQdC4WJfrqK16RU/XPFxdwO377mU7FacoGmnAhUt/JYWv9 UnASXFKFSpWSn+5yQS/vAD5/ZFV72S2Al53ZbY2gw7JboC55LZOiH2h3WC5MThIn+jqc kgMpzSCy488tiWtPlV/1ZxlY5zAbapStyqugbAKPVIscbh7coAWfVXyvnUoGVbfUZKUE sgKSznIjkh4dlIkdnxQuSxzTK7GwZHcv/qagJDp7v+3ZFkhrHOIwd5chgf9BGcLNhK3O 2irSFC5C6u3/DnyAQlW3d71GSe6Tb9R8KNrV1NvySik4lyxuAVN9zM/aYDE/FLUbDeyA Eojg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@btinternet.com header.s=btmx201904 header.b=GbeFN2nE; spf=pass (google.com: best guess record for domain of linux-nfs-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=btinternet.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t126si3026561oif.127.2020.03.08.10.47.33; Sun, 08 Mar 2020 10:48:02 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-nfs-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@btinternet.com header.s=btmx201904 header.b=GbeFN2nE; spf=pass (google.com: best guess record for domain of linux-nfs-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=btinternet.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726291AbgCHRrQ (ORCPT + 99 others); Sun, 8 Mar 2020 13:47:16 -0400 Received: from mailomta1-re.btinternet.com ([213.120.69.94]:26788 "EHLO re-prd-fep-044.btinternet.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726279AbgCHRrQ (ORCPT ); Sun, 8 Mar 2020 13:47:16 -0400 Received: from re-prd-rgout-003.btmx-prd.synchronoss.net ([10.2.54.6]) by re-prd-fep-044.btinternet.com with ESMTP id <20200308174713.YAF16865.re-prd-fep-044.btinternet.com@re-prd-rgout-003.btmx-prd.synchronoss.net>; Sun, 8 Mar 2020 17:47:13 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btinternet.com; s=btmx201904; t=1583689633; bh=MgatK+4FHcWh3IlaOJnDEIMpRwe8HhketPCBA2Zzp+o=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References:MIME-Version; b=GbeFN2nEpHxB+7YbuGEM+WJT0PDRuxjaI/Gyl+dTnp4n04m6mUFM7sMcnWmFTs7iRW9uqL1Hv3tkUZTilbcLs0lkuSEnF+nlmOYpSUEfgMTeWhP7bCRGGbOnptF0oqVCBCKJe150OULlxRz/5RXlrpO1rpfotmSG3F6qphlgrZZQYzVQJbtWTIotVSc2nrs5vDl5y+KI425qdKp6I6fM/AGobI7wWozO47RYHVI6tPnWC4qR2qQ5I7R73FaByApDtSyfny4REXgueKjEv4yzB5P3jTdFFqL0PpRszN8dufpVnnafITwHc+CwKJ9ZptrjTeHNcGfrG3I0GAIrMNQ1+A== Authentication-Results: btinternet.com; auth=pass (PLAIN) smtp.auth=richard_c_haines@btinternet.com X-Originating-IP: [31.51.79.181] X-OWM-Source-IP: 31.51.79.181 (GB) X-OWM-Env-Sender: richard_c_haines@btinternet.com X-VadeSecure-score: verdict=clean score=0/300, class=clean X-RazorGate-Vade: gggruggvucftvghtrhhoucdtuddrgedugedrudduiedguddtjecutefuodetggdotefrodftvfcurfhrohhfihhlvgemuceutffkvffkuffjvffgnffgvefqofdpqfgfvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepkffuhffvffgjfhgtfggggfesthejredttderjeenucfhrhhomheptfhitghhrghrugcujfgrihhnvghsuceorhhitghhrghruggptggphhgrihhnvghssegsthhinhhtvghrnhgvthdrtghomheqnecuffhomhgrihhnpehgihhthhhusgdrtghomhenucfkphepfedurdehuddrjeelrddukedunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehhvghloheplhhotggrlhhhohhsthdrlhhotggrlhguohhmrghinhdpihhnvghtpeefuddrhedurdejledrudekuddpmhgrihhlfhhrohhmpeeorhhitghhrghruggptggphhgrihhnvghssegsthhinhhtvghrnhgvthdrtghomhequceuqfffjgepkeeukffvoffkoffgpdhrtghpthhtohepoegrnhhnrgdrshgthhhumhgrkhgvrhesnhgvthgrphhprdgtohhmqedprhgtphhtthhopeeosghfihgvlhgushesfhhivghlughsvghsrdhorhhgqedprhgtphhtthhopeeolhhinhhugidqnhhfshesvhhgvghrrdhkvghrnhgvlhdrohhrgheqpdhrtghpthhtohepoehprghulhesphgruhhlqdhmohhorhgvrdgtohhmqedprhgtphhtthhopeeorhhitghhrghruggptggphhgr ihhnvghssehhohhtmhgrihhlrdgtohhmqedprhgtphhtthhopeeoshgushesthihtghhohdrnhhsrgdrghhovheqpdhrtghpthhtohepoehsvghlihhnuhigsehvghgvrhdrkhgvrhhnvghlrdhorhhgqedprhgtphhtthhopeeoshhmrgihhhgvfiesrhgvughhrghtrdgtohhmqedprhgtphhtthhopeeoshhtvghphhgvnhdrshhmrghllhgvhidrfihorhhksehgmhgrihhlrdgtohhmqedprhgtphhtthhopeeothhrohhnugdrmhihkhhlvggsuhhstheshhgrmhhmvghrshhprggtvgdrtghomheq X-RazorGate-Vade-Verdict: clean 0 X-RazorGate-Vade-Classification: clean Received: from localhost.localdomain (31.51.79.181) by re-prd-rgout-003.btmx-prd.synchronoss.net (5.8.340) (authenticated as richard_c_haines@btinternet.com) id 5E3A16DE04FEE9DA; Sun, 8 Mar 2020 17:47:13 +0000 Message-ID: Subject: Re: [PATCH] NFS: Ensure security label is set for root inode From: Richard Haines To: Scott Mayhew , Stephen Smalley Cc: trond.myklebust@hammerspace.com, anna.schumaker@netapp.com, bfields@fieldses.org, Paul Moore , Stephen Smalley , linux-nfs@vger.kernel.org, SElinux list Date: Sun, 08 Mar 2020 17:47:07 +0000 In-Reply-To: <20200306220132.GD3175@aion.usersys.redhat.com> References: <20200303225837.1557210-1-smayhew@redhat.com> <6bb287d1687dc87fe9abc11d475b3b9df061f775.camel@btinternet.com> <20200304143701.GB3175@aion.usersys.redhat.com> <20200306220132.GD3175@aion.usersys.redhat.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.34.4 (3.34.4-1.fc31) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-nfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org On Fri, 2020-03-06 at 17:01 -0500, Scott Mayhew wrote: > On Wed, 04 Mar 2020, Stephen Smalley wrote: > > > On Wed, Mar 4, 2020 at 9:37 AM Scott Mayhew > > wrote: > > > On Wed, 04 Mar 2020, Richard Haines wrote: > > > > I built and tested this patch on selinux-next (note that the > > > > NFS module > > > > is a few patches behind). > > > > The unlabeled problem is solved, however using: > > > > > > > > mount -t nfs -o > > > > vers=4.2,rootcontext=system_u:object_r:test_filesystem_file_t:s > > > > 0 > > > > localhost:$TESTDIR /mnt/selinux-testsuite > > > > > > > > I get the message: > > > > mount.nfs: an incorrect mount option was specified > > > > with a log entry: > > > > SELinux: mount invalid. Same superblock, different > > > > security > > > > settings for (dev 0:42, type nfs) > > > > > > > > If I use "fscontext=" instead then works okay. Using no context > > > > option > > > > also works. I guess the rootcontext= option should still work > > > > ??? > > > > > > Thanks for testing. It definitely wasn't my intention to break > > > anything, so I'll look into it. > > > > I'm not sure that rootcontext= should be supported or is > > supportable > > over labeled NFS. > > Should rootcontext= be supported for NFS versions < 4.2? If not then > maybe it that option should be rejected for nfs and nfs4 fstypes in > selinux_set_mnt_opts(). > > > It's primary use case is to allow assigning a specific context > > other > > than the default policy-defined one > > to the root directory for filesystems that support labeling but > > don't > > have existing labels on their root > > directories, e.g. tmpfs mounts. Even if we set the rootcontext > > based > > on rootcontext= during mount(2), > > it would likely get overridden by subsequent attribute fetches from > > the server I would think (e.g. it probably > > already switches to the context from the server after 30 seconds or > > Yes, that's what happens. If we wanted to retain that behavior > moving > forward, then we need to avoid calling nfs_setsecurity() for the root > inode when the rootcontext= option was used. To do that, I think > we'd > need to add a flag that could be passed back to NFS via the > set_kern_flags parameter of selinux_set_mnt_opts(). > > > so?). As long as the separate context= option > > continues to work correctly on NFS, I'm not overly concerned about > > this. > > Yep, the context= option still works. > > I should note that we are getting similar errors though when trying > > to > > specify any context-related > > mount options on NFS via the new fsconfig(2) system call, see > > https://github.com/SELinuxProject/selinux-kernel/issues/49 I've done further testing and found that with this patch the fsconfig(2) problem is also resolved for nfs (provided the rootcontext is not specified). > > I don't know if this change in when security_sb_set_mnt_opts() will > > alter that situation any. > > > > Also, FYI, we have recently made it possible to run the > > selinux-testsuite without errors within a labeled NFS > > mount. If you clone > > https://github.com/SELinuxProject/selinux-testsuite/ and follow the > > README.md > > instructions including the NFS section and run ./tools/nfs.sh, it > > will > > export and mount the testsuite directory > > via labeled NFS over loopback and run all tests that can be > > supported > > over NFS, and then runs a few specific > > tests for context= mount options (but not the other mount options > > at > > present). It still needs some further > > enhancements as per > > https://github.com/SELinuxProject/selinux-testsuite/issues/32#issuecomment-582992492 > > but it at least provides some degree of regression testing. Could you describe how I could test these, also are there any other SELinux tests that may be useful (with howto's). I'm almost ready to post another set of RFC test patches, but can add more. > > Thanks. I ran this a few times and aside from an exportfs bug > everything passed. I'll be sure to run this in the future too. > > -Scott >