From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56855) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xlv2i-0000is-PS for qemu-devel@nongnu.org; Wed, 05 Nov 2014 02:30:18 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xlv2c-0006dg-LG for qemu-devel@nongnu.org; Wed, 05 Nov 2014 02:30:12 -0500 Received: from mx1.redhat.com ([209.132.183.28]:53851) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xlv2c-0006cW-D5 for qemu-devel@nongnu.org; Wed, 05 Nov 2014 02:30:06 -0500 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sA57U5uf014483 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Wed, 5 Nov 2014 02:30:05 -0500 From: Markus Armbruster References: <87lhnq3iul.fsf@blackfin.pond.sub.org> Date: Wed, 05 Nov 2014 08:30:02 +0100 In-Reply-To: <87lhnq3iul.fsf@blackfin.pond.sub.org> (Markus Armbruster's message of "Tue, 04 Nov 2014 19:45:38 +0100") Message-ID: <87bnomxfyd.fsf@blackfin.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] Image probing: how it can be insecure, and what we could do about it List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Kevin Wolf , Jeff Cody , Stefan Hajnoczi , Max Reitz Markus Armbruster 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. [...]