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

[Anthony Liguori <anthony@codemonkey.ws>]

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
>