-----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
>> <[email protected]> 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-----
--
You received this message because you are subscribed to the Google Groups
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-devel/dc4c37a7-d82a-d348-0a1b-9ba137348a7b%40ipsumj.de.
For more options, visit https://groups.google.com/d/optout.
