Bug 1153368

Summary:	VNC unix sockets should be owned by the libvirt user
Product:	[Community] Virtualization Tools	Reporter:	Christoph Anton Mitterer <calestyo>
Component:	libvirt	Assignee:	Libvirt Maintainers <libvirt-maint>
Status:	CLOSED DEFERRED	QA Contact:
Severity:	low	Docs Contact:
Priority:	unspecified
Version:	unspecified	CC:	crobinso, rbalakri
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	All
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-03-21 23:14:05 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Christoph Anton Mitterer 2014-10-15 21:33:16 UTC

Hi.

For some background information respectively more detailed thoughts, please have a look at the original Debian bug about this:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764849

The scenario I'm talking about is having libvirt managing qemu VMs and virt-manager (or virt-viewer or anything else) accessing those VMs via VNC over Unix sockets.

Currently my conceptual understanding is about the following:
libvirt/d is intended to be the server-side interface for users, using a client-side interface like virt-manager/-viewer, to access/control VMs.
I.e. libvirt encapsulates qemu, which users (or their clients) shouldn't directly interact with.

Now from the configuration, libvirtd and and qemu use their own users/group for access control and for privilege separation.
In Debian this would e.g. be:
libvirt:
unix_sock_group = "libvirt"
=> the sockets for the daemon are owned by that group, thereby this is apparently intended for access control

qemu:
user = "libvirt-qemu"
group = "libvirt-qemu"
=> the qemu process runs as this user/group and the images are owned by that owner, so this in turn is apparently intended for privilege separation

So basically one could say:
- local users/clients that want to access/control libvirtd and VMs (i.e. starting, stopping, accessing their console), should be member of the libvirt group
- local users/clients should generally not need to be member of the libvirt-qemu, especially they shouldn't have direct access rights on the VM images.

If these assumptions are still correct, then here comes the conceptual problem:

The sockets used to access VMs via VNC, are created by the qemu process (well I guess so)... at least they're owned by it.
This however means, that for a user/client to be able to access the console of a VM he needs to be member of the libvirt-qemu group, which he actually shouldn't be.

So long story short, AFAIU the concepts of libvirt's privilege separation and access control users/group,... the VNC sockets for VMs should be owned by either the same group as libvirt's sockets are created with,... or even better, by another configurable user (that should probably default to unix_sock_group of libvirtd.conf.

Cheers,
Chris.

Comment 1 Cole Robinson 2016-03-21 23:14:05 UTC

Thanks for the report. Indeed there is some weirdness here. Part of the issue is is that libvirt doesn't know the client user, so it's not easy to just chown this as expected. However there is a libvirt API virDomainOpenGraphicsFD which allows apps to connect to a local qemu's graphic display, brokered by libvirt. So in this case the permissions of the unix socket don't matter.

virt-viewer supports it with the -a option, and there's patches posted for virt-manager. See https://bugzilla.redhat.com/show_bug.cgi?id=1044021 for the virt-manager bug tracking this.

Closing this bug though because I don't think anything is going to change at the libvirt level