Hi cprise! Nice to see you! 
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.
