Re: [kubevirt-dev] RFC: New APIs for delegation of privileged operations
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 :|