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

[Markus Armbruster <armbru@redhat.com>]

Eric Blake <eblake@redhat.com> writes:

> On 11/04/2014 07:45 PM, Markus Armbruster 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.
>> 
>
> Thanks for this write-up.  I'll probably reply again, but for now I'm
> focusing on just one thing I think you missed that came up in the
> related threads:
>
>
>> = How can we better guard the trust boundary in QEMU? =
>> 
>> The guest can violate the trust boundary only because
>> 
>> (a) QEMU supports both raw images and image formats, and
>> 
>> (b) QEMU guesses image format from raw image contents, and
>> 
>> (c) given a raw image, guests can change its contents and control a
>> future QEMU's format guess.
>> 
>> We can attack one ore more of these three conditions:
>> 
>> (a) Outlaw raw images
>> 
>> (b) Don't guess format from untrusted image contents
>> 
>> (c) Prevent "bad" guest writes
>
> (d) write metadata that records our guess before releasing data across a
> trust boundary, so that we no longer need to probe on the next encounter
>
> While this won't work for top-level images, it is a possibility for
> backing store.  Any time we open a qcow2 file that has a backing file
> without a format, we can rewrite the qcow2 metadata to record the type
> that we ended up settling on, prior to allowing the guest to manipulate
> the data.  The initial open is "safe" (we haven't yet handed the data to
> the guest - and the trust boundary is not broken until the point that
> the guest has had a chance to overwrite data) and all subsequent opens
> are now safe (because we rewrote the metadata, subsequent operations no
> longer need to probe the backing file, but are guaranteed to use the
> same format as the first open, whether or not those subsequent
> operations are performed by a different qemu that would have probed a
> different type).
>
> PRO: Plugs hole for backing files
>
> CON: Doesn't help for top-level images.  In a chain "base <- mid <- top"
> where neither mid nor top recorded backing type, it would require mid to
> be temporarily opened read-write to update the metadata.

I think we better distinguish two cases:

1. Freeze the backing format on create

   PRO: Plugs hole for backing files in new images

   CON: Incompatible change, but only for truly weird usage.

2. Freeze the backing format on writable open

   PRO: Plugs hole for this existing image's backing file

   CON: As above.

I'm quite comfy with 1's CON, but 2's gives me a slightly queasy
feeling.  Not enough of it to actually object, though.