Qubes OS review: An OS built with security in mind

Instead of trying to stop malware from detonating at all, the Qubes OS can just limit its blast radius under isolated layers

The Qubes OS interface on the ITPro background
(Image: © Future)

IT Pro Verdict


  • +

    A polished system with a thoughtful security architecture.

  • +

    Completely free.

  • +

    Native support for multiple operating systems.

  • +

    Compartmentalizes operating systems while still offering a way to exchange data.


  • -

    The system takes some getting used to for non-techies.

  • -

    Initial applications in a Qube takes extra time to load.

  • -

    No easy support for GPUs.

  • -

    A powerful system is recommended to cope with the multiple VMs involved.

Released in 2012, Qubes OS is a desktop operating system that achieves security through compartmentalization, protecting your assets by enabling you to isolate them from each other. Its creators, security researchers Joanna Rutowska and Rafal Wojtczuk, started with the assumption that parts of a user's system, whether an application or an underlying OS, would probably be compromised at some point. Isolating them at a low level means that if one application gets infected by malware there's less chance that the toxic software will be able to infect others or pilfer their data. 

Qubes OS review: Setup

What Rutowska and Wojtczuk created is an OS in its own right, but it's easier to think of it as a collection of different OSs running under a single management system. It's based on the Xen hypervisor, a 'Type 1' bare-metal hypervisor that runs multiple virtual machines. In this operating system's parlance, they're called Qubes. 

There are different kinds of Qube with different core functions. The ones that users will encounter most often are application VMs (app VMs), which handle different categories of task for the user while isolating their applications and data from the rest of the system. 

The OS comes installed with different app VM Qubes out of the box, including work, personal, and untrusted. These are just a suggestion, though; users can create as many of these as they like to support activities across different domains with different levels of trust. 

A freelancer with multiple clients might create separate app VM Qubes for each client to isolate their applications and data. If someone at client A infects the freelancer's Qube with a malicious attachment, the infection won't spread to client B's Qube. They might use each of these Qubes for nothing other than work-related tasks that rely on approved pieces of software. They might use a completely different app VM Qube to run their personal YouTube channel where they install and experiment with different pieces of random software from the Internet. 

Qubes OS review: Isolation features

The Qubes OS architecture is more nuanced than this. It also isolates other internal operations that would normally reside inside a single OS, and which users generally won't need to interact with much directly. These include an administrative Qube, dom0, which runs on a slim code base and administers the entire system, along with other separate Qubes that run various system functions. 

A GuiVM handles the GUI virtualization that runs multiple Qubes and their apps under the same user interface. Unprivileged networking Qubes handle networking (there's no networking functionality in the app VMs themselves), and these are connected to firewall Qubes that manage different sets of firewall rules. You can create multiple sys-USB Qubes to handle USB devices, and multiple sys-VPN Qubes to support different VPNs

This granular system neatly separates the internals from the app VM Qubes, which carries security benefits. You can choose which networking stack you want to connect your app VM to (perhaps a VPN for a specific work client). You can also turn networking on and off at will in a Qube via the Qubes Manager. 

Qubes OS review: Navigation

The Qubes OS GUI unifies access to all the separate Qubes in one place, accessible via a menu on the top right of the screen: 

The Qubes OS interface

(Image credit: Future)

You can launch an individual Qube, but the OS is really tailored to the launching of individual apps, shortcuts for which are provided in the menu. By default, the Personal Qube gives you four: Firefox, a settings manager, a file manager, and a terminal. You can update the apps that appear in this menu by changing the Qube's settings. 

Note that each of these Qubes is color-coded. While the Personal Qube is yellow, the default Untrusted Qube that comes out of the box is colored red. This is where you might want to play around with untrusted apps. 

Color coding in apps extends to the borders of the app windows themselves, minimizing the chance of mistakes. You can also dedicate the systems' different virtual workspaces (screens) to run each Qube's applications if that helps. Here, you can see Firefox browsers from two different Qubes running alongside the other: 

The Qubes OS interface

(Image credit: Future)

One common practice is to create 'vault' Qubes that never connect to the network. Just as with other Qubes, you can create as many of these as you like. One might contain only your local password manager, while another might contain your GPG keys. 

Although Qubes are isolated, you can still move or copy files and clipboard content between them. You do this using explicit menu commands in each Qube or by calling up a dom0 terminal directly from the desktop (Alt+F2) and typing in a command manually. Sending files this way puts them into a QubesIncoming folder in the destination Qube. You can check the status of all Qubes on the system using the Qubes Manager: 

The Qubes OS interface

(Image credit: Future)

You can also access settings from here, which gives you control over every aspect of a Qube's operation. Here is the settings panel for the Work Qube that the OS sets up by default: 

The QubesOS interface

(Image credit: Future)

Qubes OS review: Templates

You typically create Qubes using templates. These are versions of operating systems packaged specifically to work with the Qubes architecture. There are several currently available: Fedora, Debian, Ubuntu, Arch, CentOS, Gentoo, and Whonix. 

The Whonix template type deserves an extra mention. This OS was built for anonymity and is designed to run over the Tor onion routing network. This builds highly secure, privacy-focused network and client-side protections into Qubes OS. If you're a journalist wanting to probe shady characters on the dark web without leaving a trace, look no further. 

Windows users can still make Qubes using an instance of the OS built as a fully virtualized hardware virtual machine (HVM – a virtualization mode within Xen). You'll need the Qubes Windows Toolkit to provide extra features such as inter-Qube copy-paste support and automatic networking setup. Indeed, you can create any OS you like as an HVM (or run it as a live distro) as long as you have an installation ISO. You'll lose some of the goodies that templated setups provide, though. 

Templates are a fast and secure way to quickly create a new Qube with pre-existing settings. You can create three classes of Qube from a template: app VMs, standalone VMs, and disposables. 


App VMs based on a template have their own /home directory but instead of having their own root file system, they have read-only access to the templates. This facilitates the consistent, fast creation of lightweight Qubes. It also means that any security patches applied to the template are immediately applied to all Qubes based upon it. This happens via an update proxy within Qubes OS that manages updates to all templates automatically. If you want to use different Qubes for different sensitive work projects, this is an excellent system. 

The downside to creating app Qubes from templates is that only a Qube's /home, usr/local, and /rw/config directories persist across reboots. This means most applications you install on a non-template Qube will disappear on reboot. To get around this, you can create a standalone Qube instead. This is based on a template but completely independent of it, and uses its own root and home directories. This persists installed applications over time, but the downside is that you must update it manually. 

A disposable is a Qube that spawns on demand, runs a single application only once, and then deletes itself when closed. This is designed for operations that you only want to perform once, such as opening a suspicious-looking attachment or checking out an untrusted website. File managers in app Qubes include options to view or edit a file in a disposable, protecting you from any unforeseen consequences. You can also open apps like a browser in a disposable, both for privacy (there's no local record of your browsing habits) and security (malware infections aren't a problem). 

Qubes OS review: Is it worth it? 

Security by compartmentalization isn't new. Anyone who has run separate virtual machines for dangerous work like malware analysis or visiting untrustworthy sites has been operating a form of this. However, managing VMs manually can be cumbersome, especially if you want more than a couple of machines for different tasks. The Qubes OS team also makes the point that guest VMs running on a host OS are only as secure as the host. If your Windows host system is compromised, that compartmentalization no longer works. 

A Xen bare-metal hypervisor is still an underlying software shim that could be compromised, though, and the Qubes OS team admits that it has to 'blindly trust' Xen's security. However, a Type 1 hypervisor has a far smaller attack surface than an entire OS that acts as a hose for a VM. 

The Qubes OS team runs a security advisory tracker for the hypervisor, along with a separate Qubes Security Bulletin that includes any hypervisor vulnerabilities that affect Qubes. It also issues automatic security updates for dom0 and other Qubes. In short, nothing can ever be 100% secure, but the team nudges the needle as far in that direction as it can. 

There are some downsides to Qubes OS worth knowing. Because each Qube is a VM (albeit a lightweight one) it can take a lot of horsepower. The documentation recommends a fast SSD over an HDD for storage. Pack a decent amount of memory in there to keep your performance optimal (6Gb is minimal, but 16Gb is recommended). And if your CPU doesn't support the VT-x or VT-d extensions needed for virtualization, forget it. 

Also, consider graphics support. While it may work with some external GPUs, this can take some hand-holding, especially on NVIDIA kit. The team "strongly recommends" using CPUs with integrated graphics instead. That might be problematic if like mine your desktop is a Ryzen 9 3950x machine with no integrated graphics at all. My Framework laptop ran Qubes OS perfectly, though, with no hiccups. 

Qubes OS isn't right for everyone. People have had some success running games on it, for example, but it isn't built for that. What it does provide is a great foundation for the security and privacy-conscious. It isn't just for tinfoil hat types – it's useful for anyone technical who wants to interact with digital ecosystems with greater confidence and safety. The Snowdens of the world will use it (indeed, he recommends it), but we've also heard of engineers using it as their daily driver. If you're constantly working with sensitive files, especially across many different companies or types of activity, this will offer you some valuable peace of mind. 

However, there's an important caveat; there's little point in taking the extra time and effort to set up and operate Qubes OS without a basic level of privacy literacy. Basic OPSEC mistakes like accidentally uploading secrets to your work GitHub account will get your company's assets pwned, no matter how locked-down the originating Qube was. The same goes for surfing untrusted sites from that sensitive work account 'just this once', or reusing aliases between work accounts and your favorite Discord or gaming servers. However, get your digital hygiene practices right and this could level up your privacy and cybersecurity game significantly. 

Danny Bradbury

Danny Bradbury has been a print journalist specialising in technology since 1989 and a freelance writer since 1994. He has written for national publications on both sides of the Atlantic and has won awards for his investigative cybersecurity journalism work and his arts and culture writing. 

Danny writes about many different technology issues for audiences ranging from consumers through to software developers and CIOs. He also ghostwrites articles for many C-suite business executives in the technology sector and has worked as a presenter for multiple webinars and podcasts.