- Dedicated DisposableVM Template
- Non-dedicated DisposableVM Template
What is the difference between a dedicated and non-dedicated disposable VM?
I was trying to understand that myself. It sounds like that’s a conceptual distinction more than anything. Maybe we should start another thread with that question to see if anyone knows? I’m also curious.
@bill Btw, I think you mean “difference between a dedicated and non-dedicated DisposableVM Template”
Yes that is correct.
(Formerly known as a “DVM Template”.) A type of TemplateBasedVM on which DisposableVMs are based. By default, a DisposableVM Template named
fedora-XX-dvmis created on most Qubes installations (where
XXis the Fedora version of the default TemplateVM). DisposableVM Templates are not TemplateVMs, since (being TemplateBasedVMs) they do not have root filesystems of their own to provide to other VMs. Rather, DisposableVM Templates are complementary to TemplateVMs insofar as DisposableVM Templates provide their own user filesystems to the DisposableVMs based on them. There are two main kinds of DisposableVM Templates:
- Dedicated DisposableVM Templates are intended neither for installing nor running software. Rather, they are intended for customizing or configuring software that has already been installed on the TemplateVM on which the DisposableVM Template is based (see DisposableVM Customization). This software is then intended to be run (in its customized state) in DisposableVMs that are based on the DisposableVM Template.
- Non-dedicated DisposableVM Templates are typically AppVMs on which DisposableVMs are based. For example, an AppVM could be used to generate and store trusted data. Then, a DisposableVM could be created based on the AppVM (thereby making the AppVM a DisposableVM Template) so that the data can be analyzed by an untrusted program without jeopardizing the integrity of the original data.
Specifically, note how it explains the distinctions between installing software in the TemplateVM, then customizing or configuring the software in the DisposableVM Template, before finally running the software in the DisposableVM.
If there’s something unclear about this entry, please point to the specific line and state what’s unclear about it so that I can improve it.
Minor pet peeve : The phrase “beg the question” means to assume the conclusion for which one is arguing. In your sentence, I would use a phrase like “raises the question” instead.
Thanks, @adw. But I’m still a bit confused – not regarding anything specific in the description. My confusion is how this difference is implemented in practice.
In other words: this is not a setting that you check like
- dedicated non-dedicated
Instead it is more about how you use it. Is this right? If so, then it may help adding “depending on how you use it” just after “There are two main kinds of DisposableVM Templates”.
I believe that all other definitions in the glossary are explicit settings that one can tweak, hence the confusion.
To test my assumptions (not making a feature proposal): a menu shortcut for an appVM called “start as DisposableVM” would start it as a non-dedicated DisposableVM?
Thanks for the correction
FYI, this is not a unique situation. The same kind of thing occurs, for example, in Static vs. Custom DVMs…
That was my first thought too. However, I think maybe what the author of that doc meant is that it’s okay to run apps in in a dedicated DVM, but only to the extent that is necessary for customizing it, not for day-to-day usage. That is to say, DVM templates should be thought of like regular TemplateVMs, in that they should have networking disabled, and you shouldn’t run any apps in them unless you have to, but sometimes you have to. (Remember, running apt, or gnome-terminal, or even ls, in a TemplateVM is still technically running something in a TemplateVM, so there can be no hard-and-fast rule against running anything in a TemplateVM.)
Think of it this way. Even if you ran Firefox in an instance of fedora-30-dvm, say disp1234, made your customizations there, and then copied /rw from disp1234 into a new DVM template, say, fedora-30-custom-dvm. In this case, you’ve strictly adhered to the rules, but what have you actually accomplished? If firefox turned out to be exploited or malicious, then what have you done to prevent it from infecting ~/.bashrc, or side-loading a malicious browser extension in ~/.mozilla/profile.default/extensions/, or whatever, now that you’ve copied those malicious changes back to a permanent (so-called “dedicated”) DVM template? You might as well have just created fedora-30-custom-dvm and done your customizations directly in there, even though that technically violates the rule against running software in dedicated templates.
What do you mean “typically”? Is there ever a case, in Qubes 4.0, where a DisposableVM Template can have anything other than “AppVM” under its “Type” field in the VM settings dialog? (A running DispVM, such as disp1234, it has type listed as “DispVM”, but that’s not a “DisposableVM Template” then.)
Is it not also true that Dedicated DisposableVM Templates are AppVMs on which DisposableVMs are based? If so, then why is this stated specifically under the Non-Dedicated DisposableVM Templates section? Wouldn’t it be more correct to just say “DisposableVM Templates are AppVMs on which DisposableVMs are based”?
Yes, just like how “literally” now means “figuratively” in modern vernacular. Doesn’t mean it’s not still frustrating
it’s okay to run apps in in a dedicated DVM, but only to the extent that is necessary for customizing it, not for day-to-day usage
Would this sounds reasonable?
Agreed - frustrating. Even more so when folks insist on debating with not only no attempt to define terms, but active resistance to it! But, let’s not go any further down this rabbit hole(s)!
To the thread topic, how about splitting things into:
- Definitions. That are rigorous, by specifically describing a setting or something else definitive. Such as “A DisposableVMTemplate is an AppVM which has template_for_dispvms set to true”. Ambiguous words such as the pointed-out “typically” would be forbidden.
- Example Use Cases. Where for each Example one can talk about dedicated or not, running them temporarily with or without netvm set, etc.
Regarding user burden, it’s important to remember Qubes overall focus, and that some increased user burden is included by definition. The task is to minimize that to reasonable levels, and hopefully confine it as much as possible to infrequent setups rather than every day activities.
Correct. It’s not an explicit setting but rather about how the user uses it. I take your point.
Not entirely. See below regarding “AppVM.”
That’s basically right. (I’m the author, btw.) Suppose you browse the web in a DisposableVM Template, and your DisposableVM Template gets compromised as a result. Do you really want to launch a bunch of pre-compromised DisposableVMs based on that DisposableVM Template? Of course not. You want your DisposableVM Template to remain as clean as possible, so that you can rely on new DisposableVMs being clean. I think that this is highly intuitive once we understand how DisposableVMs and DisposableVM Templates work. This glossary entry just states it explicitly. However, as you’re all pointing out, there’s a big risk in stating things explicitly! People can misunderstand what’s being said (or the intention behind saying it) in ways that complicate matters that are already intuitively understood. Moreover, this is a glossary entry. It’s not a guide or tutorial. So, I think it was probably a mistake for me to include this sort of text here, even though it was meant to be helpful.
Qubes is concerned with practical, real-world security. When we say things like “running applications,” we mean running applications that have a realistic chance of harming your security, e.g., using a web browser to browse typical websites. These are not rules in the sense of a theoretical exercise. They’re practical guidelines for users, and they also depend on the user’s threat model and risk tolerance. If we’re concerned about
ls, then the game is already lost due to the security holes from upstream software, hardware, and firmware over which Qubes has no control. This is why our slogan is “a reasonably secure operating system.”
There’s an unfortunate ambiguity in the term “AppVM.” Before Qubes 4.0, when the entry for “AppVM” was written, the only definition of “AppVM” was “a VM that is intended for running software applications.” In other words, it wasn’t a technical property of the VM itself but rather a matter of how the user uses the VM (see above). However, beginning with Qubes 4.0, the term “AppVM” started being used in a new, additional way to refer to a specific type of VM at the technical level. This was unfortunate in the sense that the ambiguity could have been avoided if a different term had been chosen or invented. Now, you can have an AppVM (in the technical sense) that is not intended for running software applications, which is basically what DisposableVM Templates are. This is yet another reason to remove the text under discussion.
At this point, I wouldn’t want those in the glossary. They should be moved to some other appropriate doc page instead, such as the one covering DisposableVMs.
I’ll make some changes now, but PRs are always welcome. As I often say in qubes-issues, the documentation is a community effort, and everyone is welcome to contribute. You can read more about how to submit documentation changes here:
Thanks for clearing up the concepts and making the docs have the high quality they have. (Expect future contributions from me )
If you’re interested in the history, take a look at this issue:
and this PR:
Thank for the links.
I’m now making the conceptual model of some of these terms to see if they make sense and I was noticing some things like this that may generate some user confusion (I might do a post on that in the future) – But I’m mostly doing it to clear up the concepts in my head. Haha.
Here’s a sneak peek of that:
One quick thing: “AppVM” and “TemplateBasedVM” are now synonyms.
That was also how I though (before doing the diagram) but while doing the diagram I guess I mixed two definitions. I feel a bit more sane now thanks!
Agreed. They for sure should not be in the Glossary. Thanks also for the great docs!
That cleared it up for me. Thanks!