Qubes-Whonix Security


The following list of actionable items can help to improve security and anonymity on the Qubes platform, and by extension Qubes-Whonix users. It is advised to regularly consult Qubes forums and other channels for the latest security news and advice.

GPG and Software Packages[edit]

  • Always keep the system up to date in dom0, template VMs and standalone VMs.
  • Check gpg is enabled in config files (gpgcheck=1) if new Fedora repositories are installed.
  • Safely import new signing keys by checking it is the same from multiple sources.
  • Preferably only install packages from trusted sources, for example pre-configured Fedora, Debian, Whonix and Qubes sources.
  • Untrusted or unverifiable programs should be installed in Standalone VMs or less trusted, cloned templates.

Hardware / Hardware Settings[edit]

  • Enable VT-d/IOMMU via BIOS to have DMA protection, effective network isolation, and the ability to assign PCIe devices to a HVM. Check it is running via dom0 (qubes-hcl-report).
  • Ensure Intel VT-x or AMD-V is available, since it is required for running HVM domains, such as Windows-based AppVMs.
  • Prepare and utilize a USB qube to protect against side-channel attacks. [1]
  • Use a Yubikey to enhance the security of Qubes user authentication, mitigate the risk of password snooping, and to improve USB keyboard security.
  • Prefer Intel Integrated Graphics Processing (IGP) units for greater system stability and security. [2]
  • Ensure computer hardware meets all other Qubes-Whonix requirements for the best security, functionality and future compatibility with Qubes 4.X releases.

ISO and Qubes Version[edit]

  • Verify the authenticity and integrity of the Qubes iso download.
  • Prefer Qubes R4.0 over earlier releases, as fully virtualized (HVM or PVH) VMs provide greater protection against processor speculative execution bugs like the Meltdown and Spectre attacks, and other exploits. [3] [4]

Protecting User Data and Activities[edit]

  • For critical user data, protect against unintentional leaks by setting an empty NetVM field (set to "none") for the corresponding qube.
  • For sensitive activities, do not run trusted, high-value VMs in paralell with untrusted VMs. [5]
  • Observe the security context of colored windows borders in Qubes before running applications or manipulating data.
  • If paying in cryptocurrencies, utilize a “split” bitcoin wallet which creates an offline “cold storage” wallet and an online “watching only” wallet.
  • Avoid dual / multi-boot configurations in Qubes. The other OS could modify the unprotected /boot partition or firmware to maliciously compromise Qubes and/or spy on user activities.
  • Be careful when running command line operations. Refer to a suitable resource first, then proceed.
  • Use split-GPG for email to reduce the risk of key theft used for encryption / decryption and signing.

Template and Other VMs[edit]

  • Never run applications in TemplateVMs or dom0, except updating tools or editors for configuration purposes (running applications poses security risks).
  • Avoid configuring network traffic between two qubes for security reasons.
  • Consider leveraging the non-persistence of Qubes' templates to fend off malware by locking-down, quarantining and checking the contents of /rw private storage. [6] [7] [8]
  • Consider split dm-crypt to isolate device-mapper based secondary storage encryption (not the root filesystem) and LUKS header processing to DisposableVMs.
  • Consider running sys-net, sys-firewall and sys-usb as Static DisposableVMs.


  1. Automatically configured in Qubes R4, but an optional configuration in R3.2.
  2. Proprietary binary blobs of other GPU manufacturers pose security risks, and available open source drivers are notoriously unstable in Qubes.
  3. Qubes R3.2 and earlier versions rely on para-virtualized (PV) VMs.
  4. For instance, this recent security bug allows an attacker to escape from a PV domain and exploit the dom0 hypervisor. It only affects Qubes R3.2, since Qubes R4 only runs untrusted code in PVH or HVM domains by default.
  5. A successful exploit of the untrusted qube provides an avenue for attacking the sensitive qube.
  6. The vm-boot-protect.service is suitable for standalone VMs, AppVMs, netVMs, Whonix AppVMs and others. Do not use the vm-boot-protect-root service for Whonix AppVMs.
  7. This service: starts before the private volume is mounted, protects /home desktop and shell startup executables, quarantines /rw configs and scripts (with whitelisting), re-deploys custom / default files to /rw on each boot, conducts SHA256 checking against unwanted changes, and more.
  8. Disabling of the Qubes' default passwordless-root is also required.

Random News:

Want to get involved with Whonix? Check out our Contribute page.

https | (forcing) onion

Share: Twitter | Facebook

This is a wiki. Want to improve this page? Help is welcome and volunteer contributions are happily considered! See Conditions for Contributions to Whonix, then Edit! IP addresses are scrubbed, but editing over Tor is recommended. Edits are held for moderation.

Whonix is a licensee of the Open Invention Network. Unless otherwise noted, the content of this page is copyrighted and licensed under the same Libre Software license as Whonix itself. (Why?)