From: "J. Bruce Fields" <bfields@fieldses.org>
To: Stephen Smalley <sds@tycho.nsa.gov>
Cc: Paul Moore <paul@paul-moore.com>,
Eric Paris <eparis@parisplace.org>,
selinux@vger.kernel.org, Scott Mayhew <smayhew@redhat.com>,
linux-nfs@vger.kernel.org
Subject: Re: [PATCH] security/selinux: fix SECURITY_LSM_NATIVE_LABELS on reused superblock
Date: Wed, 6 Mar 2019 10:34:35 -0500 [thread overview]
Message-ID: <20190306153435.GF2426@fieldses.org> (raw)
In-Reply-To: <ea347670-ea52-3ab6-a786-aeebff40dd0e@tycho.nsa.gov>
On Wed, Mar 06, 2019 at 09:34:43AM -0500, Stephen Smalley wrote:
> On 3/5/19 4:17 PM, J. Bruce Fields wrote:
> >From: "J. Bruce Fields" <bfields@redhat.com>
> >
> >In the case when we're reusing a superblock, selinux_sb_clone_mnt_opts()
> >fails to set set_kern_flags, with the result that
> >nfs_clone_sb_security() incorrectly clears NFS_CAP_SECURITY_LABEL.
> >
> >The result is that if you mount the same NFS filesystem twice, NFS
> >security labels are turned off, even if they would work fine if you
> >mounted the filesystem only once.
> >
> >("fixes" may be not exactly the right tag, it may be more like
> >"fixed-other-cases-but-missed-this-one".)
> >
> >Cc: Scott Mayhew <smayhew@redhat.com>
> >Cc: stable@vger.kernel.org
> >Fixes: 0b4d3452b8b4 "security/selinux: allow security_sb_clone_mnt_opts..."
> >Signed-off-by: J. Bruce Fields <bfields@redhat.com>
>
> Acked-by: Stephen Smalley <sds@tycho.nsa.gov>
>
> Do you have some tests you are using for the selinux nfs support?
No. I'll ask around. Trond or Anna, do either of you do any selinux
testing?
> I have an open issue on the selinux-testsuite with an example script
> for running the regular selinux tests on a NFS mount but it can't
> fully succeed as noted there,
> https://github.com/SELinuxProject/selinux-testsuite/issues/32
So if I just clone
https://github.com/SELinuxProject/selinux-testsuite.git and filter out
those known failures, would that be a good starting point?
> I've also have another script to test context= mount handling for
> nfs since that should take precedence over native labels; it looks
> like that might be broken again:
Thanks for the report, I'll take a look. That's before or after
applying this patch? Assuming the former, do you have an idea how
recent a regression it is?
--b.
> #!/bin/sh
> cat > /etc/exports <<EOF
> /home localhost(rw,no_root_squash,security_label)
> EOF
> exportfs -a
> systemctl start nfs-server
> mkdir -p /mnt/home
> mount -t nfs -o vers=4.0,context=system_u:object_r:etc_t:s0
> localhost:/home /mnt/home
> echo "Under NFSv4.0:"
> ls -Za /mnt/home
> touch /mnt/home/foo
> ls -Z /mnt/home/foo
> ls -Z /home/foo
> rm /mnt/home/foo
> umount /mnt/home
> mount -t nfs -o vers=4.2,context=system_u:object_r:etc_t:s0
> localhost:/home /mnt/home
> echo "Under NFSv4.2:"
> ls -Za /mnt/home
> touch /mnt/home/foo
> ls -Z /mnt/home/foo
> ls -Z /home/foo
> rm /home/foo
> umount /mnt/home
> rmdir /mnt/home
> rm /etc/exports
> exportfs -ua
> systemctl stop nfs-server
>
> >---
> > security/selinux/hooks.c | 5 ++++-
> > 1 file changed, 4 insertions(+), 1 deletion(-)
> >
> >diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> >index f0e36c3492ba..5e9304567233 100644
> >--- a/security/selinux/hooks.c
> >+++ b/security/selinux/hooks.c
> >@@ -959,8 +959,11 @@ static int selinux_sb_clone_mnt_opts(const struct super_block *oldsb,
> > BUG_ON(!(oldsbsec->flags & SE_SBINITIALIZED));
> > /* if fs is reusing a sb, make sure that the contexts match */
> >- if (newsbsec->flags & SE_SBINITIALIZED)
> >+ if (newsbsec->flags & SE_SBINITIALIZED) {
> >+ if ((kern_flags & SECURITY_LSM_NATIVE_LABELS) && !set_context)
> >+ *set_kern_flags |= SECURITY_LSM_NATIVE_LABELS;
> > return selinux_cmp_sb_context(oldsb, newsb);
> >+ }
> > mutex_lock(&newsbsec->lock);
> >
next prev parent reply other threads:[~2019-03-06 15:34 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20190305211758.GA27437@fieldses.org>
2019-03-05 21:25 ` [PATCH] security/selinux: fix SECURITY_LSM_NATIVE_LABELS on reused superblock J. Bruce Fields
[not found] ` <ea347670-ea52-3ab6-a786-aeebff40dd0e@tycho.nsa.gov>
2019-03-06 15:34 ` J. Bruce Fields [this message]
2019-03-06 16:49 ` Stephen Smalley
2019-03-06 17:25 ` J. Bruce Fields
2019-03-06 17:28 ` Stephen Smalley
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=20190306153435.GF2426@fieldses.org \
--to=bfields@fieldses.org \
--cc=eparis@parisplace.org \
--cc=linux-nfs@vger.kernel.org \
--cc=paul@paul-moore.com \
--cc=sds@tycho.nsa.gov \
--cc=selinux@vger.kernel.org \
--cc=smayhew@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox