Qubes OS: Assume You're Already Breached

The standard operating system is a monolith. Your browser, your password manager, your email client, your banking session, your random PDF from a stranger, all running under one kernel, sharing one filesystem, watching one another's clipboards, peeking at one another's memory through dozens of side channels. The trust boundary is the kernel. When the kernel holds, you're fine. When it doesn't, the damage radius is every credential, every key, every file, every browser session, all at once.

That is not a hypothetical. A malicious PDF, a malicious npm dep, a malicious browser extension, a vulnerable PDF reader - any one of them, executed under your normal user, has access to the same files your password manager does, because the operating system has no concept of "this process should not see that file." It was never designed for the threat model we now have.

Qubes is the operating system that assumes you will be compromised, at the browser, at the document viewer, at the USB driver, somewhere, and makes that compromise survivable. It does this by giving every part of your digital life its own virtual machine, isolated by Xen at the hardware-virtualisation boundary instead of at the kernel-namespace boundary. The result is the only desktop OS where opening a sketchy PDF is actually safe.

Assume one compartment will fall. Design the system so the rest don't fall with it.

By the end of this guide you will understand the Qubes model, have a working Qubes 4.2 install on supported hardware, and have your daily life split across a small set of named, purpose-built qubes, vault, personal, work, banking, untrusted, comms, with a clear discipline for moving things between them and a real use of disposable VMs for everything you don't trust.

Every Qubes install starts from the same skeleton. The names below are conventional; the structure is non-negotiable.

            ┌──────────────────────────────────────────────┐
            │                   dom0                       │
            │   - admin only, never networked, never on    │
            │   - manages every other qube; runs the GUI   │
            └──────────────────────────────────────────────┘
                                  │
       ┌──────────────────────────┴───────────────────────────┐
       │                                                      │
   ┌───▼───────┐    ┌───────────────┐   ┌──────────┐    ┌─────▼─────┐
   │  sys-net  │──► │ sys-firewall  │──►│   apps   │    │  sys-usb  │
   │  (wifi/lan)    │  (filtering)  │   │ (you)    │    │ (devices) │
   └───────────┘    └───────────────┘   └──────────┘    └───────────┘
                            │
                            ├──► personal      (everyday browsing, mail)
                            ├──► work          (job stuff, employer SaaS)
                            ├──► banking       (only bank URLs, dedicated)
                            ├──► comms         (Signal, chats)
                            └──► sys-whonix ──► untrusted (DispVM, Tor)

                       vault   (OFFLINE, no NetVM at all; secrets only)

A Docker container is a Linux namespace. A Qubes qube is a Xen domU running its own kernel on virtualised hardware. Those are not the same isolation primitive. Container escapes are an active research area with regular CVEs; hypervisor escapes are rare, expensive, and usually require chained firmware bugs. Qubes is betting, correctly, so far, that the smaller, audited Xen trusted compute base is a better wall than the sprawling Linux kernel.

Qubes is picky. Not arbitrarily, it needs Intel VT-d or AMD-Vi for PCI passthrough (so sys-net can own the Wi-Fi card without leaking into dom0), and a graphics stack that doesn't require proprietary blobs. The HCL, Hardware Compatibility List, is the truth. Don't buy a laptop without checking it first.

• ThinkPad X1 Carbon Gen 11+ / X13 / T14

  ref ↗

  Reference laptop · Intel · widely tested

  Boring, well-supported, easy to find used. The default recommendation.

• Framework 13 (AMD Ryzen)

  ref ↗

  Repairable · open · current

  Excellent Qubes support on the AMD variant. Replaceable everything.

• NovaCustom NV41 / NS50

  ref ↗

  Coreboot/Heads firmware preloaded

  If your threat model includes firmware compromise. Ships with anti-evil-maid setup ready.

• ≥ 16 GB RAM (32 GB strongly preferred)

  Memory · the only spec that hurts in practice

  Every running qube is a VM. 16 GB feels tight after three browser qubes; 32 GB is comfortable.

• ≥ 1 TB NVMe

  Storage · templates + per-qube state add up

  Each template is ~10 GB. Each qube's private volume is yours to fill. Don't go below 1 TB.

The verification step below is not theatre. Qubes is exactly the kind of project whose ISO is worth swapping. Verify, then write.

1. STEP 01

   Download the ISO and the signature.

   From qubes-os.org/downloads. Grab the .iso, .iso.asc, and the Release Signing Key.

2. STEP 02

   Verify the signing key against the master key.

   The master signing key fingerprint is published on the Qubes site and across mirrors; cross-check it before importing.

   ▌ verify-iso.sh

   copy

   # Import the master key (verify fingerprint from at least two sources)
   gpg --import qubes-master-signing-key.asc
   gpg --fingerprint 0xDDFA1A3E36879494
   # Expected: 427F  11FD  0FAA  4B08  0123  F01C  DDFA  1A3E  3687  9494
   
   # Import the release-4 key, signed by the master
   gpg --import qubes-release-4-signing-key.asc
   gpg --check-sigs "Qubes OS Release 4 Signing Key"
   
   # Verify the ISO signature
   gpg --verify Qubes-R4.2.X-x86_64.iso.asc Qubes-R4.2.X-x86_64.iso
   # Expect: "Good signature from Qubes OS Release 4 Signing Key"

3. STEP 03

   Write the ISO to a USB.

   dd from a Linux box, or Rufus in DD mode on Windows. Ventoy works for some hardware but has been flaky on Qubes installers, prefer direct dd.

   ▌ dd.sh

   copy

   lsblk   # confirm which device is your USB
   sudo dd if=Qubes-R4.2.X-x86_64.iso of=/dev/sdX bs=4M status=progress conv=fsync
   sync

4. STEP 04

   Boot, install, encrypt.

   Use full-disk encryption with a long passphrase you can type from memory; you'll type it at every boot. Install all three default templates (Fedora, Debian, Whonix). Let the installer create the default qubes (sys-net, sys-firewall, sys-usb, sys-whonix, personal, work, untrusted, vault). You will customise from there.

The installer's defaults are a start. The layout below is the version most operators converge on after a few months. Build it deliberately on day one and save yourself the migration.

The single Qubes capability that changes daily behaviour is the disposable VM. Open a PDF from a stranger in a DispVM. Click a suspicious link in a DispVM. Browse a one-time research session in a DispVM. When you close the window, the VM and everything that happened in it ceases to exist.

# Open a DispVM with a Firefox browser
qvm-run --dispvm=debian-minimal-dvm --service qubes.StartApp+firefox

# Open a PDF from a downloaded file in a DispVM (from any other qube):
#   File manager → right-click file → "Open in disposable qube"

# Make Firefox-in-DispVM your default browser for clicked links
#   Qubes Global Settings → Default qube for opening URLs from other qubes

Qubes is only as good as the operator's habits when moving data between compartments. Three commands, used reflexively, cover almost everything.

1. STEP 01

   Files: qvm-copy / qvm-move.

   Right-click a file in any qube's file manager → "Copy to other qube" → choose destination. Qubes asks for explicit consent before the transfer; the file lands in~/QubesIncoming/<source-qube>/ and is yours to move.

2. STEP 02

   Clipboard: Ctrl-Shift-C, then Ctrl-Shift-V.

   Standard copy/paste is local to a qube. To cross boundaries: select in source qube → Ctrl-Shift-C (puts into the global Qubes clipboard) → switch to destination qube → Ctrl-Shift-V (pulls from global to local clipboard). Two extra keystrokes; zero accidental cross-qube leakage.

3. STEP 03

   No shared folders. Ever.

   Qubes deliberately does not provide a "shared folder" mechanism. That's the feature, not a missing one. If two qubes need the same file, copy it. The friction is the point, it forces you to notice every boundary you cross.

Every qube's NetVM dropdown is a policy decision. Setting it is a 10-second change; getting it right makes whole categories of attack impossible.

1. STEP 01

   Pin banking to a restricted firewall.

   Make a dedicated sys-firewall-bank and configure its allowlist in dom0:

   ▌ bank-allowlist

   copy

   # In dom0, replace example domains with your bank's
   qvm-firewall banking reset
   qvm-firewall banking add accept dsthost=your-bank.com proto=tcp dstports=443
   qvm-firewall banking add accept dsthost=*.your-bank.com proto=tcp dstports=443
   qvm-firewall banking del rule 0   # remove the implicit accept-all
   qvm-firewall banking list

2. STEP 02

   Route untrusted/comms through sys-whonix.

   Anything anonymity-sensitive points its NetVM at sys-whonix. All traffic from that qube transparently tunnels through Tor without the qube knowing or caring.

3. STEP 03

   vault: NetVM = (none).

   Set in Qube Settings → Basic → Networking dropdown. Verify with ping 1.1.1.1 from inside the qube; the only acceptable answer is "Network is unreachable".

You update templates, not running qubes. A qube based on a template gets the template's updates the next time it restarts, which is why short-lived qubes are always fresh.

# dom0, uses Qubes' own update channel
sudo qubes-dom0-update

# All templates at once (GUI: Qubes Update tool from the start menu)
qubesctl --skip-dom0 --templates state.sls update.qubes-vm

# Or per-template, from dom0:
qvm-run --pass-io fedora-40 'sudo dnf upgrade -y'
qvm-run --pass-io debian-12 'sudo apt update && sudo apt upgrade -y'
qvm-run --pass-io whonix-ws-17 'sudo apt update && sudo apt upgrade -y'

# Then restart long-running qubes so they pick up the new template state
qvm-shutdown personal && qvm-start personal

• AMNESIC RECON

  Tails: The Amnesic Machine →

  For tasks Qubes can't make stateless enough.

• IDENTITY HARDENING

  YubiKeys & Hardware 2FA →

  The factor your vault qube hands to every login.

• RECON

  Self-OSINT →

  Run from a DispVM, leave no artefacts.