From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O6O7c-0007rI-Er for qemu-devel@nongnu.org; Mon, 26 Apr 2010 09:13:12 -0400 Received: from [140.186.70.92] (port=58668 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O6O7b-0007qG-5Y for qemu-devel@nongnu.org; Mon, 26 Apr 2010 09:13:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O6O7Z-0003GD-El for qemu-devel@nongnu.org; Mon, 26 Apr 2010 09:13:11 -0400 Received: from mail-gx0-f209.google.com ([209.85.217.209]:54825) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O6O7Z-0003G7-Bx for qemu-devel@nongnu.org; Mon, 26 Apr 2010 09:13:09 -0400 Received: by gxk1 with SMTP id 1so5692894gxk.16 for ; Mon, 26 Apr 2010 06:13:07 -0700 (PDT) Message-ID: <4BD5915F.3060405@codemonkey.ws> Date: Mon, 26 Apr 2010 08:13:03 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [libvirt] Libvirt debug API References: <20100412122013.58894a64@redhat.com> <4BD09A3B.3090001@codemonkey.ws> <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> In-Reply-To: <20100426095949.GA1342@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 04:59 AM, Daniel P. Berrange wrote: > On Sun, Apr 25, 2010 at 08:53:17PM -0500, Anthony Liguori wrote: > >> On 04/25/2010 06:51 AM, Avi Kivity wrote: >> >>> Qemu is special due to the nonexistence of qemud. >>> >>> Why is sVirt implemented in libvirt? it's not the logical place for >>> it; rather the logical place doesn't exist. >>> >> sVirt is not just implemented in libvirt. libvirt implements a >> mechanism to set the context of a given domain and dynamically label >> it's resources to isolate it. >> >> The reason it has to assign a context to a given domain is that all >> domains are launched from the same security context (the libvirtd >> context) as the original user's context (the consumer of the libvirt >> API) has been lost via the domain socket interface. >> >> If you used the /session URL, then the domain would have the security >> context of whomever created the guest which means that dynamic labelling >> of the resources wouldn't be necessary (you would just do static labelling). >> > That is not correct. You do *not* ever want the guests to have the same > security context as the thing that created them, because that would allow > the guest to access& compromise resources belonging to the management app. > You assume that the management app is not smart enough to create a new context for the guest to run in. >> This is certainly a more secure model and it's a feature of qemu that I >> really wish didn't get lost in libvirt. Again, /session can do this too >> but right now, /session really isn't usable in libvirt for qemu. >> > If you really want the qemu instance to inherit the context of the mgmt > app, then you can just declare in the guest XML that it should use a > static label, and pass in the apps' own label. This is *not* a more secure > model though. > There is more context than just selinux labelling. The problem with the daemon model is that to create a guest, you start with a lower set of privileges, escalate your privileges (by talking to libvirtd), then lower privileges to launch a guest. Running a guest is essentially running arbitrary code (since you can set the emulator path) so now you've provided an environment where a user can launch arbitrary code as a different user in a different security context. There is a new attack surface here. I think it's undeniable that there is certainly the possibility that something goes wrong and a user will find a way to escalate it's privileges. Compare that to a direct launch model. There is not new attack surface. The user's privileges never increase. In fact, what's most likely to happen is that a caller will drop some of it's privileges before launching a guest. Regards, Anthony Liguori > Daniel >