Re: [Qemu-devel] [PATCH] Make default invocation of block drivers safer

[Stefan Hajnoczi]

On Thu, Jul 15, 2010 at 9:09 AM, Kevin Wolf <address@hidden> wrote:
> Am 14.07.2010 20:43, schrieb Christoph Hellwig:
>> Err, strong NACK.  Please don't start messing with the contents of the
>> data plane, we're getting into real trouble there.  It's perfectly
>> valid for a guest to create an image inside an image, and with hardware
>> support for nested virtualization I guess this use case will become
>> rather common, just as it already is on S/390 with VM.
>
> But you'll hardly ever find a legitimate or even common use case for
> putting qcow2 on a raw hard disk. I mean, we have all learned that qcow2
> can be used in LVs (which can grow at least), but directly on a hard
> disk just doesn't make any sense to me. That's the first point.
>
> The second is that you should always specify the format explicitly,
> which turns this magic off. Specify format=raw and you're free to format
> as many hard disks as qcow2 as you want.
>
> Third, if you don't specify format=raw and the guest has written a qcow2
> header, next time it would get the wrong content anyway because qcow2
> will be interpreted by the host and not the level 1 guest (this one is
> the security problem).

I have mixed feelings about this approach.  It has good usability
because legitimate users are unaffected, but adding a check into the
I/O path is unfortunate from a clean code perspective.

Management stacks that don't explicitly set format= today are in
trouble.  In an environment where the VM owner is untrusted, the VM
owner could provide/upload a malicious disk image and cold boot it.
This patch only prevents dodgy images created inside a running VM.
Luckily this scenario is increasingly unlikely since management stacks
specifying explicit format= and SELinux/sVirt will eventually make
this go away.

I think there are actually two issues here:

1. Confusing QEMU so it sees an image with a different format than expected.

This is important because it's unexpected behavior for a user who puts
a QCOW2 image onto a raw disk to find the disk itself turn into a
QCOW2 disk on next reboot.

I also worry about this bug because it means that in a scenario where
format= is not explicitly given, the VM can change its disk image
format.  This is a problem because the host administrator might have
used raw files and be unhappy to find that the user is able to exploit
a (hypothetical) security issue in the vmdk code despite having
created the VM with a raw image.

2. Image formats that support backing files are inherently insecure.

The final scenario that doesn't go away is the casual user who tries
out a foreign disk image.  The expectation is that the disk image
could boot up and do completely silly things but it could not affect
the host.  In reality it can read the contents of any file owned by
the uid running QEMU and send them over the internet if the guest has
networking.

You really need to run qemu-img info to check that there is no
unwanted backing file.  So I suspect we'll never be 100% safe unless
backing files are disabled by default with an error message asking you
to add allow_backing_file=on.

Stefan