[libvirt] improve security by adjusting the privileges of libvirtd processes

[Daniel P. Berrangé]

On Mon, Nov 16, 2020 at 08:12:22PM +0800, yebiaoxiang wrote:
> Hi Team
> 
> The daemon libvirtd runs as root user, which against the least privilege
> security model.
> 
> root 567642 1.2 0.0 2856020 47576 ? Ssl 15:49 0:02 /usr/sbin/libvirtd --listen
> 
> In addition, the "--listen" parameter exposes TCP or TLS ports on the network,
> it increasing the attack surface.
> 
> tcp   0   0 0.0.0.0:16509  0.0.0.0:*  LISTEN  647824/libvirtd
> tcp   0   0 0.0.0.0:16514  0.0.0.0:*  LISTEN  647824/libvirtd
> 
> I have the following puzzles:
>  1. Whether root is the least privilege required for libvirtd to manage
>     virtualization platforms, it's possible to run libvirtd as a non-root user?

The libvirtd daemon is our so called "monolithic" daemon that does
everything

There are two modes libvirtd can operate in. system mode where it is
running as root, and session mode where it is running as an unprivileged
user.

The main issue is that session mode lacks *many* features, because if you
are unprivileged you can't do many operations. For example, QEMU can't
use most networking features, it can't use PCI host device assignment,
it can't use huge pages, is limited in cgroups features, and more.

So data center / cloud virtualization apps, always use libvirtd in system
mode and run running as root.

The unprivileged session mode is only really useful for desktop virt, and
even then it is a bit painful to be limited in features.

>  2. Is there any plan to resolve this security weaknesses?
>     (like move the function of "--listen" to an independent non-root process,
>      or other good idea)

We have introduced a new set of modular daemons to replace libvirtd.
In this case, there is one daemon for each libvirt driver. so we have
a virtqemud, virtnodedevd, virtnetworkd, virtstoraged, and so on.

Many of these daemons will still need to run as root, however, because
you still have the issue of needing to use features which are only
available as root.

Some of them though are more amenable to lockdown. In particular the
TCP based remote access is in a separate virtproxyd daemon. That could
be made to run unprivileged without much difficulty.


We still ship with libvirtdas the default, but we want to switch to
the modular daemons by default very soon.

More info is here:

  https://libvirt.org/daemons.html

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|