Re: [libvirt] [Qemu-devel] Re: Libvirt debug API

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.