Disposable Whonix setup

I installed Qubes 4.1 with a disposable sys-net and disposable sys-firewall. I would also like a disposable whonix gateway and disposable whonix workstation that play nice together so all of the VMs in a given session are disposable.

So…

I created sys-whonix-dvm and configured it in dom0 as a disposable template and I set the NetVM as sys-firewall.

I also created anon-whonix-dvm and configured it in dom0 as a disposable template.

The problem arises when I select a NetVM for the workstation. If I choose sys-whonix-dvm and launch a disposable instance of anon-whonix-dvm, dom0 spawns and connects the new workstation to the template sys-whonix-dvm (instead of a disposable instance of sys-whonix-dvm) - which, of course, makes sense because I told dom0 to do exactly that. :slight_smile: But that’s not what I want.

If I first launch a disposable instance of sys-whonix-dvm and then manually change the NetVM for the anon-whonix-dvm template to the randomly named instance (ex. disp3453) and then launch a disposable instance of anon-whonix-dvm, I will have two disposable whonix instances networked together (although I have to restart Tor in the gateway instance for some reason).

Is there a way to set the NetVM for the workstation template so the disposable workstation instance networks with the disposable instance of a given template rather than the template itself?

All of that said, I am obviously doing this to enhance security (presumably starting with a fresh instance of whonix gw & ws every session) - mostly in an attempt to mitigate the use of javascript while using Tor. But are there any drawbacks or risks associated with this setup (aside from the logistics of getting it running)?

Oh… one other thing. When I do finally get both disposable whonix VMs running together, for some reason, the standard sys-whonix VM keeps launching. Any idea why that is happening? It’s actually not uncommon in other situations for sys-whonix to spontaneously start up as well. Not a fan of that.

Oh - make it two other things - I later noticed that one of the disposable instances of my whonix gateway template persisted after it was shutdown. It was listed in Qubes Manager with the rest of my inactive VMs. I suspect that is because dom0 couldn’t delete it because it was set as the NetVM of another qube. Not sure if that is expected behavior or a bug - but I suspect it would not be desired behavior in most situations. Hopefully a better way of naming the NetVM for a disposable template would prevent that problem.

qvm-run distinguishes between templates and disposable instances of templates with

--dispvm=<templateVMname>

It would be nice if something similar existed for the qvm-prefs netvm property. Something like

qvm-prefs <VMname> netvm --dispvm=<templateVMname>

hmm… :confused:

@necker:

disposable whonix gateway

bad idea, you would reliable use the very same entry node always (at least at the beginning of your session)

Well that’s no good. But if it’s using the same parent template, why wouldn’t it be randomized like in a persistent gateway VM?

Either way, I suppose a disposable workstation is all I really need to mitigate JS browser attacks.

Thanks for the heads up.

Somehow I missed the following post before creating this thread. Disposable sys-whonix persistent settings - #4 by deeplow

The problem isn’t that a disposable gateway would result in the same entry points but different entry points every time Tor connects. That lack of persistence in initial entry and exit points makes them easier for an attacker to correlate over time. Very counterintuitive and interesting.

Apparently this is an ongoing issue for the developers of Tails due to it’s lack of persistence - but their solutions to the problem aren’t applicable in Whonix because of differences in network configuration.

4 Likes

Excellent find. I stand corrected.

and if use different bridges every time?
why not configure sys-whonix (run anon-connection-wizard first) and then make it disposable template?