From: Seth Forshee <seth.forshee@canonical.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>,
David Woodhouse <dwmw2@infradead.org>,
Brian Norris <computersforpeace@gmail.com>,
Jeff Layton <jlayton@poochiereds.net>,
"J. Bruce Fields" <bfields@fieldses.org>,
Serge Hallyn <serge.hallyn@canonical.com>,
Andy Lutomirski <luto@amacapital.net>,
linux-fsdevel@vger.kernel.org,
linux-security-module@vger.kernel.org, selinux@tycho.nsa.gov,
linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org
Subject: Re: [PATCH v4 3/7] fs: Verify access of user towards block device file when mounting
Date: Fri, 25 Sep 2015 07:48:33 -0500 [thread overview]
Message-ID: <20150925124833.GA104990@ubuntu-hedt> (raw)
In-Reply-To: <87si63o56g.fsf@x220.int.ebiederm.org>
On Thu, Sep 24, 2015 at 04:53:11PM -0500, Eric W. Biederman wrote:
> Seth Forshee <seth.forshee@canonical.com> writes:
>
> > When mounting a filesystem on a block device there is currently
> > no verification that the user has appropriate access to the
> > device file passed to mount. This has not been an issue so far
> > since the user in question has always been root, but this must
> > be changed before allowing unprivileged users to mount in user
> > namespaces.
> >
> > To do this, a new version of lookup_bdev() is added named
> > lookup_bdev_perm(). Both of these functions become wrappers
> > around a common inner fucntion. The behavior of lookup_bdev() is
> > unchanged, but calling lookup_bdev_perm() will fail if the user
> > does not have the specified access rights to the supplied path.
> > The permission check is skipped if the user has CAP_SYS_ADMIN to
> > avoid any possible regressions in behavior.
> >
> > blkdev_get_by_path() is updated to use lookup_bdev_perm(). This
> > is used by mount_bdev() and mount_mtd(), so this will cause
> > mounts on block devices to fail when the user lacks the required
> > permissions. Other calls to blkdev_get_by_path() will all happen
> > with root privileges, so these calls will be unaffected.
>
> Good but buggy patch.
>
> In the mtd bits the flags are super flags, not file mode bits,
> which makes testing them against FMODE_READ and FMODE_WRITE is
> incorrect.
Bah, yes. Fixed.
> Further it looks like quite a few more possibly all of the lookup_bdev
> instances could use inode level permission checking.
>
> Certainly code such as quotactl makes me wonder.
I opted to stick to places related to mounting, but let's take a look at
the other callers.
bcache calls it in the context of sysfs writes, and those attributes are
writable only by root. In that case the inode permission check will be
skipped anyway, so it makes no difference either way.
Device mapper calls it in dm_get_device, which is called from a bunch of
places. I had started trying to walk back through all the callers of
dm_get_device, but that rabbit hole got really deep really quickly so I
didn't feel confident that changing it wouldn't break anyone.
quotactl gave me pause, as it seems to have done for you too. I was
surprised that inode permissions aren't checked, but
check_quotactl_permission does get called before actually doing
anything. I fear that adding a check of inode permissions could end up
breaking someone.
> Ugh. Your code needs to be using __inode_permission and not
> inode_permission.
>
> The readability or writability of a device node has little or nothing to
> do with the readability/writability of the superblock. So I don't see
> any reason we should be checking that.
Makes sense, fixed.
Thanks,
Seth
next prev parent reply other threads:[~2015-09-25 12:48 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-23 20:16 [PATCH v4 0/7] Initial support for user namespace owned mounts Seth Forshee
2015-09-23 20:16 ` [PATCH v4 1/7] fs: Add user namesapace member to struct super_block Seth Forshee
2015-09-24 21:14 ` Eric W. Biederman
2015-09-25 12:54 ` Seth Forshee
2015-09-25 17:27 ` Eric W. Biederman
2016-03-15 12:08 ` [PATCH] fs: fix a posible leak of allocated superblock Pavel Tikhomirov
2016-03-15 13:32 ` Seth Forshee
2015-09-23 20:16 ` [PATCH v4 2/7] userns: Simpilify MNT_NODEV handling Seth Forshee
2015-09-23 20:16 ` [PATCH v4 3/7] fs: Verify access of user towards block device file when mounting Seth Forshee
2015-09-24 21:53 ` Eric W. Biederman
2015-09-25 12:48 ` Seth Forshee [this message]
2015-09-25 17:16 ` Eric W. Biederman
2015-09-25 17:39 ` Seth Forshee
2015-09-25 17:49 ` Eric W. Biederman
2015-09-23 20:16 ` [PATCH v4 4/7] fs: Limit file caps to the user namespace of the super block Seth Forshee
2015-09-24 21:59 ` Eric W. Biederman
2015-09-25 12:49 ` Seth Forshee
2015-09-25 17:57 ` Eric W. Biederman
2015-09-23 20:16 ` [PATCH v4 5/7] fs: Treat foreign mounts as nosuid Seth Forshee
2015-09-23 20:16 ` [PATCH v4 6/7] Smack: Add support for unprivileged mounts from user namespaces Seth Forshee
2015-09-24 22:16 ` Eric W. Biederman
2015-09-24 22:34 ` Casey Schaufler
2015-09-27 19:30 ` Eric W. Biederman
2015-09-28 19:45 ` Seth Forshee
2015-09-23 20:16 ` [PATCH v4 7/7] selinux: " Seth Forshee
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=20150925124833.GA104990@ubuntu-hedt \
--to=seth.forshee@canonical.com \
--cc=bfields@fieldses.org \
--cc=computersforpeace@gmail.com \
--cc=dwmw2@infradead.org \
--cc=ebiederm@xmission.com \
--cc=jlayton@poochiereds.net \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=linux-security-module@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=selinux@tycho.nsa.gov \
--cc=serge.hallyn@canonical.com \
--cc=viro@zeniv.linux.org.uk \
/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).