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

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