Re: [Qemu-devel] RFC v3: blockdev_add & friends, brief rationale, QMP docs

[Stefan Hajnoczi <stefanha@gmail.com>]

On Fri, Jun 18, 2010 at 8:27 AM, Markus Armbruster <armbru@redhat.com> wrote:
> Stefan Hajnoczi <stefanha@gmail.com> writes:
>> On Thu, Jun 17, 2010 at 1:49 PM, Markus Armbruster <armbru@redhat.com> wrote:
>>> Stefan Hajnoczi <stefanha@gmail.com> writes:
>>>> On Wed, Jun 16, 2010 at 6:27 PM, Markus Armbruster <armbru@redhat.com> wrote:
>>> To let users ask for this explicitely, we could have pseudo-format
>>> "auto".
>>>
>>> We also need a pseudo-format "probe", which guesses the format from the
>>> image contents.  Can't be made the default, because it's insecure.
>>
>> In which scenario is probing the image format a security issue?  I'm
>> trying to think up scenarios where a cloud user modifies the guest
>> disk image and gets QEMU to re-open the image file as another format,
>> perhaps this would make the cloud owner/admin unhappy.  I don't see a
>> threat except for image format drivers have security bugs (corrupt
>> images leading to arbitrary code execution).
>
> User creates a raw image file.
>
> VM starts.  Image file gets probed, it's raw.  Guest has access to the
> complete file.
>
> Guest writes a valid QCOW2 image to it, chosen to include the full
> backing file in the resulting image contents.  Set the backing file to
> /secret/treasure.
>
> Reboot VM.  Image file gets probed, it's qcow2.  Backing file gets
> probed, it's raw.  Guest has access to the contents of QCOW2 image.
> This includes the backing file.  Oops.

I thought selinux/svirt was supposed to secure QEMU processes and
ensure they only have access to the resources they need?  If the
backing file doesn't belong to me then my QEMU process shouldn't be
able to open it.

Stefan