Comment 3 for bug 853330

"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."

I disagree. At very least the launcher of one instance can potentially access data from another user's instance. I see nothing above stopping them from getting raw read access to the hosts root disk.

Nova has a setting 'use_cow_images' which defaults to true. If that is set, then on instance creation, nova does: qemu-img create -f qcow2 -b /path/to/pristine-disk-image /path/to/instance/cow/disk. It passes appropriate xml to libvirt to say "this is a qcow disk" and thus kvm gets that as well. Essentially the user does not need to change the disk format. It is, as written by nova, 'qcow2'.

If the user uploads a qcow image that contains in it a backing store reference to '/dev/sda' or to /var/lib/nova/instances/i-000003/disk (a suspected path to another user's disk), then nova will launch a libvirt/kvm instance with a qcow disk image that has 2 levels of backing store. The first merely references the second (which is what the user uploaded) and the second references a secret file on disk.

Unless apparmor/ubuntu/kvm explicitly disallow 2 level qcow images, then this is valid.