Pre-select qvm-copy/move destination VM in dom0 confirmation window when it's the only possible option

[pellywog]

I've been searching around reading, amongst others, this #3529 but can't find the solution. How do I specify the destination VM in qvm-copy / qvm-move when copying / moving files from domU to domU?

Qubes Version

4.0.2

Steps to reproduce the behavior:

vm1: qvm-copy vm2 myfile.txt

-> gives me an error file "vm2" not found

What DOES work is:

vm1: qvm-copy myfile.txt

-> A dialogue box opens where I have to type the destination VM manually (takes time / not nice for scripting).

Expected behavior:

When I run:

vm1: qvm-copy vm2 myfile.txt mysecondfile.txt

A dialogue box opens asking me to confirm copying files to vm2, where I don't have to type the destination VM.

Hope I'm not missing something trivial here but just can't figure it out..

[marmarek]

qvm-copy tool intentionally leave target selection to (trusted) dom0, instead of (untrusted) source domain. You can see (quite long) discussion about it here: #910
But, you can still use old qvm-copy-to-vm tool, which allows you to select destination. To make it effective, you will need to modify /etc/qubes-rpc/policy/qubes.FileCopy to either specify default_target= or use allow action instead of ask. See https://www.qubes-os.org/doc/qrexec/#qubes-rpc-administration for details.

[pellywog]

Hi @marmarek , thanks for your quick reply.

I'm still confused. When I use qvm-copy-to-vm, I get the following warning:

$ qvm-copy-to-vm vm_name testfile.txt
qvm-copy-to-vm/qvm-more-to-vm tools are depricated,
use qvm-copy/qvm-move to avoid yping target qube name twice

then a gtk window opens in dom0, where I have to type the destination VM name again - vm_name is not filled in automatically.

To be clear, I do not want to set up fully automated copying - I always want to confirm in dom0, but I do not want to have to specify the destination name again. If I remember correctly, in qubes 3.2 this was a thing (dom0 gtk window would ask for confirmation to "copy something from vm1 to vm2").

[marmarek]

Yes, that's correct. As I've said, you need to modify qrexec policy to have also pre-filled value and/or automatic accept for selected targets.

[marmarek]

Example policy entry could look like this:

vm1 vm2 ask,default_target=vm2

[pellywog]

Ok - So the correct file name is /etc/qubes-rpc/policy/qubes.Filecopy... When I use vm1 vm2 allow there, it will not ask.

But when I put vm1 vm2 ask there, it will still not fill out the destination field in the gui window in dom0 that asks me if I want to confirm the action.

[pellywog]

ok gained one more insight... When I run qvm-copy-to-vm vm2 testfile.txt, and:

• vm1 vm2 ask is in /etc/qubes-rpc/policy/qubes.Filecopy, it will spawn a confirmation window in dom0 where destination is NOT filled out right away, but vm2 is the only selectable option.

• vm1 @anyvm ask is in /etc/qubes-rpc/policy/qubes.Filecopy (which should be the default even if the file is absent if I get this correctly), it will also spawn a confirmation window in dom0 where the destination VM field is not filled out, but (of course) all destination VMs avaialble are selectable.

So it seems to me that there is a Bug of some sort that the destination VM is not automatically filled into the confirmation window in dom0 when it is given like qvm-copy-to-vm destination_vm testfile.txt.

PS: If I specify vm1 vm2 ask,default_target=vm2 then it does fill out that field.. But what I'm actually looking for in my usecase is vm1 @anyvm ask, without a default_target - as I have a VM that creates some things and then needs to copy that to all the templates).
Is that possible somehow?

[pellywog]

As a hacky workaround, the following works:

vm1 vm2 ask,default_target=vm2
vm1 vm3 ask,default_target=vm3

Is there a more generic way?

[andrewdavidwong]

Related issues: #3584, #3141

[andrewdavidwong]

ok gained one more insight... When I run qvm-copy-to-vm vm2 testfile.txt, and:

• vm1 vm2 ask is in /etc/qubes-rpc/policy/qubes.Filecopy, it will spawn a confirmation window in dom0 where destination is NOT filled out right away, but vm2 is the only selectable option.
• vm1 @anyvm ask is in /etc/qubes-rpc/policy/qubes.Filecopy (which should be the default even if the file is absent if I get this correctly), it will also spawn a confirmation window in dom0 where the destination VM field is not filled out, but (of course) all destination VMs avaialble are selectable.

So it seems to me that there is a Bug of some sort that the destination VM is not automatically filled into the confirmation window in dom0 when it is given like qvm-copy-to-vm destination_vm testfile.txt.

PS: If I specify vm1 vm2 ask,default_target=vm2 then it does fill out that field.. But what I'm actually looking for in my usecase is vm1 @anyvm ask, without a default_target - as I have a VM that creates some things and then needs to copy that to all the templates).
Is that possible somehow?

I interpret this to mean that this issue should be classified as a UX enhancement for the case in which there is only one possible option to be selected in the dom0 confirmation window. In such a scenario, it makes sense for the only possible option to be pre-selected, since the user will have to selected it anyway (or abort). Might as well save the user a couple clicks.

[marmarek]

So it seems to me that there is a Bug of some sort that the destination VM is not automatically filled into the confirmation window in dom0 when it is given like qvm-copy-to-vm destination_vm testfile.txt.

This is intended behavior. Generally the idea is to take away call destination control from the source vm and give it to the user and the policy. This avoids attacks when compromised source vm silently replace the destination and user don't notice a slight difference in the confirmation prompt. Thing like executing qvm-copy-to-vm vm2 file.doc, but the actual target (also displayed in the confirmation is about) vm3 - if you expect the confirmation and have the target pre-filled, it's easy to miss it, especially if the name is similar.
Entering the target in a place outside of source vm control avoids the issue. But indeed also breaks scripted cases. In the #910 discussion we even considered dropping target argument at the protocol level at all, but in the end it stayed here, specifically for the scripted cases (with allow policy).

We have considered pre-selecting target if it's the only available on the list, but decided against, to have consistent policy behavior. Instead, you can use default_target= argument. And yes, right now the only way to have the target name pre-filled with the name specified by the calling vm is adding separate rules for each destination. As explained above, this practice is discouraged for security reasons.

In practice, it should be quite safe to specify allow action for qubes.Filecopy service specifically, as the receiving side have various protections in place (forbids overriding existing files, place files only in a specific directory, named after the source name etc). The main concern would be DoS attack - one VM filling another one with unwanted data. But it's quite easy to spot.
We also plan to add notifications (#3904) when some action is allowed/denied.

[pellywog]

I see. I think for scripted cases (in my case I launch my scripts from dom0) using qvm-run its ok to go like this:

echo 'vm1 vm2 ask,default_destination=vm2' | tee /etc/qubes-rpc/policy/qubes.Filecopy
qvm-run vm1 "qvm-copy-to-vm vm2 testfile.txt"
rm -v /etc/qubes-rpc/policy/qubes.Filecopy

We also plan to add notifications (#3904) when some action is allowed/denied.

👍 for that, especially when specifying vm1 vm2 allow and the destination file exists.

Thank you for your helpful input! This issue can be closed from my side.

[andrewdavidwong]

@marmarek wrote in #7720 (comment):

[...]
3. Setting just ask target= does not select that target as default, even though it makes it the only allowed choice. You'd need to specify both target= and default_target= for that.
[...]
The third one was intentional choice, but when looking at it now, I think it was a wrong one and should be changed.

Therefore, we are reopening this issue.