From: Aleksa Sarai <asarai@suse.de>
To: "Eric W. Biederman" <ebiederm@xmission.com>,
Al Viro <viro@zeniv.linux.org.uk>
Cc: linux-kernel@vger.kernel.org, containers@lists.linux-foundation.org
Subject: [REGRESSION v4.16-rc6] [PATCH] mqueue: forbid unprivileged user access to internal mount
Date: Fri, 23 Mar 2018 17:04:57 +1100 [thread overview]
Message-ID: <20180323060457.sxgsd3j2obi33fyw@gordon> (raw)
[-- Attachment #1: Type: text/plain, Size: 2619 bytes --]
Hi all,
Felix reported weird behaviour on 4.16.0-rc6 with regards to mqueue[1],
which was introduced by 36735a6a2b5e ("mqueue: switch to on-demand
creation of internal mount").
Basically, the reproducer boils down to being able to mount mqueue if
you create a new user namespace, even if you don't unshare the IPC
namespace.
Previously this was not possible, and you would get an -EPERM. The mount
is the *host* mqueue mount, which is being cached and just returned from
mqueue_mount(). To be honest, I'm not sure if this is safe or not (or if
it was intentional -- since I'm not familiar with mqueue).
To me it looks like there is a missing permission check. I've included a
patch below that I've compile-tested, and should block the above case.
Can someone please tell me if I'm missing something? Is this actually
safe?
[1]: https://github.com/docker/docker/issues/36674
--8<--------------------------------------------------------------------
Fix a regression caused by 36735a6a2b5e ("mqueue: switch to on-demand
creation of internal mount"), where an unprivileged user is permitted to
mount mqueue even if they don't have CAP_SYS_ADMIN in the ipcns's
associated userns. This can be reproduced as in the following.
% unshare -Urm # ipc isn't unshare'd
# mount -t mqueue mqueue /dev/mqueue # should have failed
# echo $?
0
Previously the above would error out with an -EPERM, as the mount was
protected by mount_ns(), but the patch in question switched to
kern_mount_data() which doesn't do this necessary permission check. So
add it explicitly to mq_internal_mount().
Fixes: 36735a6a2b5e ("mqueue: switch to on-demand creation of internal mount")
Reported-by: Felix Abecassis <fabecassis@nvidia.com>
Signed-off-by: Aleksa Sarai <asarai@suse.de>
---
ipc/mqueue.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/ipc/mqueue.c b/ipc/mqueue.c
index d7f309f74dec..ddb85091398d 100644
--- a/ipc/mqueue.c
+++ b/ipc/mqueue.c
@@ -353,6 +353,12 @@ static struct vfsmount *mq_internal_mount(void)
{
struct ipc_namespace *ns = current->nsproxy->ipc_ns;
struct vfsmount *m = ns->mq_mnt;
+ /*
+ * Match the semantics of mount_ns, to avoid unprivileged users from being
+ * able to mount mqueue from an IPC namespace they don't have ownership of.
+ */
+ if (!ns_capable(ns->user_ns, CAP_SYS_ADMIN))
+ return ERR_PTR(-EPERM);
if (m)
return m;
m = kern_mount_data(&mqueue_fs_type, ns);
--
2.16.2
--
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next reply other threads:[~2018-03-23 6:05 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-23 6:04 Aleksa Sarai [this message]
2018-03-23 6:31 ` [REGRESSION v4.16-rc6] [PATCH] mqueue: forbid unprivileged user access to internal mount Eric W. Biederman
2018-03-23 21:41 ` [PATCH 1/2] fs: Extend mount_ns with support for a fast namespace to vfsmount function Eric W. Biederman
2018-03-23 21:43 ` [PATCH 2/2] mqueuefs: Fix the permissions and permission checks when mounting mqueuefs Eric W. Biederman
2018-03-23 23:15 ` [PATCH 1/2] fs: Extend mount_ns with support for a fast namespace to vfsmount function Al Viro
2018-03-24 16:12 ` Eric W. Biederman
2018-03-24 21:48 ` Al Viro
2018-03-25 1:25 ` [GIT PULL] Revert "mqueue: switch to on-demand creation of internal mount" 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=20180323060457.sxgsd3j2obi33fyw@gordon \
--to=asarai@suse.de \
--cc=containers@lists.linux-foundation.org \
--cc=ebiederm@xmission.com \
--cc=linux-kernel@vger.kernel.org \
--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).