This patch series attempts to fix 3 security flaws in the handling of virtual disk formats. This is just another occurrance of the problem previously identified in Xen
https://www.redhat.com/security/data/cve/CVE-2008-2004.html In essence, if a guest is configured with a disk, hda, backed in the host by a plain file, then admin in the guest OS can run 'qemu-img -f qcow2 /dev/hda' to write a qcow2 header into the disk. If the host OS ever probes the backing file to identify its format, then it will see it as a qcow2 file now, instead of the expected raw. In QEMU this problem is addressed in two ways - When configuring a guest with -drive, always set format=raw|qcow2|etc Libvirt will always set this when <driver type='raw|qcow2|etc'> is set for a disk. - When creating a qcow2 guest, always set an explicit backing store format with -o backing_store_format=raw|qcow2|etc or -F raw|qcow2|etc. Libvirt will always set this when a <format type='raw|qcow2'/> is set for a volume backing store Despite having support for these QEMU features to prevent probing, there are flaws in the way libvirt handles disks in various places. - In the security drivers (SELinux, CGroups, DAC) when labelling files on the host, instead of looking at the <driver type='raw|qcow2'/> in the XML to identify the disk format, libvirt probes the file for magic data. Thus even if the app has taken the care to set an explicit format, for all disks, libvirt can be tricked into setting security labels on files that it shouldn't. If the guest OS somehow manages to break out and compromise QEMU it can take advantage of this labelling flaw to access files it shouldn't. - In the security drivers (SELinux, CGroups, DAC) when labelling the backing store for files on the host, instead of looking at embedded backing store format in the master disk image, libvirt probes magic data. Thus even if the app has taken the care to set an explicit format, for all disk backing stores, libvirt can be tricked into setting security labels on files that it shouldn't. If the guest OS somehow manages to break out and compromise QEMU it can take advantage of this labelling flaw to access files it shouldn't. - In the storage driver that creates qcow2 files, the backing store format is only set explicitly if the kvm-img binary is found. Any users with just a qemu-img binary will not have the backing store format set, even if qemu-img supports this capability. As a general matter of policy, libvirt does not mandate use of the <driver type='raw|qcow2'/> tag in the XML for disks, and if omitted will allow QEMU to probe disk formats. This is a weak default policy. If no explicit driver is set, libvirt should presume raw, since that is the only safe option. It should require a host level configuration option for the QEMU driver, to allow probing to be used. This patch series addresses all three of the security flaws, and also changes the default QEMU driver policy to disable all disk format probing out of the box. This latter change will break some existing deployments, so it is possible to turn it off in qemu.conf. The changes required significant re-factoring of the util/storage_file.c code and centralizes all processing of disk backing stores to minimise the risk of mistakes. There are also 5 additional test cases to the TCK, 3 to verify the security flaws, and 2 to verify that libvirtd is configured to disallow disk format probing. The file based storage pool needs to report the format of every volume in the pool. There is no way todo this other than to probe the volume metadata. Unfortunately if an application like virt-manager directly copies the <format> from the storage volume XML, straight into the <driver type=> of the guest disk, all our work to avoid the security problems is potentially null & void. NB, this is only a problem if re-using a pre-existing storage volume. If creating a new storage vol when provisioning a guest / hotplugging a disk, virt-manager can trust the storage volume format. I think we need to advise applications that when picking a pre-existing storage volume from a pool, they must not trust the volume format, and must confirm with the user whether to use the probed format, or force to raw The CVEs are https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2010-2237 https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2010-2238 https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2010-2239 In addition, this patch series fixes the problem of mutually recursive backing stores which would cause an infinite loop in libvirtd. Regards, Daniel -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
