| 2018-07-30 22:37:53 |
Tyler Hicks |
bug |
|
|
added bug |
| 2018-07-30 22:54:10 |
Tyler Hicks |
bug |
|
|
added subscriber Stéphane Graber |
| 2018-08-01 13:28:50 |
Seth Forshee |
linux (Ubuntu): status |
In Progress |
Fix Committed |
|
| 2018-08-11 04:45:44 |
Stéphane Graber |
nominated for series |
|
Ubuntu Bionic |
|
| 2018-08-11 04:45:44 |
Stéphane Graber |
bug task added |
|
linux (Ubuntu Bionic) |
|
| 2018-08-11 04:45:50 |
Stéphane Graber |
linux (Ubuntu Bionic): status |
New |
Triaged |
|
| 2018-08-11 04:45:52 |
Stéphane Graber |
linux (Ubuntu Bionic): importance |
Undecided |
Medium |
|
| 2018-08-16 13:27:56 |
Launchpad Janitor |
linux (Ubuntu): status |
Fix Committed |
Fix Released |
|
| 2018-08-16 13:27:56 |
Launchpad Janitor |
cve linked |
|
2018-12233 |
|
| 2018-08-16 13:27:56 |
Launchpad Janitor |
cve linked |
|
2018-13094 |
|
| 2018-10-30 23:54:55 |
Tyler Hicks |
linux (Ubuntu Bionic): assignee |
|
Tyler Hicks (tyhicks) |
|
| 2018-10-30 23:54:58 |
Tyler Hicks |
linux (Ubuntu Bionic): status |
Triaged |
In Progress |
|
| 2018-10-31 00:33:39 |
Tyler Hicks |
description |
libvirtd cannot properly configure the default bridge device when installed inside of unprivileged LXD containers. 'systemctl status libvirtd' shows the following error:
error : virNetDevBridgeSet:140 : Unable to set bridge virbr0 forward_delay: Permission denied
This is caused due to the files under /sys/class/net/ being owned by init namespace root rather than container root even when the bridge device is created inside of the container. Here's an example from inside of an unprivileged container:
# brctl addbr testbr0
# ls -al /sys/class/net/testbr0/bridge/forward_delay
-rw-r--r-- 1 nobody nogroup 4096 Jul 30 22:33 /sys/class/net/testbr0/bridge/forward_delay
libvirt cannot open this file for writing even though it created the device. Where safe, files under /sys/class/net/ should be owned by container root.
The following upstream patches have been merged into linux-next which fix this bug:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=c59e18b876da3e466abe5fa066aa69050f5be17c
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=d1753390274f7760e5b593cb657ea34f0617e559 |
[Impact]
libvirtd cannot properly configure the default bridge device when installed inside of unprivileged LXD containers. 'systemctl status libvirtd' shows the following error:
error : virNetDevBridgeSet:140 : Unable to set bridge virbr0 forward_delay: Permission denied
This is caused due to the files under /sys/class/net/ being owned by init namespace root rather than container root even when the bridge device is created inside of the container. Here's an example from inside of an unprivileged container:
# brctl addbr testbr0
# ls -al /sys/class/net/testbr0/bridge/forward_delay
-rw-r--r-- 1 nobody nogroup 4096 Jul 30 22:33 /sys/class/net/testbr0/bridge/forward_delay
libvirt cannot open this file for writing even though it created the device. Where safe, files under /sys/class/net/ should be owned by container root.
[Test Case]
A simple kernel test is to verify that you can write to the /sys/class/net/<BRIDGE>/ files as root inside of an unprivileged LXD container.
Unpatched kernels will see a Permission denied error:
$ lxc exec c1 -- sh -c 'brctl addbr testbr && \
echo 1 > /sys/class/net/testbr/bridge/flush'
sh: 1: cannot create /sys/class/net/testbr/bridge/flush: Permission denied
You can also install libvirt inside of a an unprivileged LXD container, restart the container, and verify that the default bridge (virbr0) is up.
Unpatched kernels will not see the virbr0 bridge:
$ lxc exec c1 -- sh -c 'brctl show virbr0'
bridge name bridge id STP enabled interfaces
virbr0 can't get info No such device
[Regression Potential]
The biggest concern with these patches is that they could cause a sensitive /sys/class/net/** file to be read from or written to inside of an unprivileged container. I've (tyhicks) audited all on the in-tree objects exposed to unprivileged containers by this patch set and I don't see any concerns. I did find one file (tx_maxrate) that I couldn't make heads or tails of so I added a CAP_NET_ADMIN check against the init namespace so that it couldn't be modified inside of a container.
These patches were released in 4.19 and also in the Ubuntu 18.10 release kernel. No issues have been reported in those releases.
[Other info]
The following upstream patches have been merged into linux-next which fix this bug:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=c59e18b876da3e466abe5fa066aa69050f5be17c
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=d1753390274f7760e5b593cb657ea34f0617e559 |
|
| 2018-10-31 00:37:02 |
Tyler Hicks |
description |
[Impact]
libvirtd cannot properly configure the default bridge device when installed inside of unprivileged LXD containers. 'systemctl status libvirtd' shows the following error:
error : virNetDevBridgeSet:140 : Unable to set bridge virbr0 forward_delay: Permission denied
This is caused due to the files under /sys/class/net/ being owned by init namespace root rather than container root even when the bridge device is created inside of the container. Here's an example from inside of an unprivileged container:
# brctl addbr testbr0
# ls -al /sys/class/net/testbr0/bridge/forward_delay
-rw-r--r-- 1 nobody nogroup 4096 Jul 30 22:33 /sys/class/net/testbr0/bridge/forward_delay
libvirt cannot open this file for writing even though it created the device. Where safe, files under /sys/class/net/ should be owned by container root.
[Test Case]
A simple kernel test is to verify that you can write to the /sys/class/net/<BRIDGE>/ files as root inside of an unprivileged LXD container.
Unpatched kernels will see a Permission denied error:
$ lxc exec c1 -- sh -c 'brctl addbr testbr && \
echo 1 > /sys/class/net/testbr/bridge/flush'
sh: 1: cannot create /sys/class/net/testbr/bridge/flush: Permission denied
You can also install libvirt inside of a an unprivileged LXD container, restart the container, and verify that the default bridge (virbr0) is up.
Unpatched kernels will not see the virbr0 bridge:
$ lxc exec c1 -- sh -c 'brctl show virbr0'
bridge name bridge id STP enabled interfaces
virbr0 can't get info No such device
[Regression Potential]
The biggest concern with these patches is that they could cause a sensitive /sys/class/net/** file to be read from or written to inside of an unprivileged container. I've (tyhicks) audited all on the in-tree objects exposed to unprivileged containers by this patch set and I don't see any concerns. I did find one file (tx_maxrate) that I couldn't make heads or tails of so I added a CAP_NET_ADMIN check against the init namespace so that it couldn't be modified inside of a container.
These patches were released in 4.19 and also in the Ubuntu 18.10 release kernel. No issues have been reported in those releases.
[Other info]
The following upstream patches have been merged into linux-next which fix this bug:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=c59e18b876da3e466abe5fa066aa69050f5be17c
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=d1753390274f7760e5b593cb657ea34f0617e559 |
[Impact]
libvirtd cannot properly configure the default bridge device when installed inside of unprivileged LXD containers. 'systemctl status libvirtd' shows the following error:
error : virNetDevBridgeSet:140 : Unable to set bridge virbr0 forward_delay: Permission denied
This is caused due to the files under /sys/class/net/ being owned by init namespace root rather than container root even when the bridge device is created inside of the container. Here's an example from inside of an unprivileged container:
# brctl addbr testbr0
# ls -al /sys/class/net/testbr0/bridge/forward_delay
-rw-r--r-- 1 nobody nogroup 4096 Jul 30 22:33 /sys/class/net/testbr0/bridge/forward_delay
libvirt cannot open this file for writing even though it created the device. Where safe, files under /sys/class/net/ should be owned by container root.
[Test Case]
A simple kernel test is to verify that you can write to the /sys/class/net/<BRIDGE>/ files as root inside of an unprivileged LXD container.
Unpatched kernels will see a Permission denied error:
$ lxc exec c1 -- sh -c 'brctl addbr testbr && \
echo 1 > /sys/class/net/testbr/bridge/flush'
sh: 1: cannot create /sys/class/net/testbr/bridge/flush: Permission denied
The echo command will succeed when using a patched kernel.
You can also install libvirt inside of a an unprivileged LXD container, restart the container, and verify that the default bridge (virbr0) is up.
Unpatched kernels will not see the virbr0 bridge:
$ lxc exec c1 -- sh -c 'brctl show virbr0'
bridge name bridge id STP enabled interfaces
virbr0 can't get info No such device
The brctl command will show a valid device when using a patched kerne:
$ lxc exec c1 -- sh -c 'brctl show virbr0'
bridge name bridge id STP enabled interfaces
virbr0 8000.5254005451e8 yes virbr0-nic
[Regression Potential]
The biggest concern with these patches is that they could cause a sensitive /sys/class/net/** file to be read from or written to inside of an unprivileged container. I've (tyhicks) audited all on the in-tree objects exposed to unprivileged containers by this patch set and I don't see any concerns. I did find one file (tx_maxrate) that I couldn't make heads or tails of so I added a CAP_NET_ADMIN check against the init namespace so that it couldn't be modified inside of a container.
These patches were released in 4.19 and also in the Ubuntu 18.10 release kernel. No issues have been reported in those releases.
[Other info]
The following upstream patches have been merged into linux-next which fix this bug:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=c59e18b876da3e466abe5fa066aa69050f5be17c
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=d1753390274f7760e5b593cb657ea34f0617e559 |
|
| 2018-11-08 06:29:23 |
Khaled El Mously |
linux (Ubuntu Bionic): status |
In Progress |
Fix Committed |
|
| 2018-11-15 11:34:34 |
Brad Figg |
tags |
|
verification-needed-bionic |
|
| 2018-11-27 22:57:48 |
Tyler Hicks |
tags |
verification-needed-bionic |
verification-done-bionic |
|
| 2018-12-03 14:01:15 |
Launchpad Janitor |
linux (Ubuntu Bionic): status |
Fix Committed |
Fix Released |
|
| 2018-12-03 14:01:15 |
Launchpad Janitor |
cve linked |
|
2018-18955 |
|
| 2018-12-03 14:01:16 |
Launchpad Janitor |
linux (Ubuntu Bionic): status |
Fix Committed |
Fix Released |
|
