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:58:11 +0100 Message-ID: <4B1D4233.1070105@invisiblethingslab.com> References: <4B1CFD93.7090307@invisiblethingslab.com> <4B1D0057.8030707@redhat.com> <4B1D0383.1080306@invisiblethingslab.com> <4B1D0544.9000603@redhat.com> <4B1D30F6.7050609@codemonkey.ws> <4B1D36E3.9090206@invisiblethingslab.com> <4B1D3C54.6030305@codemonkey.ws> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigABA31D763A3DBD9A36894CF3" Cc: Avi Kivity , kvm@vger.kernel.org To: Anthony Liguori Return-path: Received: from out1.smtp.messagingengine.com ([66.111.4.25]:47337 "EHLO out1.smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S964846AbZLGR6M (ORCPT ); Mon, 7 Dec 2009 12:58:12 -0500 In-Reply-To: <4B1D3C54.6030305@codemonkey.ws> Sender: kvm-owner@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigABA31D763A3DBD9A36894CF3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Anthony Liguori wrote: > Joanna Rutkowska wrote: >> Anthony Liguori wrote: >> =20 >>> Avi Kivity wrote: >>> =20 >>>> No. Paravirtualization just augments the standard hardware interfac= e, >>>> 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 domain= s. >> >> =20 >>> 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 = the >>> kernel (netback/blkback) to userspace (qemu -M xenpv). >>> >>> In general, KVM tends to keep code in userspace unless absolutely >>> necessary. That's a fundamental difference from Xen which tends to d= o >>> 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. >> =20 >=20 > Right, in KVM, Linux =3D=3D hypervisor. A process is our "unprivileged= > domain". Putting an unprivileged domain within an unprivileged domain > is probably not helpful from a security perspective since the exposure > surface is identical. >=20 >> 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. >> =20 >=20 > That's the point of mandatory access control. Of course, you need the > right policy and Spender highlighted an issue with the standard RHEL > SELinux policy, but that should be addressed now upstream. >=20 >> 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 ho= w >> to escape SE-sandboxed qemu on FC8 due to SELinux policy >> misconfiguration. >> >> When some people tried to add SELinux-like-thing to Xen hypervisor, it= >> only resulted in an exploitable heap overflow in Xen [2]. >> =20 >=20 > It's certainly fair to argue the merits of SELinux as a mandatory acces= s > control mechanism. >=20 > Again though, that's the point of MLS. Our first line of defense is > qemu. Our second line of defense is traditional Posix direct access > control. Our third line of defense is namespace isolation (ala lxc).=20 > Our fourth line of defense is mandatory access control (ala SELinux and= > AppArmor). >=20 > If you take a somewhat standard deployment like RHEV-H, an awful lot of= > things have to go wrong before you can successfully exploit the system.= =20 > And 5.4 doesn't even implement all of what's possible. If you're reall= y > looking to harden, you can be much more aggressive about privileges and= > namespace isolation. >=20 I think this ultimately comes down to the question: is the built-from-scratch minimal PV interface (as in Xen) more secure than the Linux's fat-but-sandboxed interface? joanna. --------------enigABA31D763A3DBD9A36894CF3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAksdQjcACgkQORdkotfEW86FhwCeM+KNxfeVkMJJv8P9mYlnZhPo f74An1FZj9biCsTspWveCnktCIZTzsVO =f7tQ -----END PGP SIGNATURE----- --------------enigABA31D763A3DBD9A36894CF3--