[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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.


Anthony Liguori


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]