Disable inter-VM pasting into templates by default

[herypt]

The problem you're addressing (if any)
Currently it's way too easy to accidentally paste something in a terminal window in a template and compromise it.

Describe the solution you'd like
Disabling pasting to templates, this can be done by adding $anyvm $type:TemplateVM deny to /etc/qubes-rpc/policy/qubes.ClipboardPaste.

Where is the value to a user, and who might that user be?
This prevents users from accidentally compromising their templates. While this also breaks pasting things on purpose to a template, that isn't secure in most cases anyway.

Additional context
You can't paste to dom0 either.

Related, non-duplicate issues
#6347
https://groups.google.com/g/qubes-devel/c/JJN9GZMmp5s/m/AW7gzjK1tEgJ

[andrewdavidwong]

Describe the solution you'd like
Disabling pasting to templates, this can be done by adding $anyvm $type:TemplateVM deny to /etc/qubes-rpc/policy/qubes.ClipboardPaste.

The solution you'd like is already implemented, so there is nothing to be done. I'm guessing you meant to say that you think this should be the default?

I can see the rationale for that, since it would make templates more secure by default. However, as usual, it's a trade-off between security and convenience, and most users won't know how to enable copy/pasting into templates if they do need it. (Yes, they could learn how by reading the documentation, but in practice, the vast majority will never make it that far.)

As you point out, we do already restrict copy/pasting into dom0. I think the rationale is that if dom0 is compromised, it's game over, whereas if a template is compromised, it's not (some people have untrusted templates), and users can choose to add further restrictions on templates, if they wish. Ultimately, it's a judgment call where to draw the line. One relevant consideration is how often users need to copy/paste into templates and which workflows might require this.

Although I'm a big fan of the principle of secure defaults, it does not follow that literally every possible security measure should be enabled by default, since that would guarantee the system is unusable by all but a few experts. Judgement is still required, and I leave that judgment to the developers and UX experts.

[DemiMarie]

I personally support this. I do not remember having ever had to paste into a template.

[GWeck]

What about setting the policy to ask and let the user decide? This could be done by adding $anyvm $type:TemplateVM ask to /etc/qubes-rpc/policy/qubes.ClipboardPaste, as far as I understand it. This would be somewhat inconvenient but still better than denying it completely, and it should be used only rarely so that this inconvenience could be tolerated.

[andrewdavidwong]

What about setting the policy to ask and let the user decide? This could be done by adding $anyvm $type:TemplateVM ask to /etc/qubes-rpc/policy/qubes.ClipboardPaste, as far as I understand it. This would be somewhat inconvenient but still better than denying it completely, and it should be used only rarely so that this inconvenience could be tolerated.

That's no different from how it is now. When it comes to inter-VM copy/paste, ask just requires using the inter-VM copy/paste shortcuts (ctrl+shift+C and ctrl+shift+V by default).

[ninavizz]

@eloquence Thoughts on how this ticket (that is partially flying over my head for what it is asking vs what already exists and my cognitive ability to multitask and get my head around this in the process) may or may not impact our Workstation users?

[unman]

On Thu, May 13, 2021 at 01:40:49PM -0700, Nina Eleanor Alter wrote: @eloquence Thoughts on how this ticket (that is partially flying over my head for what it is asking vs what already exists) may or may not impact our Workstation users?

@nina - as Andrew has pointed out the *mechanism* for doing this already exists in the policy file. Currently the default action in that file for all qubes and Templates is "ask" - so a user can only paste something in to a terminal in a template if they explicitly respond "OK" to the "Ask" dialog. @herypt thinks this is too risky, and wants to change it to a default "deny" for Templates. So a user wanting to copy/paste in to a Template would have to explicitly edit the policy file to enable them to do this. Not only does this require the user understand about policy files, but it requires them to edit an important policy file in dom0. Picking up on Andrews's comment, I think that draws the line in the wrong place. Demi says she doesn't remember *ever* pasting in to a template. As another data point, I regularly do. And when I work with users with problems, it's often a simple way of distributing a fix. These are generally users who would struggle to do the Right Thing(TM) editing a file in dom0. In the Forum and the mailing lists there are many people who seem to copy and paste from the web in to templates. They are doing this because they want to do something in Qubes. If we make this more difficult without providing a simple alternative mechanism they will turn elsewhere. I hope that has brought the issue down to earth.

[herypt]

@unman There is no dialog for pasting, ask just means that the user needs to do Ctrl+Shift+V.
While disabling this will certainly make some actions more difficult, pasting commands from the web in templates is insecure as websites/the qube used for browsing the web can inject any command it wants into the clipboard.

[ddevz]

So there was the assumption of a "OK" button.

I'll state what in my mind would seem ideal. It would be extending the options for the qubes.ClipboardPaste file with a "ask-gui" option which would pop a gui dialog, and ask.

One option would be make it configurable to ask something like "this is a template, are you sure?".

However another option could be for the dialog to say something like:

You are about to paste "apt-get install dwarf-fortress; rm -rf " into the template debian-10. are you sure you want to do this?

In my mind that would be ideal. However, its easy to talk. Implementing it might be another story.

[unman]

On Fri, May 14, 2021 at 01:22:54PM -0700, ddevz wrote: So there was the assumption of a "OK" button. I'll state what in my mind would seem ideal. It would be extending the options for the qubes.ClipboardPaste file with a "ask-gui" option which would pop a gui dialog, and ask. One option would be make it configurable to ask something like "this is a template, are you sure?". However another option could be for the dialog to say something like: You are about to paste "apt-get install dwarf-fortress; rm -rf <enter>" into the *template* debian-10. are you sure you want to do this? In my mind that would be ideal. However, its easy to talk. Implementing it might be another story.

Actually I **do** have an OK button for confirmation, which prompts to accept paste in to the target qube. I'd forgotten that I have this as an extra. This isn't for security, but it enhances usability for me. It doesn't improve the process for ordinary users, who *already* have to get muscle memory for the Ctrl+C/Ctrl+Shift+C/Ctrl+Shift+v/Ctrl+v combo, without adding to the burden. For them, selecting a window and Ctrl+Shift+V *is* the OK button. It should also be said that the immediate risk is attached only to pasting (blindly) in to a terminal, as opposed to a config file or note. This is explicit in the description, but not in the title. (I don't mean that there are not risks in pasting elsewhere, but that they are not immediate.)

[eloquence]

Changing the default to make an already inscrutable operation (inter-VM copy/paste) more difficult for one specific, narrowly defined case sounds like a recipe for usability debt that will be difficult to pay off in future. This is IMO something that should be configured by individual users, until the copy/paste system as a whole is overhauled to give users more straightforward access to managing copy/paste permissions and understanding copy/paste failures.

[ninavizz]

A point of note that I feel may help resolve the concerns this issue seems to have been created around: next-up on my list of Qubes UX Needs is designing a Policy Manager GUI for folks. Based on what I'm looking at in this Issue, a need for that project will be surfacing these opportunities and decisions by the user, or by Qubes as a default.

I do not disagree with the initial flag by @herypt but I am with @eloquence and @unman in wanting to offer users agency to make these decisions for themselves—in an easy to discover and intuitive fashion—else, we create more problems.

That said—because I'm about to begin that project, AND I have personally experienced the problem @herypt filed this issue about, I appreciate you summarizing this user problem and creating the issue to generate discussion around it, Herypt! I need as much as I can to inform this Policy Manager project.... as it's making visually concrete and actionable, a "problem" that has not yet been solved by any GUI as of yet. (so, it's hard!) :)

[andrewdavidwong]

Sounds like this is a "won't do." If anyone has a new reason for why this should be done, please leave a comment, and we'll be happy to take another look. Thank you.