Comment 2 for bug 853330

This is precisely the issue that http://www.ubuntu.com/usn/usn-1008-1/ addressed in libvirt. qemu can use anything as a backing store, so if a guest used a raw image, it could modify the data structures of the disk to look like a qemu qcow2 file and point somewhere else. On the next guest boot after a shutdown (not reboot), libvirt would examine all the backing stores and update the apparmor dynamic profile. Running as the libvirt-qemu user helps here, cause DAC would prevent access (but when running as root, like in Lucid, this was more of a problem). libvirt was updated in the aforementioned security update to require that the domain xml match the disk. Eg, in order to use a qemu image with backing store, the domain xml must have "<driver name='qemu' type='qcow2'>". This makes it was that if a machine with "<driver name='qemu' type='raw'>" changes its on-disk format, it will fail to start because the disk (which is now a qcow2) does not match the domain xml. Guests that are already using qcow2 images are not able to change their on disk format (and if they are, qemu-kvm would get a CVE allocated for this). Finally, if using the AppArmor driver, there are paths that the guest is not allowed to access on the host (see valid_path() in virt-aa-helper.c), eg files in /etc, /proc and /sys. The blacklist is incomplete (it must be, since users need to be allowed to put their disks, etc almost anywhere on the system), but it does prevent a lot of access.

As for qemu-kvm itself, normal DAC is in effect. If the user invoking qemu-kvm has privilege, then that user can use qemu-kvm to have privileged access to files via qemu's backing store mechanism. Keep in mind, that user must already have the privileged access in the first place, so there is no privilege escalation or crossing of privilege boundaries.

One thing to keep in mind is that all members of the libvirtd group should be considered privileged (ie 'root', because of access to disks), as discussing in /usr/share/doc/libvirt-bin/README.Debian. Also keep in mind that libvirt and its AppArmor driver are not protecting the administrator (ie, a person in the libvirtd group) from herself or guests from the host, but instead protecting guests from each other and the host from the guests.

Keeping all of the above in mind, within the context of Ubuntu, libvirt and qemu, there is no privilege escalation or crossing of privilege boundaries.

Within the context of nova, the cloud-publish-image should either enforce raw disks only, or do rigorous input validation on the disk file and reject files with a backing store at all or enforce that backing stores be within a particular path. The qemu-img command can aid in this:
$ qemu-img info ./disk0.qcow2
image: ./disk0.qcow2
file format: qcow2
virtual size: 8.0G (8589934592 bytes)
disk size: 14M
cluster_size: 65536
backing file: <path>/disk0.pristine.qcow2 (actual path: <path>/disk0.pristine.qcow2)