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

[Anthony Liguori <aliguori@linux.vnet.ibm.com>]

On 07/15/2010 04:10 AM, Stefan Hajnoczi wrote:
> 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.
>    

More specifically, management stacks are in trouble if they use raw 
images and don't use format=.  Anyone using qcow2 exclusively is fine.

I'm less concerned about uploaded images.  Format spoofing is really the 
least of the concerns for uploaded images.  The bigger concern IMHO is 
attempting to exploit vulnerabilities in qcow2 or any of the other image 
formats.

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

One of the nasty things in QEMU right now is that we have absolutely no 
way to persist information about the guest and we have no persistent 
definition of the guest.

All of our VMs are basically stateless across invocations and that 
really makes things like this difficult.

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

I'm not sure I'd classify it as insecure.  They are only insecure *if* 
the guest can modify the backing file.  With the proposed patch, they can't.

Regards,

Anthony Liguori

> Stefan
>