My request is to (optionally?) support automatically “fetching from VM clipboard to Qubes Clipboard” on Ctrl+C (right after actual Copy) and “copying to VM and wipe” on Ctrl+V (right before actual Paste).
From security perspective, everything stays as it is now (Ctrl+C and then Ctrl+Shift+C, Ctrl+Shift+V and then Ctrl+V). But for user, oooh, it’s basically gets 2x faster, 2x easier, and 2x more normal.
Also, I can tell that I would separate Browser, Messenger and Console+TextEditor in three AppVMs, but I can’t do it now bc there’s a lot of constant copypasting between. This behavior actually limits not only usability, but isolation-level too.
Also also, maybe this issue could be solved via some built-in instruments? Please share your tweaks on this, if there are some.
Browsers and other programs can automatically trigger a copy to clipboard. So you are vising a website and it copies a malicious command to your clipboard. Then you’re on a terminal and are about to paste something from a trusted VM and Booom! Malicious code pasted and executed.
Not safe…
So basically the only way seems to be learn the thing by heart until you never miss it. And then you’ll know you’re Qubes Native™.
I don’t get it. Feature described is not like “paste from Qubes clipboard and from VM clipboard” (whatever that means…), it like “copy to VM clipboard and then copy to Qubes clipboard” for Ctrl+C and “paste from Qubes clipboard to VM clipboard and wipe it, then copy from VM clipboard to some target inside VM”.
I didn’t meant and I didn’t said “update inter-VM-clipboard on every update of clipboard in one of the VMs”. I said “on Ctrl+C\V”. Keystrokes are being operated in same environment, that manages Qubes Clipboard (I guess?)
You can rebind dom0 copy/paste shortcuts to for example Super-c and Super-v in /etc/qubes/guid.conf. This decreases the number of keypresses by 33%.
For your specific method, you can probably figure out something with xsel, qvm-run-in-vm, and the dom0 clipboard file.
For example, copy might be implemented by triggering a keyboard shortcut that runs qvm-run-in-vm -p $activevm xsel > /var/run/qubes/qubes-clipboard.bin
Here $activevm can be obtained from parsing the output of xprop -id $(xdotool getactivewindow) _QUBES_VMNAME.
I guess @airelemental in a first article meant just replacing “ctrl+shift+c\v” with “super+c\v”. 3 keys vs 2 keys.
As for implementation of method described in first post, maybe it’s easier (and probably more safe?) to (somehow…) emulate pressing “ctrl+shift+c\v” after “ctrl+c\v”, then actually do all stuff necessary. But this could be an option, thanks you @airelemental
Right. I think most of the problem is the number of keypresses involved (ctrl-c, ctrl-shift-c, ctrl-shift-v, ctrl-v = 10 keys). Simply rebinding to super (ctrl-c, super-c, super-v, ctrl-v = 8 keys) reduces the number of overall key presses by 20% (not 33%, oops!).
Sure you could bind that to super-c. Personally, I don’t think it is worthwhile. You’d have to install xsel in the VMs, and using qvm-run-in-vm introduces a delay. I haven’t tested it.
After looking into this a bit more, getting “paste” working all in one command is more complicated than “copy”.
Edit: actually, this may work for paste: qvm-run -p $activevm 'xdotool type --delay 0 --file -' < /var/run/qubes/qubes-clipboard.bin
I’ve had a site A and a site B opened in the same browser in a vm. I have accounts on both sites belonging to the same identity. I switched over to my passwords vault vm and copied the password for site A, then pressed ctrl+shift+c to copy it to global clipboard, switched over to the browser vm, pressed ctrl+shift+v to pass the password to vm’s clipboard, pasted the password and logged into the site A. Then I switched over to my passwords vault vm again, copied the password to the site B, pressed ctrl+shift+c, switched to the browser vm again, pasted the password and logged into the site B. Except, I did not really, because as you might’ve noticed I forgot to press ctrl+shift+v and so I just send my password to site A to site B instead. I’ve noticed and changed both passwords immediately, but if I haven’t a malicious owner of site B could take over my account on site A.
If you are to mess up you will do it either way is what I’m trying to say. I’m still a noob, but I can see myself making the same mistake just as easy after years of using Qubes. Especially since its superior security is sure to make me lazy and unfocused over time.
Don’t get me wrong I’m not complaining, the secure clipboard might be the best QOL feature of all.
Regardless if autocopying/autopasting gets implemented in any capacity, I’d like to see an option to have a nonintrusive dialog popup any time you try to pass anything from the global clipboard to a vm. It should (be able to) show the name of the target vm as well as the contents of the clipboard. I know this goes against the general idea in this thread, but personally I think it’d be a fantastic optional addition for people who do not care about having their shoulders looked over, but do worry about pasting a wrong thing in a wrong spot very much.
Except, I did not really, because as you might’ve noticed I forgot to press ctrl+shift+v and so I just send my password to site A to site B instead.
I’m still a noob, but I can see myself making the same mistake just as easy after years of using Qubes.
You are totally right. It has happened to me. One option is to “clear” the clipboard after logging in by selecting something non-important on the page and pressing ctrl+c. The clipboard will then have that non-important thing vs. your password.
It should (be able to) show the name of the target vm as well as the contents of the clipboard.
One problem is who is to trust to display the content of the clipboard. It definitely should not be processed by dom0. Another problem is that if you use random passwords, you might not be able to tell the password for A from the password for B anyway.
What do you mean by “processed” exactly? I was under an impression that the clipboard can only handle text? In which case I’d be hoping the devs can figure out a safe way to display some text in a dialog. I know “safe” is a relative word around places like this one here, but I think as far as security challenges go this one would be one of the easier ones for them.
At first, maybe? After I’d seen them couple of times I’d not be able to remember them, but I’d for sure be able to tell if I’m pasting the correct one. Of course, there are countless examples of other, non-random data that I’d also very much not want to paste into the wrong vm.
I was under an impression that the clipboard can only handle text?
Even text can be tricky, especially if it contains unicode characters. You are unlikely to convince anyone that dom0 should display the content being copied.
After I’d seen them couple of times I’d not be able to remember them, but I’d for sure be able to tell if I’m pasting the correct one.
That’s a fair point for frequently used passwords.
It’s a good thing I’m not trying to convince anyone then ;). But if I were, I don’t think that many people would oppose having and option to have the contents of clipboard displayed in dom0, since they can just choose not to turn it on if they are worried about their displays being monitored (pun intended).
However what I think you meant is it’d be hard for me to convince people to have the clipboard contents processed in dom0 which sure is a bit of a different story. Even though I’m slightly tempted to argue about factual security risks involved I don’t really have to, fortunately, since we are talking about Qubes. If we have data that we don’t trust but have to process in some way we can do what we do all day long anyway - make a new vm for it. You could (from what I can tell fairly easily) set up a new system vm that’s sole reason for existing is interpreting clipboard content. Use a specially prepared monolithic kernel and it could be fast enough to reboot itself after interpreting content without you noticing. You lose few dozen megabytes of ram at most.
just a vote for the super-c super-v bindings, versus ctl+shift…
its not just the number of keys, its the muscle memory / co-ordination involved. Super is right next to ctl, so the hand/fingers basically need not move for intra-App copy or paste.
Also, returning ctl+shift+c/v to terminal’s rightful solitary claim to the throne in bash is worth even more, for me.
I think there was some enhancement request on qubes-issues requesting that. Shouldn’t be too hard to implement.
Btw Ctrl-V should be possible by putting /etc/qubes-rpc/policy/qubes.ClipboardPaste to “allow” for those like the OP who don’t want clipboard security.
It’s always questionable to interpret what someone else has said when
their meaning seems plain.
You make it sound as if the option would be “display by default”, and I
would oppose this. If the display were opt in, I wouldn’t use it. But
some people would.
The discussion went from “It definitely should not be processed by dom0.” to “You are unlikely to convince anyone that dom0 should display the content being copied.” in the span of two posts. There is a huge difference between processed and displayed with actual security implications. I described them in the very next post. What’s so questionable about that?
I tried to use the word “option” as many times as possible without making it sound funny to the reader, but just to be perfectly clear, yes I do think it should (could?) be an option. If it was on by default I’d be the first to complain.
One thing I realized I dislike a lot is how Qubes notifies you about clipboard operations - it uses the same message area that it uses for everything else. Which makes sense when you think about it at first. But in reality, (at least in my experience with running a lot of vms at once, some of which might not even start and just throw out an error), it’s actually pretty hard to notice you missed an action. Especially if you are tying to paste few different thing to few different destinations in a hurry. One somewhat easy (I think…) fix would be to have the mouse cursor react to clipboard actions in some way. Changing colors and/or animations are probably off the table for a lot of people and for good reasons too. But how about small icons popping up next to your cursor? You could have one icon when something gets copied to the clipboard and another one for the paste/wipe. It’s only two icons so they could be monochromatic and just two simple but distinct shapes.
However what I think you meant is it’d be hard for me to convince people to have the clipboard contents processed in dom0 which sure is a bit of a different story.
Displaying is processing whether you want it or not. For instance, if you are copying something that has Markdown markers, you have to make sure it won’t get interpreted by chance. And that’s not even getting into something like unicode and other things.
If we have data that we don’t trust but have to process in some way we can do what we do all day long anyway - make a new vm for it.
Making this efficient could be a little bit of a challenge. But this could be a good community contribution if you interested in exploring this further.
