Re: [Qemu-devel] Image probing: how it can be insecure, and what we could do about it

[Markus Armbruster]

"Dr. David Alan Gilbert" <address@hidden> writes:

> * Markus Armbruster (address@hidden) wrote:
>> I'll try to explain all solutions fairly.  Isn't easy when you're as
>> biased towards one of them as I am.  Please bear with me.
>> 
>> 
>> = The trust boundary between image contents and meta-data =
>> 
>> A disk image consists of image contents and meta-data.
>> 
>> Example: all of a raw image's contents is image contents.  Leaves just
>> file name and attributes for meta-data.
>> 
>> Example: QCOW2 meta-data includes header, header extensions, L1 table,
>> L2 tables, ...  The meta-data defines where in the image the actual
>> contents is stored.
>> 
>> A guest can access the image contents, not the meta-data.
>> 
>> Image contents you've let an untrusted guest write is untrusted.
>> 
>> Therefore, there's a trust boundary between image contents and
>> meta-data.  QEMU has to trust image meta-data, but shouldn't trust image
>> contents.  The exact location of the trust boundary depends on the image
>> format.
>
> I'm not sure of the line:
> 'QEMU has to trust image meta-data'

Quoting myself: by configuring QEMU to use an image, the user instructs
QEMU to trust the image's meta-data.

> I think there are different levels of trust and people will be more
> prepared to accept levels of pain at the commandline to avoid different
> types of problem.
>
> A problem that could cause qemu to access arbitrary other files on the
> host (as backing files for example) is obviously the worst; especially
> if things like qemu-img and other analysis type stuff could trip it.
>
> Stuff that only allows a guest to misuse it's own block storage is bad;
> but it's nowhere near as bad as being able to walk around the host.

Yes, sensible, informed users will weigh risk against pain.  They may
decide that avoiding certain risks isn't worth the pain for them.

Reckless or under-informed users will go with whatever causes the least
pain.

Our job is to reduce the pain.  Secure usage should not be painful.

That way, sensible, informed users get to take less pain, and the other
users get hopefully exposed to less risk.