Qubes OS

Qubes OS is a free, open-source operating system that achieves security by compartmentalization: instead of one big OS where a single compromised app can reach everything, Qubes runs your activities in separate lightweight virtual machines (“qubes”) on the Xen hypervisor. A malicious PDF opened in a disposable qube can’t touch your banking session, your SSH keys, or your password manager — they live in different VMs that can’t see each other.

If GrapheneOS is the practical gold standard for mobile hardening, Qubes OS is its desktop counterpart. It’s the workstation recommendation for anyone whose threat model includes targeted malware, phishing, or working with untrusted files and links — journalists, researchers, OSINT analysts, and anyone doing Digital Force Protection seriously. Edward Snowden has repeatedly endorsed it.

Page status

Living guide — built from the official docs plus hands-on operating experience. The “Gotchas” section in particular is field-derived: several Qubes failure modes look like something they’re not, and the documented fix saves hours. Open a wiki PR if you hit one worth adding.

---

Why Qubes (and who it’s for)

• Isolation by default. Each qube is a Xen VM. Compromise is contained to that one qube; it does not become root on your machine or pivot to your other data.
• Disposable VMs. Open a sketchy attachment, click an unknown link, or plug in a found USB stick inside a DisposableVM that is destroyed the moment you close it. Nothing persists.
• You assign trust explicitly. Qubes are color-coded (red = untrusted, green = trusted, yellow/orange = in-between, black = ultra-sensitive). The colored window borders are drawn by the trusted GUI layer and cannot be spoofed by a malicious app.
• The network stack is itself isolated. Your NIC and USB controllers run in their own unprivileged VMs (sys-net, sys-usb), so a driver exploit or malicious USB device lands in a sandbox, not your main OS.
• Defense in depth for the paranoid-but-practical. It is not invisible and it is not anonymity software (see Whonix below for that) — it is about limiting blast radius.

It is a commitment

Qubes asks more of you than a normal OS: capable hardware, a different mental model, and a workflow that trades convenience for isolation. If you just want a private daily phone, GrapheneOS is far less effort. Pick Qubes when compartmentalization is the actual requirement.

---

The mental model (internalize this first)

            ┌───────────────────────── dom0 (admin, NO network, never browse here) ─────────────────────────┐
            │  GUI domain · draws every window border · the most trusted thing on the machine                │
            └───────────────────────────────────────────────────────────────────────────────────────────────┘
 TemplateVM (e.g. fedora / debian)  ──provides root filesystem──▶  AppVMs (work, personal, banking, …)
        │  install software HERE                                        │  your files live in /home only
        ▼                                                               ▼
 sys-net (NIC driver VM) ◀── sys-firewall ◀── your AppVMs        DisposableVMs (spawned, used, destroyed)
 sys-usb (USB controller VM)                                     sys-whonix / Whonix (Tor-routed qubes)

Three ideas do most of the work:

1. dom0 is sacred. It’s the admin VM that runs the desktop and draws all window borders. It has no network access and you never browse or run untrusted code in it. If dom0 is compromised, the whole machine is. Treat the dom0 terminal as break-glass only.
2. TemplateVM vs AppVM persistence. AppVMs are based on a TemplateVM and are rw-only: only /home, /usr/local, and /rw survive a reboot. Everything else — /etc, /usr, anything a package manager installs — is reset from the template every boot.
   • Persistent software → install it in the TemplateVM, then restart the AppVM. Installing inside the AppVM works until the next reboot, then vanishes. This trips up everyone coming from a normal Linux box.
3. Qubes can’t see each other. No shared clipboard, no shared filesystem, no network path — unless you explicitly create one. Moving data between qubes is a deliberate action (below).

---

Hardware requirements

Qubes is demanding and picky. Check before you buy or install:

Requirement	Why
64-bit Intel/AMD CPU with virtualization (VT-x / AMD-V)	Xen needs it to run VMs
IOMMU / VT-d (Intel) or AMD-Vi	Isolates the NIC/USB driver VMs from the rest — core to the security model
16 GB RAM minimum (32 GB comfortable)	Every qube is a real VM; they add up fast
SSD, 256 GB+	Templates + qubes consume space; HDDs are painfully slow
Reasonable iGPU	Qubes has no GPU passthrough for general use; gaming/heavy GPU work is out

Buy from the certified list

The Qubes-certified hardware list (and the community Hardware Compatibility List) saves enormous pain — Wi-Fi, suspend, and IOMMU quirks are the usual failures on random laptops. Framework, NitroPad, and certain ThinkPads are popular known-good choices.

---

Installation (high level)

1. Download the ISO from qubes-os.org/downloads and verify the PGP signature — this is the step people skip and shouldn’t.
2. Write it to a USB stick (dd or balenaEtcher) and boot it (you may need to enable virtualization + disable Secure Boot in firmware).
3. Installer: enable full-disk encryption (LUKS — non-negotiable), let it create the default qubes (sys-net, sys-firewall, sys-usb, personal, work, vault, plus templates).
4. First boot: open the Qubes Update tool and update dom0 and every template before doing anything else.

See the official installation guide for the authoritative steps.

---

The default qubes you get

Qube	Role	Trust
dom0	Admin + GUI. No network.	Highest
sys-net	Owns the physical NIC; exposed to the hostile internet	Untrusted (red)
sys-firewall	Routes/filters traffic for your AppVMs; enforces per-qube firewall rules	Service
sys-usb	Owns the USB controllers; quarantines malicious USB devices	Untrusted
work / personal	Your day-to-day AppVMs — keep them separate	Yours to assign
vault	Offline qube (no netvm) for secrets: password manager, GPG/SSH keys	Highest user trust
TemplateVMs	fedora / debian / whonix — the root FS your AppVMs inherit	Trusted (you update them)

---

Daily workflow (the parts that feel different)

Moving the clipboard between qubes

There are two clipboards by design:

1. Copy inside the source app normally (Ctrl+C).
2. Ctrl+Shift+C — push this qube’s clipboard to the global inter-qube clipboard (a dom0 notification confirms the byte count).
3. Switch to the target qube → Ctrl+Shift+V — pull it in.
4. Paste normally (Ctrl+V).

The two-clipboard gotcha

The global copy reads the CLIPBOARD selection, not PRIMARY. Merely highlighting text with the mouse fills PRIMARY — so Ctrl+Shift+C then copies stale or empty content. Always do an explicit app copy (Ctrl+C) first. Also: dom0 has no clipboard bridge at all — you cannot paste into a dom0 terminal. Type short commands, or copy a file into dom0 the hard way.

Moving files between qubes

# from the source qube, send a file to another qube (a dom0 prompt asks you to approve the destination)
qvm-copy ~/Documents/report.pdf
# it lands in the target qube under ~/QubesIncoming/<source-qube>/

Open risky things disposably

Right-click a file → “Open in Disposable VM”, or open an untrusted link in a disposable browser. The VM is created on demand and destroyed on close — the safest way to triage attachments, unknown PDFs, or QR codes.

Install software the right way

# WRONG (vanishes on next reboot): apt/dnf install inside the AppVM
# RIGHT: install in the template, then restart the AppVM
#   1. open a terminal in the *TemplateVM*
#   2. sudo dnf install <pkg>   (or apt, per template)
#   3. shut the template down; restart your AppVM to pick it up

---

Networking & anonymity

• Route any qube through a VPN by creating a ProxyVM (a qube with provides_network=True running WireGuard/OpenVPN) and setting your AppVM’s netvm to it. Add a kill switch so nothing leaks if the tunnel drops.
• Whonix is built in. sys-whonix (gateway) + anon-whonix (workstation) route a qube’s traffic over Tor with strong leak protection. Use it when you need anonymity, not just isolation.
• Per-qube firewall. sys-firewall can restrict a qube to specific destinations — e.g. lock a qube to only reach one endpoint. Useful for a “this qube only ever talks to my mail server” posture.
• Offline by default for secrets. Give vault (and any key/secret qube) no netvm at all. It exposes keys to other qubes only over a tightly-scoped qrexec service (see split-GPG/split-SSH).

---

High-value patterns

• Split-GPG / Split-SSH. Keep the private key in an offline vault qube. Other qubes ask vault to use the key via qrexec — the key bytes never leave the vault. A compromised work qube can request a signature but can’t exfiltrate the key. See the official split-GPG and split-SSH docs.
• A qube per identity / per client. Separate qubes for each sensitive context (banking, a specific client, a sockpuppet research persona) so a compromise or a tracking cookie in one can’t correlate with another.
• DisposableVM as the default browser for general web. Persist nothing; start clean every time.
• USB armor. With sys-usb owning the controllers, plugging in an unknown device exposes only that sandbox. Approve individual devices to specific qubes deliberately.

---

Gotchas (field-derived — these look like something they’re not)

A qrexec policy syntax error silently breaks everything

A single bad line in any /etc/qubes/policy.d/*.policy file makes the qrexec policy daemon refuse every request silently — global clipboard paste, split-SSH, all of it — and it only re-reads policy on restart, so a broken file can sit latent until the next reboot (“but it worked yesterday”). Check systemctl status qubes-qrexec-policy-daemon in dom0 for PolicySyntaxError. Valid 4.2 format: service +argument source destination action.

• “Persistent” changes that vanish. Edited /etc in an AppVM and lost it on reboot? That’s the persistence model working as designed — system-level changes go in the template or in /rw/config/rc.local, not the AppVM.
• qvm-run --pass-io hangs forever from a terminal. It looks exactly like a dead qube — but it’s the caller’s controlling TTY never sending EOF to the remote shell. Redirect stdin from /dev/null (and setsid) to fix; the qube was fine the whole time.
• Low memory shown in an AppVM is usually fine. Qubes balloons memory on demand (qmemman); the small “total” in free -h at idle is not a ceiling.
• Laptop feels slow but load is near zero → check temperature, not CPU. Under Xen, /proc/cpuinfo “cpu MHz” shows a fixed nominal value and lies about the real clock; the Linux thermal daemons (thermald, throttled) and direct RAPL/power-limit writes don’t work in dom0 because Xen owns those MSRs. Use xenpm get-cpufreq-average for the true per-core frequency and sensors for die temp. A thermally-throttled thin laptop (or a stuck background process like a hung qubes-update-gui spinning a core) clamps every qube at once. The fix is heat (clean the fan, reduce load), not more vcpus.

---

Qubes vs. GrapheneOS — which, when

	GrapheneOS	Qubes OS
Platform	Pixel phones	x86 laptops/desktops
Model	Hardened single OS + per-app sandbox	Many isolated VMs (compartmentalization)
Best at	Daily mobile privacy/security with low effort	Containing compromise; untrusted files/links; multi-identity work
Effort	Low once installed	Moderate–high; capable hardware required
Use both?	Yes — phone + workstation is the complete picture	Yes

They’re complementary, not competing: GrapheneOS for the phone in your pocket, Qubes for the workstation you do sensitive work on.

---

Resources

• Official site & intro
• Documentation · Installation guide · Certified hardware
• Split-GPG · Disposable VMs · Whonix on Qubes
• Qubes onion site

---

Related

• Qubes OS for Tools & AI Agents — practical multi-OS use and running AI agents in a dedicated, network-controlled qube
• GrapheneOS — the mobile counterpart to Qubes
• Mobile Hardening — hardening the phone half of your kit
• Digital Force Protection Guide — where workstation isolation fits in the bigger DFP picture
• Personal Threat Modeling — decide whether Qubes’ tradeoffs match your actual threats
• Secure Messaging — pair compartmentalized comms with a compartmentalized OS