[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [DONATE]

Are 2 templates necessary?

Hi! Thanks for the work you’re doing toward a good Tor solution on Qubes. I am using Whonix Qubes now and it seems to be working very well for such an early release.

It did occur to me that maybe two whole OS templates for Qubes might not be necessary in the long run. Without having delved into the details of Whonix yet, it seems like you could eventually make one template serve both gateway and app roles based on a simple condition; A hostname with a suffix of “-gw” could trigger a startup script that is geared to running the gateway. Otherwise, the VM would act like an app system.

I realized this when I saw some of the behavior in the two templates is already the same (the sanity check program appears in both VM types, and even tells me I should upgrade Tor browser in the gw ;D ).

Thanks again…

Hi cprise! Nice to see you! :smiley:

From a Qubes perspective, you might be right about this.

Sidebar: Let me make a distinction about your point for others here… You’re not talking about doing away with the TwoVM operational configuration of having a Whonix-Gateway and Whonix-Workstation running together, for the purpose of isolating the Tor proxy from the user space. Rather, you are talking about sliming down the distribution of template files to one single VM template that can be used to create both the Whonix-Gateway and Whonix-Workstation VMs. Like how the single Fedora template in Qubes can generate both ProxyVMs and AppVMs from the same single template.

First, due to the TwoVM Tor isolation concept, I don’t know if there would be any fatal security flaws to including all of the same Gateway & Workstation packages into each template, where malware could reconfigure the VM with all of those packages? There is already Tor-over-Tor protection in the Workstation provided by a Whonix package. And malware could install whatever packages it wants. So maybe both VMs could sanely include all the same packages due to fundamental VM isolation and forced ProxyVM routing.

The use of Whonix in Qubes in still only a few months old, since my original port. And Whonix is still primarily developed with VirtualBox as the primary virtualization platform in mind. Maybe this will change in the future, especially as the Qubes R3 Odyssey framework becomes public and stable, so that Qubes can be run on top of other existing platforms, like Windows, KVM, etc.

Right now, the 2 Whonix templates (Gateway & Workstation) are both built from one single code repository. And the --tor-gateway and --tor-workstation parameters are used to differentiate the type of template that gets built.

The Whonix code would likely have to be refactored to merge the two templates into one.

And Whonix would have to have some hook for knowing if was being used as a ProxyVM (Whonix-Gateway) or as an AppVM (Whonix-Workstation), and dynamically change its functionality like the Qubes Fedora template does.

To me, this makes sense overall. But, making it a reality might depend upon how Whonix’s relationship with Qubes grows in comparison with its other virtualization platforms, and the priority/effort involved to refactor for this single template optimization.

I’m not sure about the “hostname” variable switch for Gateway vs. Workstation. Probably unnecessary and hostname is already anonymized to generic value of “host” for fingerprinting. Ideally the VM would auto detect the correct VM type, like in Qubes, and auto configure itself.

If needing to manually set a variable in Whonix when using other virtualization platforms, like VirtualBox, then messing with the “hostname” variable shouldn’t be necessary. Rather, in something like the existing “whonixsetup” script or “first run initialization” script, the user could be forced to choose Whonix-Gateway or Whonix-Workstaiton and the system could store that variable anywhere convenient in the filesystem. That could be the manual way for platforms where it couldn’t be auto detected like is possible in Qubes.

So like this…

One Whonix Template:

  • In Qubes: Auto-Configure based on ProxyVM or AppVM setting.

  • In VirtualBox: Manually configure upon first setup, choose Gateway or Workstation.

Or, here is an alternative idea, if that would be asking too much for VirtualBox users…

Build and offer 1 Whonix template file for Qubes users.

Build and offer 2 Whonix template files for VirtualBox users.

But they can come from the same integrated build script that has the ability to build a merged or separated VM template type.

Just using simple examples here to demonstrate principle as I know there are additional platforms.

Overall, I like the idea of having, at least the option of, one integrated Whonix template (assuming there are not fatal insecure design issues).

The refactoring work, other feature priorities, and platform market conditions for Whonix, might be limiting factors for seeing this happen though. Not sure. That would be more in Patrick’s domain right now.

But, in the “long run”, as you mention, the concept of optimizing to having the option of using one integrated Whonix template makes sense to me, especially in Qubes.

And Qubes R3 Odyssey framework expands the Qubes system’s reach out to working within other platforms, like Windows, KVM, etc, where an OS reinstall or multi-booting is no longer necessary to use Qubes + Whonix.

In Qubes, I can already distinguish if VM is running as a template, gateway (ProxyVM) or workstation (AppVM). I already use common init scripts between all states which complete certain tasks based on what type of VM it is.

I'm not sure about the "hostname" variable switch for Gateway vs. Workstation. Probably unnecessary and hostname is already anonymized to generic value of "host" for fingerprinting. Ideally the VM would auto detect the correct VM type, like in Qubes, and auto configure itself.

I handle this on init as well since Qubes by default sets the hostname.

Guess Patrick just needs to decide of its a good idea or not.

Common, shared code is great. Trying to use it everywhere possible.

However, Whonix wasn’t implemented with the good idea of “a single switch can change the behavior from workstation to gateway and vice versa” in mind. When Whonix development started, no one had Qubes’s architecture in mind. I see for Qubes it would be useful. For other platforms such as VirtualBox, having for example XChat installed in the gateway and Tor in the workstation wouldn’t be useful. Whonix was developed in mind to cleanly package a fine, shared configuration for a workstation or gateway machine. Some (configuration) packages are gateway specific (https://github.com/Whonix?query=-gw-), others are workstation specific (https://github.com/Whonix?query=-ws-). Dynamically choosing the gw or ws specific /etc/network/interfaces might be possible somehow. Maybe using custom scripts (preserving user modifications) (fragile) or (auto chosen) boot options that mount different /etc or something like that.

At the moment there are two packages which install a so called marker file, that allows other packages such as whonixcheck detect whether they are running in a workstation or gateway:

But that could also be implemented as VirtualBox setextradata setting (which can be used to create some unique hardware string somewhere, that can be used to distinguish if running in gateway or workstation mode). Similar mechanisms might exist for KVM and Qubes.

Yes, it might be possible. But I think it would be a lot work to implement such a Whonix-Morphstation.

[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Investors] [Priority Support] [Professional Support]