Qubes OS cheatsheet

Traditional OS: malware in browser = full system compromise. Qubes OS: malware in browser qube = only that qube is compromised.

Traditional Linux:
  [Browser] [Email] [Files] [Keys]
  ──────────── One OS ─────────────
  ──────── One kernel ─────────────
  → Compromise anything = game over

Qubes OS:
  [Browser] [Email] [Files] [Keys]
  │ VM-1  │ VM-2  │ VM-3  │VM-4 │
  ──────── Xen Hypervisor ────────
  → Compromise VM-1 = only VM-1

Each qube has a color-coded window border so you always know which security domain you are in (red = untrusted, green = trusted, etc.).

dom0 is the most privileged domain. It must never connect to any network. All admin operations happen here. If dom0 is compromised, the entire system is compromised.

TemplateVM - Read-only base image. AppVMs inherit the root filesystem from here. Install software in the template, use it in AppVMs. Changes to the root filesystem in an AppVM are discarded on shutdown.

AppVM (Application VM) - Regular qubes for daily work. Root filesystem comes from a TemplateVM (read-only). Only /home and /rw persist across reboots.

DisposableVM - Spawned from a template, destroyed entirely when closed. No persistence at all. Ideal for opening untrusted files, links, or attachments.

StandaloneVM - Fully independent VM with its own root filesystem. Changes persist. Use for VMs that need a unique OS or heavy customization.

ServiceVM (sys-*) - System qubes providing services (networking, firewall, USB, Tor) to other qubes.

Internet
   │
   ▼
[sys-net]       ← physical NIC lives here
   │
   ▼
[sys-firewall]  ← per-qube firewall rules
   │
   ├──► [work]         (clearnet)
   ├──► [dev]          (clearnet)
   │
   ▼
[sys-whonix]    ← Tor gateway
   │
   ├──► [anon-browse]  (Tor)
   ├──► [comms]        (Tor)
   └──► [engagement]   (Tor)

Each AppVM connects through a NetVM. You choose which NetVM per-qube. A qube connected through sys-whonix cannot bypass Tor - the gateway enforces it at the network level.

Critical BIOS settings to enable:

Intel VT-x (Virtualization Technology)
Intel VT-d (Directed I/O)
IOMMU (Input/Output Memory Management Unit)
TPM 2.0 (optional, for AEM)
Secure Boot: DISABLE (Qubes uses its own chain)

Check the Qubes Hardware Compatibility List (HCL) before purchasing hardware. Lenovo ThinkPads (T480, T480s, X1 Carbon Gen 5/6/7, T14 Gen 1) and NitroPads are popular choices. AMD Ryzen platforms are increasingly well-supported.

# 1. Download Qubes ISO and verify signature
wget https://www.qubes-os.org/downloads/
gpg --fetch-keys https://keys.qubes-os.org/keys/qubes-release-4-signing-key.asc
gpg --verify Qubes-R4.2.x-x86_64.iso.asc Qubes-R4.2.x-x86_64.iso

# 2. Write to USB
sudo dd if=Qubes-R4.2.x-x86_64.iso of=/dev/sdX bs=1M status=progress

# 3. Boot from USB, follow installer
# - Full disk encryption (LUKS) - ALWAYS enable
# - Choose default template (Fedora + Debian)
# - Create default system qubes

Post-install first steps:

# In dom0 terminal:
# Update dom0
sudo qubes-dom0-update

# Update Fedora template
qvm-run -u root fedora-41 'dnf upgrade -y'

# Update Debian template
qvm-run -u root debian-12 'apt update && apt upgrade -y'

# Update Whonix templates
qvm-run -u root whonix-gateway-17 'apt update && apt upgrade -y'
qvm-run -u root whonix-workstation-17 'apt update && apt upgrade -y'

# Create a new AppVM based on Fedora template
qvm-create myqube --template fedora-41 --label red

# Create with specific networking
qvm-create torqube --template fedora-41 --label purple \
  --prop netvm=sys-whonix

# Create a StandaloneVM
qvm-create standalone1 --class StandaloneVM --label blue

# Start / shutdown / kill
qvm-start myqube
qvm-shutdown myqube
qvm-shutdown --wait myqube    # wait until fully stopped
qvm-kill myqube               # force kill (like pulling the plug)

# Pause / unpause (freeze RAM state)
qvm-pause myqube
qvm-unpause myqube

# Run a command in a qube (from dom0)
qvm-run myqube 'firefox https://example.com'

# Run as root
qvm-run -u root myqube 'dnf install nmap'

# Run and pass through terminal output
qvm-run --pass-io myqube 'cat /etc/os-release'

# Run with auto-start (starts qube if not running)
qvm-run -a myqube 'xterm'

# Open a terminal in a qube
qvm-run myqube 'xterm'

# List all qubes with status
qvm-ls

# Detailed list with networking info
qvm-ls -n

# List only running qubes
qvm-ls --running

# Show qube properties
qvm-prefs myqube

# Get specific property
qvm-prefs myqube netvm
qvm-prefs myqube memory
qvm-prefs myqube template

# Set properties
qvm-prefs myqube netvm sys-whonix
qvm-prefs myqube memory 4096
qvm-prefs myqube maxmem 8192
qvm-prefs myqube autostart True

# View firewall rules for a qube
qvm-firewall myqube list

# Allow all outgoing (default)
qvm-firewall myqube reset

# Drop all traffic (complete isolation)
qvm-firewall myqube del --rule-no 0
qvm-firewall myqube add drop

# Allow only specific destination
qvm-firewall myqube reset
qvm-firewall myqube del --rule-no 0
qvm-firewall myqube add accept dsthost=10.10.10.0/24
qvm-firewall myqube add accept dsthost=192.168.1.100 proto=tcp dstports=443
qvm-firewall myqube add drop

# Allow only DNS and HTTPS
qvm-firewall myqube reset
qvm-firewall myqube del --rule-no 0
qvm-firewall myqube add accept proto=udp dstports=53
qvm-firewall myqube add accept proto=tcp dstports=443
qvm-firewall myqube add drop

Software must be installed in the TemplateVM. AppVMs based on that template will see the new software after restart.

# Open a root terminal in the template
qvm-run -u root fedora-41 'xterm'

# Inside the template, install packages
dnf install nmap wireshark python3-pip    # Fedora
apt install nmap wireshark python3-pip    # Debian

# Shut down the template
qvm-shutdown fedora-41

# Restart AppVMs to pick up changes
qvm-shutdown myqube && qvm-start myqube

AppVM persistence model:

TemplateVM (fedora-41)
├── /usr, /bin, /lib, /etc  → read-only overlay in AppVM
│                              (changes discarded on shutdown)
└── AppVM (myqube)
    └── /home/user          → persistent (stored in AppVM's private volume)
    └── /usr/local          → bind-mounted from /rw/usrlocal (persistent)
    └── /rw/config          → persistent (custom startup scripts, rc.local)

# Clone an existing template
qvm-clone fedora-41 fedora-41-redteam

# Install offensive tools in the clone
qvm-run -u root fedora-41-redteam 'dnf install -y nmap \
  python3-pip john hashcat hydra'

# Create AppVMs from your custom template
qvm-create engagement --template fedora-41-redteam --label red \
  --prop netvm=sys-whonix

# Minimal template (smaller attack surface for service qubes)
sudo qubes-dom0-update qubes-template-fedora-41-minimal

# Install only what you need in minimal template
qvm-run -u root fedora-41-minimal \
  'dnf install qubes-core-agent-networking iproute'

# Create a Whonix-based DisposableVM template
qvm-create whonix-dvm --class AppVM \
  --template whonix-workstation-17 --label purple
qvm-prefs whonix-dvm template_for_dispvms True
qvm-prefs whonix-dvm netvm sys-whonix

# Now DisposableVMs spawned from whonix-dvm
# route through Tor automatically

# Create a red-team DispVM for quick engagement work
qvm-create redteam-dvm --class AppVM \
  --template fedora-41-redteam --label red
qvm-prefs redteam-dvm template_for_dispvms True
qvm-prefs redteam-dvm netvm sys-whonix

Anything done inside a DispVM vanishes when the last window closes. No forensic artifacts remain on disk.

In dom0, configure the policy:

# /etc/qubes/policy.d/30-user-gpg.policy
# Allow 'work' to use GPG from 'vault'
qubes.Gpg  *  work  vault  allow
qubes.Gpg  *  @anyvm  @anyvm  deny

In the AppVM (work) that needs GPG access:

# Set environment variable (add to ~/.bashrc in the AppVM)
export QUBES_GPG_DOMAIN=vault

# Use qubes-gpg-client instead of gpg for operations
# needing the private key
qubes-gpg-client --list-keys
qubes-gpg-client --sign document.txt
qubes-gpg-client --decrypt secret.txt.gpg

# For git commit signing
git config --global gpg.program qubes-gpg-client-wrapper

The vault qube prompts for confirmation on each signing request, so a compromised AppVM cannot silently sign arbitrary data.

Same principle as Split-GPG: SSH private keys live in the vault qube. Other qubes request SSH operations through a Qubes RPC mechanism.

# In vault qube: generate SSH key
ssh-keygen -t ed25519 -C "redteam@qubes"

# The key stays here. It never gets copied out.

In dom0, set the policy:

# /etc/qubes/policy.d/30-user-ssh.policy
qubes.SshAgent  *  work  vault  allow
qubes.SshAgent  *  engagement-1  vault  allow
qubes.SshAgent  *  @anyvm  @anyvm  deny

In the AppVM that needs SSH access:

# Add to ~/.bashrc in the AppVM
export SSH_AUTH_SOCK=/home/user/.SSH_AGENT_vault

# Verify agent forwarding works
ssh-add -l   # Should show keys from vault

# SSH connections now use the vault's key
ssh user@target-server

Benefits:

• Private key never exists in the AppVM's filesystem
• Even if the AppVM is fully compromised, the attacker cannot exfiltrate the key
• Vault prompts on each use, so you see every SSH auth request
• Revoke access by changing the policy in dom0

By default, Qubes blocks USB keyboards through sys-usb because a malicious USB device can impersonate a keyboard and inject commands.

# If you MUST use a USB keyboard, configure in dom0:
# /etc/qubes/policy.d/30-user-input.policy
qubes.InputKeyboard  *  sys-usb  dom0  allow

# Or during installation, select the USB keyboard option
# This creates sys-usb with input device passthrough

# Better approach: use PS/2 keyboard or laptop built-in keyboard
# and keep USB keyboards blocked

Risk model: a malicious USB device plugged into the machine can only interact with sys-usb. It cannot type commands into dom0 or any AppVM unless explicitly attached.

# Copy file from one qube to another (from source qube)
qvm-copy-to-vm target-qube /path/to/file
# File arrives in: /home/user/QubesIncoming/source-qube/

# Move file (removes from source)
qvm-move-to-vm target-qube /path/to/file

# From dom0, copy a file to a qube
qvm-run --pass-io myqube 'cat > /home/user/file.txt' < /path/in/dom0/file.txt

# From dom0, copy a file from a qube
qvm-run --pass-io myqube 'cat /home/user/file.txt' > /path/in/dom0/file.txt

# Qubes has a two-step clipboard:
# 1. Copy in source qube: Ctrl+C (normal copy)
# 2. Copy to global clipboard: Ctrl+Shift+C
# 3. Switch to target qube
# 4. Paste from global clipboard: Ctrl+Shift+V
# 5. Paste normally: Ctrl+V

# This prevents any qube from reading another qube's clipboard
# without explicit user action

# Convert untrusted PDF to trusted (sanitize)
# In a qube, right-click file -> Open in DisposableVM
# The DispVM converts it to a safe format

# Using qvm-convert-pdf (Qubes PDF converter)
# Renders each PDF page as pixels, then rebuilds
# Strips all embedded code, JavaScript, macros
qvm-convert-pdf untrusted-document.pdf

# Convert untrusted images
qvm-convert-img untrusted-photo.jpg

# Create VPN gateway qube
qvm-create sys-vpn --class AppVM --template fedora-41 --label orange
qvm-prefs sys-vpn provides_network True
qvm-prefs sys-vpn netvm sys-firewall
# Configure VPN inside sys-vpn (OpenVPN/WireGuard)

# Create vault (no network)
qvm-create vault --template fedora-41 --label black
qvm-prefs vault netvm ''

# Create engagement qubes
qvm-create engagement-1 --template fedora-41-redteam --label red \
  --prop netvm=sys-whonix
qvm-create engagement-2 --template fedora-41-redteam --label orange \
  --prop netvm=sys-vpn

# Create comms qube (Tor-only)
qvm-create comms --template fedora-41 --label purple \
  --prop netvm=sys-whonix

# Create malware analysis (isolated or Tor-only)
qvm-create malware-analysis --template fedora-41-redteam --label red
qvm-prefs malware-analysis netvm ''    # fully isolated
# Or: qvm-prefs malware-analysis netvm sys-whonix  # if you need to fetch samples

# Create C2 controller
qvm-create c2-controller --template fedora-41-redteam --label red \
  --prop netvm=sys-whonix

# Firewall rules: engagement qubes only talk to target scope
qvm-firewall engagement-1 reset
qvm-firewall engagement-1 del --rule-no 0
qvm-firewall engagement-1 add accept dsthost=10.10.10.0/24
qvm-firewall engagement-1 add drop

Whonix provides stream isolation - different applications use different Tor circuits, preventing correlation.

# Default Tor ports in Whonix (each uses a different circuit)
# 9050 - general SocksPort
# 9100 - Tor Browser
# 9101 - IRC
# 9102 - Instant messaging
# 9103 - apt-get
# 9104 - other software
# 9105 - wget

# Create a Whonix-based AppVM
qvm-create anon-browse --template whonix-workstation-17 \
  --label purple --prop netvm=sys-whonix

# Tor connection in the workstation just works
# No configuration needed - all traffic forced through Tor
curl https://check.torproject.org

Benefits of Qubes-Whonix vs standalone Whonix:

• Hardware-level isolation (Xen) instead of VirtualBox
• Multiple isolated Whonix workstations simultaneously
• Compromise of one workstation does not affect others
• Integrated with Qubes firewall and policy system
• DisposableVM support for Whonix workstations

Hardware compatibility - Many laptops and desktops are not supported. Nvidia GPUs are problematic. Wi-Fi adapters may need specific drivers in sys-net. Always check the HCL.

RAM usage - Each qube consumes RAM. Running 5-10 qubes simultaneously needs 16-32 GB. Minimal templates help (use ~300 MB vs ~1 GB for full templates).

Performance - Xen overhead exists. Not suitable for gaming, video editing, or GPU-intensive tasks. No GPU passthrough for consumer GPUs.

Learning curve - Fundamentally different from standard Linux. File transfers, clipboard, software installation all work differently. Expect 1-2 weeks to become comfortable.

Software installation - Must be done in templates, not AppVMs. Some software that expects system-wide installation or persistence in unusual directories may not work well.

Suspend/resume - Can be unreliable depending on hardware. Some devices may not reconnect properly after resume.

# Use minimal templates for service qubes
sudo qubes-dom0-update qubes-template-fedora-41-minimal

# Set lower memory for qubes that don't need much
qvm-prefs myqube memory 400
qvm-prefs myqube maxmem 2048

# Monitor memory usage
xl top        # in dom0, shows Xen domain resource usage
qvm-ls -n     # shows memory allocation per qube

# Backup all qubes to external drive (encrypted)
qvm-backup --compress-filter=gzip /mnt/backup/

# Backup specific qubes only
qvm-backup --compress-filter=gzip \
  -d /mnt/backup/ work vault personal

# Backup uses dom0 passphrase encryption
# You WILL be prompted for a passphrase
# Losing this passphrase = losing the backup

# List qubes included in a backup
qvm-backup-restore --list /mnt/backup/qubes-backup-2026*

# Restore all qubes from backup
qvm-backup-restore /mnt/backup/qubes-backup-2026*

# Restore specific qubes only
qvm-backup-restore --include=work,vault \
  /mnt/backup/qubes-backup-2026*

# Restore to different template (if original is missing)
qvm-backup-restore --rename-conflicting \
  /mnt/backup/qubes-backup-2026*

# Verify backup integrity without restoring
qvm-backup-restore --verify-only \
  /mnt/backup/qubes-backup-2026*

Backup strategy: keep multiple encrypted backups on separate physical devices. Store at least one offsite. Test restores periodically - an untested backup is not a backup.

Key principle: Qubes assumes the guest OS will be compromised. It protects the system by containing that compromise. It does NOT protect against attacks below the hypervisor (hardware, firmware) or above the user (social engineering, operational mistakes).

Combine them: Qubes + Whonix gives both compartmentalization and anonymity. Use Tails on a USB stick for situations where you cannot use your Qubes machine or need to leave no trace on hardware.

• Qubes OS
• Qubes Documentation
• Qubes-Whonix
• Qubes GitHub
• Qubes HCL
• Qubes Security Bulletins
• Qubes Forum
• Split GPG

• Whonix (Tor-enforced anonymity OS with gateway isolation)
• Tails (Amnesic live OS for temporary anonymous sessions)
• GrapheneOS (Hardened mobile OS for privacy-focused devices)
• Anonymization (Identity separation and OPSEC methodology)
• Mullvad VPN (Privacy-focused VPN with anonymous signup)
• OPSEC Checklist (Operational security verification steps)
• Red Team Infra (Offensive infrastructure setup and management)