[libvirt] improve security by adjusting the privileges of libvirtd processes
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? 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) Regards, BiaoXiang
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 :|
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
participants (2)
-
Daniel P. Berrangé -
yebiaoxiang