[Spice-devel] RFC [spice-gtk] session: Allow to delay sending clipboard to the guest

Frediano Ziglio fziglio at redhat.com
Fri Jan 12 13:22:47 UTC 2018


> 
> Hi
> 
> ----- Original Message -----
> > On Thu, Jan 11, 2018 at 12:35:36PM -0500, Marc-André Lureau wrote:
> > > > I agree with you that some help from the windowing/toolkit would be
> > > > good
> > > > to have, but in this case, I doubt we are going to be able to do better
> > > > than managing this in spice-gtk.
> > > 
> > > Yet it is already being solved at a lower level, where you can actually
> > > enforce that behaviour.
> > 
> > Yes, it is solved with wayland. The question I'm asking/the problem I'm
> > trying to solve is what do we do for existing systems using Xorg and
> > gtk+3. With Xorg being phased out (which will still take a few years),
> > and gtk+3 being phased out (again, will take at least a few years), I
> > don't see this kind of clipboard behaviour changes going into either of
> > these. Maybe I'm wrong, but assuming I'm not, then either we fix it
> > ("it" being xorg + gtk3) in spice-gtk even though that's not the best
> > place, or we don't fix it at all.
> > 
> > If we decide to do something in spice-gtk, one option is to only send
> > the clipboard when the window is focused, which will reduce the attack
> > surface for everyone, and hopefully will have minimal impact.
> > Another option (which is not exclusive) is to add command-line/runtime
> > ways of enabling/disabling clipboard sharing, which you will either have
> > to know about it if it's enabled by default, or will be quite disruptive
> > if we disable clipboard sharing by default.
> 
> Is it really a security reason the clipboard behaviour is different on
> Wayland? For me, this "share on focus" is not a more secure behaviour.
> 

The bug report explains in more detail the use case.
Is describing an administrator user with different client opened sometimes
having to copy&paste some password with tools like keepass.
These tools usually clear the clipboard after some time.
Yes, in this case the user would be better not to be connected to VMs
and surely having clipboard support disabled is safer but for security
clipboard should be disable by default, not with an option.
Considering that this is considered low impact a workaround like the
focus limitation is enough.
One more good thing also about the focus limitation is that if you
keep multiple VM connected but you don't interact with them you
don't send clipboard messages potentially reducing th network usage.

> > 
> > I'd lean towards doing "clipboard sharing for focused client" +
> > "command-line/runtime option, with clipboard sharing enabled by
> > default".
> 
> I'd rather stick with a simple command-line & runtime option.

Not so simple considering that you have to patch different tools
(boxes, virt-manager, virt-viewer) while just changing spice-gtk
would be a single patch.

Frediano


More information about the Spice-devel mailing list