Re: [Spice-devel] RFC [spice-gtk] session: Allow to delay sending clipboard to the guest
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.
I'd lean towards doing "clipboard sharing for focused client" +
"command-line/runtime option, with clipboard sharing enabled by
default".
Christophe
signature.asc
Description: PGP signature
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] RFC [spice-gtk] session: Allow to delay sending clipboard to the guest
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.
>
> 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.
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] RFC [spice-gtk] session: Allow to delay sending clipboard to the guest
>
> 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 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
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] RFC [spice-gtk] session: Allow to delay sending clipboard to the guest
Hi
- Original Message -
> >
> > 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 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.
Yes, disabled by default
> 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.
very marginaly (it's not the content)
> > >
> > > 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.
Disabling by default, and command line option is in spice-gtk.
Yes, a UI change is needed in the clients, but I believe that will be needed
anyway to secure it.
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] RFC [spice-gtk] session: Allow to delay sending clipboard to the guest
On Fri, Jan 12, 2018 at 08:05:24AM -0500, Marc-André Lureau wrote: > > Is it really a security reason the clipboard behaviour is different on > Wayland? I don't know the reason for this behaviour, for me this is similar to preventing applications from capturing the whole screen. https://wiki.x.org/wiki/Events/XDC2014/XDC2014DodierPeresSecurity/xorg-talk.pdf has a slide with "Some common GUI requirements are un-secure by design • Clipboard monitoring" so at least some people wanted to fix some security problems in xorg clipboard implementation. > For me, this "share on focus" is not a more secure behaviour. "VM can monitor everything which goes in your clipboard while you are not using it" VS "VM can get what is in your clipboard when you switch to it" sounds more secure to me, even if not perfect. Christophe signature.asc Description: PGP signature ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Strange issue with PhotoShop 6
> > Hi, > trying the lazzo issue I find this issue: > > https://www.youtube.com/watch?v=fzCo6gxKLyA > > Note that the problem does not disappear if you close and open (you can still > see the garbage on the screen). Also a printscreen inside the VM (so paste > on mspaint for instance) present the garbage so is not surely a compression > or server->client error (the corruption seems on the frame buffer too). > Using a standard VGA (same VM) the problem does not appear. > I recorded (SPICE_WORKER_RECORD_FILENAME) the screen and the problem happens > also doing a replay (I can post the file, is only 17MB compressed with xz). > The selection is made with a dotted line and a XOR operation (you can see > clearly using an image, the video used a white background). > The version of Windows is 7. 32 bit display. > > Any hint? > Similar issues? > Digging on looks like Windows issues DRAW_FILL commands with: - an 8x8 32 bit pattern - xor rop operation - a (0,0) offset Also looks like this is due to the display of informations near the selected area which looks computed entirely by Windows causing the weird garbage on the next xor operation which is supposed to remove the old selection. I can suppose is a problem of the Windows driver sending wrong offsets or some miscomputation on the offset in our canvas code. Frediano ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/spice-devel
