| 2016-05-16 19:55:43 |
Seth Forshee |
bug |
|
|
added bug |
| 2016-05-16 19:56:11 |
Seth Forshee |
nominated for series |
|
Ubuntu Xenial |
|
| 2016-05-16 19:56:11 |
Seth Forshee |
bug task added |
|
linux (Ubuntu Xenial) |
|
| 2016-05-16 19:56:38 |
Seth Forshee |
linux (Ubuntu Xenial): importance |
Undecided |
High |
|
| 2016-05-16 19:56:38 |
Seth Forshee |
linux (Ubuntu Xenial): status |
New |
In Progress |
|
| 2016-05-16 19:56:38 |
Seth Forshee |
linux (Ubuntu Xenial): assignee |
|
Seth Forshee (sforshee) |
|
| 2016-05-16 21:26:19 |
Seth Forshee |
description |
Impact: When the ipc and user namespaces are unshared in a single system call mqueue will do an internal mount of the new mqueue super block before the new user namespace is installed. This results in s_user_ns being set to the parent user ns, however the new ipc ns is owned by the new user ns. Attempting to mount the mqueue filesystem in the new user ns results in EBUSY when it should succeed. This breaks docker when user namespace support is enabled.
Fix: Use the ipc namespace's owner for s_user_ns for all mqueue mounts. Since mqueue already checks that the user has CAP_SYS_ADMIN in this namespace for any userspace mounts we already know the user is sufficiently privileged, and this is really the only arrangement that makes sense.
Test Case: The following commands will result in a failure to mount mqueue without the fix; with the fix the mount will succeed.
$ mkdir mnt
$ unshare -Umuniprf --mount-proc bash
# mount -t mqueue mqueue mnt |
Impact: When the ipc and user namespaces are unshared in a single system call mqueue will do an internal mount of the new mqueue super block before the new user namespace is installed. This results in s_user_ns being set to the parent user ns, however the new ipc ns is owned by the new user ns. Attempting to mount the mqueue filesystem in the new user ns results in EBUSY when it should succeed. This breaks docker when user namespace support is enabled.
Fix: Use the ipc namespace's owner for s_user_ns for all mqueue mounts. Since mqueue already checks that the user has CAP_SYS_ADMIN in this namespace for any userspace mounts we already know the user is sufficiently privileged, and this is really the only arrangement that makes sense.
Test Case: The following commands will result in a failure to mount mqueue without the fix; with the fix the mount will succeed.
$ mkdir mnt
$ unshare -Umuniprf --mount-proc bash
# mount -t mqueue mqueue mnt
Originally reported at https://github.com/docker/docker/issues/22633. |
|
| 2016-05-19 17:08:38 |
Kamal Mostafa |
linux (Ubuntu Xenial): status |
In Progress |
Fix Committed |
|
| 2016-05-22 19:15:28 |
Iavael |
bug |
|
|
added subscriber Iavael |
| 2016-06-14 14:22:26 |
Kamal Mostafa |
tags |
|
verification-needed-xenial |
|
| 2016-06-15 08:26:16 |
Launchpad Janitor |
linux (Ubuntu): status |
In Progress |
Fix Released |
|
| 2016-06-15 08:26:16 |
Launchpad Janitor |
cve linked |
|
2016-4482 |
|
| 2016-06-15 08:26:16 |
Launchpad Janitor |
cve linked |
|
2016-4569 |
|
| 2016-06-15 08:26:16 |
Launchpad Janitor |
cve linked |
|
2016-4578 |
|
| 2016-06-15 08:26:16 |
Launchpad Janitor |
cve linked |
|
2016-4951 |
|
| 2016-06-21 14:41:04 |
Seth Forshee |
tags |
verification-needed-xenial |
verification-done-xenial |
|
| 2016-06-27 18:27:24 |
Launchpad Janitor |
linux (Ubuntu Xenial): status |
Fix Committed |
Fix Released |
|
