[SDW] Beyond dom0 deployment: Missing RPC Policy System in ManagementVM-based MultiVM Applications

[deeplow]

Starting this as a discussion because there are probably many different sub-issues and this is a bit open-opened at this point. It may also be moved into Qubes-issues or somewhere else at some point.

The Problem

MultiVM applications exist in many shapes and sizes. Most use SaltStack running in dom0 directly, to provision and configure qubes (including SecureDrop). Yet, there is another way way with more tightly scoped boundaries, using the Qubes Admin API and Management VMs. But despite its introduction in 2017, it still hasn’t seen wide adoption in publicly-known projects. One of the limitations is the fact that it is semi-trusted: it either fully manages a policy file or it doesn't. A ManagmentVM does not have the fine-grained policy control to only manage itself, but there is a proposal to fix that.

Why now? What made Management VMs cumbersome to work with is improving

• SaltStack being cumbersome to setup in a Management VM
  With momentum towards Ansible in Qubes (which works great under ManagementVMs), this appears to no longer being a limitation
• Qrexec being rather slow (which the Admin API uses) - actions run from dom0 directly are much faster, but Qubes 4.3 should have qrexec calls about 5x faster due to needed optimizations for the GuiVM.

Workstation Needs

The Workstation plays several separate roles that would need to be considered separately on a management-VM based architecture.

Here's a breakdown:

• Managing its own VMs - "Pure" MultiVM Management
  • Admin API policy needs
    • manage itself
    • manage its own qubes
    • install new templates (potentially)
  • Regular qrexec policy needs
    deny policies from other app qubes (e.g. qubes.ClipboardPaste, qubes.Filecopy)
• Managing SystemVMs
  • Admin API policy needs
    • manage itself
    • manage some default system qubes (sys-usb, fedora-XX-xfce, etc.)
  • Regular qrexec policy needs
    • Allow "Pure MultiVM" qubes to interact with system qubes (use split-gpg)

Future needs:

• "Extensible/Pluggable" MultiVM Management
  • Use-cases
    • Dangerzone: interfacing with a Dangerzone mutliVM application or simply the crude inclusion of Dangerzone (separate from standalone Dangerzone)
    • Export extensibility: A way to define how the workstation can be extended or what policies it "exports" as further "pipelines" for processing or exporting documents.

Workstation/Dangerzone's Needs vs Proposal

Managing it own VMs (:heavy_check_mark:)

Regarding intra-MultiVM application policy management, the proposal adds the ability for fully untrusted MultiVM Applications.

Practical example: SecureDrop Workstation wants to allow sd-app to call qubes.Gpg on sd-gpg to decrypt submissions.
Following this, we'd have:

/etc/qubes/policy.d/35-securedrop-admin.policy:

*                      *        @tag:created-by-sd-mgmt @tag:created-by-sd-mgmt !include include/sd-managed
policy.include.Get     +sd-managed sd-mgmt                 dom0                    allow
policy.include.Replace +sd-managed sd-mgmt                 dom0                    allow

/etc/qubes/policy.d/include/sd-managed.policy:

qubes.Gpg * sd-app sd-gpg                  allow

When qubes-policy-daemon is checking what it sees in practice is the following (, is read as "AND"):

qubes.Gpg,qubes.Gpg   *,*   sd-app,@tag:created-by-mgmt-vm sd-gpg,@tag:created-by-mgmt-vm                  allow

Therefore, in this case, internal policies are fully allowed. And further changes can be done directly by the managementVM by calling the policy.include.Replace Policy Admin API, without any further updates in dom0 code.

RPC Policies to System VMs

This is partially solved by the proposal. The file in policy.d defines the scope of actions that the management VM can theoretically do, while the file in policy.d/include/ (controlled by the managment VM) defines what it actually does.

In the following example, we can see how sd-mgmt (SecureDrop's hypothetical management qube) would be able to manage sys-net's template.

Practical example: SecureDrop Workstation wants to allow sd-mgmt wants to change template sys-net.
Following this, we'd have:

/etc/qubes/policy.d/35-securedrop-admin.policy:

admin.property.Set         +template        @tag:created-by-sd-mgmt    sys-net !include include/sd-managed
policy.include.Get     +managed sd-mgmt                 dom0                    allow
policy.include.Replace +managed sd-mgmt                 dom0                    allow

/etc/qubes/policy.d/include/sd-managed.policy:

admin.property.Set +template sd-mgmt sys-net                  allow

When qubes-policy-daemon is checking what it sees in practice is the following (, is read as "AND"):

admin.property.Set,admin.property.Set * sd-mgmt,@tag:created-by-mgmt-vm sys-net,sys-net                  allow

It should be highlighted that sd-mgmt would be able to do nothing more than change the template for sys-net. Even if it added some other policy because the "outer" policy (the one in policy.d) restricts it. The corollary is that outer policy approvals require dom0 policy changes.

In this sense, I'd say that the policy syntax proposal sufficiently addresses the issue and makes clear permission for outer operations a dom0 change -- a sane approach!

Non-overridable Denials

The workstation denies certain policies to (among other things) prevent copying an pasting into these qubes or moving files.

From my assessment, it should be totally fine to have something like this:

/etc/qubes/policy.d/35-securedrop-mgm.policy:

# Ability to deny anything coming out of the workstation
*      *        @tag:created-by-sd-mgmt     *  deny !include include/sd-managed
#  Ability to deny anything coming into the workstation
*      *        *      @tag:created-by-sd-mgmt deny !include include/sd-managed

The only problem here is that the above syntax is not part of the proposal because !include would be in the place of action (allow, deny or ask).

My suggestion here would be to have the action also as included in the list of things that can get "and". This could be tricky when one wants to give full flexibility in the included files (i.e. not specifying an action). For these cases, I'd suggest either making action optional (keeping it as originally proposed) or allowing * in action when !include.

Composability and Extensibility

The last point in my assessment is the composability of MultiVMs and its interaction, something I believe the proposal does not address (neither does it need to).

Goals:

• Abstraction: MultiVM1 calls dz.Convert MultiVM2, but it should not need to know which VM implements that. MultiVM2 should be able to have flexibility to change internal implementation without requiring all other MultiVM apps relying on it to also change. Versioned policies (dz.v1.Convert could alleviate semantic changes).
• Extensibility: when a user has various multiVM applications, the user shouldn't have to do the plumbing, telling which VMs can talk to which. There should be a way consent between mutliVM applications. They should be able to state which interfaces they expose and ideally, where possible, they would "auto-connect". Example: Dangerzone multiVM app installed on system and later SecureDrop is installed. SecureDrop should be able to make use of dz.Convert policy, without any dom0 policy changes (in policy.d) because Dangerzone consents to having this policy exposed.

The proposed change does not address this (from what I can tell), since inter-MultiVM application policies need dom0 policy changes. Furthermore, there is no way to say which VMs expose which RPC policies and which ones are internal only. Marek mentioned the idea of a MultiVM Application manifest defining this, but these are early day and no spec exists for that yet.

[deeplow]

Composability and Extensibility

The last point in my assessment is the composability of MultiVMs and its interaction, something I believe the proposal does not address (neither does it need to).

Just though of a possible way to make this work with a slight tweaks:

• !include can also be "AND"-able
• when calling a qrexec policy the target can be a tag (e.g. @tag:created-by-dz-dvm), so that multiVM applications can be targetted

Let's imagine the following scenario:

1. SecureDrop has a managment VM (sd-mgmt) and so does Dangerzone (dz-mgmt)
2. Dangerzone wants to tell the world that anyone can make use of its dz.Convert policy (each call will run in its own disposable qube)
3. SecureDrop wants to call dz.Convert

/etc/qubes/policy.d/30-securedrop.policy

# (Column names bellow)
# service_name   argument    source_qube             target_qube           action   parameter=value

# Securedrop -> Dangerzone interaction (needs explicit changes in dom0-controlled RPC policy file)
*                *           @tag:created-by-sd-mgmt     @tag:created-by-dz-mgmt   allow    !include=include/sd-managed,include/dz-managed

# Needed permissions for sd-mgmt to manage its own qubes
*                *           @tag:created-by-sd-mgmt     @tag:created-by-sd-mgmt   allow    !include=include/sd-managed
policy.include.Get     +managed sd-mgmt                 dom0                    allow
policy.include.Replace +managed sd-mgmt                 dom0                    allow

/etc/qubes/policy.d/31-dangerzone.policy

# @anyvm -> Dangerzone interaction (needs explicit changes in dom0-controlled RPC policy file)
dz.Convert          *           @anyvm     @tag:created-by-dz-mgmt   allow !include=include/dz-managed

# Needed permissions for dz-mgmt to manage its own qubes
*                *           @tag:created-by-dz-mgmt     @tag:created-by-dz-mgmt   allow    !include=include/dz-managed
policy.include.Get     +managed dz-mgmt                 dom0                    allow
policy.include.Replace +managed dz-mgmt                 dom0                    allow

/etc/qubes/policy.d/include/sd-managed

# allow dz.Convert, but don't specify the vm where said should happen (it's up for dz-mgmt to deal with that)
dz.Convert    *   sd-app    @tag:created-by-dz-mgmt   allow

/etc/qubes/policy.d/include/dz-managed

# Defines where this should be targeted at
dz.Convert    *   @anyvm    @tag:created-by-dz-mgmt   allow     target=@dispvm:dz-dvm

In the end if sd-app calls cat file-for-sanitization | qrexec-client-vm dz.Convert @tag:created-by-dz-dvm [...], then will match the joing of the line from 30-securedrop with the two policies in !include (include/sd-managed,include/dz-managed). The final policy matching line that succeeds is:
*,dz.Convert,dz.Convert *,*,* *,@tag:created-by-sd-dvm,@anyvm @tag:created-by-dz-mgmt,@tag:created-by-dz-mgmt,@tag:created-by-dz-mgmt allow target=@dispvm:dz-dvm

This is a bit convoluted, but it is an attempt to use the same "AND" philosophy to make multiVM application extensibility work. Alternative approach would be a manifest files describing which policies a multiVM application exposes.

Note: in case no rule is matched in one of the included policies, this would result in a deny action.

Evolution of this idea

Allow SecureDrop's management VM to define which VMs can interact with it. !include inside !include.

[eloquence]

Notes from 2025-07-03 discussion at proposal review meeting:

Introducing a management VM is not on the immediate horizon, but under consideration longer term, and relevant for potential Signal/DZ integration.

For folks interested in looking at similar architectures, Qubes 4.3's GUI VM will be a good example to study.

Kunal notes that it would be good to review the impact of potential changes to the format as qrexec-policy-graph outputs as well.

Francisco's first suggested change is motivated by this use case: We would like multi-VM application to be able to deny calls targeted at it within the includes themselves. Francisco will make that use case explicit on the upstream issue & suggest possible approaches if not covered by current syntax.

Francisco suggests deeper explorations of management VM (e.g., toy project to demonstrate concepts) as part of Salt->Ansible transition; not necessarily blocked on 4.3. He'll comment directly on relevant upstream issues, flagging any larger potential custom work that could be charged against the retainer.

[deeplow]

I could not confirm my impression that GUI VM was a management VM, but I found two other examples:

• Qubes Builder w/ Qubes Executor - to create and kill disposable qubes in which compontents are built.
• Qubes-infra

[almet]

Thanks for the explanation of all this.

We would like multi-VM application to be able to deny calls targeted at it within the includes themselves. Francisco will make that use case explicit on the upstream issue & suggest possible approaches if not covered by current syntax.

One thing that I've had in mind is the fact that depending on the action we might want the merge operator to be different. e.g. we need the and when we allow, but to deny, using or might be enough.

Would that solve the mentioned use case of "denying the calls targeted at it within the includes themselves"?