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

[yebiaoxiang]

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
>