Even that didn’t help. The value of default_dispvm is not visible in any log either and the default dispvm is still whonix-16-ws-dvm.
Another thing which caught my attention is that this script refers to template.features. I don’t know if that “features” is the same “features” which qvm-features manipulates but it seems worth noting because qvm-features doesn’t seem able to change default_dispvm. Only qvm-create and qvm-prefs can do that and there is no “craete” or “prefs” anywhere in the Python script.
Did you try with fedora based dispVM? It works for me, but I disabled default dispVM, and rather prefer dialog box to choose dispVM when “view/edit in dispVM” is clicked.
Yes, right after reading your reply, I have set default_dispvm (yes, through UI settings) of whonix-ws-16-dvm to Fedora based DVM and then it works. I have not touched any policy.
Then I tried the following:
In Qubes Global Settings I set the disposable template = none (it was d12-m-dvm).
After that, setting d12-m-dvm as default_dispvm of whonix-ws-16-dvm worked too.
Then, I went back to Qubes Global Settings and reverted the change, setting default disposable template again to d12-m-dvm, and started a whonix-ws-16-dvm based DispVM. Result: works as expected with default_disvmp=d12-m-dvm.
IOW, there doesn’t seem to exist any network leak protection at all. The problem is that is seems impossible to use the globally default disposable template without the gymnastics from above.
I know that a numbered disposable, when launched, invariably makes its own dvm template the default dvm, regardless of what you have the global default set to. It also doesn’t matter what the template’s dvm is.
OK, that’s probably very confusing to read. So, let me do an example. I have a template with firefox (firefox-tmpl). I create an appvm and make it a disposable template: firefox-dvmt.
I then create another template with document viewers on it, global-tmpl, and base global-dvmt off of it; I want global-dvmt to be the default dispVM for everything. It’s isolated from networks and has apps needed to view documents on it.
So I set the global dvm to be global-dvmt. Normally that’s now the disposable template for qubes. Appvms will use it. It’s even the disposable when I am running firefox-dvmt itself. (In qubes-mgr firefox-dvmt’s default dispvm is global-dvmt.)
But when I launch a disposable disp1234 off of firefox-dvmt, disp1234’s disposable is firefox-dvmt, NOT global-dvmt. There’s no way to prevent this because the qube is created right then and there. You have to go into its settings and change it to global-dvmt, AFTER you start it.
I really don’t like this. Because I probably didn’t install document viewers and the like on firefox-tmpl, thinking that that was global-tmpl and global-dvmt’s job. The way this is set up requires you to install document viewers and the like on the same template as your browser.
If you have an e-mail client (rather than using webmail through a browser), that client is probably a regular AppVM (so it will remember things like your email inbox from one run to the next), so it’s not that big an issue then–attachments will go to global-dvmt. But even so, what about documents you download off of a website?
Interesting. I don’t experience what you describe (using Qubes 4.1.2) with non-whonix disposables.
There’s no way to prevent this because the qube is created right then and there. You have to go into its settings and change it to global-dvmt, AFTER you start it.
There is a way. You can achieve this, if you follow what I described above:
In global settings, set disposable template = none
In your DVM (firefox-dvmt), set default_dispvm=global-dvmt
The other option is to use the script for RAM based disposables.
what about documents you download off of a website?
I proceed with those like this:
If I am not going to open the file (but just store/copy it), in the AppVM, I have default action for the file type called “nothing”. It is a simple bash script I place in /usr/bin:
#!/bin/bash
exit
This prevents me from accidentally double clicking on a file in Thunar and opening it in the AppVM. Perhaps there is a way to make this the default action for all files in the template itself, so that I don’t need to do it in every AppVM, but I still have not done this.
For files which I am willing to open, I either right click and “View in VM”, or I have default action qvm-open-in-dvm which opens the file in my version of your firefox-dvm based disposable. Yes, it works. Currently I am working on customizing the default action, so that files open in RAM based offline disposables. Then even RAM disposables will be able to open files in other RAM disposables.
But that’s the point. You shouldn’t have to go through those gyrations. I’m agreeing with you in comment #14 that it might be a bug.
Also, I described a specific use case where (it seems to me) the actual behavior is nonsensical. So, is this deliberate? If so it’s a “feature” rather than an out-and-out bug,* but I think it needs to change either way.
As for the rest of what you wrote, thanks, it’s good info.
Note* Bug: The code doesn’t behave as the developer(s) intended. Feature: The code behaves as the developer(s) intended, but you think the developer(s) shouldn’t have intended it that way–in other words you’re arguing with their design decision, not their implementation.
In fact a common complaint is a dvm that cannot handle a file, so it hands it off to its default disposable. That can loop forever if it is its own default disposable. I could sometimes be racing to kill dvms faster than they’re being created when this happened.
This seems to encourage that to happen, on top of all of our other complaints about it.