Continuing the discussion from Qubes DispVM technical discussion:
This post has a Qubes feel to it because it was originally to be posted in Qubes-Whonix sub-forum. Halfway through though, I realized it was applicable to all Whonix flavors. The concept of Template VMs are universal, just called different things, ie base images. In short, separate VMs are not enough to guarantee identity isolation if customization parameters are shared by those VMs and are discoverable.
Here’s my draft:
It is strongly recommended to never run user applications (especially network-facing ones) in any type of template VM. This is because applications often generate files, that when propagated to child VMs, can result in VM-linkability. For example, starting Firefox and connecting to a website might result in the download of unique cookies. Some applications may generate a random number seed that could be used to identify the VM uniquely.
In the case of Tor Browser, an exception may be made to allow for customization. However, it should be clearly understood that the best practice, as recommended by The Tor Project, is to use Tor Browser in its stock configuration. This is because Tor Browser has a very deliberate fingerprint, one that is designed to be shared by all Tor Browser users. Even seemingly innocuous changes, like enabling the NoScript option to ‘Show message about blocked scripts’ can alter the fingerprint by changing the reported screen size. Further, while Tor Browser is designed to prevent any type of linkability through fingerprinting, issues past and present suggest that it is not perfect. These issues are only magnified by using a custom configuration that is shared by multiple VMs.
But after re-reading the original text, I changed my mind. Here’s a very relevant ticket to our situation: Browser configuration fingerprinting (#14390) · Issues · Legacy / Trac · GitLab. This bug is still embargoed after 2 years?!?!? Given something like that, how can we recommend anything other than best practice / stock configuration? In fact, I think we need to do the opposite and whitelist things that are safe to customize in templates for Tor Browser.
- Can you customize the toolbar? Add/remove buttons?
- Can you change Preferences?
-update preferences? (I find it very useful for disposableVMs to set update to notify-only instead of auto)
- NoScript? disable JS?
- TorButton? change security slider?
What about other applications? I’m sure most users have a favorite terminal and a set of preferences for it. Even if you don’t customize a terminal in your template VM, if you then perform the identical customization in each of your user VMs, the result will be the same. An adversary that gains user-access to your VMs will be able to link them together based solely on your config files.
With Qubes, we rely on the fact that attackers with user/root privileges don’t necessarily constitute an existential threat. From a privacy perspective, it could be game over. So do we need to construct a list of customizable apps? or just tell everyone to live in misery with all default settings?