UX issues with qrexec service confirmation dialogs - missing target default value

[na--]

Qubes OS version:

R4.0 RC2

Affected TemplateVMs:

all (dom0 issue)

---

Steps to reproduce the behavior:

Try to execute a simple Qubes RPC call, for example try to copy a file from one VM to another with qvm-copy-to-vm, plug in an external keyboard/mouse, use VMAuth (yeah, I know...:) ), sign a git commit with split gpg, etc. - most RPC actions with an ask policy.

Expected behavior:

A simple dialog opens and with minimum friction the user chooses whether to allow the requested action or not.

Actual behavior:

The "Operation execution" dialog is missing a default target value and it always has to be chosen from the dropdown. This leads to significantly more friction (instead of "escape or enter" / "yes or no" quick choice by the user), first the dropdown value has to be populated.

General notes:

That behavior is ok for calls like qvm-copy that do not specify the destination VM initially, but it's annoying for:

• actions like VMAuth and InputMouse/InputKeyboard have only one possible target in the dropdown and it should be pre-populated or missing altogether.
• actions like qvm-move-to-vm, qvm-copy-to-vm for which I have to write the destination VM twice - once in the command itself and once in the dom0 dialog
• automation related stuff like signing git commits with split-gpg - what's the point of specifying /rw/config/gpg-split-domain if I have to enter it again every time anyway

---

Related issues:

None that I could find

[andrewdavidwong]

I believe this is intentional, as explained here:
https://www.qubes-os.org/news/2017/10/03/core3/

@marmarek, what do you think?

[marmarek]

Yes, this is intentional. If for some particular service it is desired to have some default value there, the qrexec policy needs to be adjusted for that, adding default_target= option. For example:

$anyvm sys-usb ask,default_target=sys-usb

As for qvm-copy-to-qvm, in default policy the target parameter is redundant. But it is left there for compatibility reasons. There are friendly wrappers without this argument: qvm-copy, qvm-move - there you provide target VM only once - in confirmation window.

So, I think documentation for some services needs to be adjusted (qubes.VMAuth, split gpg etc), to include default_target= if desired.

[na--]

Thanks, that solves a lot of my issues. The qrexec documentation also needs to be adjusted, there is no mention of default_target= there.

[qubesuser]

I think the solution could be to have qvm-copy-to-vm and qvm-move-to-vm print a warning that they are deprecated and that qvm-copy and qvm-move should be used instead.

For instance, I just learned that by reading this bug.

[qubesuser]

And ideally some help text in the confirmation dialog that says "if you want to specify a target in the VM issuing the request, add a specific allow rule in the Qubes RPC policy for that specific source and target VM combination before the ask rule" (perhaps only shown after clicking on a "I want to specify a target from the VM" hyperlink to avoid polluting the dialog too much).

[marmarek]

That would encourage such configuration, which not what we want to achieve. In fact this change is especially to take out control over target domain from the source domain, where possible/sensible. But including such cases in documentation (where we have more space, also for recommendations) is a good idea.

[marmarek]

Added default_target= to documentation: QubesOS/qubes-doc@1fb4b57

[qubesos-bot]

Automated announcement from builder-github

The package qubes-core-agent_4.0.14-1+deb8u1 has been pushed to the r4.0 testing repository for the Debian jessie template.
To test this update, first enable the testing repository in /etc/apt/sources.list.d/qubes-*.list by uncommenting the line containing jessie-testing, then use the standard update command:

sudo apt-get update && sudo apt-get dist-upgrade

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package qubes-core-agent_4.0.14-1+deb9u1 has been pushed to the r4.0 testing repository for the Debian stretch template.
To test this update, first enable the testing repository in /etc/apt/sources.list.d/qubes-*.list by uncommenting the line containing stretch-testing, then use the standard update command:

sudo apt-get update && sudo apt-get dist-upgrade

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package core-agent-linux has been pushed to the r4.0 testing repository for the CentOS centos7 template.
To test this update, please install it with the following command:

sudo yum update --enablerepo=qubes-vm-r4.0-current-testing

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package python2-dnf-plugins-qubes-hooks-4.0.14-1.fc24 has been pushed to the r4.0 testing repository for the Fedora fc24 template.
To test this update, please install it with the following command:

sudo yum update --enablerepo=qubes-vm-r4.0-current-testing

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package python2-dnf-plugins-qubes-hooks-4.0.14-1.fc25 has been pushed to the r4.0 testing repository for the Fedora fc25 template.
To test this update, please install it with the following command:

sudo yum update --enablerepo=qubes-vm-r4.0-current-testing

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package qubes-core-agent_4.0.15-1+deb8u1 has been pushed to the r4.0 stable repository for the Debian jessie template.
To install this update, please use the standard update command:

sudo apt-get update && sudo apt-get dist-upgrade

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package qubes-core-agent_4.0.15-1+deb9u1 has been pushed to the r4.0 stable repository for the Debian stretch template.
To install this update, please use the standard update command:

sudo apt-get update && sudo apt-get dist-upgrade

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The component core-agent-linux (including package python2-dnf-plugins-qubes-hooks-4.0.20-1.fc26) has been pushed to the r4.0 stable repository for the Fedora template.
To install this update, please use the standard update command:

sudo yum update

Changes included in this update

[andrewdavidwong]

Reopening for three reasons:

1. We need a similar solution for qvm-open-in-vm, as reported in qvm-open-in-vm doesn't fill Target with vmname #4207.
2. qvm-copy and qvm-move are missing from https://www.qubes-os.org/doc/tools/4.0/domU/.
3. qvm-copy appears to have an incorrect usage message, as reported in qvm-open-in-vm doesn't fill Target with vmname #4207 (comment):

$ qvm-copy
usage: /usr/bin/qvm-copy-to-vm [--without-progress] dest_vmname file [file]+
$ qvm-copy-to-vm
usage: /usr/bin/qvm-copy-to-vm [--without-progress] dest_vmname file [file]+

[marmarek]

2. `qvm-copy` appears to have an incorrect usage message, as reported in #4207 (comment): ``` $ qvm-copy usage: /usr/bin/qvm-copy-to-vm [--without-progress] dest_vmname file [file]+ $ qvm-copy-to-vm usage: /usr/bin/qvm-copy-to-vm [--without-progress] dest_vmname file [file]+ ```

This is a duplicate of #3529 (already fixed in master).

[ghost]

This doc is outdated because the confirmation(for qvm-open-in-vm untrusted https://duckduckgo.com) requires re-entering the target VM name(that is: untrusted) in the dialog that appears (and you can even override it by using a different VM name), so it's no longer true that

it will open duckduckgo.com in the untrusted AppVM (after you confirmed the request).

thus the .desktop file is kinda useless unless you already know what APPVMNAME was used inside it, for the purpose of re-entering its name every time an url is opened.

[marmarek]

Indeed, it is slightly different on R4.0. For this to work, you need to add following line to /etc/qubes-rpc/policy/qubes.OpenURL (above default rules):

SOURCE_APPVM untrusted ask,default_target=untrusted

(replace SOURCE_APPVM with actual VM name, or @anyvm if you want to apply it all VMs)

Alternatively, you can use @default as target VM in .desktop file and control default target solely from the policy using rule like this:

SOURCE_APPVM @default ask,default_target=untrusted

The latter generally should be preferable, as the source VM doesn't learn about other VM names, but will not work if you want multiple .desktop file for opening links in different VMs.