Inconsistency in RPC policy with action "ask" and @adminvm/dom0

[HW42]

Qubes OS release

Qubes OS 4.2, Qubes OS 4.3

Brief summary

When parsing qrexec policy dom0 is translated to @adminvm/AdminVM.

But when evaluating an ask action AdminVM is translated to dom0 (regardless of if it was originally specified as dom0 or @adminvm.

This inconsistency leads to the problem that you can't redirect a request to @default to dom0 with an ask policy. dom0/@adminvm in target= will end up as AdminVM in targets_for_ask, but this is incompatible with a default_target = "dom0".

Steps to reproduce

No response

Expected behavior

No response

Actual behavior

No response

Additional information

This is easy to fix by resolving AdminVM in targets_for_ask to dom0. But I'm not sure if that's the proper fix. Given the comments there it sounds like the original intention was to get rid of dom0 at some point. So if the proper fix to make things work without translating @adminvm to dom0 in the process?

[DemiMarie]

The way I would interpret this is that @adminvm means “the VM that the policy engine and qrexec daemon are running on”, to which dom0 is a legacy alias.

[HW42]

To make sure I understand you comment correctly: Since you say "to which dom0 is a legacy alias", I assume you are in favor of consistently using @adminvm (or in the Python code an instance of AdminVM)?

[DemiMarie]

You assume correctly.

[marmarek]

Honestly, I don't think that's a good idea. The actual qube is named dom0 and it has a function of AdminVM. @adminvm is a keyword for this function. Currently there is only a single AdminVM in the system (so, @adminvm and dom0 are interchangeable), but with upcoming Qubes Air it may complicate at some point.
Policy should support identifying qube by name.

[HW42]

Honestly, I don't think that's a good idea. The actual qube is named dom0 and it has a function of AdminVM. @adminvm is a keyword for this function.

Ok, so then the logic replacing dom0 with @adminvm during parsing is wrong (or at least no longer desired).

Currently there is only a single AdminVM in the system (so, @adminvm and dom0 are interchangeable), but with upcoming Qubes Air it may complicate at some point. Policy should support identifying qube by name.

If the remote machine is a Qubes system it also has a dom0, so there still needs some differentiation of the names. But yes, seems plausible that in the feature we might want to extend the meaning of @adminvm, for example something like @adminvm:foo to mean the AdminVM of the qube foo. IIRC with the current concept for Qubes Air with a proxying VM the remote AdminVM isn't specially addressed, so it's somewhat speculative.

[HW42]

@DemiMarie based on @marmarek's above comment (and clarified during a call), while the original plan probably was to move to the term AdminVM/@adminvm, now he prefers keep the name dom0 for the one AdminVM we have when running under Xen. We currently also expose this name in many cases to the user. I'm currently preparing a patch to remove the automatic translation of dom0 to @adminvm (actually this uncovered some oddities in the current tests for this code path). Since you argued directly in the other direction, now would be a good time to raise your concerns/argument.

[DemiMarie]

@HW42 I am fine this approach, so long as Qubes OS behaves consistently. I had assumed that dom0 was a legacy name, but am fine with it not being.