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.
Regards,
Anthony Liguori
Daniel