GNOME Bugzilla – Bug 667593
RFE: no need for a spice password for local boxes
Last modified: 2016-03-31 13:58:54 UTC
When creating a local box there is no added security by using a spice password to authenticate the spice client (spice-gtk in boxes) to the spice server (in qemu). Removing this would simplify the code probably, and remove a false sense of added security. However, there are two issues that should also be address: 1. spice-server should only listen to localhost - I think this is probably already addressed, not sure so listing this here. 2. Other users shouldn't be able to connect on the same machine. To achieve this one of two options can be done: 1. the soon to be merged (I hope) patchset to allow spice-server to accept an fd from a monitor command (http://lists.freedesktop.org/archives/spice-devel/2011-October/005834.html) 2. teach spice-server to create a unix domain socket and spice-gtk to connect to it.
(In reply to comment #0) > When creating a local box there is no added security by using a spice password > to authenticate the spice client (spice-gtk in boxes) to the spice server (in > qemu). Removing this would simplify the code probably, and remove a false sense > of added security. Only if the user chose a password for the account/VM (right?). > However, there are two issues that should also be address: > 1. spice-server should only listen to localhost - I think this is probably > already addressed, not sure so listing this here. Not really, we have a function that is not implemented that should allow VMs to be "shared". Although I don't know what it means exactly. > 2. Other users shouldn't be able to connect on the same machine. To achieve > this one of two options can be done: > 1. the soon to be merged (I hope) patchset to allow spice-server to accept an > fd from a monitor command just pushed (I ran a few tests this afternoon before pushing) > 2. teach spice-server to create a unix domain socket and spice-gtk to connect > to it. Isn't this handled by libvirt now? I suppose Daniel know.
Adding Daniel for the question in last comment (i-e the only remaining issue).
(In reply to comment #2) > Adding Daniel for the question in last comment (i-e the only remaining issue). Sent him a mail to get his attention. :)
(In reply to comment #1) > (In reply to comment #0) > > When creating a local box there is no added security by using a spice password > > to authenticate the spice client (spice-gtk in boxes) to the spice server (in > > qemu). Removing this would simplify the code probably, and remove a false sense > > of added security. > > Only if the user chose a password for the account/VM (right?). > > > However, there are two issues that should also be address: > > 1. spice-server should only listen to localhost - I think this is probably > > already addressed, not sure so listing this here. > > Not really, we have a function that is not implemented that should allow VMs to > be "shared". Although I don't know what it means exactly. > > > 2. Other users shouldn't be able to connect on the same machine. To achieve > > this one of two options can be done: > > 1. the soon to be merged (I hope) patchset to allow spice-server to accept an > > fd from a monitor command > > just pushed (I ran a few tests this afternoon before pushing) > > > 2. teach spice-server to create a unix domain socket and spice-gtk to connect > > to it. > > Isn't this handled by libvirt now? I suppose Daniel know. I don't believe you can specify a UNIX domain socket for SPICE. There is, however, a libvirt API virDomainOpenGraphics which lets you connect to SPICE using file descriptor passing which lets you bypass authentication. So you can configure SPICE with auth on TCP as normal, and still have password-less connections locally. Virt-viewer already supports this if you want a reference impl to look at.
Actually things have changed quite a bit since this bug was filed. We don't setup password on spice connection at all. However, this also means that anyone on the localhost can connect to your displays. :( For most hosts out there, this wont be a real issue but for multi-seat hosts, its good to be a serious security issue. So we really need ability to connect to SPICE through a private (to user) mechanism. However, I believe thats a different/new issue and I believe the main point of this bug has already be resolved. I created a new bug for spice connection issue: bug#738573.