** Description changed: + [Impact] + + * Upstream changed the apparmor profiles of libvirt to be named profiles + (instead of being path based). Yet some rules still sued the odl paths, + so they no more applied. + + * Backport the upstreamed fix to have the rules match and let qemu- + bridge-helper work again. + + [Test Case] + + * #1 Static + The installed rules should use labels + # grep qemu_bridge_helper /etc/apparmor.d/usr.sbin.libvirtd + good: + unix ... peer=(label=libvirtd//qemu_bridge_helper), + bad: + unix ... peer=(label=/usr/sbin/libvirtd//qemu_bridge_helper), + + Essentially the change of the patch applied needs to reach the system + + * #2 dynamic + $ apt install virt-manager + # Prep qemu-bridge helper + $ sudo mkdir /etc/qemu/ + $ echo "allow virbr0" | sudo tee -a /etc/qemu/bridge.conf + $ sudo chown ubuntu:libvirt-qemu /etc/qemu/bridge.conf + $ sudo chmod 0640 /etc/qemu/bridge.conf + $ sudo chmod u+s /usr/lib/qemu/qemu-bridge-helper + # create a system of your choice e.g. based on an ubuntu iso + $ wget http://archive.ubuntu.com/ubuntu/dists/bionic/main/installer-amd64/current/images/netboot/mini.iso + $ mv mini.iso .local/share/libvirt/images/ + $ virt-manager + # use the session connection + # "Add connection", select "user session" + # "Create guest" under "user session" + # On the network tab change "usermode networking" to "Specify shared + device name" + # Bridge name is "virbr0" + # Starting the guest will net a fail and apparmor denies: + [985025.273241] audit: type=1400 audit(1584436785.255:1595): apparmor="DENIED" operation="filer" pid=30843 comm="qemu-bridge-hel" family="unix" sock_type="stream" protocol=0 requested_mask + [985025.273245] audit: type=1400 audit(1584436785.255:1596): apparmor="DENIED" operation="fileemu-bridge-hel" family="unix" sock_type="stream" protocol=0 requested_mask="send receive" deni + [985025.273586] audit: type=1400 audit(1584436785.255:1597): apparmor="DENIED" operation="signd" requested_mask="send" denied_mask="send" signal=term peer="libvirtd//qemu_bridge_helper" + + This is due to the bridge helper being a Cx rule and not detecting it + correctly. + + There are further blockers since the usage of the helper is insecure and + needs further steps, but those denies apparmor should no more trigger + which is enough for this test. + + [Regression Potential] + + * This change will re-enable an apparmor profile that was formerly not + detected and active correctly. For libvirt that means it was unable to + send/recive from qemu-bridge-helper and now it is - don't see a + problem on that. + But if people added some custom measures to get this part of the + communication right then the change will start to apparmor-guard qemu- + bridge-helper which it wasn't before. That could trigger apparmor + denials for them - OTOH for years there was no denial reported since + that was the same from Precise to Disco so I doubt this is a real + issue that will happen. + + [Other Info] + + * n/a + -- + On the last update of libvirt-daemon-system the /etc/apparmor.d/usr.sbin.libvirtd file was changed and the reference to the qemu-bridge-helper location was wrong. qemu-system-common: /usr/lib/qemu/qemu-bridge-helper The /etc/apparmor.d/usr.sbin.libvirtd leaves out /qemu/ Not sure if this is the correct place for this bug.
-- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1655111 Title: LibVirt Apparmor profile has qemu-bridge-helper listed in the wrong directory To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1655111/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
