Thanks for the information, that's really a good news. I'll learn more about modular daemons . Regards, BiaoXiang On 2020/11/16 21:22, Daniel P. Berrangé wrote: > 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 >
