[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.
Regards,
Anthony Liguori
> Daniel
>
More information about the libvir-list
mailing list