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

[Eric Blake]

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.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature