On Wed, Nov 23, 2016 at 7:47 PM, HW42 <[email protected]> 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. -- 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_CL-j_7HduS6pE9Dcg_5ZP8LJE2-e9wHJifNR3993hPvg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
