Received: by 2002:a25:c205:0:0:0:0:0 with SMTP id s5csp7273184ybf; Fri, 6 Mar 2020 14:02:45 -0800 (PST) X-Google-Smtp-Source: ADFU+vsXdJ5R7uPGbQBULC1/Brd4Lu+frkiJ+yG+71deNjamx4f923V68LdyKyZbaePvwoqC1Vwr X-Received: by 2002:aca:488a:: with SMTP id v132mr4199170oia.166.1583532165560; Fri, 06 Mar 2020 14:02:45 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1583532165; cv=none; d=google.com; s=arc-20160816; b=s/FNE1dziExkX5h3MB/2AeSJyUIfwCFFERY5qTUaSUoYrygdp3y09mFXp8wIf4jQII c0mQh6IHr4UcZRL+ovWTmAKcht9TpmmwwQ020GU4NAJLWDb5FZlKb6/JUDcsLbX+82JK KmqUg7BzmX6Ko2p1BKDXKzKRHKrVZLnF51OkJspVPytTU3OQ+qmgX4ftI7hcbqcQWXV1 6SzKhXmGJL99X2l8IuX2bbAk9CWr4WJXHCyGkLLSFTnb00h50wxChNunYOp7fug9hoEB THn/diiBx0bfdiJGWxQRoDFBKfI219vnLP8IZ4uyMCWfUp46c3f+UvITABE2+MURfdn8 8SdQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-disposition :content-transfer-encoding:in-reply-to:mime-version:references :message-id:subject:cc:to:from:date; bh=uSiahUP77xS+3nL4n4Uwew4wSuc3W8SYLk7DX39ZnQI=; b=GEqCgn/ZQTTgBm5x6ufe1NReQTpW+efxQm5fHGUVMHUgk8IF7sXaN0UGSFQWSMbVQ9 H6rcz8EKmHT5gUKxTBARDw7ls2Q/yg3siCk7ett0sbIZQwDShkePKx2NTqmuRROjDSh0 uoZG0sDlCtt4hgk9NeFe0NFT/lb2DbFkfBD4QhDNWnIXL+WsIS5AEKq8cNdNqa3NuRAL fAI0L4/VfLVLT/QOe1quBGepAqp5Co5l9yN8gE2EgehJYWmtyAzKaDFmQE1RNbG/zjFi 5dojl7FHMXzMth6AMuClrljDK9ItBru7jr3I3SFBLca9Jo/EPfNa4Wuku5gNAwG/HIKj syFQ== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m11si2229688otf.146.2020.03.06.14.02.18; Fri, 06 Mar 2020 14:02:45 -0800 (PST) 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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726194AbgCFWBl convert rfc822-to-8bit (ORCPT + 99 others); Fri, 6 Mar 2020 17:01:41 -0500 Received: from us-smtp-delivery-1.mimecast.com ([207.211.31.120]:54906 "EHLO us-smtp-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726171AbgCFWBl (ORCPT ); Fri, 6 Mar 2020 17:01:41 -0500 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-159-girT2cKGN6qj0ciNYhcecg-1; Fri, 06 Mar 2020 17:01:36 -0500 X-MC-Unique: girT2cKGN6qj0ciNYhcecg-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id A891A800D54; Fri, 6 Mar 2020 22:01:34 +0000 (UTC) Received: from aion.usersys.redhat.com (ovpn-120-213.rdu2.redhat.com [10.10.120.213]) by smtp.corp.redhat.com (Postfix) with ESMTPS id CAB4F5C28D; Fri, 6 Mar 2020 22:01:33 +0000 (UTC) Received: by aion.usersys.redhat.com (Postfix, from userid 1000) id F18AF1A0110; Fri, 6 Mar 2020 17:01:32 -0500 (EST) Date: Fri, 6 Mar 2020 17:01:32 -0500 From: Scott Mayhew To: Stephen Smalley Cc: Richard Haines , trond.myklebust@hammerspace.com, anna.schumaker@netapp.com, bfields@fieldses.org, Paul Moore , Stephen Smalley , linux-nfs@vger.kernel.org, SElinux list Subject: Re: [PATCH] NFS: Ensure security label is set for root inode Message-ID: <20200306220132.GD3175@aion.usersys.redhat.com> References: <20200303225837.1557210-1-smayhew@redhat.com> <6bb287d1687dc87fe9abc11d475b3b9df061f775.camel@btinternet.com> <20200304143701.GB3175@aion.usersys.redhat.com> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: aion.usersys.redhat.com Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: 8BIT Content-Disposition: inline Sender: linux-nfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org 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:s0 > > > 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 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. 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