From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1Bb0X7-0005Xn-Jw for qemu-devel@nongnu.org; Thu, 17 Jun 2004 13:18:37 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1Bb0X5-0005WD-RE for qemu-devel@nongnu.org; Thu, 17 Jun 2004 13:18:37 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1Bb0X5-0005WA-Oi for qemu-devel@nongnu.org; Thu, 17 Jun 2004 13:18:35 -0400 Received: from [213.146.130.142] (helo=trantor.org.uk) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.34) id 1Bb0Vk-0001m6-UL for qemu-devel@nongnu.org; Thu, 17 Jun 2004 13:17:13 -0400 Subject: Re: [Qemu-devel] [PATCH] Security house-cleaning From: Gianni Tedesco In-Reply-To: <20040617163740.GB20148@sentinelchicken.org> References: <20040617043838.GA1938@sentinelchicken.org> <1087484840.21569.108.camel@sherbert> <20040617151418.GD27872@cs.unibo.it> <20040617163740.GB20148@sentinelchicken.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-R/zcTSufZThyQnFKGfev" Date: Thu, 17 Jun 2004 18:16:57 +0100 Message-Id: <1087492617.3375.127.camel@sherbert> Mime-Version: 1.0 Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org --=-R/zcTSufZThyQnFKGfev Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2004-06-17 at 09:37 -0700, Tim wrote: > > One of the main pros of Qemu (among the others) it that it has been > > designed NOT to run SUID. > > The only piece of code that need root access is tuntap networking. > > This problem can be circunvented by: > > - using sudo for tuntap > > - using user net (a.k.a slirp) > > - using vde. >=20 > Other future considerations:=20 > - PCI Proxy support (if it is ever offically supported) > How will the host OS allow access by QEMU guest in this case? > - Other bus (USB, firewire, etc) direct access to real hardware well first thought is even you aren't root, you are still playing with PCI devices, and due to the coarse grained control on some platforms (read: x86) if you can access PCI devices, you can 0wn the entire system (man 2 iopl). USB is packet based so can be secured reasonably. The easiest approach is to acquire the resource as root and drop your privileges... FD passing across fork isn't really feasable because you need to parse commandline to know what nodes to open with both PCI and USB. Another approach is having a daemon which mediates access over a socket (either mediating all access for security, or passing fds for performance). The former approach would allow you to use devices in remote machines so as to avoid locking up your qemu machine. It all sounds quite nice, but I'm not sure we need yet another daemon though :) --=20 // Gianni Tedesco (gianni at scaramanga dot co dot uk) lynx --source www.scaramanga.co.uk/scaramanga.asc | gpg --import 8646BE7D: 6D9F 2287 870E A2C9 8F60 3A3C 91B5 7669 8646 BE7D --=-R/zcTSufZThyQnFKGfev Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBA0dIJkbV2aYZGvn0RAm5NAJwPho/ekRfMkNeQD/78ZVWs7UcjpwCghc2I AKu9hU6p0VoDSiFFPF54H2E= =+gyz -----END PGP SIGNATURE----- --=-R/zcTSufZThyQnFKGfev--