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

Anthony Liguori anthony at codemonkey.ws
Mon Apr 26 13:13:03 UTC 2010

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.


Anthony Liguori

> Daniel

More information about the libvir-list mailing list