** Description changed: + [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 + 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 + # 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
** Description changed: [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' + 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 -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. 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: In Progress 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 -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
