-----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 > <[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. - -- 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----- -- 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/20161124001749.GN1145%40mail-itl. For more options, visit https://groups.google.com/d/optout.
