From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MOapR-0002Xy-Jw for qemu-devel@nongnu.org; Wed, 08 Jul 2009 13:21:09 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MOapO-0002Pv-38 for qemu-devel@nongnu.org; Wed, 08 Jul 2009 13:21:09 -0400 Received: from [199.232.76.173] (port=45974 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MOapN-0002Pe-Jb for qemu-devel@nongnu.org; Wed, 08 Jul 2009 13:21:05 -0400 Received: from rv-out-0708.google.com ([209.85.198.246]:32516) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MOapN-0002B9-3Z for qemu-devel@nongnu.org; Wed, 08 Jul 2009 13:21:05 -0400 Received: by rv-out-0708.google.com with SMTP id c5so574085rvf.2 for ; Wed, 08 Jul 2009 10:21:04 -0700 (PDT) Message-ID: <4A54D57B.8080603@codemonkey.ws> Date: Wed, 08 Jul 2009 12:20:59 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 0/5] ATAPI pass through v2 References: <200907011931.53521.alexandre.bique@citrix.com> <20090707200327.GA3902@miranda.arrow> <4A53D2FD.4040004@codemonkey.ws> <5d3bb3090907071421i506a2f0bh5aca170c35a26f62@mail.gmail.com> <200907072344.33893.paul@codesourcery.com> <5d3bb3090907071550s6e832c45k804bca769aa57f70@mail.gmail.com> <4A53D3B1.2020903@codemonkey.ws> <19028.50372.333318.144669@mariner.uk.xensource.com> In-Reply-To: <19028.50372.333318.144669@mariner.uk.xensource.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Ian Jackson Cc: Paul Brook , Alexandre Bique , qemu-devel@nongnu.org Ian Jackson wrote: > Anthony Liguori writes ("Re: [Qemu-devel] [PATCH 0/5] ATAPI pass through v2"): > >> No need for a switch IMHO. If a user is doing pass through, they ought >> to expect that the guest has direct access to the device. >> > > The firmware of an IDE device can usually take over complete the > control of the host, if it chooses to and knows how. So upgrading the > firmware on the device is a lot more serious than just being able to > break the device. It would allow the guest to escape containment. > > So this definitely needs to be disabled by default. > Pass through == escape containment. That's generally true (even with VT-d). There's all sorts of bad things you can do generating interrupt storms or physically bricking hardware. > I disagree entirely. The qemu process inevitably has access to an > enormous amount of stuff that the guest shouldn't have, and in most > cases users don't even run it as a different user. > > Or are you suggesting qemu should always be run in a chroot ? As a lesser privileged user or as root heavily restricted by SELinux, yes. > Or a VM > perhaps ? qemu only safe run under Xen PV ? I don't think the KVM > guys are really going to like that as a security policy ... > It's about layers of security. If you design your security assuming that QEMU is safe, you're taking a much bigger risk than if you assume QEMU is hostile. >> I'm sure something like SELinux can be used to prevent a root QEMU >> process from doing a firmware upgrade. >> > > *boggle* You're not serious, are you ? > Yes, I'm actually a fan of SELinux in the context of a dedicated virtualization system. Regards, Anthony Liguori