Default disposable for a named disposable

User Support
1

It seems like I’ve asked this before…but I can’t find it (I did try a search).

The default_dispvm setting in global configs is great, but for some reason it doesn’t carry through to named disposables. If you go to the settings for a named disposable and select the (default) setting, you get the Named Disposable’s own DVM template, even if something else is set globally; its as if named disposables simply override this setting.

I have a lot of named disposables, and I have to hand-set every single one of their disposables to the one I actually want. Then if I have to regenerate my intended default disposable, or its template, or THAT appVM’s template, I have to go through and hand set all the named disposables’ default disposables to something else…then undo that later once my rebuild is complete. Otherwise, I’d just have to change the global setting, then change it back.

This is a bit aggravating, and I can’t figure out why anyone would want to set a named template’s default disposable to its own DVM template, but even if there’s a logical reason, it seems like there ought to be a way to NOT do this that’s less tedious.

1 Like
2

The special logic applies whenever a new unnamed disposable is spawned by any disposable, named or unnamed. Maybe it should be narrowed down to only the latter.

2 Likes
3
4

I remember being pleasantly surprised by this behaviour, after setting up some no-net, no-anything named disposable(s), as I hadn’t thought about what they would use as their dispvm. In my case, the default case was the most secure.

I think it is not bad as a behaviour, although the Principle of Least Surprise make me wonder if the term “default” is a bit overloaded.

5

Really?

This behavior actually makes sense to you?

I create a dvm specifically to serve as a thing to open documents and view them in isolation–and this “feature” does its best to ensure I won’t be able to actually USE it for this purpose without a lot of unnecessary pain–because my named disposables WON’T have this set as their default unless I specifically, one-by-one, set them to do so…never mind the fact that there’s a “global” setting that SHOULD be doing this.

I just had to write a script to step through all of my VMs, and change the default dvm for these qubes, because changing the global default does no good because I can’t USE it for this. It was that or spend fifteen minutes changing them all, one by one.

All so I could delete and rebuild the template of my default dispvm.

6

Thank you for placing it.

But I really don’t want it doing this for a numbered disposable either. If I am using a browser in one, download a file and want to view it, i CAN’T because it’s trying to go to its own template (which doesn’t have LibreOffice or even an image viewer installed). To say nothing of the fact that the policy file won’t allow it anyway, since the template isn’t listed there as an allowed recipient (and OBTW even if it did work, it would open ANOTHER browser disposable THAT HAS NETWORK ACCESS…which is the very problem Marmarek thought he was solving).

In other words, opening another copy of the VM that has network access to avoid network access, is worse than poinless.

In fact it’s even worse for numbered disposables, because unlike with a named disposable there’s absolutely NOTHING I can set to prevent this from happening, because until I start it there’s no qube that exists that I can do a qvm-prefs on.

I honestly can’t see how this makes any damned sense.

7

If you run qvm-open-in-vm @default your-file you should be able to select “Disposable VM (your document viewer disposable template)”. Unless there’s a custom deny policy causing it to be hidden?

8

Do I think it

?

I was surprised, which is not entirely good.

However, I do see some sense to the logic of this being the default:

  • Disposables are often (always?) used to impose minimal, or decreased, privilege for some purpose, to confine the bad.
  • For named disposable, it is usually for a single, specific ,purpose. For both types, it is probably undesirable to give an increased privilege to anything opened in a disposable by another disposable.
  • Without some formal model of ~~levels of ~~privilege, the only way to guarantee “no greater privs” is to give “equal privs”.

OTOH, I feel your pain… and I haven’t really thought about it very deeply. My reaction was just because I rather liked that my “dirty” documents didn’t get given -by default - network access or anything extra than in their source qube.

[Edit: there is no way to order privilege. ]

9

…at least, that’s what I remembered, but now I’m having doubts about what actually gets inherited by disposables. I seem to recall a not-so-nice surprise, too, although it may have been that I hoped for the same behaviour for regular disposables though I do not recall what.

Anyway, the new PR causes some newly created disposables to be leaky by default. Current behaviour seems the only one for disp-of-a-disp that maintains compartmentalization in all cases.

Sorry!

10

I am not sure I read carefully, but does this help?

11

I have to admit I have been a bit confused relating to this issue, and I apologize for the factually-wrong statements I have made. This is what I get for visiting this forum from a non-qubes machine!

Here, as near as I can tell, is the current behavior:

A disposable virtual machine template (which I abbreviate as “dvmt”) that fires up numbered disposables (disp1234), is where one sets the default disposable that will run in disp1234s launched from it. THIS defaults to whatever your systemwide (qubes-prefs default-dispvm) is set to and you get that if you select the default. (This is exactly what I want.) If I change the system default, and I selected “default” in the dvmt, the dvmt’s setting tracks that and I get the new system default.

A named disposable machine, on the other hand, must be hard-set to whatever the system default is, or it will pick its own dvmt as its default disposable template if you try to set it to use the system default. (This is NOT what I want.) This is true even if its dvmt has its default_dispvm set to “default.”

12

Aaahh, now I see and I can confirm this “bug”/behavior! It’s just that I rarely do anything in service qubes (that’s what I’m using named disposables exclusively for), and if I do, then it’s terminal mostly, and for that I’m using console in a qube and that fires dispVM which is internal/hidden and whose default dvm is default-mgmnt-dvm, so never paid attention actually…

13

For launching unnamed disposables, there’s currently no distinction between unnamed and named disposables in this regard. They behave identically. (My PR tried to introduce such a distinction, which turned out to be controversial.)

I think you might be mixing up two concepts: (1) Who’s launching an unnamed disposable - dom0 or any kind of qube, disposable or not, and if disposable: named or unnamed - and (2) what disposable template / dvmt it is instantiated from. A disposable template would typically not be launching unnamed disposables, ever.

14

OK fair enough. I don’t think I’m in the least bit confused, but I may not have been expressing myself clearly enough. (It would help if “template” didn’t mean two different things; it’s easy to forget to say “dvm” at the wrong time.)

As I understand it, if I launch a disposable from any VM, it will use the one named in the column “Default DispVM” in the Qube Manager window. Indeed that’s the case.

If I use the QubeManager window to bring up the settings for a particular qube, and that particular qube is the template for numbered disposables, then I can scroll down to default( some-qube-name ) and “some-qube-name” will be the qube defined as the default dispvm in Qubes OS Global Config (default disposable template), and when working in a numbered disposable based off that qube, that’s what I get–the default DispVM. This makes sense to me.

As for why I’d want to launch a disposable from a numbered disposable; if the numbered disposable is based on a minimal qube that ONLY has a browser installed, I will need a different disposable to (say) open a word document that someone sent me. (So if you’re trying to claim that “no one would ever want to do this” I would have to disagree. I want to do it, often.)

OK, the unhappiness starts when I am dealing with a named disposable. I go into Qubes Manager, select it, try to change its default disposable, scroll down to the bottom to select “default( some-qube-name )” and for some reason “some-qube-name” is set to the numbered disposable’s OWN TEMPLATE, not the one set in Qubes OS Global Config. This is wrong in my context (at least) because it’s entirely possible–even likely–that the needed software does not reside on that template! So I instead have to explicitly specify (via one of the menu items) the same qube I specified in Qubes OS global config. Which means if I ever change the global default DispVM [if I ever rebuild the default disposable template, or it’s template, I have to change the default temporarily], the change doesn’t carry through to my named templates, and I have to go through and individually change each one.

In other words what I want is for the default dispvm shown in “Qubes OS Global Config” to be respected when the launching VM is a named disposable. Referencing the named disposable’s own dvm-template here is just simply useless as I’m running off minimal templates and the needed software is likely not installed there.

15

No, here too you’ll get an unnamed disposable based on the template of the unnamed disposable that’s launching it. (Unless the disposable template is configured with an explicitly set default_dispvm / “default disposable template” property - because this property will be inherited by unnamed disposables based on it!) That’s what I meant by unnamed and named disposables behaving identically.

The reason it looks different in Qube Manager settings for the disposable template is that you’re looking at the template, not at the unnamed disposable based on it from which you’re launching another unnamed disposable. Qube Manager settings for the disposable template qube are telling you which disposable template would be used if you launched a new unnamed disposable from within the disposable template itself. Look at the Qube Manager settings for the disp1234 unnamed disposable instead.

This would be my preferred behavior too. But there was disagreement in the PR about introducing such a distinction between named and unnamed disposables (making only the unnamed ones behave specially), and also how to deal with existing users for whom this unexpected change in behavior of named disposables could be a problem.

16

Wait, are we on the same page what a named disposable is? You seem to be using it interchangeably with “named template” in two posts, which I’ve never heard.

unnamed disposable: a disp1234 qube of type DispVM
named disposable: any qube of type DispVM except disp1234, e.g. sys-firewall or sys-usb (if created as disposable in the installer)
disposable template: any qube of type AppVM or StandaloneVM with the template_for_dispvms / “disposable template” property enabled, usually with a name ending in -dvm

17

“unnamed disposable” I will sometimes call a numbered disposable. The key here is that it doesn’t exist at all until you click on some app on its dvm template (and on the correct menu (“disposable: QubeName”, not “template: QubeName”); otherwise you run the template itself). But yes I think we’re on the same page.

named disposable–agreed here too. And I use these a LOT.

disposable template: Same here. I name them “*-dvmt” to make “template” explicit because at least to my mind a “-dvm” could be a reference to the disposable it spawns.

If I ever used the term “named template” it’s a typo on my part, and I apologize. Unfortunately without looking at the specific context, I couldn’t tell you whether I meant 1) a named disposable or 2) an attempt to reference the dvm template of a named disposable [named disposable’s disposable-template would have been better] or 3) I just meant disposable template (dvm) (dvmt).

But I think, based on your prior reply, I now understand the confusion:

I am indeed setting default_dispvm to '*default*' on the disposable template and I am getting the behavior that I (at least) expect. It brings up a numbered/unnamed disposable whose default disposable is in turn based on the system default disposable template–let’s say it’s called "my-default-dvmt’. And the dropdown (when setting via the gui lists “default (my-default-dvmt)” but as you point out that’s a menu entry on the disposable template. OK and as you say since I am looking at an AppVM that happens to be a disposable template, THERE I am seeing the same behavior I would see on an ordinary AppVM. But it is the case that when I do that, then when I am running an unnamed/numbered dvm off of it, it’s default disposable is actually the same–the system setting.

When I create a named disposable, and I try to set its default template (using ‘default’ or the menus in settings) the “default( )” entry points to its own disposable template. And this makes no sense to me whatsoever; why would anyone want to do that in preference to the system setting? And it’s even worse when you tell me that this would normally be the behavior for unnamed templates too, I’m just doing something to trick the system. (But at least the consistency you are talking about would be true–up until now it has looked anything BUT consistent to me.)

OK…my next task is to select the dvm-template of one of my NAMED disposables, explicitly set its default dispvm to '*default*' (or default (my-default-dvmt) in the menu), then over on its “child” named disposable check to see what the menu looks like, and also try running the child named disposable with no explicit setting at all.

18

In reading my prior response I realized I had again said something I didn’t mean…and I have no idea whether you read it before or after my edit.

So let me walk through step by step.

Template: firefox-only
Another Template: viewers (with jpeg editor, libre-office, vlc, the works, so I can look at any document type in it)

Appvm: firefox-dvmt, with “is dvm template” set to true. This is intended to fire up disp1234 unnamed/numbered disposables.

Appvm: viewers-dvmt, with “is dvm template” set to true. And it is the “default disposable” on the system.

OK…so if I go into firefox-dvmt’s settings, and try to select a default dispvm, one of the choices that it offers is “default (viewers-dvmt)”. And if I pick that, sure enough I will get an unnamed disposable that is based on viewers-dvmt. Perfect. Exactly what I want. (And this is what one gets in command line when one sets qvm-prefs default_dispvm to '*default*'.)

Now a third Appvm: brave-dvmt. It fires up brave. dvm-template set to true;
And a Named Disposable, “Brave”

If I go to the named disposable Brave’s settings, pick the dropdown for setting its default disposable, at the very end I see “default (brave-dvmt)” NOT “default (viewers-dvmt).” That’s my complaint. and if I set Brave qvm-prefs default_disposable to '*default*' it is again set to brave-dvmt.

OK so if I understand you, had I not set firefox-dvmt’s default disposable, its spawned unnamed disposables would also have their default disposables set to firefox-dvmt. (their parent dvm-template).

And I could conceivably get the named disposable (Brave) to behave the way I want by NOT trying to set its default disposable, but instead setting brave-dvmt’s default disposable.

OK let me try that out.

19

Unfortunately, that didn’t work. Referring to my previous example:

explicitly setting brave-dvmt’s default_disposable to default (viewers-dvmt), then creating a new named disposable; the named disposable’s default_disposable is “default( brave_dvmt )” not “default( viewers-dvmt)”. So no matter what, I must explicitly set all named disposables’ default_disposables to viewers-dvmt, and if I ever want to rebuild the template (viewers) or dvm-template( viewers-dvmt ) I not only have to temporarily change the system default, I have to hunt down all of the named disposables on the system and temporarily change their defaults as well (because I will have set them to viewers-dvmt explicitly, brave-dvmt being useless for that purpose), before I can delete and rebuild viewers and viewers-dvmt. So that means going to qubes-prefs, changing that setting, and then going to Brave and changing its default-disposable.

Why, oh why, do disposables just disregard the system setting?

20

See the message in the linked commit from 2019. To flesh it out a bit:

Say a user clicks on “view in disposable” for a file or a link.

They’ve taken care to set up the disposable template used for this (and hence the disposable instantiated from it) to have some sort of more isolated perspective: Maybe it is connected to a proxy. Or maybe it has a different software selection, because they don’t want the potential malware handled by the disposable to have any insight into what software they normally use.

Malware in the disposable can launch another disposable from within. If Qubes OS used the global default disposable template for that one, it would be an easy breakout from the intended isolation. The user would have to avoid this by never forgetting to explicitly configure the isolated disposable template to use itself for launching new disposables. Which is quite easy to forget though. Or more likely, to not even consider the finer points of default_dispvm property inheritance (from disposable template to disposable) and its relation to global default fallbacks, until it’s too late. Qubes OS makes a trade-off that avoids this footgun and defaults to a safer setup, at the cost of now requiring annoying configuration (per disposable template) to opt into the potentially less safe setup.

So that’s a way of justifying the special behavior for an unnamed disposable launching another unnamed disposable. This special behavior also affecting a named disposable launching an unnamed disposable seemed to me like it was just a side effect of the implementation. But in the PR discussion, people appreciated consistency in the behavior of disposables, whether named or unnamed.

FWIW, try clearing its ‘private’ volume: How to initialize the default dvm template - #4 by rustybird

1 Like