From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joanna Rutkowska Subject: Re: A few KVM security questions Date: Mon, 07 Dec 2009 18:09:55 +0100 Message-ID: <4B1D36E3.9090206@invisiblethingslab.com> References: <4B1CFD93.7090307@invisiblethingslab.com> <4B1D0057.8030707@redhat.com> <4B1D0383.1080306@invisiblethingslab.com> <4B1D0544.9000603@redhat.com> <4B1D30F6.7050609@codemonkey.ws> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig4E610CD3066C17627CF68F9A" Cc: Avi Kivity , kvm@vger.kernel.org To: Anthony Liguori Return-path: Received: from out1.smtp.messagingengine.com ([66.111.4.25]:54084 "EHLO out1.smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S964791AbZLGRJv (ORCPT ); Mon, 7 Dec 2009 12:09:51 -0500 In-Reply-To: <4B1D30F6.7050609@codemonkey.ws> Sender: kvm-owner@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4E610CD3066C17627CF68F9A Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Anthony Liguori wrote: > Avi Kivity wrote: >> No. Paravirtualization just augments the standard hardware interface,= >> it doesn't replace it as in Xen. >=20 > NB, unlike Xen, we can (and do) run qemu as non-root. Things like > RHEV-H and oVirt constrain the qemu process with SELinux. >=20 On Xen you can get rid of the qemu entirely, if you run only PV domains. > Also, you can use qemu to provide the backends to a Xen PV guest (see -= M > xenpv). The effect is that you are moving that privileged code from th= e > kernel (netback/blkback) to userspace (qemu -M xenpv). >=20 > In general, KVM tends to keep code in userspace unless absolutely > necessary. That's a fundamental difference from Xen which tends to do > the opposite. >=20 But the difference is that in case of Xen one can *easily* move the backends to small unprivileged VMs. In that case it doesn't matter the code is in kernel mode, it's still only in an unprivileged domain. Sandboxing a process in a monolithic OS, like Linux, is generally considered unfeasible, for anything more complex than a hello world program. The process <-> kernel interface seem to be just too fat. See e.g. the recent Linux kernel overflows by Spender. Also, SELinux seems to me like a step into the wrong direction. It not only adds complexity to the already-too-complex kernel, but requires complex configuration. See e.g. this paper[1] for a nice example of how to escape SE-sandboxed qemu on FC8 due to SELinux policy misconfiguration= =2E When some people tried to add SELinux-like-thing to Xen hypervisor, it only resulted in an exploitable heap overflow in Xen [2]. [1] http://invisiblethingslab.com/resources/misc08/xenfb-adventures-10.pd= f [2] http://invisiblethingslab.com/resources/bh08/part2-full.pdf joanna. --------------enig4E610CD3066C17627CF68F9A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAksdNuMACgkQORdkotfEW85gAQCg2pfO7IrnC7IU2hz+LLIB9g05 rygAoL5v9nbVboqnbSwj5FmtCHbd3QoC =XjlB -----END PGP SIGNATURE----- --------------enig4E610CD3066C17627CF68F9A--