libvirtd is unable to configure bridge devices inside of LXD containers
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
linux (Ubuntu) |
Fix Released
|
Medium
|
Tyler Hicks | ||
Bionic |
Fix Released
|
Medium
|
Tyler Hicks |
Bug 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 : virNetDevBridge
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/
-rw-r--r-- 1 nobody nogroup 4096 Jul 30 22:33 /sys/class/
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/
Unpatched kernels will see a Permission denied error:
$ lxc exec c1 -- sh -c 'brctl addbr testbr && \
sh: 1: cannot create /sys/class/
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:/
https:/
CVE References
Changed in linux (Ubuntu): | |
status: | In Progress → Fix Committed |
Changed in linux (Ubuntu Bionic): | |
assignee: | nobody → Tyler Hicks (tyhicks) |
status: | Triaged → In Progress |
description: | updated |
description: | updated |
Changed in linux (Ubuntu Bionic): | |
status: | In Progress → Fix Committed |
Patches submitted for inclusion in Ubuntu Cosmic:
https:/ /lists. ubuntu. com/archives/ kernel- team/2018- July/094426. html