Automated Qubes AppVMs based on Whonix Anonymity Modes
I love QubesOS. I use it as a daily driver for a lot of things at this point, especially compartmentalized communications. Many people I speak to use Qubes as well, so I often pick their brains about use cases, threat models, and what bells and whistles they’ve set up on their system.
I was speaking with one person in particular about how they manage privacy schemes with AppVMs, and they told me about how they rely on following guidelines put forth by Whonix in their wiki (located on the Whonix Anonymity Modes page). This idea makes a lot of sense to me, and I was eager to try it out.
Understanding Anonimity Mode levels
To me, a fundamental understanding with these different anonymity modes is data retention. If you are posting something to a public forum with a username connected to your actual identity in one way or another, its good to get into the mindset that you “left a piece of you” somewhere. The internet in constantly mined for user content and metadata: your contact information, your “likes”, your political opinions and ideologies, etc. It is every marketing agency’s dream to be able to tie everyone’s account details to one another to paint a mosiac of a user’s desires - data brokers have big dreams of operating as if they were intelligence agencies. There are already Open Source Intelligence tools that do just this.
Thus it is necessary to use threat modeling and carefully consider use cases based on activity against the proper tools and connections.
Whonix’s Anonimity Mode Levels stand as a nice spectrum in approaching things this way. Each Mode is applicable to different types of sitatuations and with Qubes, we can build AppVMs respective to each Mode for these varying situations.
Anonimity Mode use-cases
Let’s inspect the Whonix’s Documentation page titled “Tips on Remaining Anonymous”.
Whonix’s documentation is careful to define the clear differences between what should be considered Anonymity and Pseudoanonimity, which is key factor in operational security with this set set up:
- Anonymous connection: A connection to a destination server, where it has no ability to discover the origin (IP address / location) of the connection, nor to associate any identifier with it.
- Pseudonymous connection: A connection to a destination server, where it has no ability to discover the origin (IP address / location) of the connection, but it can be associated with an identifier.
The key here is not to solely think about things like originating IP, but also unique identifiers used in tracking cookies and other technology as well as user information. To put it plainly in an example, the act of logging into an account with a username and password turns what could have been an “anonymous” connection into a technically “pseudonymous” one - it is a connection that does not reveal your actual originating IP, but does reveal your specific user information.
A poigniant and somewhat contraversial quote from a developer of the now defunct Liberte Linux drives the point a bit further:
I think we get it now. This is where the different Whonix Mix Anonimity Modes come into play:
Mode 1: Anonymous User; Any Recipient
- Scenario: Posting messages anonymously in a message board, mailing list, comment field, forum and so on. - Scenario: Whistleblowers, activists, bloggers and similar users. - The user is anonymous. - The real IP address / location stays hidden. - Location privacy: The user's location remains secret.
Mode 2: User Knows Recipient; Both Use Tor
- Scenario: The sender and recipient know each other and both use Tor. - Communication occurs without any third party being aware of this activity or having knowledge that the the sender and recipient are communicating with each other. - The user is not anonymous.  - The user's real IP address / location stays hidden. - Location privacy: The user's location remains secret.
Mode 3: User Non-anonymous and Using Tor; Any Recipient
- Scenario: Logging in with a real name into any service like webmail, Twitter, Facebook and others. - The user is obviously not anonymous. As soon as the real name is used for the account login, the website knows the user's identity. Tor can not provide anonymity in these circumstances. - The user's real IP address / location stays hidden. - Location privacy. The user's location remains secret. 
Mode 4: User Non-anonymous; Any Recipient
- Scenario: Normal browsing without Tor. - The user is not anonymous. - The user's real IP address / location is revealed. - The user's location is revealed.
Think of these as use cases based on threat models, but also - in the context - as compartmentalized VMs. These scenarios can work quite well paired with the designated AppVMs on a QubesOS system. For instance - where a Mode 1-based VM is a generated AppVM titled
mode-1 using the
whonix-ws template-VM and
But we can do one better here - we can get a freshly installed QubesOS system off the ground with this setup. Let’s create an AppVM for each of these Modes using infrastructure management via Salt.
Generating the AppVMs with Salt
Ever since way back with version R3.1, QubesOS users have been able to utilize the Salt management engine to build and control Templates and AppVMs from the
dom0 level on their system.
This comes in handy for quickly deploying VMs based on an
.sls file - or “Salt State File” - configured by a user. I have built a repo on github with these state/config files for AppVMs respective to each one of these Modes.
Here is an example of the
.sls file for the
Mode 1: Anonymous User; Any Recipient create-mode-1-vm qvm.vm: - name: mode-1 - preset: - template: whonix-ws - label: red - mem: 3000 - prefs: - template: whonix-ws - netvm: sys-whonix
“Sitting above” the
.sls files is a
.top file that serves as a deployment file for the grouping of machines here. Here is the
.top file needed to generate all the Modes-based AppVMs - based on their
.sls files - from
base: dom0: - mode-1 - mode-2 - mode-3 - mode-4
Pretty simple, huh? It is basically just pointing to the
.sls files and will take the underlying metadata to build each of these AppVMs. So let’s get started with pushing this out with these following steps:
- It is best not to copy things to
dom0with the QubesOS tools to do so, as you would normally do from AppVM to AppVM - this has been noted as a security risk. Knowing this, it might be best to clone the repo here and copy the underlying files in a bit more of a manual way here…
- You will want to put your
.topfile somewhere such as
.slsfields in the same directory, like so:
- Enable the
dom0terminal with the following command:
qubesctl top.enable qubesmodes
- Let’s make sure we see the
.topfile we created for this in the output after this command, which is used to check enabled
- If we see it there, we are ready to apply the build of the AppVMs now with the following command:
qubesctl --show-output --skip-dom0 --all state.highstate
- Notice that we are getting the verbose output with the added parameters in this command, and also telling the system to not worry about
dom0states, since we are only focused on building AppVMs in the context here.
- You should now see the VMs populated on your Qubes VM Manager!
Class of characters
So we have our generated AppVMs based on the Whonix Mixed Anonymity Modes. Now what? Well, we obviously want to start installing some applications to use for each, based on the aformentioned Whonix documentation.
While we really haven’t pre-configured applications for use here from the start, we mainly wanted to get a “hull” for each AppVM going - from there on, it is up to you to decide what applications you will use within each Mode. However, it is definitely an option to adjust the Salt files to include these to install automatically as well - Kushal Das goes more into this in one of his great blog posts, which can serve as a guide to do this at an earlier stage with the management stack.
In this case, let’s have a think at some of the options and apps well reserved for each one of these modes.
Here are some considerations to dabble with:
- Installing OnionShare on
sys-whonixto use within the
mode-1AppVm as a tool to send/recive files or quickly host file anonymously via the tor network (this can be a bit more tricky to get set up in a Qubes/Whonix environment compared to a standard system - this article goes over some of the intricacies and should serve well with setting things up)
- Using Hexchat in either
mode-1for an ephermeral usage, where you will not retain your presence/username in a particular channel, or
mode-3if there is not a concern about identity but the user wishes some of their connection details to remain somewhat private. (Whonix has a good guide for this too)
- Pseudonymize things like emails, form submissions, records requests, etc. by using a dedicated email configuration with a client such as Thunderbird in
mode 2or (more likely)
mode-3- and effectively strip out most actual identifying metadata attached.
- Pseudonymize end-to-end encrypted communications with Signal within your
mode-3AppVM (you can optionally use a secondary phone number and configure the application consulting this guide)
- Scrape data from public sites anonymously with your artisinally-crafted script in the
mode-1terminal (your mileage may vary!)
There are plenty of other ideas you can commit to with this particular compartmentalized approach in QubesOS. It serves as a great way to force a user to be conscious of what is going on in the background when they make a connection, a post, or commit just about any act using the internet, and generally allows them to do so in a way that fits their specific needs in terms of privacy.
For a bit of a meta-joke conclusion, here is s screenshot of me creating this blog post in a