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

[Daniel P. Berrange]

On Mon, Apr 26, 2010 at 08:13:03AM -0500, Anthony Liguori wrote:
> 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.

No matter what emulator path is provided, that will never be run with
elevated privileges unless the host sysadmin has explicitly configured
that capability. The QEMU binaries always run in a dedicated account
which is completely unprivileged. This setuid is done *before* QEMU 
is even exec()'d. This is one of the reasons why we don't use the
QEMU -runas argument, which would allow custom emulator binaries to
potentially gain evelated privileges.

> 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.

Of course all software has bugs. 

> 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.

What you describe is not inherant to the daemon model. This is why we have
two separate models in libvirt. The system instance is pre-spawned with
high privileges, to allow use of hosts resources which require high 
privileges to access. The session instance is auto-spawned when the app
connects to libvirt, thus it inherits the privileges of the app that is
using it.

I don't deny that the system instance has a new attack surface, because it
is running privileged. If the app needs to connect VMs to privileged 
resources, then the architecture has to have some privileged component
to give access to those resoruces. You don't want the VM to be privileged,
nor the whole management app to be privileged. The system daemon is thus the
arbitrator for this privileged access. If you don't need todo anything that
requires higher privileges though, just use the session instance which 
always matches the apps privileges. 

Daniel
-- 
|: Red Hat, Engineering, London    -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org        -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|