All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ondrej Mosnacek <omosnace@redhat.com>
To: Paul Moore <paul@paul-moore.com>
Cc: selinux@vger.kernel.org,
	"Eric W . Biederman" <ebiederm@xmission.com>,
	Trond Myklebust <trond.myklebust@primarydata.com>,
	Seth Forshee <seth.forshee@canonical.com>,
	linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH] selinux: always allow mounting submounts
Date: Wed, 21 Nov 2018 13:41:21 +0100	[thread overview]
Message-ID: <CAFqZXNsAHnV5RzwtONF0hJRy31qb4c=sajvaEkmEjjky4duEBA@mail.gmail.com> (raw)
In-Reply-To: <CAHC9VhTn9qz77PQ3mboaCsNzK9D8hjYFg9z5sCWr8Yb7W2Pqxg@mail.gmail.com>

On Tue, Nov 20, 2018 at 11:09 PM Paul Moore <paul@paul-moore.com> wrote:
> On Fri, Nov 16, 2018 at 8:12 AM Ondrej Mosnacek <omosnace@redhat.com> wrote:
> > If a superblock has the MS_SUBMOUNT flag set, we should always allow
> > mounting it. These mounts are done automatically by the kernel either as
> > part of mounting some parent mount (e.g. debugfs always mounts tracefs
> > under "tracing" for compatibility) or they are mounted automatically as
> > needed on subdirectory accesses (e.g. NFS crossmnt mounts). Since such
> > automounts are either an implicit consequence of the parent mount (which
> > is already checked) or they can happen during regular accesses (where it
> > doesn't make sense to check against the current task's context), the
> > mount permission check should be skipped for them.
> >
> > Without this patch, attempts to access contents of an automounted
> > directory can cause unexpected SELinux denials.
> >
> > In the current kernel tree, the MS_SUBMOUNT flag is set only via
> > vfs_submount(), which is called only from the following places:
> >  - AFS, when automounting special "symlinks" referencing other cells
> >  - CIFS, when automounting "referrals"
> >  - NFS, when automounting subtrees
> >  - debugfs, when automounting tracefs
> >
> > In all cases the submounts are meant to be transparent to the user and
> > it makes sense that if mounting the master is allowed, then so should be
> > the automounts. Note that CAP_SYS_ADMIN capability checking is already
> > skipped for (SB_KERNMOUNT|SB_SUBMOUNT) in:
> >  - sget_userns() in fs/super.c:
> >         if (!(flags & (SB_KERNMOUNT|SB_SUBMOUNT)) &&
> >             !(type->fs_flags & FS_USERNS_MOUNT) &&
> >             !capable(CAP_SYS_ADMIN))
> >                 return ERR_PTR(-EPERM);
> >  - sget() in fs/super.c:
> >         /* Ensure the requestor has permissions over the target filesystem */
> >         if (!(flags & (SB_KERNMOUNT|SB_SUBMOUNT)) && !ns_capable(user_ns, CAP_SYS_ADMIN))
> >                 return ERR_PTR(-EPERM);
> >
> > Verified internally on patched RHEL 7.6 with a reproducer using
> > NFS+httpd and selinux-tesuite.
>
> I think this all sounds reasonable, but please verify this with an
> upstream kernel.  Upstream our focus is on the upstream kernel
> (surprise!), downstream RHEL is your responsibility, not ours :)

I tested on RHEL because that's what I can do most conveniently. I
don't have a very good workflow/environment for complex testing on
upstream right now. I don't expect the results to be any different on
the upstream kernel, but I understand your concern. I have been
thinking about some patch testing automation using Fedora Rawhide (I
hope that's close enough to upstream at least :), so I guess it's time
to get scriptin'...

I was hoping to get some independent testing after porting the test to
the selinux-testsuite... (But I get it, the burden of proof is on my
side...)

>
> > Fixes: 93faccbbfa95 ("fs: Better permission checking for submounts")
> > Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com>
> > ---
> >  security/selinux/hooks.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> > index 7ce683259357..7ce012d9ec51 100644
> > --- a/security/selinux/hooks.c
> > +++ b/security/selinux/hooks.c
> > @@ -2934,7 +2934,7 @@ static int selinux_sb_kern_mount(struct super_block *sb, int flags, void *data)
> >                 return rc;
> >
> >         /* Allow all mounts performed by the kernel */
> > -       if (flags & MS_KERNMOUNT)
> > +       if (flags & (MS_KERNMOUNT | MS_SUBMOUNT))
> >                 return 0;
> >
> >         ad.type = LSM_AUDIT_DATA_DENTRY;
>
> --
> paul moore
> www.paul-moore.com
--
Ondrej Mosnacek <omosnace at redhat dot com>
Associate Software Engineer, Security Technologies
Red Hat, Inc.

  reply	other threads:[~2018-11-21 23:15 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-16 13:12 [PATCH] selinux: always allow mounting submounts Ondrej Mosnacek
2018-11-19 13:15 ` Ondrej Mosnacek
2018-11-20 22:09 ` Paul Moore
2018-11-21 12:41   ` Ondrej Mosnacek [this message]
2018-11-21 15:38     ` Ondrej Mosnacek
2018-11-26 23:25       ` Paul Moore
2018-11-28 15:40         ` Eric W. Biederman
2018-11-28 16:12           ` Ondrej Mosnacek
2018-11-28 16:12             ` Ondrej Mosnacek
2018-11-28 17:38             ` Eric W. Biederman
2018-11-28 17:38               ` Eric W. Biederman

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='CAFqZXNsAHnV5RzwtONF0hJRy31qb4c=sajvaEkmEjjky4duEBA@mail.gmail.com' \
    --to=omosnace@redhat.com \
    --cc=ebiederm@xmission.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=paul@paul-moore.com \
    --cc=selinux@vger.kernel.org \
    --cc=seth.forshee@canonical.com \
    --cc=trond.myklebust@primarydata.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.