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

[Markus Armbruster]

Markus Armbruster <address@hidden> writes:

[...]
> = 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
>
> Nobody is seriously suggesting we do (a).  It's clearly too late for
> that.  Let's explore the other two in more detail.

Of course, if we really *want* (a)...

== Outlaw raw images ==

Define a simple raw image container, or steal an existing one we like
(suggestions welcome).  Drop support for containerless images.

Naturally, the raw container should support "single file",
i.e. container file actually contains the image.

It could also support separate container and image file, for easy and
efficient wrapping and unwrapping.

PRO: Simple, plugs the hole.

CON: Breaks a lot of existing usage.

CON: Upgrade involves image wrapping operations, which may be a bother.
If the container doesn't support separate image files, it's also a lot
of expensive copying.

Mitigation: lengthy transition period where we warn "use of
containerless raw images are insecure, and we'll eventually break this
usage; here's how to wrap your raw images in a container".

CON: We delay plugging the hole one more time.  But at least we no
longer expose our users to it silently.

Variation: keep supporting them with explicit format=raw.

PRO: Simple.

CON: Still breaks a lot of existing usage.  Not libvirt's, though.

CON: Doesn't fully plug the hole: mixing non-probed usage (user
specifies format=raw) with probed usage (user doesn't specify format)
remains insecure.  The guest's write succeeds in non-probed usage, and
the guest escapes isolation in the next probed usage.

[...]