[RFC] centralized triggering of copy/paste shortcuts

[Jean-Philippe Ouellet]

Copying text from dom0 to the qubes clipboard is not currently easy,
but this appears only due to implementation details instead of a
conscious design decision. Pasting things *into* dom0 is obviously
potentially dangerous, and I argue that having no easy mechanism to do
so is a good thing. However I see nothing dangerous with the other
direction (dom0 -> domU).

The ability to do so would (among other things) ease the reporting of
errors, e.g. https://github.com/QubesOS/qubes-issues/issues/2438

Currently the Ctrl+Shift+{C,V} shotcuts are implemented in the dom0 X
side of gui-daemon. There is an instance of the gui-daemon process for
each VM, and each separately listens for the Ctrl+Shift+{C,V}
shortcuts when they are in focus. Adding a global keyboard shortcut to
copy from dom0 X clipboard to qubes clipboard would catch all
Ctrl+Shift+C keypresses, breaking copy from VMs (as gui-daemon would
never see the keypress).

Having a single global catcher of the keyboard shortcut would allow us to:
- if a gui-daemon has focus: notify that gui-daemon to perform copying
- if no gui-daemon has focus (some dom0 window does): copy dom0
clipboard to qubes clipboard

I would like feedback on:
1) Is dom0->other copying (not the other direction) something we even want?
2) The best way to detect which (if any) gui-daemon has focus?
3) The best way to tell the gui-daemon process to perform copying?

My thoughts:
1) seems useful and in no way dangerous to me
2) perhaps checking _QUBES_VMNAME of root window's _NET_ACTIVE_WINDOW?
(note that this may produce incorrect results in case of windows not
decorated with full title bar (e.g. some pop-ups, drop-downs,
nm-applet, etc.) There's gotta be a better way...
3) SIGUSR1? dbus? some X thing?

[Jean-Philippe Ouellet]

Cross-linking for better archives:
https://github.com/QubesOS/qubes-issues/issues/2450

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Wed, Nov 23, 2016 at 05:20:36PM -0500, Jean-Philippe Ouellet wrote:
> Copying text from dom0 to the qubes clipboard is not currently easy,
> but this appears only due to implementation details instead of a
> conscious design decision. Pasting things *into* dom0 is obviously
> potentially dangerous, and I argue that having no easy mechanism to do
> so is a good thing. However I see nothing dangerous with the other
> direction (dom0 -> domU).
>
> The ability to do so would (among other things) ease the reporting of
> errors, e.g. https://github.com/QubesOS/qubes-issues/issues/2438
>
> Currently the Ctrl+Shift+{C,V} shotcuts are implemented in the dom0 X
> side of gui-daemon. There is an instance of the gui-daemon process for
> each VM, and each separately listens for the Ctrl+Shift+{C,V}
> shortcuts when they are in focus. Adding a global keyboard shortcut to
> copy from dom0 X clipboard to qubes clipboard would catch all
> Ctrl+Shift+C keypresses, breaking copy from VMs (as gui-daemon would
> never see the keypress).
>
> Having a single global catcher of the keyboard shortcut would allow us to:
> - if a gui-daemon has focus: notify that gui-daemon to perform copying
> - if no gui-daemon has focus (some dom0 window does): copy dom0
> clipboard to qubes clipboard
>
> I would like feedback on:
> 1) Is dom0->other copying (not the other direction) something we even want?

Yes. Of course with explicit user consent.

> 2) The best way to detect which (if any) gui-daemon has focus?
> 3) The best way to tell the gui-daemon process to perform copying?

Those two things may be tricky in practice, to not introduce any race
condition...

> My thoughts:
> 1) seems useful and in no way dangerous to me
> 2) perhaps checking _QUBES_VMNAME of root window's _NET_ACTIVE_WINDOW?
> (note that this may produce incorrect results in case of windows not
> decorated with full title bar (e.g. some pop-ups, drop-downs,
> nm-applet, etc.) There's gotta be a better way...

_QUBES_VMNAME of window pointed by XGetInputFocus()?

> 3) SIGUSR1? dbus? some X thing?

Maybe inject the key back to that window? Like XSendEvent or so.

Another idea: have some window "paste here to send to inter-VM clipboard".
(Much) Less convenient, but easier to implement (including smaller risk of some
race condition, or another not obvious interaction with other
applications). This can be made available from some tray icon (the one
of qubes manager?).

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJYNh3lAAoJENuP0xzK19csL2EH/jQLueCDnAdrN1ME3gfilxEA
tO4AHOZYsRp9zQRofxPF4Mb/Vih/SZtr1qLXh4iiR0h24uX89gMpMZLCjcSUpEXW
AjkzSnamUES+XHzVAeTMCAbEMPcQNN1AAbs6YyP3m6iRqx+4EFNqTZRMe/acwdnK
2aswxAEIygK6JQUdIGC74FwojH+oxuvlCYlyDgSkjYv69BMJiRUNWhKGL8klVB8h
UwsVt0pcaUiNwfy2yzPlk34vYzqhY5Pd6/lYXWY0nI1GkMvsnKEhDFrRqVo/B3uC
d8fx6BG4SjOWW8YYIEkz6+YNsb0cuP6Jr3ome2FoQTcA+4TvwKKEvPdt8XpZZv8=
=XJ6o
-----END PGP SIGNATURE-----

[Jean-Philippe Ouellet]

On Wed, Nov 23, 2016 at 5:53 PM, Marek Marczykowski-Górecki
<marm...@invisiblethingslab.com> wrote:
>> I would like feedback on:
>> 1) Is dom0->other copying (not the other direction) something we even want?
>
> Yes. Of course with explicit user consent.

I believe a keyboard shortcut triggered in dom0 is a trustworthy
indication of this. No?

>> 2) The best way to detect which (if any) gui-daemon has focus?
>> 3) The best way to tell the gui-daemon process to perform copying?
>
> Those two things may be tricky in practice, to not introduce any race
> condition...

Yes, needs more thought.

AFAICT the sequence of events we wish to be atomic here is:
1) user observes a certain window on the screen having focus
2) user presses copy-to-qubes-clipboard shortcut
3) shortcut is somewhere caught
4) current focus is determined
5) gui-daemon for corresponding VM is instructed to set qubes-clipboard

It seems to me that the only exploit for such races would be
focus-stealing attacks.

I understand your concern that this would likely add an additional
race between steps 3 and 5, but there is already a race between 1 and
2 which can not be eliminated (human delay).

It seems to me the solution of both race 3-5 and the already-existing
race 1-2 is focus-stealing prevention.

Therefore, considering this does not change the state of existence of
a race in window 1-5 (which is what a user cares about), and the
solution to this race and the existing race are the same, it appears
to me that the proposed change does not have any meaningful increase
of risk.

I welcome any/all challenge of this analysis.

I also have thoughts on how to mitigate focus-stealing attacks, but
those are for a separate proposal once I have a PoC.

>> My thoughts:
>> 1) seems useful and in no way dangerous to me
>> 2) perhaps checking _QUBES_VMNAME of root window's _NET_ACTIVE_WINDOW?
>> (note that this may produce incorrect results in case of windows not
>> decorated with full title bar (e.g. some pop-ups, drop-downs,
>> nm-applet, etc.) There's gotta be a better way...
>
> _QUBES_VMNAME of window pointed by XGetInputFocus()?

Fantastic! I still have yet to get around to learning X protocols/api.
I now have some scripts to go update :)

>> 3) SIGUSR1? dbus? some X thing?
>
> Maybe inject the key back to that window? Like XSendEvent or so.

Then we either to either parse guid.conf by two programs, or need to
rely on the keyboard shortcut default not being changed. I think
neither is ideal, and some mechanism that more clearly communicates
intent rather than relying on interpretation of "magic constant"
keyboard shortcuts to be preferable.

> Another idea: have some window "paste here to send to inter-VM clipboard".
> (Much) Less convenient, but easier to implement (including smaller risk of some
> race condition, or another not obvious interaction with other
> applications). This can be made available from some tray icon (the one
> of qubes manager?).

This sounds safe(r), and I like safe :)

Downside is inconsistent UX which appears rather silly and dumb to
users not understanding the rationale.

I'd like to solve this cleanly if possible.

[Jean-Philippe Ouellet]

If we take this appraoch, we would not actually need a "paste here to
send to inter-VM clipboard" window, simply clicking a qubes tray menu
item to copy write current dom0 clipboard should be sufficient.

Also, regardless of how we end up having dom0 write to the clipboard,
it appears to me that it should take appviewer.lock (see gui-daemon)
while manipulating /var/run/qubes-clipboard.*. This suggests to me
that perhaps we should factor the clipboard-file manipulation out of
gui-daemon's xside.c into some other thing to be shared between both
dom0 writer & gui-daemon.

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Wed, Nov 23, 2016 at 06:29:40PM -0500, Jean-Philippe Ouellet wrote:
> On Wed, Nov 23, 2016 at 5:53 PM, Marek Marczykowski-Górecki
> <marm...@invisiblethingslab.com> wrote:
> >> I would like feedback on:
> >> 1) Is dom0->other copying (not the other direction) something we even want?
> >
> > Yes. Of course with explicit user consent.
>
> I believe a keyboard shortcut triggered in dom0 is a trustworthy
> indication of this. No?

Yes, it is. Just stressing it out.

> >> 2) The best way to detect which (if any) gui-daemon has focus?
> >> 3) The best way to tell the gui-daemon process to perform copying?
> >
> > Those two things may be tricky in practice, to not introduce any race
> > condition...
>
> Yes, needs more thought.
>
> AFAICT the sequence of events we wish to be atomic here is:
> 1) user observes a certain window on the screen having focus
> 2) user presses copy-to-qubes-clipboard shortcut
> 3) shortcut is somewhere caught
> 4) current focus is determined
> 5) gui-daemon for corresponding VM is instructed to set qubes-clipboard
>
> It seems to me that the only exploit for such races would be
> focus-stealing attacks.
>
> I understand your concern that this would likely add an additional
> race between steps 3 and 5, but there is already a race between 1 and
> 2 which can not be eliminated (human delay).
>
> It seems to me the solution of both race 3-5 and the already-existing
> race 1-2 is focus-stealing prevention.
>
> Therefore, considering this does not change the state of existence of
> a race in window 1-5 (which is what a user cares about), and the
> solution to this race and the existing race are the same, it appears
> to me that the proposed change does not have any meaningful increase
> of risk.
>
> I welcome any/all challenge of this analysis.

The race between 1-2 (or even 1-3) is invisible to the system. Unlike
3-5. The sequence may be:

1-4 - as above
4a - focus is changed, potentially some other action happen here
5 - as above

This will result in instructing gui-daemon to copy clipboard even though
it does not have focus right now (and know about it already). This may
result in some weird corner cases I can't think about right now. And
generally asynchronously delaying processing of this particular key
shortcut may result in "interesting" situations.

Oh, one example:
1. Focus some VM
2. Press Ctrl-Shift-C, then immediately Ctrl-Shift-V, without changing
focus.

Normally it would be guaranteed that Ctrl-Shift-C is processed before
Ctrl-Shift-V, so VM clipboard content is unchanged in the end (gets
replaced with data extracted from this very VM). But if Ctrl-Shift-C got
delayed enough, then Ctrl-Shift-V is processed before actually copying
clipboard (using whatever method). So in the end, VM clipboard will be
replaced with previous content of inter-VM clipboard (if any). Very
similar problem, for the case of different VMs was fixed here:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-013-2015.txt

I recommend reading it thoroughly, maybe it will inspire some other
problems, or some solution.

> I also have thoughts on how to mitigate focus-stealing attacks, but
> those are for a separate proposal once I have a PoC.
>
> >> My thoughts:
> >> 1) seems useful and in no way dangerous to me
> >> 2) perhaps checking _QUBES_VMNAME of root window's _NET_ACTIVE_WINDOW?
> >> (note that this may produce incorrect results in case of windows not
> >> decorated with full title bar (e.g. some pop-ups, drop-downs,
> >> nm-applet, etc.) There's gotta be a better way...
> >
> > _QUBES_VMNAME of window pointed by XGetInputFocus()?
>
> Fantastic! I still have yet to get around to learning X protocols/api.
> I now have some scripts to go update :)
>
> >> 3) SIGUSR1? dbus? some X thing?
> >
> > Maybe inject the key back to that window? Like XSendEvent or so.
>
> Then we either to either parse guid.conf by two programs, or need to
> rely on the keyboard shortcut default not being changed. I think
> neither is ideal, and some mechanism that more clearly communicates
> intent rather than relying on interpretation of "magic constant"
> keyboard shortcuts to be preferable.

Maybe I'm missing some implementation detail, but doesn't the tool know
with which sequence it was triggered? Can't it just replay what was
intercepted (whatever it was)?

> > Another idea: have some window "paste here to send to inter-VM clipboard".
> > (Much) Less convenient, but easier to implement (including smaller risk of some
> > race condition, or another not obvious interaction with other
> > applications). This can be made available from some tray icon (the one
> > of qubes manager?).
>
> This sounds safe(r), and I like safe :)
>
> Downside is inconsistent UX which appears rather silly and dumb to
> users not understanding the rationale.

Maybe, that could be combined with some dedicated indicator about that
clipboard in general - like from which VM the current content is?
But still the UX would be inconsistent...

> I'd like to solve this cleanly if possible.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJYNjGvAAoJENuP0xzK19csr0gH/2FpRp19KsCXY63aoIU+Nn9O
JtaN2PICBKk5h6qObqYECgZJbH2uvyKCh0Bs5jKSxvh97j8YauKA016MR5jTOmP3
Vi/gtm3vuL2hHKDbKXdGdJ+qxq1ZXSsMKPTOgggCxu1QPjFb0QUoHRjbybOpI0k1
EAE4jJ10dIP8YXjWSM5NcUtouof97LVLSytyyDMBus8j1QJqVHPIfkpoGEnYCX4u
18qDlWlXBCbKEEKf9BPPQhCwpVAey3kGcqqF/uVHTmwCiF9dv3/LB1bXcl+Uq1C5
dsSaf8usdJEsBxKVp11m0cziSDjO8EOJn/I/G8+oCI0U3nKouH6S5qKujTfk1pw=
=KrhN
-----END PGP SIGNATURE-----

[HW42]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Marek Marczykowski-Górecki:

> On Wed, Nov 23, 2016 at 06:29:40PM -0500, Jean-Philippe Ouellet wrote:
>> On Wed, Nov 23, 2016 at 5:53 PM, Marek Marczykowski-Górecki
>> <marm...@invisiblethingslab.com> wrote:

>>>> I would like feedback on:
>>>> 1) Is dom0->other copying (not the other direction) something we even want?
>>>
>>> Yes. Of course with explicit user consent.
>
>> I believe a keyboard shortcut triggered in dom0 is a trustworthy
>> indication of this. No?
>

> Yes, it is. Just stressing it out.
>

>>>> 2) The best way to detect which (if any) gui-daemon has focus?
>>>> 3) The best way to tell the gui-daemon process to perform copying?
>>>
>>> Those two things may be tricky in practice, to not introduce any race
>>> condition...
>
>> Yes, needs more thought.
>
>> AFAICT the sequence of events we wish to be atomic here is:
>> 1) user observes a certain window on the screen having focus
>> 2) user presses copy-to-qubes-clipboard shortcut
>> 3) shortcut is somewhere caught
>> 4) current focus is determined
>> 5) gui-daemon for corresponding VM is instructed to set qubes-clipboard
>
>> It seems to me that the only exploit for such races would be
>> focus-stealing attacks.
>
>> I understand your concern that this would likely add an additional
>> race between steps 3 and 5, but there is already a race between 1 and
>> 2 which can not be eliminated (human delay).
>
>> It seems to me the solution of both race 3-5 and the already-existing
>> race 1-2 is focus-stealing prevention.
>
>> Therefore, considering this does not change the state of existence of
>> a race in window 1-5 (which is what a user cares about), and the
>> solution to this race and the existing race are the same, it appears
>> to me that the proposed change does not have any meaningful increase
>> of risk.
>
>> I welcome any/all challenge of this analysis.
>

> The race between 1-2 (or even 1-3) is invisible to the system. Unlike
> 3-5. The sequence may be:
>
> 1-4 - as above
> 4a - focus is changed, potentially some other action happen here
> 5 - as above
>
> This will result in instructing gui-daemon to copy clipboard even though
> it does not have focus right now (and know about it already). This may
> result in some weird corner cases I can't think about right now. And
> generally asynchronously delaying processing of this particular key
> shortcut may result in "interesting" situations.
>
> Oh, one example:
> 1. Focus some VM
> 2. Press Ctrl-Shift-C, then immediately Ctrl-Shift-V, without changing
> focus.
>
> Normally it would be guaranteed that Ctrl-Shift-C is processed before
> Ctrl-Shift-V, so VM clipboard content is unchanged in the end (gets
> replaced with data extracted from this very VM). But if Ctrl-Shift-C got
> delayed enough, then Ctrl-Shift-V is processed before actually copying
> clipboard (using whatever method). So in the end, VM clipboard will be
> replaced with previous content of inter-VM clipboard (if any). Very
> similar problem, for the case of different VMs was fixed here:
> https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-013-2015.txt
>
> I recommend reading it thoroughly, maybe it will inspire some other
> problems, or some solution.
>

>> I also have thoughts on how to mitigate focus-stealing attacks, but
>> those are for a separate proposal once I have a PoC.
>
>>>> My thoughts:
>>>> 1) seems useful and in no way dangerous to me
>>>> 2) perhaps checking _QUBES_VMNAME of root window's _NET_ACTIVE_WINDOW?
>>>> (note that this may produce incorrect results in case of windows not
>>>> decorated with full title bar (e.g. some pop-ups, drop-downs,
>>>> nm-applet, etc.) There's gotta be a better way...
>>>
>>> _QUBES_VMNAME of window pointed by XGetInputFocus()?
>
>> Fantastic! I still have yet to get around to learning X protocols/api.
>> I now have some scripts to go update :)
>
>>>> 3) SIGUSR1? dbus? some X thing?
>>>
>>> Maybe inject the key back to that window? Like XSendEvent or so.
>
>> Then we either to either parse guid.conf by two programs, or need to
>> rely on the keyboard shortcut default not being changed. I think
>> neither is ideal, and some mechanism that more clearly communicates
>> intent rather than relying on interpretation of "magic constant"
>> keyboard shortcuts to be preferable.
>

> Maybe I'm missing some implementation detail, but doesn't the tool know
> with which sequence it was triggered? Can't it just replay what was
> intercepted (whatever it was)?
>

>>> Another idea: have some window "paste here to send to inter-VM clipboard".
>>> (Much) Less convenient, but easier to implement (including smaller risk of some
>>> race condition, or another not obvious interaction with other
>>> applications). This can be made available from some tray icon (the one
>>> of qubes manager?).
>
>> This sounds safe(r), and I like safe :)
>

>> Downside is inconsistent UX which appears rather silly and dumb to
>> users not understanding the rationale.
>

> Maybe, that could be combined with some dedicated indicator about that
> clipboard in general - like from which VM the current content is?
> But still the UX would be inconsistent...
>

>> I'd like to solve this cleanly if possible.

Another option is to take Jean-Philippe's original approach a little
step further. Have a single process running in dom0 which binds to
Ctrl-Shift-{C,V}.

On a key event the focused VM is determined (like you suggested [0])
and the request is passed into a queue.

Another thread reads from this queue. On a copy request it calls
qubes.GetClipboard on the VM (with a timeout of maybe 1 s); saves the
response and shows a notification. On a paste request it calls
qubes.SetClipboard on the VM with the clipboard data (also with a short
timeout).

The rpc services are simple 'xclip' one liners.

This should be much simpler and if I'm not mistaken should ensure the
correct ordering of the requests and the correct VM association.

But maybe I'm missing some rationale for the original approach.

The only downside I see it that it first needs a VM update before dom0
can rely on the availability of the rpc services. So the R4 switch would
be a good opportunity to introduce this change.

[0]: Is the focus information not even part of the X event?
XKeyEvent.root suggest so.
-----BEGIN PGP SIGNATURE-----

iQJDBAEBCgAtFiEEqieyzvOmi9FGaQcT5KzJJ4pkaBYFAlg2OLAPHGh3NDJAaXBz
dW1qLmRlAAoJEOSsySeKZGgW1sEP/3RYgFP1rUNG9c1ALJrAIHeOCRVNrkZhuGxq
ozihpWrbfEF/e6dJjkEi6d0H8fJOUfr5J0UHK6SrAhzato6jG55sbx8v0yYRKqyV
ZNH17mEQu5WeOPtWeQrGFHgh4myNjb5I8QGi3th4hSThgFXBSw/pwNGo8oWuh1Nw
LJHuaWfMNj3yFDfePfOoDp3V2SaLRKxatCvPfMko0QYiPLg4E55VGA6fp7Ins1kE
kAhVFOv/sKRVd5od/Spa0VEuumm9fYUfNZla49WK6/wCI/SPJE37kePmAJhINqZY
NkYAJToTfHRNlw/Z0v2buXGMVpyvVC/XPbGuheScVZAc8BOlCsSRf/CEXLUdnIBh
LG98xo338dZoMHYfSGLebMeIIUNUsLl3mt7+xOKMh58KfBHrOy9OldR9t3yu0+BL
acIk5rGA13MTApKxz1hWFMk8ciWaUn5v4QguMOfxF/9XZopbW4hklqTGR0uFSam9
Fbmb1XD7uctwwdbBS3HRu9BXN7XMET8fduIXU96PrBVRQR+k012TxZCoJg9ncQTm
Bb7Rg4XdqIoPwONZgsvenlvEg7zZLujxYDq+iKf+N9aQ0D2MWLlT3i8/X1Fsjchx
2hYXeExQ2eeS/EzlP5AeeZUSrZ5f1lM99WtahJoo/ysqBB8Izc3R3zQ5TFG8HjxO
oy4LxUl/
=EAqR
-----END PGP SIGNATURE-----

[Chris Laprise]

On 11/23/2016 07:17 PM, Marek Marczykowski-Górecki wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On Wed, Nov 23, 2016 at 06:29:40PM -0500, Jean-Philippe Ouellet wrote:
>> On Wed, Nov 23, 2016 at 5:53 PM, Marek Marczykowski-Górecki
>> <marm...@invisiblethingslab.com> wrote:
>>>> I would like feedback on:
>>>> 1) Is dom0->other copying (not the other direction) something we even want?
>>> Yes. Of course with explicit user consent.
>> I believe a keyboard shortcut triggered in dom0 is a trustworthy
>> indication of this. No?
> Yes, it is. Just stressing it out.

This does sound a bit risky to me. If this existed and I had the option,
I'd turn it off.

The only semi-common use case is to transfer CLI and log output to a
domU app like TB. This makes a CLI command like 'copy-clipboard-to-vm'
attractive because the flow is more deliberate and its probably easier
to implement.

Chris

[HW42]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Chris Laprise:

> On 11/23/2016 07:17 PM, Marek Marczykowski-Górecki wrote:
>> On Wed, Nov 23, 2016 at 06:29:40PM -0500, Jean-Philippe Ouellet wrote:
>>> On Wed, Nov 23, 2016 at 5:53 PM, Marek Marczykowski-Górecki
>>> <marm...@invisiblethingslab.com> wrote:
>>>>> I would like feedback on:
>>>>> 1) Is dom0->other copying (not the other direction) something we even want?
>>>> Yes. Of course with explicit user consent.
>>> I believe a keyboard shortcut triggered in dom0 is a trustworthy
>>> indication of this. No?
>> Yes, it is. Just stressing it out.
>
> This does sound a bit risky to me. If this existed and I had the
> option, I'd turn it off.

Could you clarify why you think it's risky?
-----BEGIN PGP SIGNATURE-----

iQJDBAEBCgAtFiEEqieyzvOmi9FGaQcT5KzJJ4pkaBYFAlg2Pp0PHGh3NDJAaXBz
dW1qLmRlAAoJEOSsySeKZGgWsWkQALAKfP6pXJGe3NOvrbWSzodR3hd4xTrISqUb
obxhlSFUsDrbiZcUC07Ee56ulvXg6VVjzNa+zbxc/GzRDec7NQWxmm7vZzRKHhjv
YX7p4zgjmeOYjX7bdFxqBvaHMMGJ8zFKlPun6uXZxRmr9cIyAvS7I6z+iZ8NOd9k
dg8Diro5sXmSaAh246OV1CvdKaGP4zGPRuARRQUe/KhSV3CZRtGc9Cf8qwLiFDYp
ZuzA9Pwx0i9cSVwGbizgcuqzrF2dN61ncS067uWeGzo324RY5c/o3xBBEzV1Ke8t
wTIaRLengjGtLzSD0ghSZSCb0Ak666COa+XkUeTHAvWL+f8ZwNLcbgW1/2pLNdpR
X5q8UINKSbuIXeXeYyfLfoEFwMN2W8LUSFzPa/pvf/hRqQWy5KP5c28t1/r0+G0v
Hd5ZpEoMQQO6m7aU2D+7ZlTsP3cKl3HIqYNrRKiH7Dmv6VLFDmnb1V1wF9a8pYqd
2wNQ2Eo0eOpIXPvOT16i2oFa0k8ttjV4s3tFThMyWDKoFNya3I3DwJSxYn4vHbDl
2E15K30huijq/vxnWLmzLFj9f1fbbbStQVrXSzX4QMDqe/jwdGKMGefIFvOHnYBq
pmN+RjokIvzGqylSTSmeD35OepcqA1/cx7I69H9A0JTrcAAwyV/Ie7iRkPhRdLfg
dzYXGLJT
=uX6L
-----END PGP SIGNATURE-----

[Chris Laprise]

On 11/23/2016 08:13 PM, HW42 wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Chris Laprise:
>> On 11/23/2016 07:17 PM, Marek Marczykowski-Górecki wrote:
>>> On Wed, Nov 23, 2016 at 06:29:40PM -0500, Jean-Philippe Ouellet wrote:
>>>> On Wed, Nov 23, 2016 at 5:53 PM, Marek Marczykowski-Górecki
>>>> <marm...@invisiblethingslab.com> wrote:
>>>>>> I would like feedback on:
>>>>>> 1) Is dom0->other copying (not the other direction) something we even want?
>>>>> Yes. Of course with explicit user consent.
>>>> I believe a keyboard shortcut triggered in dom0 is a trustworthy
>>>> indication of this. No?
>>> Yes, it is. Just stressing it out.
>> This does sound a bit risky to me. If this existed and I had the
>> option, I'd turn it off.
> Could you clarify why you think it's risky?

Because a user doing config/maintenance in dom0 CLI may well be
switching back and forth to domUs (searching for howtos, etc) at the
same time they are using the dom0 clipboard to copy and paste
information between multiple dom0 windows. As it is now, I can be at
peace that Shift-Ctrl-V won't send any snippets from dom0 clipboard into
a domU.

Even if this used a special key combination, getting used to it means
there is a risk of absent-mindedly triggering it instead of a similar
domU-only function.

Chris

[HW42]

Sure there is a risk that a user copy&pastes by accident from dom0. But
why do you think that it's likely that the dom0 clipboard contains
sensitive information? I would expect that it's much more likely to
happen when somebody copies a password form a vault VM (and that's a
usage error which is very tricky to prevent).
-----BEGIN PGP SIGNATURE-----

iQJDBAEBCgAtFiEEqieyzvOmi9FGaQcT5KzJJ4pkaBYFAlg2Q/YPHGh3NDJAaXBz
dW1qLmRlAAoJEOSsySeKZGgWfVYQALGosAYV31lkQulOxVagxlylnpf8/aRfVuoA
iyudHztYHIHj3kf7XqfKRpY2p9xlHCE+NfiRgHlFSI4hDDC58ncceTw8KtBPR9f3
bFk8SzbWc18yGc6+PAgw3chUa+aU2Yu6KAwR6HO40dbXPxWCIKdF1wLe2D73iuEA
kppqWRVSnLFZn0SUHLDHR3OkATOvjPny2euOcNCVtCAQjOZlYikfsqEf6BYvJjRf
fnSxgvgHRL536ZKYktqHe+9Xs+lXmAsEcIypI+/dOFH3xeP0tb/CQpQ78lTSSLhn
Yk4803ir/8o5p8U5FV1tXedZ/BA7UeHJjgFz1hwHrDWK79b/xaCCGrqJCQw9MCK7
2CwssEV1qtdvlDlnWztwId1LwVkKakvyqj95ho7QAzA8mbxlJ3yy0Ti/B8MH1u94
2PAmdy1y8D0qQsEKJ3PFuiDelFt4hDNddQ7bYU7kiY6oShOec4LTxRZEsPuyoL6S
nCEORlMgJWuFFQx069G9hWNZED8v82UHivMSYhT0XMa622/HbkOraviSJ1swEOw2
ulWG9Z54JZukEacx6MscCMiL6HInqVKDPUltN+n/T3IBiTfhn9oeTvdNKuT1zCVR
6C4Uq8+EDDW+kctJovbGae135piKekndLROoZew+R9YpNyw0fe/9gwxb7kOVf2w9
BkURMJT5
=m0Z4
-----END PGP SIGNATURE-----

[Jean-Philippe Ouellet]

On Wed, Nov 23, 2016 at 7:47 PM, HW42 <hw...@ipsumj.de> wrote:
> Marek Marczykowski-Górecki:

>> This will result in instructing gui-daemon to copy clipboard even though
>> it does not have focus right now (and know about it already). This may
>> result in some weird corner cases I can't think about right now. And
>> generally asynchronously delaying processing of this particular key
>> shortcut may result in "interesting" situations.

See, this is why I love you guys :)

You all seem to really "get it" with respect to the relationship
between complexity and insecurity and are not over-confident in our
collective ability to think of all potential attacks when designing
systems, and explicitly account for that truth when making decisions.
I really respect that.

>> Oh, one example:
>> 1. Focus some VM
>> 2. Press Ctrl-Shift-C, then immediately Ctrl-Shift-V, without changing
>> focus.
>>
>> Normally it would be guaranteed that Ctrl-Shift-C is processed before
>> Ctrl-Shift-V, so VM clipboard content is unchanged in the end (gets
>> replaced with data extracted from this very VM). But if Ctrl-Shift-C got
>> delayed enough, then Ctrl-Shift-V is processed before actually copying
>> clipboard (using whatever method). So in the end, VM clipboard will be
>> replaced with previous content of inter-VM clipboard (if any). Very
>> similar problem, for the case of different VMs was fixed here:
>> https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-013-2015.txt
>>
>> I recommend reading it thoroughly, maybe it will inspire some other
>> problems, or some solution.

Consider me sufficiently convinced that inconsistent UI here is a
satisfactory outcome here :)

>> Maybe I'm missing some implementation detail, but doesn't the tool know
>> with which sequence it was triggered? Can't it just replay what was
>> intercepted (whatever it was)?

I was imagining using the desktop manager's built-in keyboard shortcut
providing functionality (which just exec's some binary), which in the
case of Xfce I am not aware of it being available in a non-hacky way.
AFAIK the only way is to search the shortcut config for thing matching
argv[0], and this is obviously not very robust at all.

>> Maybe, that could be combined with some dedicated indicator about that
>> clipboard in general - like from which VM the current content is?
>> But still the UX would be inconsistent...

May be desirable even out of context of this proposal, idk.

>>> I'd like to solve this cleanly if possible.
>
> Another option is to take Jean-Philippe's original approach a little
> step further. Have a single process running in dom0 which binds to
> Ctrl-Shift-{C,V}.
>
> On a key event the focused VM is determined (like you suggested [0])
> and the request is passed into a queue.
>
> Another thread reads from this queue. On a copy request it calls
> qubes.GetClipboard on the VM (with a timeout of maybe 1 s); saves the
> response and shows a notification. On a paste request it calls
> qubes.SetClipboard on the VM with the clipboard data (also with a short
> timeout).
>
> The rpc services are simple 'xclip' one liners.
>
> This should be much simpler and if I'm not mistaken should ensure the
> correct ordering of the requests and the correct VM association.

Seems correct at first to me too, but I will sit on this and try to
convince myself more strongly before agreeing.

> But maybe I'm missing some rationale for the original approach.

Not that I see. Your proposal appears to be a better solution to the
problem I am trying to solve.

[Chris Laprise]

Hardware and software configuration details can be considered sensitive.

This is not something that should be enabled by default.

Chris

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Wed, Nov 23, 2016 at 10:53:27PM -0500, Jean-Philippe Ouellet wrote:
> On Wed, Nov 23, 2016 at 7:47 PM, HW42 <hw...@ipsumj.de> wrote:
> > Marek Marczykowski-Górecki:

> >> Maybe, that could be combined with some dedicated indicator about that
> >> clipboard in general - like from which VM the current content is?
> >> But still the UX would be inconsistent...
>
> May be desirable even out of context of this proposal, idk.
>
> >>> I'd like to solve this cleanly if possible.
> >
> > Another option is to take Jean-Philippe's original approach a little
> > step further. Have a single process running in dom0 which binds to
> > Ctrl-Shift-{C,V}.
> >
> > On a key event the focused VM is determined (like you suggested [0])
> > and the request is passed into a queue.
> >
> > Another thread reads from this queue. On a copy request it calls
> > qubes.GetClipboard on the VM (with a timeout of maybe 1 s); saves the
> > response and shows a notification. On a paste request it calls
> > qubes.SetClipboard on the VM with the clipboard data (also with a short
> > timeout).
> >
> > The rpc services are simple 'xclip' one liners.
> >
> > This should be much simpler and if I'm not mistaken should ensure the
> > correct ordering of the requests and the correct VM association.
>
> Seems correct at first to me too, but I will sit on this and try to
> convince myself more strongly before agreeing.

Ok, my turn ;)
Consider quickly pressing Ctrl+Shift+V, then Ctrl+V - something I think
happen very often. If those two will be handled asynchronously, there is
no guarantee for actual ordering. And if Ctrl+Shift+V will involve
calling some qrexec service, it will be slower than Ctrl+V. Result:
quick Ctrl+Shift+V, then Ctrl+V will not work anymore.

Actually we have considered something very similar before. Clipboard
operations for Windows VMs are handled using qrexec calls. But exactly
for the above reason, we've kept calling it still in gui-daemon and
handle it synchronously (wait for qrexec service completion, before
processing any further events).

Generally, I think if different key combinations will be handled by
different processes asynchronously, then there will also be some
place for race condition.

Alternative, less risky, but also less elegant solutions I see:

1. Intercept all the keys, filter them in one place and release (if
desired) for original application after processing special action. This
way order of events will be preserved. But this will also introduce
single point of failure, or at least bottleneck for input events.
Technically, I believe it can be done at X11 API level (maybe using
XGrabKeyboard?), but will not be easy.

2. Asynchronously handle Ctrl+Shift+C from dom0, _without_ intercepting
it. So gui-daemon (or any other application) will receive it as before.
But then handling application will need to check if any gui-daemon have
handled it (check current focus and check xevent counter stored besides
clipboard file). This is also not ideal, because still is racy
(Ctrl+Shift+C in dom0 and Ctrl+Shift+V in VM can be reordered), but I
think the risk of such race is somehow smaller - user needs to change
focus in between, so there is more time in between. The other downside
of this approach is that non-gui-daemon application will also receive
Ctrl+Shift+C, so in practice it will trigger two actions at the same
time: one from original application, and clipboard-copy-from-dom0. In
undefined order.

I don't like neither of those...

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJYNu7oAAoJENuP0xzK19csgzQH/0HtD9FR+vlMWsH7IwEtloxe
/qmCi3pldZ8bjtpwlLQv9xt0Zmx7PV/eNdlQTIHiEwByYQyH6yAmr5Sl37OtvDsA
4H6Ru8rdSyICk/u5blwvnyL+wdaKMeDCXPR9urwU3sIAyWHHL59ci17gaivAfrGc
xhF68+ZCwy0yUApnuH7u4YvGYKnQLMcONM051os6vDM2Xpj5Zn2vIuVmDDL7rHUS
4VWoT30/E9QNMmy3moBbrl4iiPZJRstNIoQ/MFyumxPegOhUR9gsXNTLEQL3y5hs
gLSjJCn1xolkJtQH3gwvKluj7Jyt+MhEao05oG1EAMkh+7Ue0pf2fjZsZCtJ9sE=
=fe4z
-----END PGP SIGNATURE-----

[Ivan]

It looks complicated... :)

Frankly, is there really a need for such thing ? For the last year or so
I've been using Qubes I had to copy/paste from dom0 to VMs only a few times.

Granted, the qvm-run --pass-io command line stuff is a bit convoluted
for new users who want to publish a HCL report or send some debugging
info, but what is the problem of simply easing the process while keeping
it simple ? Something like:

- select something in dom0 and copy it to the clipboard (ctrl-c, right
click/copy, ...) like you would do in any VM

- use a specific shortcut (*not* ctrl-shift-v), or a tray button, or a
menu entry, ..., to send the content of the clipboard to a given VM
(would require a popup list to choose the VM). A terminal command in
dom0 could trigger it too.

- ctrl-v / paste in the chosen vm.

Or am I missing something ?

Ivan

[Jean-Philippe Ouellet]

On Thu, Nov 24, 2016 at 8:45 AM, Marek Marczykowski-Górecki
<marm...@invisiblethingslab.com> wrote:
> Alternative, less risky, but also less elegant solutions I see:
>
> 1. Intercept all the keys, filter them in one place and release (if
> desired) for original application after processing special action. This
> way order of events will be preserved. But this will also introduce
> single point of failure, or at least bottleneck for input events.

It is unclear to me how errors should be handled here. Are we to wait
for the copy/paste operation to succeed before injecting the next
keystroke? It appears to me that we would have to in order to solve
race you described. This would have tremendous potential for DoS.

> Technically, I believe it can be done at X11 API level (maybe using
> XGrabKeyboard?), but will not be easy.

IIUC XGrabKeyboard is exclusive, and screen-lockers also try to use
it. This means such a solution would prevent screen-locking from
working properly. Avoid, avoid!

> 2. Asynchronously handle Ctrl+Shift+C from dom0, _without_ intercepting
> it. So gui-daemon (or any other application) will receive it as before.
> But then handling application will need to check if any gui-daemon have
> handled it (check current focus and check xevent counter stored besides
> clipboard file). This is also not ideal, because still is racy
> (Ctrl+Shift+C in dom0 and Ctrl+Shift+V in VM can be reordered), but I
> think the risk of such race is somehow smaller - user needs to change
> focus in between, so there is more time in between. The other downside
> of this approach is that non-gui-daemon application will also receive
> Ctrl+Shift+C, so in practice it will trigger two actions at the same
> time: one from original application, and clipboard-copy-from-dom0. In
> undefined order.

Yes, I was thinking of something like this too. It seems like a better
solution lies somewhere this direction, however I can not think of a
race-free (and non-ugly!) way to implement it.

> I don't like neither of those...

Yeah... I'm satisfied triggering this via a menu item of the qubes tray icon :)

[Jean-Philippe Ouellet]

On Thu, Nov 24, 2016 at 9:52 AM, Ivan <iv...@c3i.bg> wrote:
> It looks complicated... :)
>
> Frankly, is there really a need for such thing ? For the last year or so
> I've been using Qubes I had to copy/paste from dom0 to VMs only a few times.

I do it sufficiently often that I wrote a (incorrect)
/usr/local/bin/qubes-set-clipboard. Incorrect because it does not grab
the inter-appviewer lock when manipulating the files, so it's possible
that there could be interleaving of updating the files between my
writing and a gui-daemon's writing, but in practice I don't care since
it is nearly impossible to trigger (I perform copy first

I was looking for a better way to solve this though, potentially with
a consistent UX (just use the same keyboard shortcut in dom0 & domU
because the action you are trying to perform is the same, so that's
what users would likely expect).

> - use a specific shortcut (*not* ctrl-shift-v), or a tray button, or a menu
> entry, ..., to send the content of the clipboard to a given VM (would
> require a popup list to choose the VM). A terminal command in dom0 could
> trigger it too.

I didn't like that because it's an inconsistent UX, but given the
difficulty of doing it properly here, I think that's a very reasonable
solution.

[Ivan]

>> Frankly, is there really a need for such thing ? For the last year or so
>> I've been using Qubes I had to copy/paste from dom0 to VMs only a few times.
>
> I do it sufficiently often that I wrote a (incorrect)
> /usr/local/bin/qubes-set-clipboard. Incorrect because it does not grab
> the inter-appviewer lock when manipulating the files, so it's possible
> that there could be interleaving of updating the files between my
> writing and a gui-daemon's writing, but in practice I don't care since
> it is nearly impossible to trigger (I perform copy first
>
> I was looking for a better way to solve this though, potentially with
> a consistent UX (just use the same keyboard shortcut in dom0 & domU
> because the action you are trying to perform is the same, so that's
> what users would likely expect).

I fully agree that providing a consistent UX copy/paste from dom0 would
be nice for users who need that functionality, but the past ML posts
showed that a proper implementation would not be straightforward at all,
hence my comment about "keeping it simple".

If that's not impolite to ask, out of curiosity, why do you often need
to copy/paste from dom0 ? Why doesn't the pass-io functionality (wrapped
into a user friendly script for copying files or maybe performing git
operations) fit in your workflow ?

>> - use a specific shortcut (*not* ctrl-shift-v), or a tray button, or a menu
>> entry, ..., to send the content of the clipboard to a given VM (would
>> require a popup list to choose the VM). A terminal command in dom0 could
>> trigger it too.

[ re-reading my reply, I see I've made a typo: I meant ctrl-shift-c, not
ctrl-shift-v ].

> I didn't like that because it's an inconsistent UX, but given the
> difficulty of doing it properly here, I think that's a very reasonable
> solution.

Cheers,
Ivan

[Jean-Philippe Ouellet]

On Sat, Nov 26, 2016 at 2:47 AM, Ivan <iv...@c3i.bg> wrote:
> If that's not impolite to ask, out of curiosity, why do you often need to
> copy/paste from dom0 ? Why doesn't the pass-io functionality (wrapped into a
> user friendly script for copying files or maybe performing git operations)
> fit in your workflow ?

Various development and debugging needs.

I frequently copy things both in and out of dom0, making sure to
carefully examine an escaped-special-characters rendering of
everything copied in from untrusted origins each and every time before
use.

AFAIK normal consumers of Qubes should not need to do this (ideally
ever), but it has become apparent that at least copying an occasional
error message out is commonly-desired functionality.

[Jean-Philippe Ouellet]

A tray icon seems like a reasonable compromise to me.

I propose a possible implementation here:
https://github.com/QubesOS/qubes-manager/pull/15

[Chris Laprise]

A clipboard tray icon for developer debugging?

Chris

[Jean-Philippe Ouellet]

For any time a user desires to copy anything out of dom0.

See https://github.com/QubesOS/qubes-issues/issues/2438 as an example
of a real-world use case.

"developer debugging" just happens to be a common use case for me
because for some reason I seem to do a lot of that :)