All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Smalley <stephen.smalley.work@gmail.com>
To: Scott Mayhew <smayhew@redhat.com>
Cc: Richard Haines <richard_c_haines@btinternet.com>,
	trond.myklebust@hammerspace.com, anna.schumaker@netapp.com,
	bfields@fieldses.org, Paul Moore <paul@paul-moore.com>,
	Stephen Smalley <sds@tycho.nsa.gov>,
	linux-nfs@vger.kernel.org, SElinux list <selinux@vger.kernel.org>
Subject: Re: [PATCH] NFS: Ensure security label is set for root inode
Date: Wed, 4 Mar 2020 10:38:15 -0500	[thread overview]
Message-ID: <CAEjxPJ7A1KRJ3+o0-edW3byYBSjGa7=KnU5QaYCiVt6Lq6ZfpA@mail.gmail.com> (raw)
In-Reply-To: <20200304143701.GB3175@aion.usersys.redhat.com>

On Wed, Mar 4, 2020 at 9:37 AM Scott Mayhew <smayhew@redhat.com> 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.
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
so?). As long as the separate context= option
continues to work correctly on NFS, I'm not overly concerned about this.

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.

  reply	other threads:[~2020-03-04 15:37 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-03 22:58 [PATCH] NFS: Ensure security label is set for root inode Scott Mayhew
2020-03-04 13:55 ` Richard Haines
2020-03-04 14:37   ` Scott Mayhew
2020-03-04 15:38     ` Stephen Smalley [this message]
2020-03-06 22:01       ` Scott Mayhew
2020-03-08 17:47         ` Richard Haines
2020-03-09 13:35           ` Stephen Smalley
2020-03-09 16:41             ` Richard Haines
2020-03-09 18:05               ` Stephen Smalley
2020-03-10 13:27             ` Richard Haines
2020-03-10 15:20               ` Stephen Smalley
2020-03-09 13:14         ` Stephen Smalley
2020-03-10 15:54 ` Stephen Smalley
2020-03-13  0:52   ` Paul Moore

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAEjxPJ7A1KRJ3+o0-edW3byYBSjGa7=KnU5QaYCiVt6Lq6ZfpA@mail.gmail.com' \
    --to=stephen.smalley.work@gmail.com \
    --cc=anna.schumaker@netapp.com \
    --cc=bfields@fieldses.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=paul@paul-moore.com \
    --cc=richard_c_haines@btinternet.com \
    --cc=sds@tycho.nsa.gov \
    --cc=selinux@vger.kernel.org \
    --cc=smayhew@redhat.com \
    --cc=trond.myklebust@hammerspace.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.