Maybe:
qvm-features minimal-offline-dvm whonix-default-dispvm 1
Nope. That still doesn’t give the desired result.
You’d need to add debug output to that python script (print()) to see what’s happening. The file location in dom0 is:
/usr/lib/python3.11/site-packages/qubeswhonix/__init__.py
OK. On my (up-to-date) 4.1.2 system the directory is python3.8 (not 3.11). I don’t know if that matters. Just mentioning it.
So, I added print(default_dispvm) inside on_domain_add function, properly indented, right after all the checks related to its assignment, and ran:
user@dom0:~ > qvm-run -v -q -a --service --dispvm=whonix-ws-16-dvm -- qubes.StartApp+janondisttorbrowser
Running 'qubes.StartApp+janondisttorbrowser' on $dispvm:whonix-ws-16-dvm
IOW, it doesn’t output anything. I don’t know how output is handled internally among those Python scripts but it obviously doesn’t show on CLI.
Then I tried hard coding default_dispvm and logging it by adding this at the very end of on_domain_add:
default_dispvm = 'd12-m-dvm'
vm.log(default_dispvm)
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.
So far, the only way through which I was able to manipulate this successfully is through the bash script for creating RAM based disposables which does it through qvm-create.
Please let me know if there is a way to fix that Python stuff.
1 Like
In that case, we need a Qubes developer to give a hint on how to enable print debug output.
Another hacky option in these cases is writing the debug output to a log, maybe quick and dirty somewhere in the home folder.
In that case, we need a Qubes developer to give a hint on how to enable print debug output.
How do we invite one here?
Another hacky option in these cases is writing the debug output to a log, maybe quick and dirty somewhere in the home folder.
How to do that?
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.
# qubes.OpenInVM * @anyvm @dispvm allow
qubes.OpenInVM * @anyvm @anyvm ask
in a correspondent RPC policy.
Did you try with fedora based dispVM?
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 wonder if this needs a bug report.
Such things made me use fedora everytwhere, except cacher-ng of course. Qubes is just designed based on and for Fedora.
IIUC, the issue is not Fedora or non-Fedora. It seems related to default global disposable setting.
What is cacher-ng? (please link to whatever doc/thread is relevant, thanks)
1 Like
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.
I’m guessing you opened that. If so, thanks!
Interesting that it was indeed a deliberate decision. It makes no sense to me.
Yes.
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.
so it hands it off to its default disposable.
How exactly does this work?
I honestly couldn’t tell you now. This was something I was dealing with in my early days of qubes last year (2022), I’d sometimes get into a loop where a disposable kept opening another copy of itself, ad infinitum, because (apparently) its default action for some file type was to open up a disposable…and it was its own default dvm.
I solved that problem by making my actual target disposables have NO default dvm–which to me makes sense; that VM is a destination, not a way point. Then I was just left with having to make sure the target disposable knew what to do with the file type, otherwise it would fail in other, more graceful ways.
(So you may be wondering why I am griping about this if my target DVMs have default dvm set to none–it’s because not every DVM I have is a final destination. In fact almost all of my VMs are disposables that connect to offline storage. In most cases they are named disposables, but web browsing uses a disp1234 type disposable.)
Again, this becomes more likely if a disp1234’s template is set up so that disp1234’s default dvm is that same template (regardless of what that template’s default template is)…which again appears to have been done deliberately for some reason I cannot fathom.