qubes.OpenInVM * @anyvm @dispvm ask default_target=@dispvm:[...] causes AssertionError

[andrewdavidwong]

How to file a helpful issue

Qubes OS release

4.1.1

Brief summary

Attempting to open a file in a non-global-default disposable with an ask default_target=[...] policy fails.

Steps to reproduce

1. Create a disposable template named dvm-default.
2. In Qubes Global Settings, set dvm-default as the default disposable template.
3. Specify these policy rules in /etc/qubes/policy.d/30-user.policy in dom0:

   qubes.OpenInVM  *  @anyvm  @dispvm  ask default_target=@dispvm:dvm-default
   qubes.OpenInVM  *  @anyvm  @anyvm   deny
   

4. Create another disposable template called dvm-other.
5. Create an app qube called my-app-qube
6. In my-app-qube's advanced settings, set "Default disposable template" to dvm-other.
7. In my-app-qube, do qvm-open-in-dvm <some_file>.

Expected behavior

An "Operation execution" prompt is created in dom0 with the following:

Source: my-app-qube
Operation: qubes.OpenInVM
Target: Disposable VM (dvm-other)

(The target should be pre-filled.)

Actual behavior

No dom0 prompt is created. journalctl shows:

Aug 29 04:26:15 dom0 qrexec-policy-daemon[4452]: AssertionError
Aug 29 04:26:15 dom0 qrexec-policy-daemon[4452]:     assert default_target is None or default_target in targets_for_ask
Aug 29 04:26:15 dom0 qrexec-policy-daemon[4452]:   File "/usr/lib/python3.8/site-packages/qrexec/policy/parser.py", line 619, in __init__
Aug 29 04:26:15 dom0 qrexec-policy-daemon[4452]:     return request.ask_resolution_type(self.rule, request,
Aug 29 04:26:15 dom0 qrexec-policy-daemon[4452]:   File "/usr/lib/python3.8/site-packages/qrexec/policy/parser.py", line 922, in evaluate
Aug 29 04:26:15 dom0 qrexec-policy-daemon[4452]:     return rule.action.evaluate(request)
Aug 29 04:26:15 dom0 qrexec-policy-daemon[4452]:   File "/usr/lib/python3.8/site-packages/qrexec/policy/parser.py", line 1307, in evaluate
Aug 29 04:26:15 dom0 qrexec-policy-daemon[4452]:     resolution = policy.evaluate(request)
Aug 29 04:26:15 dom0 qrexec-policy-daemon[4452]:   File "/usr/lib/python3.8/site-packages/qrexec/tools/qrexec_policy_exec.py", line 273, in handle_request
Aug 29 04:26:15 dom0 qrexec-policy-daemon[4452]:     result = await handle_request(**args, log=log,
Aug 29 04:26:15 dom0 qrexec-policy-daemon[4452]:   File "/usr/lib/python3.8/site-packages/qrexec/tools/qrexec_policy_daemon.py", line 100, in handle_client_connection
Aug 29 04:26:15 dom0 qrexec-policy-daemon[4452]: Traceback (most recent call last):
Aug 29 04:26:15 dom0 qrexec-policy-daemon[4452]: future: <Task finished name='Task-35552' coro=<handle_client_connection() done, defined at /usr/lib/python3.8/site-packages/qrexec/tools/qre>
Aug 29 04:26:15 dom0 qrexec-policy-daemon[4452]: Task exception was never retrieved

[unman]

I don't see this. In any case, unless you have changed the rules, should your expectation not be - "A dialog appears with @dispvm:dvm-default preselected" rather than "a disposable is created based on `dvm-other`" ? That's exactly what happens for me.

[marmarek]

Those rules, with the current policy semantic, does not allow the call. The default_target selects default target from targets allowed (ask or allow) by other rules already. This is different from target, which overrides target regardless of whether it is otherwise allowed or not. See https://github.com/QubesOS/qubes-core-qrexec/blob/master/doc/qubes-policy.rst (hmm, it seems we don't have this rendered anywhere else).
And indeed no other rule allows calls to @dispvm:dvm-default (@dispvm means @dispvm:dvm-other when it has dvm-other set as default_dispvm).

So, we have few points here:

1. Error handling - it should be clear message what really happened, not AssertionError
2. Confusing difference between target= and default_target= - the later requires another rule that would allow/ask the call, while the former does not
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 first point is an obvious bug. The second is intended semantics, but I can be persuaded to change it. The third one was intentional choice, but when looking at it now, I think it was a wrong one and should be changed.

[andrewdavidwong]

should your expectation not be - "A dialog appears with @dispvm:dvm-default preselected" rather than "a disposable is created based on dvm-other" ?

Yes, I caught my mistake and edited the issue description between the time when GitHub emailed a copy of it to you and the time when you replied.

Those rules, with the current policy semantic, does not allow the call. The default_target selects default target from targets allowed (ask or allow) by other rules already. This is different from target, which overrides target regardless of whether it is otherwise allowed or not. See https://github.com/QubesOS/qubes-core-qrexec/blob/master/doc/qubes-policy.rst (hmm, it seems we don't have this rendered anywhere else). And indeed no other rule allows calls to @dispvm:dvm-default (@dispvm means @dispvm:dvm-other when it has dvm-other set as default_dispvm).

So, we have few points here:

1. Error handling - it should be clear message what really happened, not AssertionError

Ok, let's keep this issue for that.

2. Confusing difference between target= and default_target= - the later requires another rule that would allow/ask the call, while the former does not

Opened a separate issue for this: #7723

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.

Reopened #5510 for this.

The first point is an obvious bug. The second is intended semantics, but I can be persuaded to change it. The third one was intentional choice, but when looking at it now, I think it was a wrong one and should be changed.

Summary:

• First point = [this issue]
• Second point = RPC policy rule syntax: the difference between target= and default_target= can be confusing #7723
• Third point = Pre-select qvm-copy/move destination VM in dom0 confirmation window when it's the only possible option #5510

[UndeadDevel]

I've found another case where this happens; I'll report just to cover this edge case, as it's error is slightly different and the trigger / use case is different:

When specifying a named DVM as default_target, e.g. default_target=named in the otherwise same scheme used above, then it will correctly ask for the file or URL to be opened in a prompt window, with the specified named DVM being pre-selected, even when its dvm-template is not the default. However, when trying to use e.g. qvm-open-in-dvm from that named DVM, which is itself the default_target, the reported assertion error happens:

dom0 qrexec-policy-daemon[2771]: Task exception was never retrieved 
dom0 qrexec-policy-daemon[2771]: future: <Task finished name='Task-22002' coro=<handle_client_connection() done, defined at /usr/lib/python3.8/site-packages/qrexec/tools/qrexec_policy_daemon.py:75> exception=AssertionError()>
dom0 qrexec-policy-daemon[2771]: Traceback (most recent call last):
dom0 qrexec-policy-daemon[2771]:   File "/usr/lib/python3.8/site-packages/qrexec/tools/qrexec_policy_daemon.py", line 120, in handle_client_connection
dom0 qrexec-policy-daemon[2771]:     result = await handle_request( 
dom0 qrexec-policy-daemon[2771]:   File "/usr/lib/python3.8/site-packages/qrexec/tools/qrexec_policy_exec.py", line 326, in handle_request
dom0 qrexec-policy-daemon[2771]:     resolution = policy.evaluate(request)
dom0 qrexec-policy-daemon[2771]:   File "/usr/lib/python3.8/site-packages/qrexec/policy/parser.py", line 1553, in evaluate
dom0 qrexec-policy-daemon[2771]:     return rule.action.evaluate(request)
dom0 qrexec-policy-daemon[2771]:   File "/usr/lib/python3.8/site-packages/qrexec/policy/parser.py", line 1058, in evaluate
dom0 qrexec-policy-daemon[2771]:     return request.ask_resolution_type(
dom0 qrexec-policy-daemon[2771]:   File "/usr/lib/python3.8/site-packages/qrexec/policy/parser.py", line 708, in __init__
dom0 qrexec-policy-daemon[2771]:     assert default_target is None or default_target in targets_for_ask 
dom0 qrexec-policy-daemon[2771]: AssertionError

The order of error messages is reversed and the line numbers are different, but I think it still fits the case described in this issue.

If I should post this also in one of the other two related issues, let me know...

[marmarek]

The corner case here is that loopback calls are refused, so named cannot do a call back to named. It should be handled better (likely call refused with more appropriate message).

[UndeadDevel]

Would it be possible to actually allow it if the policy is ask?

My (more detailed) use case is as follows: I have two cached, named DVMs, one with and one without networking. This is why I often open files in them, but also do other tasks, such as mount another VM's volume in them, because they're basically immediately available, so it's very convenient to use them. But it can happen that, e.g. I am looking through a volume and want to open some files in it, but without exposing that volume to risk and so I call qvm-open-in-dvm from this named DVM that I mounted the volume in, but then the error occurs.

So I have to either mount things that could have multiple files in a non-cached DVM to then use the standard functionality defined via policy, or start a non-cached DVM, manually copy the files over and then open there. It would be nice if I could just call qvm-open-in-dvm from there and have the prompt come up.

Edit: I retract this post, as I've made a mistake while trying to correct this issue via an additional policy (I thought that dvm-default will "autofill" the default DVM template, but that's not the case). I solved this by adding "higher" policy rules with the named DVM as source and specifying @dispvm as default_target.

[ben-grande]

Those rules, with the current policy semantic, does not allow the call. The default_target selects default target from targets allowed (ask or allow) by other rules already.
...
2. Confusing difference between target= and default_target= - the later requires another rule that would allow/ask the call, while the former does not

Summary of the problem: an ask rule with default_target= requires target=. If no target= is used, exception is thrown`, if it is used, only one qube can be selected.

Instead of handling the exception, I would like to propose for the target= to not be necessary before the GUI dialog is presented to the user. This would allow for the user to pre-select a default target but not force it to be the only one.

If this proposal is not accepted, I will try to PR handling the exception.

[ben-grande]

This issue was fixed. Qubes 4.2.3 and qubes-core-qrexec 4.2.21-1.

Used rule on non-existent service to try:

qubes.Test * dev @default ask default_target=dom0

qrexec: qubes.Test: dev -> : denied: policy define 'ask' action at /etc/qubes/policy.d/30-user.policy:7 but no target is available to choose from