KUHBS Kuh Build System Qubes OS KUHBS Kuh Build System
English KUHBS Qubes OS website
Menu

Documentation

Qubes OS, KUHBS, and threat models

Learn how Qubes OS isolates apps, how KUHBS makes setup easier, and the limits of clean rebuilds, backups, and firmware security.

What is Qubes OS?

Qubes OS is a free and open-source, security-oriented desktop operating system. It uses Xen virtualization to create isolated security domains implemented as Qubes OS VMs, then presents their application windows together on one desktop with names and colored borders.

Its primary security property is compartmentalization: compromise of software in one Qubes OS VM should not automatically expose software and data in other VMs. TemplateVMs, DisposableVMs, network VMs, device VMs, and controlled cross-VM transfer make those compartments practical to use. The official introduction explains the model in more detail.

What is KUHBS?

KUHBS is a GUI-first build and lifecycle system for Qubes OS. An end user selects an application or service KUHB—Signal, Thunderbird, Office, a VPN, a firewall—and presses Create. The operator-reviewed KUHB definition resolves the required Qubes OS VM topology, applies settings, runs setup and hooks, and generates only its configured launchers.

KUHBS treats generated Qubes OS VMs as cattle rather than pets. The operator-reviewed definition is the rebuild recipe; selected application data is backed up separately; and Create, Upgrade, Backup, Restore, and Remove operate on the whole KUHB through the same Python CLI used by the GUI.

Which threat models do they address?

Qubes OS assumes that ordinary software contains exploitable bugs. Its isolation helps contain a compromised browser, document viewer, network stack, USB stack, or other risky workload inside the Qubes OS VM that owns it. It does not isolate applications from each other when they share one VM, and users can still defeat compartment boundaries by moving unsafe data or granting untrusted code access to more trusted VMs. See the official security design goals .

KUHBS addresses a different problem: Qubes OS is powerful, but manually creating, connecting, updating, backing up, and rebuilding many Qubes OS VMs is too complicated for many people. KUHBS turns operator-reviewed definitions into repeatable GUI actions and makes clean replacement practical; it is not an additional isolation boundary or a live drift reconciler.

Who is KUHBS for?

The Qubes OS project explicitly discusses users such as journalists, human-rights activists, whistleblowers, and researchers. Those users may need strong compartmentalization without having the time or technical background to design every TemplateVM, AppVM, NetVM, qrexec rule, launcher, and backup path themselves.

KUHBS exists to make that daily use easier for non-technical people. A catalog author can define a starting topology for an application, and the end user can independently review it, enable its card, and click Create. This is not a security guarantee: the result is only as good as Qubes OS, the hardware, the complete KUHB tree, its software sources, and the user’s decisions.

What KUHBS helps with

  • installing an application as a complete, predefined Qubes OS VM topology;
  • reproducing the same topology after a failure or clean reinstall;
  • keeping configured launchers, VM settings, network paths, setup, upgrades, and removal together;
  • backing up only the application paths selected in kuhb.yml; and
  • making privileged setup code visible in a repository that can be reviewed before use.

Browser sessions: disposable by default

Web browsers are one of the most common ways malicious content reaches a computer. KUHBS therefore recommends the surf KUHB for normal browsing. surf is an unnamed DisposableVM (udp) KUHB: Firefox, LibreWolf, Chromium, Mullvad Browser, Brave, and its other browser launchers each start a fresh unnamed DisposableVM and discard that session when it closes. Do not use a persistent AppVM for normal web browsing.

This means logging in again for every browser session. That repeated login is intentional and is time well spent on security. Keep the websites and credentials you need in the persistent, no-network KeePassXC KUHB. Copy only the URL, username, and password currently needed through the Qubes OS cross-VM clipboard into the disposable browser session. Do not preserve browser profiles, cookies, extensions, or session state merely for convenience.

What KUHBS does not do

  • It does not make Signal, Thunderbird, a browser, Office, or any other application free of vulnerabilities.
  • It does not detect an intrusion or prove that a Qubes OS VM, backup, firmware image, or KUHB repository is clean.
  • It does not make a malicious KUHB safe. KUHB code may run in dom0 or as root inside Qubes OS VMs.
  • It does not protect two applications from each other when they run in the same Qubes OS VM.
  • It does not stop malware that is restored inside application data.
  • It does not provide complete protection against an advanced state-level adversary.

Assume Qubes OS plus KUHBS is not sufficient by itself against an advanced state-level adversary. Compartmentalization can still limit some compromises, but an attacker may target firmware, the supply chain, dom0, Xen, installation media, updates, accounts, physical access, or the data you later restore.

CVEs, zero-days, and AI

A vulnerability is a security weakness. A zero-day is a vulnerability being used or known before defenders have a usable fix. A CVE—Common Vulnerabilities and Exposures—is the public identifier assigned to a specific known vulnerability so vendors and users can discuss and track the same flaw. A zero-day may receive a CVE after it is disclosed, but not every CVE was ever a zero-day.

For example, Mozilla’s CVE-2026-57963 describes a Thunderbird flaw where a malicious HTML chat message could inject styled content and phishing links and manipulate the chat interface. Mozilla fixed it in Thunderbird 152.0.1. The complete Thunderbird security advisory list shows how often ordinary applications need security fixes.

AI can help defenders review code and find bugs, but it can also help criminals and state-backed attackers search large codebases and develop exploits faster. New vulnerabilities and zero-days will continue to appear. For a high-risk threat model, take the pessimistic position: assume that at least part of the computer, and possibly all of it, may already have been compromised through vulnerabilities that were unknown at the time.

Regular upgrades are essential because they close known vulnerabilities before those flaws can be exploited. They are not proof of recovery after exploitation: updating the vulnerable application does not necessarily remove malware or persistence that was installed earlier, and compromised state can survive in backups. The clean-rebuild strategy depends on rebuilding later with software in which some of the previously unknown vulnerabilities have been fixed, then restoring as little old state as possible.

The clean-rebuild routine

KUHBS is specifically designed to make clean replacement practical: definitions recreate the Qubes OS VM topology, and configured archives restore selected application data. For this project’s high-risk threat model, periodic clean replacement is the strongest practical routine it recommends. You do not have to rebuild the computer regularly, but this project highly recommends it. Rebuild immediately after a suspected compromise and on a schedule appropriate to the user’s risk.

  1. Back up only the application data that is genuinely needed, and test that the backup can be read.
  2. On a separate trusted computer, download Qubes OS and the correct BIOS/UEFI or other firmware images. Verify every available signature and hash from the official publisher.
  3. Create fresh trusted recovery media and keep it offline until use.
  4. Follow the hardware vendor’s exact model-specific procedure to flash supported firmware. Do not flash when the model, image, signature, power, or recovery procedure is uncertain.
  5. Wipe the system disk and install Qubes OS from the verified installer.
  6. Update Qubes OS, then install the reviewed KUHBS version and reviewed KUHB repositories.
  7. If you use the separate hardware-specific system catalog, create its reviewed KUHBs. Start the backup VM and attach, unlock, and mount the backup storage.
  8. Run kuhbs create-all or click Create all. Create restores matching KUHBS archives before setup scripts when the backup VM and /mnt/kuhbs-backup are available.
  9. Verify every restored application before treating the new installation as trusted.

This routine removes malware that only persisted on the old system disk or inside replaceable Qubes OS VMs. It cannot remove malware that survives in unflashed firmware or that is reintroduced from recovery media, repositories, software downloads, accounts, or backups.

Three remaining persistence risks

1. Firmware that was not reflashed

Reinstalling Qubes OS does not rewrite every firmware component. BIOS/UEFI, embedded controllers, storage, network devices, USB devices, docks, and other peripherals may have separate firmware. Flash every supported component only with the correct, verified vendor image. Treat components that cannot be reflashed or independently verified as a remaining risk.

2. Trusted recovery media

A USB stick is not trusted merely because it contains an installer. Build recovery media on a separate trusted computer from verified Qubes OS and firmware downloads. Label it, store it offline, do not use it for ordinary file transfer, and recreate it whenever its history is uncertain. If a firmware image or Qubes OS installer cannot be authenticated, do not use it for a high-assurance rebuild.

3. Backups

KUHBS reduces backup exposure by declaring exact paths in kuhb.yml. A Thunderbird KUHB might back up /home/user/.thunderbird instead of all of /home/user. That is a useful reduction, but malware can still hide in /home/user/.thunderbird, browser profiles, documents, extensions, macros, caches, or other selected data. The USB stick or other backup device also has firmware and a controller that ordinary file deletion does not rewrite. A compromised backup device can remain a risk across rebuilds, and KUHBS cannot verify or clean that firmware.

Restore less data, not more. The most secure option is to restore nothing and start from scratch. When that is not practical, prefer the smallest possible set of simple data, such as reviewed text files. Re-enter passwords manually or restore only a minimal encrypted password-manager database; do not store passwords in unencrypted text. Avoid restoring complete application profiles when individual files or exports are enough.

Keep old and rarely used data on a second air-gapped laptop that never connects to a network. Data that is no longer required for daily work should remain there instead of returning to the new Qubes OS and KUHBS installation. This will not always be possible, but reduce restored state as far as practical.

Automatic restoration is convenient, not automatically safe. Before create-all, place only the KUHBS archives you intend to restore under /mnt/kuhbs-backup; keep older archives on the air-gapped system. The less old state you restore, the fewer places previously installed malware has to persist.

Next: Create a structured backup of your old system .