From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40131) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xlxtw-0004Zy-Ie for qemu-devel@nongnu.org; Wed, 05 Nov 2014 05:33:25 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xlxtr-0007xP-L0 for qemu-devel@nongnu.org; Wed, 05 Nov 2014 05:33:20 -0500 Received: from mx1.redhat.com ([209.132.183.28]:51786) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xlxtr-0007xJ-ED for qemu-devel@nongnu.org; Wed, 05 Nov 2014 05:33:15 -0500 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sA5AXEkA028216 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Wed, 5 Nov 2014 05:33:14 -0500 Message-ID: <5459FCE8.2050007@redhat.com> Date: Wed, 05 Nov 2014 11:33:12 +0100 From: Eric Blake MIME-Version: 1.0 References: <87lhnq3iul.fsf@blackfin.pond.sub.org> In-Reply-To: <87lhnq3iul.fsf@blackfin.pond.sub.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="SCWaMvkCoiI6NuT0DSwXnFeKPjvfQiTRn" 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: Markus Armbruster , qemu-devel@nongnu.org Cc: Kevin Wolf , Jeff Cody , Stefan Hajnoczi , Max Reitz This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --SCWaMvkCoiI6NuT0DSwXnFeKPjvfQiTRn Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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. >=20 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: > =3D How can we better guard the trust boundary in QEMU? =3D >=20 > The guest can violate the trust boundary only because >=20 > (a) QEMU supports both raw images and image formats, and >=20 > (b) QEMU guesses image format from raw image contents, and >=20 > (c) given a raw image, guests can change its contents and control a > future QEMU's format guess. >=20 > We can attack one ore more of these three conditions: >=20 > (a) Outlaw raw images >=20 > (b) Don't guess format from untrusted image contents >=20 > (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. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --SCWaMvkCoiI6NuT0DSwXnFeKPjvfQiTRn Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg iQEcBAEBCAAGBQJUWfzoAAoJEKeha0olJ0Nq0LEIAJ11YSXNgwi77JBbCpRQoZTS E3m1dWvSDClGQ2PGBAGr8Y3owS/zZtMH41h6EgaohtYwZJRUBFHSToG3iyBpHQaV hb875e54FfRb4uZHnV7kjdBZfBxNa0zmwiWqVhiSlPkkAMufr/YbVjA/dIc2Zj0o Sx/F2tyjIIDUgXdVxVxOpjoZ4OTxXHvp4FXaVQ9vGSlnSfmQCOl6+wfUlXpES9Ah IaIodbglcMavyKBy5gAjfXtFsELN/y+trPT9OkDrHFJXVKJcSWVTkTe65KSkDZi5 ULsx+Bo0Cj57NGXtMd1BV3xBPiep44kaPPiVe1izsvwLKQfwfM2IRJQFcHXbCH0= =tfN/ -----END PGP SIGNATURE----- --SCWaMvkCoiI6NuT0DSwXnFeKPjvfQiTRn--