Qubes OS explained: assume you will get hacked

Technological concepts & product features (Qubes OS)

Core security idea: “assume evil / assume you will be broken”

Qubes OS is designed around the belief that parts of your system will eventually be compromised (for example: the browser, downloads, USB devices, suspicious links, etc.). The goal is that a single compromise shouldn’t spread to everything else.

Isolation via “cubes” (security compartments)

• Cubes are isolated compartments implemented as virtual machines.
• They are integrated into one desktop experience so apps can appear side-by-side while remaining separated under the hood.
• Risk-based separation: different cubes handle different trust levels (e.g., personal browsing vs. work vs. untrusted downloads).

Visual cues using colored window borders

• Window borders indicate which cube an app belongs to (example: yellow = personal, blue = work).
• Opening Firefox in different cubes isn’t just separate windows—it runs in different isolated environments.

Per-cube file systems

• File manager demos show that personal and work cubes use different file systems.
• Result: personal downloads don’t mix with work documents, and work space isn’t exposed to random content from other cubes.

Disposable qubes (temporary browsing / malware containment)

• For PDFs, downloads, or links you don’t fully trust, run them in a disposable cube.
• When closed, the environment is destroyed, limiting how long malware or suspicious activity can persist.

Vault cube for offline confidentiality

• Vault stores confidential files.
• By default it has no network access.
• Intended for secrets/keys/password exports/docs rather than browsing or downloading.

Clipboard isolation between cubes (anti-data-theft design)

Qubes avoids a single shared clipboard because any app across compartments could potentially read the same buffer.

Instead, it uses a special inter-cube clipboard requiring extra steps:

• Copy in source cube: Ctrl + C
• Move to global transfer buffer: Ctrl + Shift + C
• Paste into target cube buffer: Ctrl + Shift + V
• Paste normally: Ctrl + V

The global buffer is cleared after transfer to reduce the chance of one cube silently stealing sensitive data from another.

Explicit data movement between cubes

• Files don’t automatically “appear” across cubes.
• Users must explicitly choose copy to another cube, which creates an incoming folder structure showing source/destination (e.g., Qubes incoming → personal → file).

Whonix integration option for Tor/anonymity

• If enabled at setup, Qubes can create Whonix cubes (e.g., sys-whonix, anon-whonix).
• Running Tor Browser in the anon cube automatically starts the required gateway in the background.
• Emphasizes limits: not a magic anonymity shield; it primarily reduces the blast radius if mistakes occur.

System/service cubes (“plumbing” separation)

App/data cubes are separated from infrastructure cubes:

• sys-net: network hardware management (Wi‑Fi/Ethernet access)
• sys-firewall: firewall layer connecting app cubes to sys-net
• sys-usb: manages/isolates USB device access (USB is treated as dangerous)

Application cubes (personal/work/untrusted/vault) don’t directly interact with network hardware.

---

Security/operation guidance & update model

Updates are split across Qubes components

• dom0: trusted administrative environment
• Templates (e.g., Debian/Fedora): provide the OS/root filesystem for app cubes
• App/worker cubes (personal/work/untrusted): inherit most software from templates

Recommended beginner workflow: use the Qubes update tool

Use the Qubes update tool (menu-based) rather than bypassing it.

Typical order:

1. Update dom0
2. Update templates
3. Restart dependent cubes so they use updated software

It warns against bypassing Qubes update mechanisms with direct package managers (e.g., dnf, apt), because Qubes’s update tooling includes security measures.

Template end-of-life warning

If a template reaches end-of-support, it may stop receiving security updates.

Example mentioned:

• Fedora 42 already reached EOL in the video
• The presenter chooses Debian 13 XFCE by default unless needing Fedora

---

Hardware/install requirements (important nuance)

Installation differs from “normal Linux”

Hardware configuration is critical because virtualization and isolation depend on platform features.

Requirements mentioned:

• 64-bit Intel or AMD
• Hardware virtualization
• IOMMU support
• At least 6 GB RAM, with recommendations of:
  • 16 GB RAM
  • 128 GB storage
  • plus fast SSD
• Secure Boot should be disabled
• Verify virtualization/IOMMU settings
• Back up data, since incorrect choices (e.g., during disk selection) could wipe it

Graphics note:

• Intel integrated graphics strongly recommended
• Nvidia may require extra setup

---

VPN sponsorship/analysis embedded in the video

ProtonVPN sponsorship context

ProtonVPN is used as an example for:

• Regional blocking
• Travel-related access problems
  • Can’t access region-locked sites
  • The opposite problem when traveling: home-region sites can be blocked
• Currency conversion issues while traveling (e.g., terrible exchange rates)

ProtonVPN features highlighted

• Change virtual location using servers in other countries
• Zero-logs policy verified by independent auditors
• Open-source code
• “VPN accelerator,” “fast connection,” and a large server network

---

Main speakers / sources (as mentioned)

• David Bombell (presenter; “I’m David Bombell…”)
• ProtonVPN / Proton (sponsorship referenced)
• Whonix (mentioned as an integration used inside Qubes)