qemu-bridge-helper fails due to apparmor blocks

[Toni Spets]

The qemu-bridge-helper binary provided in qemu-system-common has at least two issues:

1. it's not setuid root
2. it doesn't have proper apparmor profile

Trying to use the bridge helper as a regular user will fail unless I set the setuid bit after every package upgrade and tear down the apparmor profiles. I'm probably the only one using it but it would be nice if worked since it's part of the package.

The setuid bit is probably an upstream issue from Debian but the apparmor issue is likely Ubuntu specific.

I'm on Ubuntu 18.04 and the qemu packages are 1:2.11+dfsg-1ubuntu4.

[Andreas Hasenack (ahasenack)]

Correct, it's not suid root because of security concerns, according to this changelog entry from verison 2.1+dfsg-3:

  * include /usr/lib/qemu-bridge-helper binary, but not make it setuid
    due to security concerns outlined in #691138 (Closes: #691138)

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=691138: "qemu-bridge-helper is not packaged"

I'll subscribe @paelzer for further commenting.

[Toni Spets (hifi)]

Reading the original Debian thread I don't really disagree with the packager but there should at least be a better way to permanently enable the setuid bit and have a correct apparmor profile so it would be possible to use it.

I qemu://session as a regular user with virt-manager because it helps managing images as I don't need to change the owner of anything from my own user. I would even say this would be the preferred way many would do "desktop virtualization" if they knew it existed.

[Christian Ehrhardt  (paelzer)]

Hi Toni,
by permanently I assume you mean to retain it through package updates?
For now I'd like to stick following Debian on that.

Even the upstream doc expects it to be off [1]

What would be a good idea for this to be easier to stick across updates - a custom maintainer script entry maybe?
But even then I'd prefer to stay in sync with Debian on it, would you mind reporting this (the demand to have the suid bit sticky across updates) to Debian and report the bug number here?

And for the apparmor profile that is available through lbivirt (as the other virt related apparmor bits).
It is a child profile of libvirt in /etc/apparmor.d/usr.sbin.libvirtd
Would you expect it to be available without libvirt or does it lack rules it needs?

[1]: https://wiki.qemu.org/Features/HelperNetworking

[Toni Spets (hifi)]

The apparmor profile from libvirt doesn't seem to work, only tearing down apparmor completely makes it tick. Getting that fixed for Ubuntu would be a big help.

If you need to test this, use virt-manager with a user session and try to use an existing bridge as the interface for a VM. You also need to create /etc/qemu/bridge.conf with a single line consisting of 'allow bridge0' depending on your interface name.

Will look into reporting the setuid bit not sticking to downstream but it's less of an issue than the apparmor profile as it prevents me from using apparmor right now.

[Christian Ehrhardt  (paelzer)]

Running as
 $ virt-manager -c qemu:///session

Setting up a bridge device the virt-manager way:
1. "specify shared device name"
   name: virbr0
   (that is the name of the default bridge in -c qemu:///user and not visible to qemu:///session)

The profile applies and blocks
Unable to complete install: 'internal error: /usr/lib/qemu/qemu-bridge-helper --use-vnet --br=virbr0 --fd=24: failed to communicate with bridge helper: Transport endpoint is not connected
stderr=failed to open /dev/net/tun: Permission denied

Denies (simplified):
apparmor="DENIED" profile="/usr/sbin/libvirtd//qemu_bridge_helper" family="unix" sock_type="stream" requested_mask="send receive" addr=none peer_addr=none peer="/usr/sbin/libvirtd"

apparmor="DENIED" profile="/usr/sbin/libvirtd" family="unix" sock_type="stream" requested_mask="send receive" addr=none peer_addr=none peer="/usr/sbin/libvirtd//qemu_bridge_helper"

apparmor="DENIED" profile="/usr/sbin/libvirtd" operation="signal" requested_mask="send" denied_mask="send" signal=term peer="/usr/sbin/libvirtd//qemu_bridge_helper"

apparmor="DENIED" profile="/usr/sbin/libvirtd//qemu_bridge_helper" operation="signal" requested_mask="receive" denied_mask="receive" signal=term peer="/usr/sbin/libvirtd"

I see, this is the mediation of signals and sockets kicking in, that wasn't existing back then.

Rules needed for those are:
--- usr.sbin.libvirtd.orig 2018-04-04 07:40:24.814316241 +0000
+++ usr.sbin.libvirtd.new 2018-04-04 08:12:44.734708742 +0000
@@ -73,6 +73,11 @@
   # required if guests run unconfined seclabel type='none' but libvirtd is confined
   signal (read, send) peer=unconfined,

+ # for qemu-bridge-helper
+ #unix (send) type=stream addr=none peer=/usr/sbin/libvirtd/qemu_bridge_helper,
+ unix (send, receive) type=stream addr=none peer=(label=/usr/sbin/libvirtd//qemu_bridge_helper),
+ signal (send) set=("term") peer=/usr/sbin/libvirtd//qemu_bridge_helper,
+
   # Very lenient profile for libvirtd since we want to first focus on confining
   # the guests. Guests will have a very restricted profile.
   / r,
@@ -121,6 +126,10 @@

    network inet stream,

+ # Be controllable from libvirtd
+ unix (send, receive) type=stream addr=none peer=(label=/usr/sbin/libvirtd),
+ signal (receive) set=("term") peer=/usr/sbin/libvirtd,
+
    /dev/net/tun rw,
    /etc/qemu/** r,
    owner @{PROC}/*/status r,

When these are resolved we obviously need still:
  $ chmod u+s /usr/lib/qemu/qemu-bridge-helper
But that is expected for now.

Even after all that it doesn't work for me (also tried g+s later).
It still complains that bridge helper isn't controllable, and that it got permission denied messages.
libvirtError: internal error: /usr/lib/qemu/qemu-bridge-helper --use-vnet --br=virbr0 --fd=25: failed to communicate with bridge helper: Transport endpoint is not connected
stderr=failed to open /dev/net/tun: Permission denied

If I run it with sudo it works, so it is as if the setuid would not kick in at all for me.

Never the less, maybe my setup is broken in other ways.
@Toni - could you
1. apply the proposed appamor change above to your local file /etc/apparmor.d/usr.sbin.libvirtd
2. reload the profile "sud...

[Toni Spets (hifi)]

Finally got time to test this. Adding those lines to the apparmor profile indeed fixes it for me when the setuid bit is set.

Did you add the bridge device to /etc/qemu/bridge.conf? I'm using qemu:///session with virt-manager.

[Christian Ehrhardt  (paelzer)]

You are right, the conf is what I missed.
Since this is an uncommon feature (I agree it is currently underated, but that is how it is) there is no rush to fix it in release. Especially since it (the apparmor change) can be fixed by changing the conffile.

But I want to help to fix this the long run by bringing the change upstream...
Also by being a qemu-apparmor issue it is actually a libvirt bug (which is what carries these profiles).

[Christian Ehrhardt  (paelzer)]

Submitted upstream as https://www.redhat.com/archives/libvir-list/2018-April/msg00534.html

[Christian Ehrhardt  (paelzer)]

Will be in libvirt >=4.3 once released

[Launchpad Janitor (janitor)]

This bug was fixed in the package libvirt - 4.6.0-2ubuntu1

---------------
libvirt (4.6.0-2ubuntu1) cosmic; urgency=medium

  * Merged with Debian unstable (LP: #1786957).
    Among many other new features and fixes this includes fixes
    for (LP: #1754871), Remaining changes:
    - Disable libssh2 support (universe dependency)
    - Disable firewalld support (universe dependency)
    - Set qemu-group to kvm (for compat with older ubuntu)
    - Additional apport package-hook
    - Autostart default bridged network (As upstream does, but not Debian).
      In addition to just enabling it our solution provides:
      + do not autostart if subnet is already taken (e.g. in guests).
      + iterate some alternative subnets before giving up
    - d/p/ubuntu/Allow-libvirt-group-to-access-the-socket.patch: This is
      the group based access to libvirt functions as it was used in Ubuntu
      for quite long.
      + d/p/ubuntu/daemon-augeas-fix-expected.patch fix some related tests
        due to the group access change.
      + d/libvirt-daemon-system.postinst: add users in sudo to the libvirt
        group.
    - ubuntu/parallel-shutdown.patch: set parallel shutdown by default.
    - d/p/ubuntu/enable-kvm-spice.patch: compat with older Ubuntu qemu/kvm
      which provided a separate kvm-spice.
    - Xen related
      - d/p/ubuntu/ubuntu-libxl-qemu-path.patch: this change was split. The
        section that adapts the path of the emulator to the Debian/Ubuntu
        packaging is kept.
      - d/p/ubuntu/ubuntu-libxl-Fix-up-VRAM-to-minimum-requirements.patch: auto
        set VRAM to minimum requirements
      - d/p/ubuntu/xen-default-uri.patch: set default URI on xen hosts
      - Add libxl log directory
      - libvirt-uri.sh: Automatically switch default libvirt URI for users on
        Xen dom0 via user profile (was missing on changelogs before)
    - d/p/ubuntu/apibuild-skip-libvirt-common.h: drop libvirt-common.h from
      included_files to avoid build failures due to duplicate definitions.
    - Update README.Debian with Ubuntu changes
    - Convert libvirt0, libnss_libvirt and libvirt-dev to multi-arch.
    - Enable some additional features on ppc64el and s390x (for arch parity)
      + systemtap, zfs, numa and numad on s390x.
      + systemtap on ppc64el.
    - d/t/control, d/t/smoke-qemu-session: fixup smoke-qemu-session by making
      vmlinuz available and accessible (Debian bug 848314)
    - d/t/control, d/t/smoke-lxc: fix up lxc smoke test isolation
    - Add dnsmasq configuration to work with system wide dnsmasq (drop >18.04,
      no more UCA onto Xenial then which has global dnsmasq by default).
    - d/p/ubuntu/ubuntu_machine_type.patch: accept ubuntu types as pci440fx
    - Further upstreamed apparmor Delta, especially any new one
      Our former delta is split into logical pieces and is either Ubuntu only
      or is part of a continuous upstreaming effort.
      Listing related remaining changes in debian/patches/ubuntu-aa/:
      + 0001-apparmor-Allow-pygrub-to-run-on-Debian-Ubuntu.patch: apparmor:
        Allow pygrub to run on Debian/Ubuntu
      + 0003-apparmor-libvirt-qemu-Allow-read-access-to-overcommi.patch:
        ...