From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=54703 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1OPWkX-0007Li-6Z
	for qemu-devel@nongnu.org; Fri, 18 Jun 2010 04:16:30 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69)
	(envelope-from <stefanha@gmail.com>) id 1OPWkV-0005bl-SI
	for qemu-devel@nongnu.org; Fri, 18 Jun 2010 04:16:28 -0400
Received: from mail-yw0-f180.google.com ([209.85.211.180]:65177)
	by eggs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <stefanha@gmail.com>) id 1OPWkV-0005bh-Nd
	for qemu-devel@nongnu.org; Fri, 18 Jun 2010 04:16:27 -0400
Received: by ywh10 with SMTP id 10so527982ywh.18
	for <qemu-devel@nongnu.org>; Fri, 18 Jun 2010 01:16:25 -0700 (PDT)
MIME-Version: 1.0
In-Reply-To: <m3k4pw3imj.fsf@blackfin.pond.sub.org>
References: <m3ocfadh19.fsf@blackfin.pond.sub.org>
	<AANLkTilAjlPwSYP144bVNzqS2flkygY_HSgbo5TO5eQh@mail.gmail.com>
	<m3typ1vn7k.fsf@blackfin.pond.sub.org>
	<AANLkTilSQjM1Ml5G7KuqhlVeuF82pTSP7K4-BLHzw02p@mail.gmail.com>
	<m3k4pw3imj.fsf@blackfin.pond.sub.org>
Date: Fri, 18 Jun 2010 09:16:24 +0100
Message-ID: <AANLkTimqxW3M4PL-hSJBtrfKKEmqaMxsnsrH2O0BUlsW@mail.gmail.com>
Subject: Re: [Qemu-devel] RFC v3: blockdev_add & friends, brief rationale, QMP
	docs
From: Stefan Hajnoczi <stefanha@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Markus Armbruster <armbru@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>, Christoph Hellwig <chellwig@redhat.com>, qemu-devel@nongnu.org, Luiz Capitulino <lcapitulino@redhat.com>, Avi Kivity <avi@redhat.com>, Gerd Hoffmann <kraxel@redhat.com>

On Fri, Jun 18, 2010 at 8:27 AM, Markus Armbruster <armbru@redhat.com> wrot=
e:
> Stefan Hajnoczi <stefanha@gmail.com> writes:
>> On Thu, Jun 17, 2010 at 1:49 PM, Markus Armbruster <armbru@redhat.com> w=
rote:
>>> Stefan Hajnoczi <stefanha@gmail.com> writes:
>>>> On Wed, Jun 16, 2010 at 6:27 PM, Markus Armbruster <armbru@redhat.com>=
 wrote:
>>> To let users ask for this explicitely, we could have pseudo-format
>>> "auto".
>>>
>>> We also need a pseudo-format "probe", which guesses the format from the
>>> image contents. =A0Can't be made the default, because it's insecure.
>>
>> In which scenario is probing the image format a security issue? =A0I'm
>> trying to think up scenarios where a cloud user modifies the guest
>> disk image and gets QEMU to re-open the image file as another format,
>> perhaps this would make the cloud owner/admin unhappy. =A0I don't see a
>> threat except for image format drivers have security bugs (corrupt
>> images leading to arbitrary code execution).
>
> User creates a raw image file.
>
> VM starts. =A0Image file gets probed, it's raw. =A0Guest has access to th=
e
> complete file.
>
> Guest writes a valid QCOW2 image to it, chosen to include the full
> backing file in the resulting image contents. =A0Set the backing file to
> /secret/treasure.
>
> Reboot VM. =A0Image file gets probed, it's qcow2. =A0Backing file gets
> probed, it's raw. =A0Guest has access to the contents of QCOW2 image.
> This includes the backing file. =A0Oops.

I thought selinux/svirt was supposed to secure QEMU processes and
ensure they only have access to the resources they need?  If the
backing file doesn't belong to me then my QEMU process shouldn't be
able to open it.

Stefan