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? >> 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. -- 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/CABQWM_B8n%3D6J66JHhQNX2gRJcZOPzVm%3DAJem%2BoKtmRW%3DNkmbJQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
