[Bug 1784501] Re: libvirtd is unable to configure bridge devices inside of LXD containers

** Changed in: linux (Ubuntu Bionic)
Status: In Progress => Fix Committed

--
You received this bug notification because you are subscribed to linux
in Ubuntu.
Matching subscriptions: Bgg, Bmail, Nb
https://bugs.launchpad.net/bugs/1784501

Title:
libvirtd is unable to configure bridge devices inside of LXD
containers

Status in linux package in Ubuntu:
Fix Released
Status in linux source package in Bionic:
Fix Committed

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 : 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

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1784501/+subscriptions