Bug 1043950

Summary:	gnome-boxes: local users can use SPICE connections to access other user's boxes
Product:	Red Hat Enterprise Linux 7	Reporter:	Florian Weimer <fweimer>
Component:	gnome-boxes	Assignee:	Matthias Clasen <mclasen>
Status:	CLOSED ERRATA	QA Contact:	Desktop QE <desktop-qa-list>
Severity:	medium	Docs Contact:	Lucie Vařáková <lmanasko>
Priority:	medium
Version:	7.0	CC:	cfergeau, marcandre.lureau, mclasen, modehnal, tpelka, vbenes, virt-maint
Target Milestone:	rc
Target Release:	7.3
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	gnome-boxes-3.14.3.1-8.el7	Doc Type:	Release Note
Doc Text:	Virtual machines started by GNOME Boxes are no longer accessible to every user Previously, virtual machines started by GNOME Boxes were listening on a local TCP socket. As a consequence, any user could connect to any virtual machine started by another user. A patch has been applied and GNOME Boxes no longer opens such sockets by default. As a result the virtual machines are now accessible through SPICE only to the user who owns the virtual machine.	Story Points:	---
Clone Of:	1043949	Environment:
Last Closed:	2016-11-04 04:41:56 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:
Bug Depends On:	1043949, 1328898, 1330571, 1336491
Bug Blocks:	1023462, 1040467, 1297830, 1313485

Description Florian Weimer 2013-12-17 13:46:54 UTC

Also present in gnome-boxes-3.8.3-2.el7.x86_64.

+++ This bug was initially created as a clone of Bug #1043949 +++

Boxes does not prevent other local users from using the SPICE protocols to access the console of virtual machines created using gnome-boxes.

Using UNIX domain socket connections by default would be the best solution for this.  Automatically generated random passwords do not authenticate the server and allow it to be impersonated by other users because it is usually running on an untrusted port.

Verified with gnome-boxes from 3.8, but I don't think this has changed in later versions.

Comment 2 Zeeshan Ali 2014-01-07 13:06:49 UTC

Oh my, quite an overlook from our side when we decided to make user's life easier by not continuously asking for password each time they connect.

Comment 3 Marc-Andre Lureau 2014-01-07 13:16:08 UTC

(In reply to Zeeshan Ali from comment #2)
> Oh my, quite an overlook from our side when we decided to make user's life
> easier by not continuously asking for password each time they connect.

that's not the problem. it should use unix socket with appropriate rights (or we would need a way to identify remote process credentials etc, but I don't think we should do that in the server)

Comment 4 Zeeshan Ali 2014-01-07 13:34:14 UTC

(In reply to Marc-Andre Lureau from comment #3)
> (In reply to Zeeshan Ali from comment #2)
> > Oh my, quite an overlook from our side when we decided to make user's life
> > easier by not continuously asking for password each time they connect.
> 
> that's not the problem.

Sorry, wasn't implying that this decision was itself the problem but we overlooked this issue when made that decision and implemented it.

Comment 7 Vladimir Benes 2015-05-06 09:52:02 UTC

Still present in 3.14.3. Rising severity.

Comment 8 Zeeshan Ali 2015-05-18 12:19:56 UTC

This has only been fixed in 3.16 with latest spice release. We'll have to backport those patches I guess. BTW, most of the fix is in spice-gtk and libvirt. do we have the following releases in RHEL 7.2?

spice-gtk >= 0.3
libvirt >= 1.2.8

Comment 9 Florian Weimer 2015-05-18 14:37:06 UTC

(In reply to Zeeshan Ali from comment #8)
> This has only been fixed in 3.16 with latest spice release. We'll have to
> backport those patches I guess. BTW, most of the fix is in spice-gtk and
> libvirt. do we have the following releases in RHEL 7.2?
> 
> spice-gtk >= 0.3
> libvirt >= 1.2.8

The latest 7.2 compose has only spice-gtk3, not spice-gtk.  The versions for these packages are higher, though.

Comment 10 Zeeshan Ali 2015-05-29 18:20:37 UTC

(In reply to Florian Weimer from comment #9)
> (In reply to Zeeshan Ali from comment #8)
> > This has only been fixed in 3.16 with latest spice release. We'll have to
> > backport those patches I guess. BTW, most of the fix is in spice-gtk and
> > libvirt. do we have the following releases in RHEL 7.2?
> > 
> > spice-gtk >= 0.3
> > libvirt >= 1.2.8
> 
> The latest 7.2 compose has only spice-gtk3, not spice-gtk.  The versions for
> these packages are higher, though.

Awesome. I'm confident backporting the gnome-boxes patches won't be an issue but unfortunately the changes reveal a bug in spice-gtk that completely breaks usb-redirection. The fix is in spice-gtk git master for a while now though so its about releasing and backporting from their side. I guess I can open a bug on spice-gtk for that after backporting gnome-boxes patches for this issue..

Comment 11 Christophe Fergeau 2015-06-01 09:41:12 UTC

(In reply to Zeeshan Ali from comment #10)
> The fix is in spice-gtk git master for a while now
> though so its about releasing and backporting from their side. I guess I can
> open a bug on spice-gtk for that after backporting gnome-boxes patches for
> this issue..

Better to open the spice-gtk bug sooner rather than later so that people are aware of your needs and can plan for a fixed spice-gtk build. Not much point for you to do the backport if the spice-gtk package can't get the needed patches in time for one reason or another.

Comment 12 Zeeshan Ali 2016-02-01 12:45:34 UTC

(In reply to Christophe Fergeau from comment #11)
> (In reply to Zeeshan Ali from comment #10)
> > The fix is in spice-gtk git master for a while now
> > though so its about releasing and backporting from their side. I guess I can
> > open a bug on spice-gtk for that after backporting gnome-boxes patches for
> > this issue..
> 
> Better to open the spice-gtk bug sooner rather than later so that people are
> aware of your needs and can plan for a fixed spice-gtk build. Not much point
> for you to do the backport if the spice-gtk package can't get the needed
> patches in time for one reason or another.

Sorry to have forgotten about this but by now spice-gtk has been released and this feature was part of Fedora 23 already. Has the spice-gtk release/patches been pushed to RHEL 7.2 or 7.3 already? i-e Do I still need to file a bug on spice-gtk for this?

Comment 13 Christophe Fergeau 2016-02-01 16:14:06 UTC

spice-gtk in rhel 7.2 is spice-gtk-0.26-5.el7, if that's new enough for your needs, then you're all set.
If that's not a new enough version, I don't know whether spice-gtk will be rebased in 7.3 or not, so in this case, better to open a bug for the specific feature (+ fixes) that you need.

Comment 14 Zeeshan Ali 2016-04-22 16:38:01 UTC

Actually we'll need to port one patch to libvirt-glib as well:

commit: fbb7dbe42c5bc47b32298d7d13d37ac1dc8c96b9

    Add gvir_domain_open_graphics_fd()
    
    Add binding for virDomainOpenGraphicsFD. If virDomainOpenGraphicsFD is
    not available, it means we are dealing with older libvirt so we create
    the socket pair ourselves if that is the case.

---

I can do that as part of the same errata as Boxes patches so don't see the need to file a separate bug for this.

Comment 15 Christophe Fergeau 2016-04-25 08:14:19 UTC

(In reply to Zeeshan Ali from comment #14)
> I can do that as part of the same errata as Boxes patches so don't see the
> need to file a separate bug for this.

You need an additional bug for the 3ack process regarding the libvirt-glib build you will make. Ie not needed for errata, but needed for push to dist-git/pm and qa tracking purposes, ...

Comment 20 Matthias Clasen 2016-06-20 13:27:51 UTC

The qemu-kvm fix is now included

Comment 24 Tomas Pelka 2016-08-19 09:39:15 UTC

Verified with 
gnome-boxes-3.14.3.1-10.el7
qemu-kvm-1.5.3-121.el7
libvirt-daemon-2.0.0-5.el7
spice-gtk-0.31-5.el7

Comment 29 errata-xmlrpc 2016-11-04 04:41:56 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2016-2367.html