I just updated my whonix-ws-16 because I saw the DVM was using an out of date Tor browser. After updating I had to reboot the DVM and I noticed the Disp qube did not reset or anything and I am worried this is unintended behavior.
Looks like DVM is still a template, just had internet access and the real disposable is the disp, starting to make more sense.
So this is expected behavior, and after updates you should shutdown disp qubes and start the process anew from the DVM.
If this understanding can be confirmed as the reality of the design, that’d be appreciated. Hopefully this question and answer helps anyone who comes across it in the future.
If I understand correctly what you wrote, I think you’re correct!
This is how the inheritance chain for disposables works:
The template (templateVM) is like any other template (no network, etc), and its role is mostly to provides the system directories
A “regular” VM (appVM) based on that template has a special option enabled to become a template for dispVM. That allows it to be used as a template for disposable VMs. It provides them with its home directory (and the system directories that it itself got from the templateVM, does that make sense?)
A disposable VM (dispVM) that is created using the appVM as a template
Now, when you want to update a regular appVM after making changes to a templateVM, you need to shutdown the templateVM and restart the appVM.
Similarly, when you want to update a dispVM after updating the appVM that it originates from, you need to shutdown the appVM and restart the dispVM.
Depending on what you want to add or remove from your dispVM, you might end up, for example:
installing a package in the templateVM (since that modifies the system directories, it must be done in the templateVM if you want the changes to be persistent)
shutting down the templateVM
restarting the appVM (if it was running) so that it is updated with what changed in its template
starting the appVM and configuring your new app (assuming that config gets stored somehwere in the /home/user directory)
shutting down the appVM
(Re-)starting the dispVM (which now contains both the new package and the config, respectively from the templateVM and the appVM-that-is-a-template-for-dispVMs) Pfeww!
I answered a similar question with a little “drawing”, that you might find useful:
And here is the relevant section of the Templates (Inheritance and persistence) documentation:
Thanks a bunch @gonzalo-bulnes, and I just tested to answer my follow up question: Can I just make DVM template to isolate programs from each other? The answer appears to be yes. Downloading an image to the Downloads directory in a disposable and trying to see the file in disposable VM based on the same DVM template shows no such file, so good news for simplifying your qubes layout. I would probably know this by reading documentation but half the fun is figuring it out along the way lol.
You’re welcome! And, yes, that’s correct too. What you do in a disposableVM doesn’t affect other disposableVMs, even if they’re based off the same disposable template (appVM).
Note that that’s similar to how what you do in an appVM doesn’t affect other appVMs, even if they’re based off the same templateVM.
That behavior is what makes dispVMs a possible mitigation for malware. If something you do in a dispVM triggers the installation of a piece of malware (be it visiting a website or opening an email attachment), then that malware will only have access to what happened in that specific dispVM. If additionally the dispVM has no network access (e.g. a dispVM to view untrusted documents that may contain malware that may try to “phone home”), then you’ve got yourself a sandbox that’s destroyed with anything malicious once you close it.
Depending on your threat model and needs you could decide to only opening untrusted documents in a dispVM, an only one per dispVM. Even to have distinct disposable templates with software to see PDF, videos etc.
That’s the kind of granularity that the design allows.
Edit: see the “Open in dispVM” entry in the contextual menu of some appVMs, and the appVM setting that defines which disposable template is associated with that appVM.
