compiling with libcap-ng disallows qemu/kvm access to files not owned by root when not using AppArmor

[Jamie Strandboge]

libvirt in 10.04 is now compiled with libcap-ng. According to http://libvirt.org/drvqemu.html#securitycap this will affect QEMU/KVM access to files if libvirt is configured to launch VMs as root (the default in Ubuntu, see bug #522619 for why). From the libvirt.org page:
"The Linux capability feature is thus aimed primarily at the scenario where the QEMU processes are running as root. In this case, before launching a QEMU virtual machine, libvirtd will use libcap-ng APIs to drop all process capabilities. It is important for administrators to note that this implies the QEMU process will only be able to access files owned by root, and not files owned by any other user."

As it happens, the AppArmor security driver (which is enabled by default) disallows the SETPCAP capability, which is needed to drop these capabilities. As such, these capabilties are not dropped and libvirt behaves in much the same way as it would without being compiled with libcap-ng, like in previous releases of Ubuntu (this is not a security issue because the VM is confined by a restrictive AppArmor profile). This means that accessing VMs in $HOME still work.

However (and this is where the potential problem is) if someone disables the AppArmor security driver or adds this capability to the AppArmor profile, then SETPCAP is available and any VMs that need access to disk files, etc not owned by root will break with the following in /var/log/libvirt/qemu/<machine>.log:
qemu: could not open disk image /home/.../disk0.qcow2: Permission denied

This could be a serious regression for people using QEMU/KVM without AppArmor.

ProblemType: Bug
Architecture: i386
Date: Tue Feb 16 14:30:49 2010
DistroRelease: Ubuntu 10.04
InstallationMedia: Ubuntu 10.04 "Lucid Lynx" - Alpha i386 (20100130)
Package: libvirt-bin 0.7.5-5ubuntu7
ProcEnviron:
 PATH=(custom, user)
 LANG=en_US.utf8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.32-13.18-generic
SourcePackage: libvirt
Uname: Linux 2.6.32-13-generic i686

[Launchpad Janitor (janitor)]

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

---------------
libvirt (0.8.1-2ubuntu1) maverick; urgency=low

  * Merge from debian unstable. Remaining changes:
    - Fixes:
      LP: #522845
      LP: #553737
      LP: #520386
    - debian/control:
      + Build-Depends on qemu-kvm, not qemu
      + Build-Depends on open-iscsi-utils, not open-iscsi
      + Build-Depends on libxml2-utils
      + Build-Depends on libapparmor-dev and Suggests apparmor
      + Bump bridge-utils, dnsmasq-base, netcat-openbsd, and iptables
        to Depends of libvirt-bin
      + Drop qemu-kvm and qemu to Suggests
      + We call libxen-dev libxen3-dev, so change all references
      + Rename Vcs-* to XS-Debian-Vcs-*
    - debian/libvirt-bin.postinst:
      + rename the libvirt group to libvirtd
      + add each admin user to the libvirtd group
      + reload apparmor profiles
    - debian/libvirt-bin.postrm:
      + rename the libvirt group to libvirtd
      + remove apparmor symlinks on purge
    - debian/README.Debian: add AppArmor section based on the upstream
      documentation
    - debian/rules:
      + update DEB_DH_INSTALLINIT_ARGS for upstart
      + add DEB_MAKE_CHECK_TARGET := check
      + use --with-apparmor
      + copy apparmor and apport hook to debian/tmp
    - add debian/libvirt-bin.upstart
    - debian/libvirt-bin.dirs: add /etc/apparmor.d/abstractions,
      /etc/apparmor.d/disable, /etc/apparmor.d/force-complain,
      /etc/apparmor.d/libvirt, /etc/cron.daily and
      /usr/share/apport/package-hooks
    - add debian/libvirt-bin.cron.daily
    - add debian/libvirt-bin.apport
    - debian/libvirt-bin.install: install apparmor profiles, abstractions
      and apport hook
    - debian/apparmor:
      - add TEMPLATE
      - add libvirt-qemu abstraction
      - add usr.lib.libvirt.virt-aa-helper
      - add usr.sbin.libvirtd
    - debian/patches/series:
      + don't apply 0002-qemu-disable-network.diff.patch
      + don't apply 0005-Terminate-nc-on-EOF.patch. Use
        9010-autodetect-nc-params.patch instead
      + 9000-delayed_iff_up_bridge.patch (refreshed)
      + 9001-dont_clobber_existing_bridges.patch
      + 9002-better_default_uri_virsh.patch (updated)
      + 9004-better-default-arch.patch
      + 9005-libvirtd-group-name.patch
      + 9006-increase-unix-socket-timeout.patch (refreshed)
      + 9007-default-config-test-case.patch (updated)
      + 9008-fix-daemon-conf-ftbfs.patch (rewritten)
      + 9009-run-as-root-by-default.patch (refreshed)
      + 9010-autodetect-nc-params.patch (refreshed, formerly 9015)
      + 9011-dont-disable-ipv6.patch (updated)
  * Dropped following packaging changes, no longer required with upgrades
    from Lucid:
    - debian/control:
      + versioned Conflicts/Replaces to libvirt0 for libvirt0-dbg
      + remove Build-Depends on libcap-ng-dev
    - debian/libvirt-bin.postinst: virt-aa-helper profile migration to
      /usr/lib/libvirt
    - debian/libvirt-bin.preinst: added to force complain on certain
      upgrades
  * Dropped the following patches, included upstream:
    - 0010-Use-base-16-for-product-vendor.patch
    - 9003-increase-logoutput-timeout.patch
    - 9010-apparmor-ftbfs...

[Christian Ehrhardt  (paelzer)]

This is a very old Delta we are still carrying.
Compared to a lot of the delta which just has no trace where it came from this one had at least a bug link - yeah - thanks Jamie!

So for documentation purpose I'm updating here as I'm about to remove the related Delta on the next merge as it is safe to be removed.

Case dependent tests:
- We have an allow and a deny, who wins anyway?
  Discussed - denies are evaluated separate and win - so the rule was effective.

- Test:
     1. make a setup with disks owned by root and non-root (mixed)
     2. run default - ok
     DROP the setpcap deny
     3. run again - ok
     4. disable apparmor security via seclabel none
     5. run again - ok
     6. repeat 1-5 with user/group set to root in /etc/libvirt/qemu.conf - all ok

So it works fine in all cases related to the initial issue.

Note: It will grab ownership for the time of the execution, example:

-rw-r--r-- 1 root root 196616 Dec 14 15:46 test.qcow2
when run as extra user changes to:
-rw-r--r-- 1 libvirt-qemu kvm 196616 Dec 14 15:46 test.qcow2

So we are good to drop that old change