8:30 a.m.
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