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

[Markus Armbruster]

Stefan Hajnoczi <address@hidden> writes:

> On Fri, Jun 18, 2010 at 8:27 AM, Markus Armbruster <address@hidden> wrote:
>> Stefan Hajnoczi <address@hidden> writes:
>>> On Thu, Jun 17, 2010 at 1:49 PM, Markus Armbruster <address@hidden> wrote:
>>>> Stefan Hajnoczi <address@hidden> writes:
>>>>> On Wed, Jun 16, 2010 at 6:27 PM, Markus Armbruster <address@hidden> 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.

Yes, SELinux will protect you from security holes in applications.
Protecting from != fixing of :)