On Tue, Nov 29, 2022 at 06:23:07PM +0000, Fox, Kevin M wrote: > Would a regular libvirt installation benefit from having > libvirtd run untrusted too (I think so)? especially if its > on the network? so instead of making it plugable, maybe the > architecture should be updated and libvirtd never does > trusted operations and maybe the solution can be shared > between libvirt without kubevirt and libvirt+kubevirt? Yes, in general the idea of privilege separation is of course a good one. We've put almost all our effort though into getting privilege separation between QEMU and libvirtd, rather than between libvirted and the host. KubeVirt has taken a different approach of having QMEU and libvirtd run at the same privilege level, and then trying to get separation between libvirtd and the host. This difference in approach is the root of the problems. That said, it is not that different from the limitations we have when libvirtd runs in session mode, where it operates in thue user's own account, rather than system mode which runs as root. This has long meant that the session mode has access to fewer features than the system mode. No PCI passthrough, no virtual networks, far fewer storage features, etc. One of the steps we have taken towards to address this was to introduce the libvirt modular daemons, splitting libvirtd up into virtqemud, virtnetworkd, virtnodedevd, etc. The idea there was that a mgmt app like virt-manager could use the unprivileged virtqemud for running VMs, but talk to tthe privileged virstoraged to access storage, or virtnetworkd to get a virtual network connection. We never actually got around to implementing the glue needed to support this kind of setup though. It would require virtnetworkd, for example, to expose an internal only API for acquiring a configured TAP device FD, or virtstoraged to expose an API for acquiring an FD for a disk/file. Also not all the privilege problems can be handled by offloading between existing libvirt modular daemons. Low level process tunables such as real time priorities, don't fit into any of our existing daemons. We would require to add a virtqemuprivd to service privileges operations, on behalf of virtqemud. With 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 :|
