From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34241) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XmMji-0005t9-Ok for qemu-devel@nongnu.org; Thu, 06 Nov 2014 08:04:32 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XmMjc-0000Mk-JV for qemu-devel@nongnu.org; Thu, 06 Nov 2014 08:04:26 -0500 Received: from mx1.redhat.com ([209.132.183.28]:53879) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XmMjc-0000Mc-7i for qemu-devel@nongnu.org; Thu, 06 Nov 2014 08:04:20 -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 sA6D4IWN014915 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Thu, 6 Nov 2014 08:04:19 -0500 From: Markus Armbruster References: <87lhnq3iul.fsf@blackfin.pond.sub.org> <20141105152401.GC2527@work-vm> Date: Thu, 06 Nov 2014 14:04:16 +0100 In-Reply-To: <20141105152401.GC2527@work-vm> (David Alan Gilbert's message of "Wed, 5 Nov 2014 15:24:01 +0000") Message-ID: <87ioisv5tb.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: "Dr. David Alan Gilbert" Cc: Kevin Wolf , Jeff Cody , qemu-devel@nongnu.org, Stefan Hajnoczi , Max Reitz "Dr. David Alan Gilbert" writes: > * 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' Quoting myself: by configuring QEMU to use an image, the user instructs QEMU to trust the image's 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. Yes, sensible, informed users will weigh risk against pain. They may decide that avoiding certain risks isn't worth the pain for them. Reckless or under-informed users will go with whatever causes the least pain. Our job is to reduce the pain. Secure usage should not be painful. That way, sensible, informed users get to take less pain, and the other users get hopefully exposed to less risk.