RFE: expose listen type 'socket' for SPICE/VNC

[calestyo]

Hey.

AFAIU, at least SPICE should support connections via Unix sockets instead of TCP (see https://bugzilla.redhat.com/show_bug.cgi?id=1335832) and I'd assume VNC does so too.

However, this seems not to be exported via virt-manager (right now one can only select "Listen Type" of "Address" or "None".

The GUI should allow to configure both, the socket that's created by the SPICE/VNC server ... and the one used by the viewer. These may be different if e.g. the socket is forwarded via SSH.

The nice thing about support sockets would be that this can be much more secure than TCP+passphrase, depending on the usage scenario.

Thanks, Chris.

[phrdina]

Hi, for security reasons there is no need to add listen type 'socket' as you can use listen type 'none'. This will require to use libvirt APIs to pass FD to QEMU that spice uses instead of socket or TCP https://libvirt.org/formatdomain.html#graphical-framebuffers.

Using listen type 'none' works by default with virt-manager.

For virt-viewer you need to use --attach option to make it work, if used without that option virt-viewer displays error message suggesting to use that option.

[calestyo]

I don't quite get your reasoning here.

People may e.g. want to connect via any VNC viewer to a VM. Doing so via TCP is a security risk, as e.g. even when constraining it to localhost any user on that host would be able to connect.

With sockets instead, on can easily restrict access based on file permissions.

[phrdina]

Well for virt-manager needs having Address and None is what most users will ever need. If users really need socket to make it is usable outside of virt-manager/virt-viewer they can edit the XML directly in virt-manager or they can use virt-xml as they most likely know what they are doing.

Libvirt doesn't support setting permissions to that socket in VM XML so somebody or some script/cron/... would have to change the socket permissions once the VM is started and every single time the VM is started otherwise it would have default permissions set by libvirt. For example on Fedora and Ubuntu regular user cannot even access that socket by default as it is restricted to qemu user.

In addition using socket with permissions set doesn't mean it's the only way how to access Spice/VNC as I stated on previous comment, libvirt has APIs that can pass FD directly bypassing any Address or Socket listen type. So if there are multiple users on host using system connection they all can access any VM unless there is an extra access control configured using polkit https://libvirt.org/acl.html.

All of this falls into advanced usage that requires additional configuration and in general we do not want to expose these in the graphical UI.

[calestyo]

Hmm ok.

Libvirt doesn't support setting permissions to that socket in VM XML so somebody or some script/cron/... would have to change the socket permissions once the VM is started and every single time the VM is started otherwise it would have default permissions set by libvirt.

If that functionality would have been exported by GUI, then I'd have expected one could select the path for the socket, and via that (respectively via the directory where the socket were to be created in) one could have once manually set the permissions. Cause IIRC, not all UNIXes use socket-file permissions anyway.

Ah, so even with None and FDs, other users per default could access the SPICE/VNC?

Btw, with the None, why can one still set a passphrase? I mean is it actually used (and just because of the above, to prevent other users from using the FD?)?

[phrdina]

Hmm ok.

Libvirt doesn't support setting permissions to that socket in VM XML so somebody or some script/cron/... would have to change the socket permissions once the VM is started and every single time the VM is started otherwise it would have default permissions set by libvirt.

If that functionality would have been exported by GUI, then I'd have expected one could select the path for the socket, and via that (respectively via the directory where the socket were to be created in) one could have once manually set the permissions. Cause IIRC, not all UNIXes use socket-file permissions anyway.

And exactly that need to do manual steps is usually the sign why it is not a good feature for UI part of virt-manager.

Ah, so even with None and FDs, other users per default could access the SPICE/VNC?

Only in some cases. If you are using system libvirt (qemu:///system) you usually need to be part of libvirt group or be able to use sudo in order to access that libvirt and create VMs there as it is running under root. If there are multiple users able to use system connection they can control all VMs by default unless it is restricted configuring polkit for libvirt.

If you are using user session libvirt (qemu:///session) that daemon is running under your user so usually only you and root can access that libvirt.

Btw, with the None, why can one still set a passphrase? I mean is it actually used (and just because of the above, to prevent other users from using the FD?)?

Nobody added code into libvirt that would reject this combination. It is probably useless because if some other user can open graphics using FD and no polkit is configured that user will be able to get VM XML with the password in readable form.