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

[Frediano Ziglio]

> 
> Hi
> 
> ----- Original Message -----
> > On Tue, Jan 09, 2018 at 11:08:44AM -0500, Marc-André Lureau wrote:
> > > ----- Original Message -----
> > > > 
> > > > What makes spice different here is that it's used to access a VM, and a
> > > > VM is supposed to give you isolation. If some hostile code is running
> > > > in
> > > > the VM, its impact on the host/client OS should be minimal. The fact
> > > > that a VM with an open client connection can monitor everything that
> > > > goes in the clipboard breaks that isolation. For example, I have a ton
> > > > of password going through my clipboard, which I don't necessarily want
> > > > VM to have direct access to.
> > > 
> > > Spice isn't that tied to the VM or isolation concept. It's a remote
> > > display protocol, aiming to blur the lines between remote and locate
> > > applications or desktop. As such, it's not that different from say,
> > > the X protocol or the Wayland protocol...
> > 
> > In theory it's not tied to VMs, in practice, 90% of the time (and I'm
> > being conservative) it's used to access VMs.
> > 
> > > > > I am not that familiar with Wayland clipboard behaviour, could you
> > > > > explained what changed? That could help me to understand this patch
> > > > > better.
> > > > 
> > > > I'll detail this in the commit log, but if you try the 'watch' command
> > > > from above in a VM, then copy something to your clipboard on the
> > > > client,
> > > > you'll notice that the clipboard content shows up in the VM only after
> > > > you give it focus. In a way, this answers your "this shouldn't be
> > > > solved
> > > > at the spice/spice-gtk level" concern, and this was indeed solved at a
> > > > different level. However, we still have the issue on x11 for now.
> > > 
> > > Ok, but then I think we should accept the fact that this is a x11
> > > "limitation", like many others x11 security issues. If not, try to fix
> > > it at a different level, like the toolkit.
> > 
> > For most applications using gtk+, this really is a non-issue, or
> > something not really important, so it does not really make sense to do
> > that at the gtk+ level. spice on the other hand takes local clipboard
> > data, and forwards it remotely, so I think it makes sense that it's
> > careful with what it does with it.
> 
> I think it's problematic for traditional applications as well. clipboard
> access is probably going to be limited by default and only accessed through
> so-called "portals", just like file access etc. This topic should be brought
> on desktop / flatpak mailing list.
> 
> Thus I don't believe the problem should be solved at spice-gtk level, as this
> can potentially break some use cases, like clipboard managers running in the
> guest etc

This patch is solving guest <-> client issue, I doubt portals would address this
so I think only spice-gtk can address it. The agent could do something but the
agent is controlled by the guest so cannot protect client data.

On the implementation I didn't have a deep look but saving data from clipboard
to later usage seems really wrong. I don't know how clipboard works on Unix or
GTK but on Windows data copies are done (or can be done) lazily to avoid huge
copies or optimize some cases (for instance same app c&p or avoiding useless
conversions). I would just save which clipboards were changed during out of
focus (so kind of some bools variable) and tell the guest the change when we
receive the focus. Can't we do it?

Frediano