From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53784) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xm2me-0001P3-26 for qemu-devel@nongnu.org; Wed, 05 Nov 2014 10:46:14 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xm2mX-0000cL-TK for qemu-devel@nongnu.org; Wed, 05 Nov 2014 10:46:07 -0500 Received: from mx1.redhat.com ([209.132.183.28]:37473) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xm2mX-0000c4-Mt for qemu-devel@nongnu.org; Wed, 05 Nov 2014 10:46:01 -0500 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sA5FjujZ017979 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Wed, 5 Nov 2014 10:45:59 -0500 Date: Wed, 5 Nov 2014 15:24:01 +0000 From: "Dr. David Alan Gilbert" Message-ID: <20141105152401.GC2527@work-vm> References: <87lhnq3iul.fsf@blackfin.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87lhnq3iul.fsf@blackfin.pond.sub.org> 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 Cc: Kevin Wolf , Jeff Cody , qemu-devel@nongnu.org, Stefan Hajnoczi , Max Reitz * Markus Armbruster (armbru@redhat.com) 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. > > > = The trust boundary between image contents and meta-data = > > A disk image consists of image contents and meta-data. > > Example: all of a raw image's contents is image contents. Leaves just > file name and attributes for meta-data. > > Example: QCOW2 meta-data includes header, header extensions, L1 table, > L2 tables, ... The meta-data defines where in the image the actual > contents is stored. > > A guest can access the image contents, not the meta-data. > > Image contents you've let an untrusted guest write is untrusted. > > Therefore, there's a trust boundary between image contents and > meta-data. QEMU has to trust image meta-data, but shouldn't trust image > contents. The exact location of the trust boundary depends on the image > format. I'm not sure of the line: 'QEMU has to trust image meta-data' I think there are different levels of trust and people will be more prepared to accept levels of pain at the commandline to avoid different types of problem. A problem that could cause qemu to access arbitrary other files on the host (as backing files for example) is obviously the worst; especially if things like qemu-img and other analysis type stuff could trip it. Stuff that only allows a guest to misuse it's own block storage is bad; but it's nowhere near as bad as being able to walk around the host. Dave -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK