Skip to content

Default to global default_dispvm for *named* disposables #735

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from
Closed

Default to global default_dispvm for *named* disposables #735

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 7 additions & 1 deletion qubes/vm/dispvm.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -189,7 +189,13 @@ class DispVM(qubes.vm.qubesvm.QubesVM):
"default_dispvm",
load_stage=4,
allow_none=True,
default=(lambda self: self.template),
default=(
lambda self: (
self.template
if any(tag.startswith("disp-created-by-") for tag in self.tags)
else self.app.default_dispvm
Copy link
Contributor

@ben-grande ben-grande Oct 14, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

but not named disposables. The latter cannot be leveraged to e.g. bypass networking restrictions.

How not?

  • Global default dispvm netvm: sys-firewall
  • Named disposable netvm: vpn

Also checking name would be wrong (could break in the future on naming scheme changes, which there is something planned, not executed, for management qubes), check for auto_cleanup property.

See this branch of the documentation from my PR: https://qubes-doc--1554.org.readthedocs.build/en/1554/developer/services/disposablevm-implementation.html#disposable-behavior

Copy link
Contributor Author

@rustybird rustybird Oct 14, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How not?

  • Global default dispvm netvm: sys-firewall
  • Named disposable netvm: vpn

By saying it cannot be leveraged I meant that a named disposable can't just be created without user intervention like an unnamed one.

But yes, in the case where a named disposable is based on a different disposable template than the global default disposable template, the commit would change how someone might want to properly configure this named disposable. Do you think it's too harsh of a change to spring upon users?

Also checking name would be wrong, check for auto_cleanup property.

Hmm, I actually started out with auto_cleanup but then wondered about exotic named disposables with auto_cleanup == True (odd but... why not), then thought maybe check for a disp-created-by- tag instead (as something that only exists for disp1234 disposables created via admin.vm.CreateDisposable), and ultimately arrived at checking for name == "disp" + dispid because this seemed like the most natural way to express the concept of an "unnamed" disposable.

(Of course checking for auto_cleanup is more natural in other contexts, like omitting those disposables from backups by default.)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How not?

  • Global default dispvm netvm: sys-firewall
  • Named disposable netvm: vpn

By saying it cannot be leveraged I meant that a named disposable can't just be created without user intervention like an unnamed one.

A compromised named disposable that can open unnamed disposables that have a different netvm can be considered network leak.

But yes, in the case where a named disposable uses a different disposable template than the global default disposable template, the commit would change how someone might want to properly configure this named disposable. Do you think it's too harsh of a change to spring upon users?

Also checking name would be wrong, check for auto_cleanup property.

Hmm, I actually started out with auto_cleanup but then wondered about exotic named disposables with auto_cleanup=True (odd but... why not), then thought maybe check for a disp-created-by- tag instead (as something that only exists for disposables created via admin.vm.CreateDisposable), and ultimately arrived at checking for name == "disp" + dispid because this seemed like the most natural way to express the concept of an "unnamed" disposable.

The main differentiator of unnamed disposables is having the auto_cleanup enabled, the name is just something for us humans to differentiate them. Unnamed and named disposables behave exactly alike except on shutdown (which scripts such as qvm-run handle manually cleaning the disposable). If a named disposable has the auto_cleanup enabled, perhaps it should be treated as an unnamed disposable?

Unfortunately, this confusion appears to be a lack of definitions, unnamed and named might not be the best name, but I don't know any better right know. I am doing a big PR to the disposable documentation, if you want to propose different vocabulary, I think it would be nice if it happened on qubes-devel before the PR is merged.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Definitely do not rely on the name for distinguishing unnamed disposables. It's technically possible to create an app qube with name disp1234, you can even create a standalone with such name. Whether it's a good idea is another question, but technically it's perfectly possible.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

By saying it cannot be leveraged I meant that a named disposable can't just be created without user intervention like an unnamed one.

A compromised named disposable that can open unnamed disposables that have a different netvm can be considered network leak.

For sure. But with a named disposable, it seems intuitive to me that I should explicitly configure its default_dispvm to avoid that leak, same as I should explicitly configure an AppVM's default_dispvm to avoid it.

There probably are some users though who haven't yet configured this explicitly, because so far it wasn't necessary. Maybe this tweak isn't worth the trouble that comes with changing configuration semantics for these existing users?

If a named disposable has the auto_cleanup enabled, perhaps it should be treated as an unnamed disposable?

As weird as a named disposable with auto_cleanup is, it doesn't pose the same risk here as a disposable created through qrexec-client-vm @dispvm, i.e. admin.vm.CreateDisposable. I guess conceptually it might be clearer to check for a disp-created-by- tag after all, rather than the name?

Unfortunately, this confusion appears to be a lack of definitions, unnamed and named might not be the best name, but I don't know any better right know. I am doing a big PR to the disposable documentation, if you want to propose different vocabulary, I think it would be nice if it happened on qubes-devel before the PR is merged.

Named and unnamed are fine IMO :)

Copy link
Contributor Author

@rustybird rustybird Oct 14, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@marmarek It's checking for "disp" + dispid (not "disp" + any number suffix). But disp-created-by- tag might be better (see above)

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A compromised named disposable that can open unnamed disposables that have a different netvm can be considered network leak.

Strongly agree with this, having been protected by the current behaviour.
Users (including me) may not have considered the "disposable of a disposable" issue, as a way "open in disposable" could create new risk of information leakage. Current default behaviour guarantees no greater privilege is given to the content of a disposable without explicit intervention by the user to change the default.

)
),
doc="Default VM to be used as Disposable VM for service calls.",
)

Expand Down