linux-next.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Al Viro <viro@zeniv.linux.org.uk>
To: Ondrej Mosnacek <omosnace@redhat.com>
Cc: Paul Moore <paul@paul-moore.com>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	linux-next@vger.kernel.org,
	Linux kernel mailing list <linux-kernel@vger.kernel.org>,
	David Howells <dhowells@redhat.com>,
	selinux@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: linux-next: manual merge of the selinux tree with the vfs tree
Date: Wed, 5 Dec 2018 16:16:01 +0000	[thread overview]
Message-ID: <20181205161601.GW2217@ZenIV.linux.org.uk> (raw)
In-Reply-To: <CAFqZXNvSOzyhnTUxF2mP4BTFMVQ8H1uh-Yyn2fH2K=4yRDX-tQ@mail.gmail.com>

On Wed, Dec 05, 2018 at 10:37:56AM +0100, Ondrej Mosnacek wrote:

> I just tested the Q28 branch rebased onto a recent Fedora rawhide
> kernel (4.20.0-0.rc5.git0.1) and that code seems to be working fine.
> The submount test failed with Q28 and succeeds with Q28+fix, as
> expected. Also, the overlay tests failures are gone now (except for
> the 4 known failures from GH issue #43, since I had to rebase onto
> 4.20-rcX).
> 
> This is the commit that I used as the SELinux submount fix:
> https://gitlab.com/omos/linux-public/commit/47922f9c70a83008388b836c285f94c40da1af2b

FWIW, I'm none too happy about the fix.  Observations:
	* sb_get_tree (and sb_kern_mount past the "LSM: lift parsing
LSM options into the caller of ->sb_kern_mount()" in this series)
is equivalent to sb_set_mnt_opts() + (for userland mounts) an selinux-only
MAC check.  IOW, application of options (for LSMs that have those
in the first place) + actual "are we permitted to mount that?" check.
	* the second part should be done only for userland mounts -
not automounting, not kernel-internal ones, etc.
	* a very common pattern is "vfs_get_tree, vfs_create_mount if we
hadn't failed that, then unconditional put_fs_context".  So much that it
clearly deserves a helper - too much boilerplate as it is.
	* look at the callers of vfs_get_tree():
1) afs_mntpt_do_automount(): submount, helper fodder.  No MAC.
2) nfs_do_submount(): submount, standalone, but caller will very shortly follow
with the rest of the helper.  No MAC.
3) btrfs_mount_root(): helper fodder, cloned context, probably no point
in the actual MAC - we are in ->get_tree(), the caller will decide if
it wants to bother.
4) do_nfs4_mount(): NFS counterpart of the above.
5) mount_one_hugetlbfs(): kernel-internal, helper fodder, no MAC.
6) pid_ns_prepare_proc(): kernel-internal, helper fodder, no MAC.
7) mq_create_mount(): kernel-internal, helper fodder, no MAC.

8) do_new_mount(): almost a helper fodder, wants MAC (mount(2) guts)
9) fsopen(2): standalone, wants MAC (it's mount(2)-equivalent)
10) vfs_kern_mount(): that's a bit more complicated.  It is, again,
a helper fodder.  The need of MAC depends upon the caller, in theory.
Callers:
	simple_pin_fs() - kernel-internal, no MAC
	init_mount_tree() - no MAC, that's the absolute root and that, by
definition, is much too early in the boot (before initramfs, etc.) for
any LSM shite to be applicable.  In any case, it's done by the kernel.
	kern_mount() - kernel-internal, no MAC
	cpuset_get_tree() - part of ->get_tree(), caller will decide if they
want the damn MAC.
	vfs_submount() - automounts, presumably no MAC.

Conclusion: fuck the MAC in vfs_get_tree().  Let's just lift it into
do_new_mount()/fsopen().  The only thing we really need there is to
keep ->s_umount held (exclusive) until after the MAC.  So let vfs_get_tree()
return with fc->root->d_sb->s_umount locked and have mount_create_mount()
(which is _always_ preceded by successful vfs_get_tree()), unlock the
sucker.  In vfs_get_tree() we need to do sb_set_mnt_opts(), with the
rest of it (selinux-only) called by do_new_mount()/fsopen(2).  All there
is to it...

  reply	other threads:[~2018-12-05 16:16 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-27  0:52 linux-next: manual merge of the selinux tree with the vfs tree Stephen Rothwell
2018-11-27  8:53 ` Ondrej Mosnacek
2018-11-27  9:14   ` Ondrej Mosnacek
2018-11-27 11:50   ` Stephen Rothwell
2018-11-28 21:52     ` Paul Moore
2018-11-29 10:07       ` Ondrej Mosnacek
2018-11-29 22:23         ` Paul Moore
2018-11-29 23:51           ` Al Viro
2018-11-30  0:57             ` Casey Schaufler
2018-11-30  1:27               ` Al Viro
2018-11-30  1:36                 ` Al Viro
2018-12-01 21:32         ` Ondrej Mosnacek
2018-12-02  9:13           ` Ondrej Mosnacek
2018-12-03 10:12             ` Ondrej Mosnacek
2018-12-03 21:56               ` Al Viro
2018-12-05  9:37                 ` Ondrej Mosnacek
2018-12-05 16:16                   ` Al Viro [this message]
2018-12-05 21:58                     ` Casey Schaufler
2018-11-30 15:10 ` David Howells
2018-11-30 15:17   ` Ondrej Mosnacek
2018-12-18  3:48 Stephen Rothwell
2018-12-18  4:10 ` Al Viro

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=20181205161601.GW2217@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=dhowells@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=omosnace@redhat.com \
    --cc=paul@paul-moore.com \
    --cc=selinux@vger.kernel.org \
    --cc=sfr@canb.auug.org.au \
    /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;
as well as URLs for NNTP newsgroup(s).