andrewdavidwong
commented
7 years ago I believe this is intentional, as explained here: https://www.qubes-os.org/news/2017/10/03/core3/
@marmarek, what do you think?
Open na-- opened 7 years ago
andrewdavidwong
commented
7 years ago I believe this is intentional, as explained here: https://www.qubes-os.org/news/2017/10/03/core3/
@marmarek, what do you think?
marmarek
commented
7 years ago 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-usbAs 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--
commented
7 years ago 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
commented
7 years ago 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
commented
7 years ago 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
commented
7 years ago 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
commented
6 years ago Added default_target= to documentation: https://github.com/QubesOS/qubes-doc/commit/1fb4b57b236b4558a9557cdc653854fbc9ce2a46
qubesos-bot
commented
6 years ago 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-upgradeAutomated 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-upgradeAutomated 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-testingAutomated 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-testingAutomated 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-testingAutomated announcement from builder-github
The package python2-dnf-plugins-qubes-hooks-4.0.14-1.fc26 has been pushed to the r4.0 testing repository for the Fedora fc26 template.
To test this update, please install it with the following command:
sudo yum update --enablerepo=qubes-vm-r4.0-current-testingAutomated announcement from builder-github
The package core-agent-linux has been pushed to the r4.0 stable repository for the Fedora centos7 template.
To install this update, please use the standard update command:
sudo yum updateAutomated announcement from builder-github
The package python2-dnf-plugins-qubes-hooks-4.0.15-1.fc24 has been pushed to the r4.0 stable repository for the Fedora fc24 template.
To install this update, please use the standard update command:
sudo yum updateAutomated 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-upgradeAutomated 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-upgradeAutomated 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 updateReopening for three reasons:
qvm-open-in-vm, as reported in #4207.qvm-copy and qvm-move are missing from https://www.qubes-os.org/doc/tools/4.0/domU/.qvm-copy appears to have an incorrect usage message, as reported in https://github.com/QubesOS/qubes-issues/issues/4207#issuecomment-412361138:
$ 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]+
qvm-copyappears to have an incorrect usage message, as reported in https://github.com/QubesOS/qubes-issues/issues/4207#issuecomment-412361138:$ 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 https://github.com/QubesOS/qubes-issues/issues/3529 (already fixed in master).
ghost
commented
6 years ago 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
untrustedAppVM (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
commented
6 years ago 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=untrustedThe 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.
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 anaskpolicy.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
targetvalue 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-copythat do not specify the destination VM initially, but it's annoying for:VMAuthandInputMouse/InputKeyboardhave only one possible target in the dropdown and it should be pre-populated or missing altogether.qvm-move-to-vm,qvm-copy-to-vmfor which I have to write the destination VM twice - once in the command itself and once in the dom0 dialogsplit-gpg- what's the point of specifying/rw/config/gpg-split-domainif I have to enter it again every time anywayRelated issues:
None that I could find