Qubes OS for Anarchists

Published on   | Last edited on 
41 min
PDF: Letter | A4

Categories: Defensive

Qubes OS is a security-oriented operating system (OS), which means it is an operating system designed from the ground up to be more difficult to hack. This is achieved through compartmentalization, where the base system is divided into compartments called "qubes" (using "virtual machines" — more on that below). All other Linux systems like Tails are monolithic, which means that if a hack succeeds anywhere on the system, it can more easily take over. In Qubes OS, if one qube is compromised, the others remain safe. You can think of using Qubes OS as having many different computers on your desk, each for a different activity, but with the convenience of a single physical machine, a single unified desktop environment, and a set of tools for securely using them all together as parts of a unified system.

Qubes OS can be configured to force all Internet connections through the Tor network (like Tails) by using Whonix, which is included by default. Devices (USBs, network devices, microphone and camera) are all strongly isolated and only allowed access when explicitly granted. "Disposables" are one-off qubes that self-destruct when shut down.

Who is Qubes OS For?

Given that anarchists are regularly targeted for hacking in repressive investigations, Qubes OS is an excellent choice for us. AnarSec recommends Qubes OS for everyday use, and below we compare when it is appropriate to use Tails vs. Qubes OS - both have unique strengths. While Tails is so easy to use that you don't even need to know anything about Linux, Qubes OS is a bit more involved, but still designed to be accessible to users with limited technical know-how, like journalists. This guide is labelled as "intermediate", though if you need to extensively customize your set up or troubleshoot something, it is more likely to be "advanced".

Even if you don't do anything directly incriminating on the computer you use every day, if it were compromised, this would still give investigators a field day for network mapping - knowing who you talk to and what you talk to them about, what projects you are involved in, what websites you read, etc. Most anarchists use everyday computers for some anarchist projects and to communicate with other comrades, so making our personal computers difficult to hack is an important baseline for all anarchists. That said, the time investment to learn Qubes OS isn't for everyone. For those with limited energy to put towards increased anonymity and security, Tails is much more straightforward.

How Does Qubes OS Work?

Qubes OS is not quite another version of Linux. Rather, it is based on many "virtual machines" running Linux. All of these "virtual machines" are configured to work together to form a cohesive operating system.

What is a virtual machine? Virtualization is the process of running a virtual computer inside your computer. The virtual machine thinks it's a computer running on real hardware, but it's actually running on abstracted hardware (software that mimics hardware). Qubes OS uses a special program called a hypervisor to manage and run many of these virtual machines simultaneously, on the same physical computer. To simplify things, virtual machines are referred to as qubes. Different operating systems such as Debian, Whonix, Fedora, Windows, etc. can all run together at the same time in their own qubes. The hypervisor strongly isolates each of the qubes from one another.

At the risk of overwhelming you, here is an overview of how Qubes OS is structured. You don't need to memorize any of this to actually use Qubes OS, but it may be helpful to understand the outline of the system before you get started. Each rectangle represents a qube (i.e. a virtual machine). Let's break it down.

General Usage

Ignore the greyed-out parts of the diagram for now. Daily use of Qubes OS primarily involves interaction with two components:

  • App qubes. In this example, there are three. #1 is running the Debian operating system, #2 is running Fedora, and #3 is running Whonix. App qubes are where you run applications, store files, and do your work. You can have many isolated App qubes for different activities or purposes. Each App qube is like a complete, self-contained operating system.

  • Service qubes. Sys qubes (as in system) connect to the Internet and to devices. sys-usb manages connected USB devices so that they are only able to attach to a qube if you give them permission. sys-net is similar to sys-usb, but for network devices. sys-firewall is firewall control for all Internet-connected qubes, and is in a separate qube so that if sys-net is compromised, the firewall isn't. Note that qubes never connect directly to sys-net, they always connect via sys-firewall. sys-whonix forces all network traffic through Tor, and connects to the firewall itself.

You'll notice that App qube #1 is connected to the Internet, App qube #2 is offline, while App qube #3 is connected to the Internet via Tor and is Disposable. Note that Whonix is actually split between two qubes: the workstation (App qube #3) and the gateway (sys-whonix). This has the security property that if the workstation qube is compromised, the gateway qube (where Tor runs) is not.

A Disposable qube is a type of App qube that self-destructs when its originating window closes. Note that while Tails uses only memory (when the Persistent Storage feature is not enabled), Qubes OS uses the hard drive, so a Disposable qube will leave forensic traces on your computer - a Disposable isn't intended to be anti-forensic, it's intended to reset a qube in case it is compromised by malware.

Management Qubes

Two more components are needed to complete the Qubes OS system:

  • Admin qube. This is the small, isolated and trusted qube that manages the other qubes. It's very protected because if it's compromised, it's game over. It uses a technology called Xen as the hypervisor. It is also called dom0, which is a Xen naming convention. The Admin qube has no network connectivity and is only used to run the desktop environment and window manager.

  • Template qubes. These are where applications and operating system files live and where you install and update software. Each App qube is based on a Template qube, and the App qube can only read from the Template, not write to it. This means that the more sensitive system files are protected from whatever happens in an App qube - they are not retained between App qube restarts. Multiple App qubes can be based on a single Template, which has the convenient feature that updating one Template will update all App qubes based on that Template.

Another security feature of the Qubes OS structure is that the App qubes don't have direct access to the hardware - only the Admin qube can directly access the hard drive and only the Service qubes can directly access the networking, USB, microphone and camera hardware. This means that it's not possible to compromise the hardware from a compromised App qube.

When to Use Tails vs. Qubes OS

Put simply, Tails is easier to use and better protects against forensics, while Qubes-Whonix better protects against malware.

Qubes OS includes Whonix by default (Qubes-Whonix) for when you want to force all connections through Tor. As compared by Privacy Guides (emphasis added):

Whonix is meant to run as two virtual machines: a “Workstation” and a Tor “Gateway.” All communications from the Workstation must go through the Tor gateway. This means that even if the Workstation is compromised by malware of some kind, the true IP address remains hidden.

Tails is great for counter forensics due to amnesia (meaning nothing is written to the disk); however, it is not a hardened distribution like Whonix. It lacks many anonymity and security features that Whonix has and gets updated much less often (only once every six weeks). A Tails system that is compromised by malware may potentially bypass the transparent proxy allowing for the user to be deanonymized.

Whonix virtual machines may be more leak-proof, however they are not amnesic, meaning data may be recovered from your storage device. By design, Tails is meant to completely reset itself after each reboot. Encrypted persistent storage can be configured to store some data between reboots.

In order to recover data from a Qubes OS system, an attacker would still need to successfully bypass the Full Disk Encryption (e.g. by seizing the computer when it is turned on, or cracking a weak password). The situation is the same with Tails if any data is saved to Persistent Storage or an encrypted USB - this saved data is no longer protected by anti-forensic features but by Full Disk Encryption.

Our recommendation is to use Tails:

  • For writing and submitting communiques
  • For action research
  • For provisioning and connecting to hacking infrastructure
  • For anything else where traces will land you in prison
  • If the learning curve for Qubes OS is too steep

And to use Qubes OS:

  • As an everyday computer
  • For sanitizing untrusted files
  • For tasks or workflows where Tails is too restrictive
  • For increased security against malware in a project, if you will be storing sensitive project data long-term on an encrypted volume anyways, because this long-term storage negates the anti-forensic property of Tails. For example, a project's private PGP key needs to be stored long-term, so the benefit of using Tails is negated but the benefit of using Qubes-Whonix remains (increased security against malware).

Keep in mind that with Tails it is easy to destroy an encrypted USB you no longer need in order to revert to a blank slate of "no trace", but the equivalent with Qubes OS requires destroying the hard drive.

Getting Started

Qubes OS works best on a laptop with a solid state drive (SSD, which is faster than a hard disk drive, or HDD) and 16GB of RAM. Check this hardware compatibility list to see if a specific laptop model will work. If you want to install HEADS open-source firmware it has limited compatibility, so keep that in mind when buying your laptop. We recommend the ThinkPad X230 because it's the only developer-tested laptop model and is easily found in refurbished computer stores for around $200 USD. See the list of community-recommended computers for some other options, and Best Practices for further discussion of hardware security.

The installation guide will get you started. The verification step requires using the command line. If this is over your head, ask a friend to walk you through it. Alternatively, learn the basics of the command line with Linux Essentials and see the explanation of a similar verification for Tails.

Do not set up "dual boot" - another operating system could be used to compromise Qubes OS.

After you first boot Qubes OS, there is a post-installation:

  • Check the boxes for Whonix qubes, and for updates to happen over Tor.

  • The post-installation gives the you option to install only Debian or only Fedora Templates (instead of both), and to use the Debian Template for all sys qubes (the default is Fedora). Whether you choose to use Debian or Fedora for qubes that don't require Tor is up to you. The Privacy Guides project argue that the Fedora software model (semi-rolling release) is more secure than the Debian software model (frozen), but also recommend Kicksecure (which is based on Debian). See Best Practices for further discussion of this configuration choice.

  • Make sys-net disposable. If you are using Wi-Fi instead of Ethernet, you will need to re-enter the Wi-Fi password after every boot.

The Getting Started document is a good overview of most of what you need to know to begin - stop here to read it! The Qubes documentation is very thorough, but can be difficult for a new user to navigate. We'll go over some basics here that aren't already covered on the Getting Started page.

How to Update

On Qubes OS, you should NOT use the apt update or apt upgrade commands, which you may be used to from other Linux experiences. As the documentation states, "these bypass built-in Qubes OS update security measures. Instead, we strongly recommend using the Qubes Update tool or its command-line equivalents." The first thing you'll want to do after connecting to the Internet is run Qubes Update. From the docs:

you can [...] start the tool manually by selecting it in the Applications Menu under “Qubes Tools.” Even if no updates have been detected, you can use this tool to check for updates manually at any time by selecting “Enable updates for qubes without known available updates,” then selecting all desired items from the list and clicking “Next.”

Make sure to have the computer plugged into power whenever you run Qubes Update. Updates take a moment to be detected on a new system, so select "Enable updates...", check the boxes for all qubes, and press Next. A Whonix window may pop up asking you to do a command line update, but ignore this since the update will resolve it. Once Qubes Update is complete, reboot.

How to Copy and Paste Text

Qubes has a special global clipboard that allows you to copy and paste text between qubes.

  1. Press Ctrl+C to copy text as normal to the internal clipboard of the source App qube.
  2. Press Ctrl+Shift+C to copy the contents of the internal clipboard of the source App qube to the global clipboard.
  3. Press Ctrl+Shift+V in the destination App qube to copy the contents of the global clipboard to the internal clipboard of the destination App qube.
  4. Press Ctrl+V to paste text as usual from the internal clipboard of the destination App qube.

It's a bit tricky at first, but you'll get the hang of it in no time!

How to Copy and Move Files

There is a special tool for moving files and directories (folders) between qubes that requires explicit user permission. As a rule of thumb, only move files from more trusted qubes to less trusted ones.

From the docs:

  1. Open a file manager in the qube containing the file you wish to copy (the source qube), right-click on the file you wish to copy or move, and select Copy to Other AppVM... or Move to Other AppVM....

  2. A dialog box will appear in dom0 asking for the name of the target qube (qube B). Enter or select the desired destination qube name.

  3. If the target qube is not already running, it will be started automatically, and the file will be copied there. It will show up in this directory (which will automatically be created if it does not already exist): /home/user/QubesIncoming/<source_qube>/<filename>. If you selected Move rather than Copy, the original file in the source qube will be deleted. (Moving a file is equivalent to copying the file, then deleting the original.)

  4. If you wish, you may now move the file in the target qube to a different directory and delete the /home/user/QubesIncoming/ directory when no longer needed.

How to Shutdown Qubes

Click on the Domains widget to see which Qubes are currently running and how much memory (RAM) and processing power (CPU) they are using. Each qube uses memory, so when you are done with a qube, you should shut it down to free up the memory it is using. Closing windows isn't enough - you need to shut down the qube when you're done with it.

How to Install Software

While Tails has a Graphical User Interface (GUI) for installing additional software, Qubes OS does not at this time, so new software must be installed from the command line. If you are unfamiliar with the command line or how software works in Linux, see Linux Essentials to get acquainted. When choosing what additional software to install, keep in mind that being open-source is an essential criteria, but not sufficient to be considered secure. The list of included software for Tails will cover many of your needs with reputable choices.

Software is installed into Templates, which have network access only for their package manager (apt or dnf). Installing a package requires knowing its name, which can be found using a web browser for both Debian and Fedora, or on the command line.

It is best not to install additional software into the default Template, but rather to install the software into a cloned Template, to avoid unnecessarily increasing the attack surface of all App qubes based on the default Template. The basic formula is:

  1. Clone Template
  2. Install additional packages on the cloned Template
  3. Create an App qube based on the cloned Template
  4. Optional: Make this App qube a disposable

For example, to install packages for working with documents, which are not included by default in debian-11, I clone it first. Go to Applications menu → Qubes Tools → Qube Manager. Right click on debian-11 and select "Clone qube". Name the new Template debian-11-documents.

To install new software, as described in the docs:

  1. Start the template.

  2. Start a terminal.

  3. Install software as normally instructed inside that operating system, e.g.:

  • Fedora: sudo dnf install <PACKAGE_NAME>
  • Debian: sudo apt install <PACKAGE_NAME>
  1. Shut down the template.

  2. Restart all qubes based on the template.

  3. (Recommended) In the relevant qubes’ Settings → Applications tab, select the new application(s) from the list, and press OK. These new shortcuts will appear in the Applications Menu. (If you encounter problems, see here for troubleshooting.)

Remember that you should not run apt update or dnf update.

Returning to the example above, I start a terminal in the debian-11-documents Template I just cloned, and then run sudo apt install libreoffice-writer mat2 bookletimposer gimp gocryptfs gnome-disk-utility. Once the installation was complete, I shut down the Template. I could then create or assign an App qube to use this Template, and it would now have LibreOffice, etc. Installing software should be the only time most users need to use the command line with Qubes OS.

You may want to use software that is not in the Debian/Fedora repositories, which makes things a bit more complicated and also poses a security risk - you must independently assess whether the source is trustworthy, rather than relying on Debian or Fedora. Linux software can be packaged in several ways: deb files (Debian), rpm files (Fedora), AppImages, Snaps and Flatpaks. A forum post outlines your options, and several examples are available in Encrypted Messaging for Anarchists. If the software is available on Flathub but not in the Debian/Fedora repositories, you can use Qube Apps - if the Flathub software is community maintained, this is a security consideration.

How to Organize Your Qubes

The next step is to decide how to organize your system - the options are much more flexible in Qubes OS than in a monolithic system like Tails (and more prone to user error). In general, you should try to use disposables to connect to the Internet whenever possible. Here is our recommended setup for the typical user, which can be tweaked as needed.

After installation, a number of qubes will already exist by default. Click on the Applications Menu to see them all. We are going to delete the following default App qubes because they connect to the Internet without being disposable: work, personal, and untrusted. Go to Applications menu → Qubes Tools → Qube Manager. Right-click and select "Delete qube" for each.

How the App qubes will be organized, without displaying service qubes or Templates:

  • A vault qube. This is used for all data storage because you don't need internet to store files. This qube can be reassigned to the debian-11-documents Template so that trusted files can be opened there.

  • A disposable Whonix-Workstation qube (whonix-ws-16-dvm).

    • Remember - Whonix works by using the Whonix-Workstation Template (whonix-ws-16) for the App qube, and the Whonix-Gateway Template (whonix-gw-16) for a separate Service qube called sys-whonix (not shown in this diagram). Unless you are an advanced user, you should never touch the Whonix-Gateway - all your activity takes place in Whonix-Workstation. When an App qube is disposable, the naming convention is to append -dvm for disposable virtual machine.
    • Disposables appear in Applications Menu in a way that can be confusing. You will see two entries for this qube: the Disposable: whonix-ws-16-dvm entry, which is where you launch applications from, and the Template (disp): whonix-ws-16-dvm entry which is the Template for the disposable (do not use applications from here).
    • You can think of a disposable Whonix-Workstation qube as similar to Tails: system-wide Tor, and deletion after shutdown (without the anti-forensics property, as noted above).
    • Do not customize the disposable Template at all to resist fingerprinting.
  • A disposable Debian or Fedora qube. The default debian/fedora-dvm qube (depending on your post-installation decision) is disposable, and is great for web browsing that blocks Tor, such as logging into online banking.

Creating Qubes

If you wanted, you could use the system as is, but let's create an App qube and a disposable so that you have more options.

  • A Monero qube. Say you want to use the Monero wallet for an anarchist project. We'll create a new qube to compartmentalize this activity. Go to Applications menu → Qubes Tools → Create Qubes VM

    • Name: Project-monero
    • Color: Yellow
    • Type: AppVM
    • Template: whonix-ws-16
    • Networking: sys-whonix
    • Now that the qube exists, install the Monero wallet into the App qube. Then, in the Settings → Applications tab, move Monero Wallet to the Selected column and press OK. The shortcut will now appear in the Applications Menu.
    • This App qube is not made disposable - we prefer all networked qubes to be disposable, but a simple setup requires data persistence for the wallet to work properly.
  • An offline disposable qube. At the moment, both disposables are networked (with and without Tor). Finally, we will demonstrate how to create a disposable without networking for opening untrusted files (like PDFs and LibreOffice documents). Again, go to Applications menu → Qubes Tools → Create Qubes VM

    • Name: debian-11-offline-dvm
    • Color: Black
    • Type: AppVM
    • Template: debian-11-documents
    • Networking: none
    • You can also use Fedora. In the new qubes' Settings → Advanced tab, under "Other", check "Disposable Template", then press OK. You will now see the offline disposable at the top of the Applications Menu - make sure you are working in the disposable, not the disposable Template.
    • Go to Applications menu → Qubes Tools → Qubes Global Settings. Set the default disposable Template to debian-11-offline-dvm
    • Now, if a malicious document achieves code execution after being opened, it will be in an empty Qube that has no network and will be destroyed upon shutdown.

Qubes Task Manager is a Graphical User Interface for creating and configuring qubes that would otherwise require advanced command line configuration. Available configurations include:

  • Split-GPG: GPG keys live in an offline qube and access to them is strictly controlled
  • Split-SSH: SSH keys live in an offline qube and access to them is strictly controlled
  • Mullvad-VPN: A VPN qube using the WireGuard protocol (via Mullvad). Mullvad is one of the few reputable VPN companies - they accept cryptocurrency and also sell voucher cards.
  • sys-VPN: A VPN qube that uses the OpenVPN protocol
  • split-XMR: The Monero wallet lives in an offline qube and access to it is strictly controlled.

You should configure your non-Tor qubes to be forced through a VPN (RiseupVPN, Mullvad, or IVPN), for reasons that are well-summarized by the Security Lab:

Using a reputable VPN provider can provide more privacy against surveillance from your ISP or government and prevent network injection attacks from those entities. A VPN will also make traffic correlation attacks – especially those targeting messaging apps – more difficult to perform and less effective.

By default, App qubes only have 2 GB of private storage. This small amount will fill up quickly - when an App qube is about to run out of space, the Disk Space Monitor widget will alert you. To increase the amount of private storage for any qube, go to the qubes' Settings → Basic tab and change the "Private storage max size". This storage won't be used immediately, it's just the maximum that can be used by that qube.

If a Disposable keeps crashing, try to increase the amount of RAM allocated to it: go to the disposable Template's Settings → Advanced tab and increase the "Initial memory" and "Max memory".

How to Use Disposables

Disposables can be launched from the Applications menu: the disposable is at the top, and the disposable Template is near the bottom. For example, to use a disposable Tor Browser, go to Application Menu → Disposable: whonix-16-ws-dvm → Tor Browser. This is how you do all your Tor browsing. If you launch a disposable application, but then want to access the file manager for the same disposable qube, you can do so from the Qubes Domains widget in the top-right corner of the interface. If you were to simply select "Files" from the Applications menu, this would launch another disposable.

Once you close all the windows of a disposable, the whole disposable is shut down and reset to the state of its Template - any malware that may have been installed is now gone.

In contrast, an App qube must be shut down manually (using the Qubes Domains widget), and will persist data in the /home, /usr/local, and /rw/config directory. The next time an App qube boots, all locations in its file system other than these three directories will reflect the state of its Template. See how inheritance and persistence works for Templates, App qubes, and disposables for more information.

In the file manager of an App qube, right-clicking on certain fle types gives you the Edit In DisposableVM and View In DisposableVM options. This is how we want to open any untrusted files. It will use the default disposable that we set earlier, which is offline. As soon as you close the viewing application, the disposable is reverted to its prior state. If you have edited the file and saved the changes, the changed file will be saved back to the original app qube, overwriting the original. In contrast, viewing in a disposable is read-only, so if the file does something malicious, it can't write to the App qube you launched it from - this is preferable for files you don't need to edit.

If your file opens in an application other than the one you want, you'll need to change the default for the disposable Template:

  1. Send a file of this type to your disposable Template (in our case, debian-11-offline-dvm).
  2. Open the file manager for the disposable Template.
  3. Select the file, right click and select Properties.
  4. In the Open With tab, select your preferred application for this file type.
  5. Press Set as default.
  6. Delete the file from the disposable Template (remember to empty the trash).
  7. Shut down the disposable Template for the change to take effect.

For PDF files, right-click and select Convert To Trusted PDF, and for image files, right-click and select Convert To Trusted Img. This will sanitize the file so that it can go from untrusted to trusted. It does this by converting it to images in a disposable and wiping the metadata.

You can set it up so that certain types of files in an App qube open in a disposable by default. However, setting PDF files to always open in a disposable is not failsafe - some files may have their name end in .pdf, but in fact be something else. This guide sets all file types to open in a disposable to mitigate this possibility. If you'd still like to set the default to open only PDF files in a disposable, right-click a PDF file and select Open With Other Application → qvm-open-in-dvm.

How to Use Devices (like USBs)

To learn how to attach devices, let's format the empty USB or hard drive that will be used for backups. Attaching the USB to an offline disposable mitigates against BadUSB attacks.

  1. Go to Applications menu → Disposable: debian-11-offline-dvm → Disks. The disposable will have a name with a random number such as disp4653. If Disks does not exist, make the change in the Settings → Applications tab.

  2. The Qubes Devices widget is used to attach a USB drive (or just its partitions) to any qube. Just click on the widget and plug in your USB drive (see the screenshot above). The new entry will be under "Data (Block) Devices", typically sys-usb:sda is the one you want (sda1 is a partition and would need to be mounted manually). Hover over the entry and attach it to the disposable you just started (in the case of the example above, disp4653).

  3. The empty USB or hard drive should now appear in the Disks application. Format the empty device, and then create a new encrypted partition as you would in Tails. You can use the same LUKS password for the backup that you use for your Qubes OS LUKS because you will need to memorize it to restore from backup and it will contain the same data.

  4. Before removing the USB drive, first eject it using the Qubes Devices widget, which will eject it from the qube. Then go to Applications menu → sys-usb → Files and select "Safely Remove Drive" to eject it from the computer.

Webcams and microphones are considered devices and must be attached to an App qube to be used.

There are command line instructions for setting up an external keyboard or mouse - we recommend configuring a confirmation prompt. We also recommend enabling a USB keyboard on a dedicated USB controller.

You don't always need to attach a USB drive to another qube with the Qubes Devices widget - external devices are also accessible directly from sys-usb, through the File Manager. You can copy specific files between the USB and another App qube without having to attach the USB controller to the App qube. After the USB is ejected, restart sys-usb to take advantage of it being disposable.

How to Backup

Once your qubes are organized the way you want them, you should back up your system. Depending on your needs, we recommend a weekly backup. We also recommend making a redundant backup that you store off-site and synchronize monthly (to protect against data loss in a house raid).

Adapted from the docs:

  1. Go to Applications menu → Qubes Tools → Backup Qubes.

  2. Move the VMs that you want to back up to the right-hand Selected column. VMs in the left-hand Available column will not be backed up. You may choose whether to compress backups by checking or unchecking the Compress the backup box. Compressed backups will be smaller but take more time to create. Once you have selected all desired VMs, click Next.

  3. Go to Applications menu → Disposable: debian-11-offline-dvm → Files to start a file manager in an offline disposable. Plug in the LUKS USB or hard drive you will be saving your backup to and attach it to the qube (see above for instructions on creating and attaching this drive). The drive should now be displayed at Other Locations in the file manager. Mount the LUKS partition by entering your password. Create a new directory in the LUKS partition called backups.

  4. In Backup Qubes, select the destination for the backup:

  • Target qube: select the disposable, named something like disp1217.
  • Backup directory: click ... to select the newly created folder backups.
  1. Set an encryption passphrase, which can be the same as your Qubes OS user passphrase, because you will need to memorize it to restore from backup, and it will contain the same data. This is dom0, so you won't be able to paste it from a password manager.
  2. Untick "Save settings as default backup profile", and press Next.
  3. Once the backup is complete, test restore your backup. Go to Applications menu → Qubes Tools → Restore Backup. DO NOT FORGET to select Test restore to verify backup integrity (no data actually restored). A test restore is optional but strongly recommended. A backup is useless if you can’t restore your data from it, and you can’t be sure that your backup is uncorrupted until you successfully restore.

Whonix and Tor

The Whonix project has its own extensive documentation. So does Kicksecure, on which Whonix is based. When Whonix is used in Qubes OS, it is sometimes referred to as Qubes-Whonix. Whonix can be used on other operating systems, but it's preferable to use it on Qubes OS because of the superior isolation it provides.

Multiple default applications on a Whonix-Workstation App qube are configured to use unique circuits of the Tor network so that their activity cannot be correlated - this is called stream isolation.

To take advantage of compartmentalization, create separate Whonix-Workstation App qubes for distinct activities/identities, as we did above for the Project-monero qube. Distinct Whonix-Workstation App qubes are automatically stream isolated. Note that it is considered best practice not to use multiple Whonix-Workstation App qubes at the same time:

While multiple Whonix-Workstation are recommended, this is not an endorsement for using them simultaneously! It is safest to only use one Whonix-Workstation at a time and for a single activity. New risks are introduced by running multiple Whonix-Workstation at the same time. For instance, if a single Whonix-Workstation was compromised, it could potentially perform various side channel attacks to learn about running processes in other VMs, and not all of these can be defeated. Depending on user activities, a skilled adversary might be able to correlate multiple Whonix-Workstations to the same pseudonym.

Tor Browser won't be able to upload files from /home/user/QubesIncoming/ due to how permissions are set, so you'll need to move files to another location in /home/user/ to upload them, such as the Downloads directory.

Like any software, the Tor Browser has vulnerabilities that can be exploited - various police agencies have Tor Browser exploits for serious cases. To mitigate this, it's important to keep Tails up to date, and you should increase the Tor Browser's security settings: click the shield icon, and then click Settings.... By default, it's set to Standard, which maintains a browsing experience comparable to a regular browser. We strongly recommend that you set it to the most restrictive setting before you start browsing: Safest. The vast majority of exploits against Tor Browser will not work with the Safest setting.

Occasionally, a new version of the Tor Browser will be available before it can be updated using the Qubes Update tool. When this happens, you can run Tor Browser Downloader from the Whonix-Workstation Template (whonix-ws-16). As noted in the docs, do NOT run this tool from a disposable Template - the disposable Template will be updated automatically.

Password Management

Manage passwords by using KeePassXC from the vault App qube. If you are not familiar with KeePassXC, you can learn about it in Tails for Anarchists. This approach requires you to memorize three passwords:

  1. LUKS password (first boot password)
  2. User password (second boot password, which is much less important than LUKS)
  3. KeePassXC password

Shutdown Qubes OS whenever you are away from the computer for more than a few minutes. For advice on password quality, see Tails Best Practices.

Windows Qubes

It is possible to have Windows qubes, although the installation is a bit involved. This allows programs not available for Linux, such as the Adobe Creative Suite programs, to be used from Qubes OS (ideally offline). Installing "cracked" software downloaded from a torrent is not recommended, as these files are often malicious. The Adobe Creative Suite can be downloaded from Adobe and then cracked using GenP.

Best Practices

Configuring Qubes OS is much more flexible than configuring Tails, but most of the Tails best practices still apply. To summarize, in the order of the Tails article:

  • Protecting your identity
    • Still clean metadata from files before you share them.
    • Compartmentalization is baked into Qubes OS; instead of restarting Tails, use a dedicated qube.
  • Limitations of the Tor network
    • For sensitive activities, don't use Internet connections that could deanonymize you, and prioritize .onion links when available. BusKill is also available for Qubes OS (and we recommend not obtaining it through the mail).
    • If you might be a target for physical surveillance, consider doing surveillance detection and anti-surveillance before going to a cafe to use the Internet. Alternatively, use a Wi-Fi antenna from indoors. See the Tails article for further discussion of deciding what Internet to use.
  • Reducing risks when using untrusted computers
    • The verification stage of the Qubes OS installation is equivalent to the GnuPG verification of Tails.
    • Only attach USBs and external drives to a qube that is disposable and offline.
    • To mitigate physical attacks on the computer, buy a dedicated laptop from a refurbished store, make the laptop screws tamper-evident, and use tamper-evident storage.
    • To mitigate remote attacks on the computer, you can use anonymous Wi-Fi. You can also replace the BIOS with HEADS, though this is advanced. Unlike for Tails, it's not possible to remove the hard drive because it is used by the operating system. Qubes OS already isolates the Bluetooth interface, camera, and microphone. USBs with secure firmware are less important thanks to the isolation provided by sys-usb, and a USB with a physical write-protect switch is unnecessary because the operating system files are stored on the hard drive (and App qubes don't have write access to their templates).
  • Encryption
  • Phishing awareness
    • This is where Qubes OS really shines. Awareness is no longer your only defense - Qubes OS is designed to protect against phishing attacks.
    • Open attachments in a disposable and offline qube.
    • Open links in a disposable Whonix-Workstation qube.

Post-installation Decisions

During the post-installation of Qubes OS, you have the option to install only Debian or only Fedora Templates (instead of both). You also have the option to use the Debian Template for all sys qubes (the default is Fedora). Our recommendation is to install only Debian Templates and convert them to Kicksecure. This way, every App qube on your system will be either Whonix or Kicksecure - Kicksecure is significantly more hardened than either Debian or Fedora.

Kicksecure is not currently available as a Template. To get the Kicksecure Template, clone the Debian Template - follow the Kicksecure docs for distribution morphing on Qubes OS. App qubes that require Internet access without Tor can now use the Kicksecure template instead of the Debian Template. We recommend using disposable qubes whenever possible when connecting to the Internet. To create a Kicksecure disposable:

  • Go to Applications menu → Qubes Tools → Create Qubes VM
    • Name: kicksecure-16-dvm
    • Color: purple
    • Type: AppVM
    • Template: kicksecure-16
    • Networking: default (sys-firewall)
  • In the new qubes' Settings → Advanced tab, under "Other", check "Disposable Template", then press OK. You will now see the disposable at the top of the Applications Menu - make sure you are working in the disposable, not the disposable Template.

Kicksecure is considered untested for sys qubes. If you set all sys qubes to use the Debian Template during the Qubes OS installation, and set sys qubes to be disposable, the Template for sys-net, sys-firewall, and sys-usb will be debian-11-dvm. If you want to use disposable Kicksecure for sys qubes:

  • Set sys-net, sys-firewall, and sys-usb to use the kicksecure-16-dvm Template.

Hardware Security

Hardware security is a nuanced subject, with three prominent factors at play for a Qubes OS computer:

  • Root of trust: A secure element for storing secrets that can be used as a root of trust during the boot process.

  • Blobs: Newer hardware comes with binary blobs that require trusting corporations to do the right thing, while some older hardware is available without binary blobs.

  • Microcode updates: Newer hardware gets microcode updates to the CPU that (ideally) fix vulnerabilities as they are discovered, while older hardware doesn't after it's considered end-of-life. The Heads threat model page explains why CPU vulnerabilities are important:

    "With the disclosure of the Spectre and Meltdown vulnerabilities in January 2018, it became apparent that most processors manufactured since the late 1990s can potentially be compromised by attacks made possible because of transient execution CPU vulnerabilities. [...] Future not-yet-identified vulnerabilities of this kind is likely. For users of Qubes OS, this class of vulnerabilities can additionally compromise the enforced isolation of virtual machines, and it is prudent to take the risks associated with these vulnerabilities into account when deciding on a platform on which to run Heads and Qubes OS."

Of the community-recommended computers, the ThinkPad X230 and ThinkPad T430 strike a relatively unique balance because they both use the Ivy generation of CPUs and are both compatible with Heads:

  • Root of trust: Heads uses the Trusted Platform Module (TPM) to store secrets during the boot process - the Thinkpad X230 and T430 have TPM v1.1.
  • Blobs: There are no binary blobs on these models after Heads is installed, except for the Intel Management Engine (which can be neutered) and the Ethernet blob (which can be generated).
  • Microcode updates: Spectre and Meltdown are mitigated by microcode updates for this generation of CPUs which are installed by default on Qubes OS. Newer hardware uses CPUs with different extensions that are vulnerable to new attack vectors - the Ivy generation is not affected by these.

Qubes OS also applies appropriate software mitigation to this class of attacks at the hypervisor level, including disabling HyperThreading.

OPSEC for Memory Use

To address "future not-yet-identified vulnerabilities of this kind" on older hardware that no longer receives microcode updates, the operational security (OPSEC) suggestion is to limit the presence of secrets in memory that could lead to leaks. Each running qube uses memory, and a compromised qube could use such vulnerabilities to read and exfiltrate memory used by other qubes. Disposables are reset after they are shut down, so we can assume that their compromise would likely be temporary. Perform sensitive operations in qubes without networking, and shut down secure qubes when not in use. Make sure to always be aware of which qubes are running simultaneously - it is best to only have trusted qubes alongside each other.

  • sys-usb: Disposable. Run only when needed, and shut down when finished.
  • sys-net: Disposable. Run only when needed, and shut down when finished. Shut down when performing sensitive operations in other qubes, if possible. Restart before activities that require sys-net (i.e. email, ssh sessions, etc.).
  • vault qube:
    • Instead of having only one vault qube that stores all files (as described above), you can compartmentalize by having different vault qubes dedicated to specific activities (i.e. vault-personal, vault-project1, etc.). This means that if a networked qube is compromised while working on project1, intentional sniffing will not have potential access to all files, but only to those files that are compartmentalized for project1.
    • Configure KeePassXC to lock when it is unused: Application Settings → Security → Timeouts, enable Lock databases after inactivity. Configure automatic clipboard wiping, which is disabled by default. If you need a password when using an untrusted qube:
      • "Emergency pause" the untrusted qube(s),
      • start the necessary vault qube and open the KeePassXC database,
      • copy the credential to the global clipboard,
      • shut down the vault qube,
      • unpause the untrusted qube(s), and paste the credential

Wrapping Up

The documentation has several troubleshooting entries, and the forum is generally very helpful. We recommend that you start using Qubes OS gradually, as trying to learn everything at once can be overwhelming. But we promise, it's not as complicated as it seems at first!