Option to ask for confirmation on Qubes clipboard paste (focus stealing mitigation)

[mattmccutchen]

The problem you're addressing (if any)

Focus stealing between VMs in the Qubes UI presents a risk of user keyboard or mouse input being sent to an unintended VM, violating confidentiality and/or integrity. The general problem is unsolved: see this thread and #4705. But ISTM the greatest current risk is the immediate loss of confidentiality of an entire password (or the like) by a Qubes clipboard paste being stolen. Violating integrity by causing a Qubes clipboard copy from the wrong VM via a focus steal is less of a risk because the clipboard widget shows a notification with the name of the source VM and the user has an opportunity to read the notification before deciding whether to paste.

Describe the solution you'd like

Let the user opt in (via an /etc/qubes/guid.conf option) to treating "ask" in /etc/qubes-rpc/policy/qubes.ClipboardPaste as a true "ask" that shows the RPC confirmation dialog, so the user can verify the target VM. Since qubes-guid does not support changing the target VM at that point, the target VM field should be pre-filled and unchangeable. The user would then have the option to restore the previous behavior for some target VMs by setting their policy to "allow" in /etc/qubes-rpc/policy/qubes.ClipboardPaste.

Here's a proof of concept implementation that I'm using on my own system for now. It has two parts:

1. Since the Qubes clipboard paste is the only thing I'm aware of that currently uses qrexec-policy --assume-yes-for-ask and I didn't want to go to the trouble of recompiling qubes-guid yet, I just patched the qrexec-policy Python code to unconditionally ignore --assume-yes-for-ask. Once qubes-guid supports a /etc/qubes/guid.conf option to not pass --assume-yes-for-ask, I would revert this change.
2. Patch qrexec-policy so that "ask" in --just-evaluate mode shows the RPC confirmation dialog, fixed to the original target VM. If in the future there are other callers of qrexec-policy --just-evaluate that can't afford to block, we can add another flag that restores the previous behavior of treating "ask" as "deny" (unless, of course, the caller passed --assume-yes-for-ask). Or if we're concerned that such callers might already exist, we can add a flag to opt in to using the RPC confirmation dialog.

At first, I was afraid that qubes-guid might be doing tricky X things that would break if it waited for the user to respond to the RPC confirmation dialog. Indeed, all window updates and keyboard/mouse input to and from the target VM are delayed while the dialog is open; that's not terribly nice, but I hope it is acceptable for an initial implementation of an opt-in feature. I haven't noticed any other problems in brief testing.

If the Qubes OS maintainers would accept this feature, I'll clean up my implementation and submit it as a pair of PRs to the qubes-core-admin and qubes-gui-daemon repos. Both changes need to be installed on a system for the feature to work, but installing only one of the two should not break anything compared to the status quo.

Where is the value to a user, and who might that user be?

This gives any user who frequently copies confidential data between VMs using the Qubes clipboard (such as me) a way to prevent it from being stolen by another running VM via focus stealing.

Describe alternatives you've considered

• A comprehensive solution to focus stealing: seems to be far off.
• Disable qubes-guid's built-in secure paste shortcut (by setting it to a key I never press) and instead implement my own secure paste shortcut that works the way I propose. The advantage of this approach is that it requires no changes to existing Qubes OS components and could be distributed as an add-on. The disadvantage is that the implementation is a bit fiddly: it would need a new way to detect the secure paste shortcut regardless of which VM is focused and transfer the clipboard data. I imagine the shortcut detection could be done either in dom0 (where the awkward part is to identify the focused VM; I've read that this can perhaps be done by looking at the _QUBES_VMNAME window property) or by running some process in every VM that listens for the shortcut (in which case a VM could falsely report a shortcut press, but the user could decline the confirmation).

Additional context

None.

Relevant documentation you've consulted

https://www.qubes-os.org/doc/copy-paste/

Related, non-duplicate issues

#2120; #4705 (specifically about "override redirect" windows)

As an aside, it seemed like an odd decision to me to introduce --assume-yes-for-ask rather than just set the default policy to "allow". #273 doesn't offer much more insight. Was the intent that if the target VM defined a real qubes.ClipboardPaste service (as it appears that only the Windows tools currently do), then clipboard transfer could be achieved via either qubes-guid or a direct qubes.ClipboardPaste call initiated by the source VM, both regulated by the same policy file but with the former bypassing the confirmation dialog (because the secure shortcut was assumed to indicate user confirmation and the risk of focus stealing was not recognized)?

[andrewdavidwong]

Personal opinion: While this is one way to mitigate focus stealing, it's unnecessary. The tools to mitigate focus stealing are already present in Qubes. I never have this problem, because I set my window manager settings to be maximally anti-focus-stealing.

The only time I have a window focus problem is with different windows in the same VM (#1455), but since it's within the same VM, and inter-VM pasting happens at the VM level, it's irrelevant to this problem.

[mattmccutchen]

Personal opinion: While this is one way to mitigate focus stealing, it's unnecessary. The tools to mitigate focus stealing are already present in Qubes. I never have this problem, because I set my window manager settings to be maximally anti-focus-stealing.

Hm. It looks like the main setting is "Automatically give focus to newly created windows" in the XFCE "Window Manager" settings. If I uncheck that, then normal windows don't steal focus. I assumed that override-redirect windows would still be able to steal focus, but I couldn't demonstrate it in a simple test, and now I see that Qubes OS may have a specific countermeasure for such windows (#2311). So maybe my proposal was ill-informed. How confident are we, though, that the settings you mentioned cover all the cases and there isn't some special case we're unaware of?

It seems like turning off "Automatically give focus to newly created windows" may be a significant hit to usability; I'd have to run with it for a while to see how much of a hassle it is to manually switch the focus and how that compares to other hassles I already accept for other reasons. But if it's tolerable and it in fact completely solves the problem, it may be preferable to just restricting the clipboard. Allowing normal focus stealing and restricting the clipboard presents a different usability/security trade-off that some users might prefer, though there may not be enough such users to justify maintaining the option in Qubes OS. Conceivably, some users might want to restrict focus stealing and additionally restrict the clipboard as a second line of defense against a slip of the keyboard or mouse.

As usual, I think that's all I have to say and now it's up to your team what you want to do with the proposal. I plan to keep using it on my system for now.

The only time I have a window focus problem is with different windows in the same VM (#1455), but since it's within the same VM, and inter-VM pasting happens at the VM level, it's irrelevant to this problem.

Agreed.

[andrewdavidwong]

How confident are we, though, that the settings you mentioned cover all the cases and there isn't some special case we're unaware of?

All I can say is that I haven't experienced bad focus stealing with these settings in my normal daily use, but there could always be a special case I haven't experienced.

It seems like turning off "Automatically give focus to newly created windows" may be a significant hit to usability

Yes, but so would a pop-up for every inter-VM paste, IMHO. I suppose which one is worse is a matter of personal preference. I've gotten used to working with the anti-focus-stealing windows. I find that they give me more control and complement the way that Qubes requires us to be very deliberate about which qube we use for which purpose. They also have the benefit of making it difficult to accidentally confirm prompts.

Allowing normal focus stealing and restricting the clipboard presents a different usability/security trade-off that some users might prefer, though there may not be enough such users to justify maintaining the option in Qubes OS. Conceivably, some users might want to restrict focus stealing and additionally restrict the clipboard as a second line of defense against a slip of the keyboard or mouse.

I think that's a reasonable assessment.

As usual, I think that's all I have to say and now it's up to your team what you want to do with the proposal. I plan to keep using it on my system for now.

I'll leave this open to see what the devs think.

[mattmccutchen]

Some addenda:

How confident are we, though, that the settings you mentioned cover all the cases and there isn't some special case we're unaware of?

All I can say is that I haven't experienced bad focus stealing with these settings in my normal daily use, but there could always be a special case I haven't experienced.

Right, I'm afraid there may be some special case that only an attacker would find. It doesn't seem that we have the resources to continually penetration-test the complex stack of technologies that makes up Qubes OS. 🙁

I've gotten used to working with the anti-focus-stealing windows.

After about 2 days, I'm still regularly sending keystrokes to the old window. Thank goodness I haven't triggered a dangerous keyboard shortcut (so far, to my knowledge). Give it a few weeks?

[mattmccutchen]

It occurs to me that our current documentation of the Qubes clipboard ("it doesn’t allow any qube other than your selected target to steal any contents from the inter-qube clipboard") gives users a false sense of security by not calling out the ease of focus-stealing a paste. If addition of my proposed feature is not imminent, I'd like to go ahead and submit a PR to the documentation to describe the problem and the existing potential solution of restricting focus stealing (which we're not sure is 100%).

[marmarek]

Requiring extra confirmation for every cross-qube paste would be an UX nightmare. Especially since the qrexec policy prompt dialog has its own focus stealing protection - requiring to wait about 1s after receiving focus to allow accepting the call.
I think a better option (if going with qrexec policy prompt at all) would be to enable it only for selected operations - for example pasting data copied from "passwords" or "vault" qube. For this, we can't simply set "allow" to some actions and "ask" to others, because "allow" would allow such qubes silently steal (or actually - inject) clipboard content. I don't have immediate idea for a policy syntax that would work in this case.

An alternative approach would be to built focus-stealing prevention into clipboard paste itself. For example prevent paste (or only then ask for confirmation) if the target window got focus in the last 1s. Or maybe just when it was recently created? The latter combats just one attack scenario (are there others?), but also will much less likely trigger in normal use.

Another way for a window to receive focus without user's explicit action is previous window to close. But this case cannot be triggered by the attacker to receive focus - only to give it to other (unknown if in another qube) window.

BTW we really need some proper password manager integration, together with features like auto-type or browser integration. It's likely possible to integrate some existing solution and just isolate passwords storage split-gpg style (with proper policy saying which qube can access what password and when confirmation is required). But that's offtopic here.

[ninavizz]

@mattmccutchen This is a legit problem, and I appreciate you flagging it... a lot! I agree, that users shouldn't have to configure settings & such, to maximise protections.

TL;DR, imho the "solution" is better overall UX of the clipboard functions. Users need more visibility into what is happening, and what impacts there are—but without the cognitive burdens imposed by more toast messages, task burdens imposed by more confirmation dialogs, or other "obvious" yet burdensome solutions.

A non-trivial problem to solve for, so I'm tagging #5778 here, which I created to more generally address the Cut/Paste experience. It could totally be improved, TY for flagging this!

[ninavizz]

BTW @mattmccutchen Do you have thoughts on the idea presented in the first comment on #5778 ?? That's an issue I created for a specific solution, but just renamed to more globally speak to this as a future UX project.

[mattmccutchen]

BTW @mattmccutchen Do you have thoughts on the idea presented in the first comment on #5778 ?? That's an issue I created for a specific solution, but just renamed to more globally speak to this as a future UX project.

Neutral: I don't feel I need it personally (at least at this point), but I have no objection if others find it helpful. Let's keep any further discussion of the broader project on that thread.