From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O6Oat-0007TA-TL for qemu-devel@nongnu.org; Mon, 26 Apr 2010 09:43:28 -0400 Received: from [140.186.70.92] (port=38343 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O6Oaq-0007Ri-IM for qemu-devel@nongnu.org; Mon, 26 Apr 2010 09:43:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O6Oan-0001wq-6H for qemu-devel@nongnu.org; Mon, 26 Apr 2010 09:43:24 -0400 Received: from mail-pw0-f45.google.com ([209.85.160.45]:64047) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O6Oan-0001wf-1N for qemu-devel@nongnu.org; Mon, 26 Apr 2010 09:43:21 -0400 Received: by pwi6 with SMTP id 6so7600662pwi.4 for ; Mon, 26 Apr 2010 06:43:19 -0700 (PDT) Message-ID: <4BD59874.2000207@codemonkey.ws> Date: Mon, 26 Apr 2010 08:43:16 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [libvirt] Libvirt debug API References: <4BD1971B.7060907@redhat.com> <4BD1A543.1050004@codemonkey.ws> <4BD1ADA2.2050605@redhat.com> <4BD1E723.6070005@codemonkey.ws> <4BD2BDE0.7020907@redhat.com> <4BD3B965.3060205@codemonkey.ws> <4BD42CDB.2030901@redhat.com> <4BD4F20D.8030901@codemonkey.ws> <20100426095949.GA1342@redhat.com> <4BD5915F.3060405@codemonkey.ws> <20100426133120.GD1342@redhat.com> In-Reply-To: <20100426133120.GD1342@redhat.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: "Daniel P. Berrange" Cc: "libvir-list@redhat.com" , Jiri Denemark , Chris Lalancette , qemu-devel , Luiz Capitulino On 04/26/2010 08:31 AM, Daniel P. Berrange wrote: > What you describe is not inherant to the daemon model. This is why we have > two separate models in libvirt. The system instance is pre-spawned with > high privileges, to allow use of hosts resources which require high > privileges to access. The session instance is auto-spawned when the app > connects to libvirt, thus it inherits the privileges of the app that is > using it. > > I don't deny that the system instance has a new attack surface, because it > is running privileged. If the app needs to connect VMs to privileged > resources, then the architecture has to have some privileged component > to give access to those resoruces. You don't want the VM to be privileged, > nor the whole management app to be privileged. The system daemon is thus the > arbitrator for this privileged access. If you don't need todo anything that > requires higher privileges though, just use the session instance which > always matches the apps privileges. > I regret saying "more secure" because I think it's a difficult concept to really quantify and that makes it hard to meaningfully discuss. The reason I lean toward the direct launch model is that it gives the user a lot of flexibility in terms of using things like namespaces, DAC, cgroups, capabilities, etc. A lot of potential features are lost when you do indirect launch because you have to teach the daemon how to support each of these features. Regards, Anthony Liguori > Daniel >