I’ve been using Qubes OS as my primary OS since version 2, released in 2014. That means I’m using Qubes OS for about a decade. Despite having to deal with a couple issues over the years, I think it’s a great Linux system. I can’t quite imagine switching to a more traditional one. Yet I know very few other Qubes OS users in my developer community, which surprises me. Let me explain why I like Qubes OS, and maybe give it a try.

How I learned about Qubes OS?

I don’t recall how I learned about Qubes OS. Possibly from a conference talk in the aftermath of the Snowden leaks in 2013? Maybe, not sure. But I liked how pragmatic the attitude was. It was described as “a reasonably secure operating system”, a motto still quoted on the web. I took it as an acknowledgement that a perfect security is either outright impossible, or would be extremely inconvenient. So let’s be pragmatic, and build the most secure usable system we can.

I’m a software engineer / developer, not a security specialist, nor a researcher in academia. For me, a practical system with improved security is infinitely better than a perfectly secure imaginary one. Or an impractical system I can’t actually use to do stuff.

Accepting some limitations (e.g. due to limited visibility into CPU microcode / firmware), and building the most secure Linux system within those constraints, seems like a pragmatic and impactful approach.

Of course, if NSA is after you, this may not be the right trade off. In my threat model there are many other (and much more likely) risks, and the Qubes OS helps with many of those.

Compartmentalization

The core idea of the Qubes OS is compartmentalization, which wikipedia defines as

… technique of separating two or more parts of a system to prevent malfunctions from spreading between or among them.

In other words, the system is divided into smaller pieces, to limit the blast radius of a security issue. Ship builders use the same approach by splitting the hull into waterproof sections. Buildings use firewalls. Same core idea.

One option is to define compartments for individual applications, and systems like SELinux, seccomp or AppArmor do mostly that. If you ever used such systems, you are aware how painful it can be. You have to define a profile describing what the application is allowed to do.

Defining a good profile is hard. It’s feasible for static deployments, like a webserver with a fixed list of directories or sockets. But apps on a workstation/laptop are not like that. Even the best profile will be pretty crude. Applications often need to exchange data, but how do you handle that in a profile? Only the user can decide, but there’s no way to do that. And many common applications may not even have a profile. What then?

Application qubes

Instead, Qubes OS defines compartments as VMs (called “qubes”) serving a particular purpose. You may have qubes for “work”, “personal”, “banking”, and so on. Each qube can run many applications (it really is just a VM), exchanging information freely.

But qubes are isolated. There may be a Firefox running in both “work” and “personal” qubes, but those are completely isolated processes, sharing no data. Here’s a diagram of the Qubes architecture, from the official docs:

The application VMs (qubes) are at the bottom. You could do something similar by running VMs, and Qubes does pretty much exactly that (it’s based on Xen). But Qubes does a great job at integrating this into the UI. There is a UI to create new qubes, copy data between them, manage USB devices and other resources (RAM, disk, network, firewall, …).

There’s much more details about this in the official docs.

The crucial detail is that while qubes are isolated (sharing no data), it is possible to pass data between them. However, doing so requires user action, i.e. the user has to initiate that. And it should be a fairly rare event. Having to pass data too often means you have defined the compartments wrong.

I find the system of qubes extremely convenient. It’s based on a concept of a “template” VM, providing the base system image, with a fixed set of installed packages. The “application” qubes are a thin layer on top of a particular “template,” with user data.

Any changes to the system in an application qube are ephemeral. I can install a package in a running qube, but it’ll disappear when the qube gets restarted. Only when a package gets installed into a “template” VM is it persistent, and all qubes based on that template will have it.

This means I can easily test a package in a qube, and if it breaks something I can just restart the qube and everything is fine. Here’s a list of (some of) the templates available in my system:

Qubes provides official templates for a range of Fedora and Debian versions, and community templates. Or you can build a custom one, of course. It’s just a VM, after all. It’s trivial to switch a qube to a different template and see how well it works.

This means I can test new releases easily, with an easy rollback.

I can install a new version of a template (e.g. fedora-42-xfce), set the qube to use the new template, and start it. If everything works OK, great. If not, I can switch back to the old template.

It’s trivial to clone a template (or application qube), and customize it in some way. I have multiple variants for the “fedora-42-xfce” template, with different sets of packages installed.

Qubes are just VMs, but it’s all nicely integrated. Every qube gets a network out of the box, you can set how much resources (CPU, RAM, disk space) it gets, etc.

System qubes

The same compartmentalization approach is used to place sensitive system components (networking code, USB stacks and drivers) into unprivileged VMs. Qubes defines “system” VMs, and provides ways to access them from app VMs.

Isolating USB devices into a special VM adds a bit of inconvenience as USB devices need to be “attached” to individual application qubes. But it’s not hard, it’s about two clicks in the GUI.

The great thing about “network” VMs is that they stack. The sys-net VM isolates the network stack, and then there can be “proxy” VMs doing all kinds of stuff with the network. There’s sys-firewall out of the box, but it’s trivial to add VMs forcing traffic through a VPN, and so on. For application qubes this is entirely transparent.

A couple days ago I configured a proxy VM forcing all traffic through a wireguard VPN into my home network. It took me about 5 minutes and now I can use this for any qube on my laptop.

Inconvenience and habit

Having to deal with a world split between multiple qubes may seem quite inconvenient, and there’s some truth to that. In practice it’s not an issue, for a couple reasons.

Copying data between qubes should be an exception, not a common thing. If you need to move data (e.g. files) between qubes very often, it’s a sign you put the boundary in the wrong place.

The Qubes OS provides a pretty decent UI/UX for sharing data between qubes. It’s pretty trivial to send a file to another qube, or copy-paste a value. There is a CLI and/or GUI for most of this. It may take a bit of time to learn, but then it’s just muscle memory. I don’t even need to think about it.

I realized Qubes forces me to stick to good practices and build healthy habits, and I like it. I know it’s reasonable to isolate the password manager from the rest of the system. And it’s possible to do all this without Qubes. But would I do that consistently? Probably not. I’d get lazy and everything would end up in a single pile. Qubes allows me to set things up in a way that allows me to stick to this with very little friction.

Issues

I like Qubes, but over the years I had to deal with a couple issues too. Some of this boils down to running a virtualized system based on Xen, and hardware compatibility.

I repeatedly ran into issues with UEFI during installation, particularly with Qubes OS 3.x. The exact issues tend to vary depending on the vendor and firmware, and it can be quite frustrating. But the docs have a whole chapter on how to troubleshoot this, and in the end I figured it out. I haven’t seen any issues with Qubes OS 4.x, but maybe I was lucky.

It’s worth checking the hardware compatibility list (HCL) which has information about known issues for laptops etc. There’s also a forum where you can discuss issues.

Another annoyance seems to be power management. AFAICS the Xen hides some of the information and controls from the kernel, limiting how it can manage this. I suspect the fans on my laptop are louder and it has worse battery life than with a regular Linux distro. But I haven’t done any back to back testing, so it’s more of a guess. And it’s acceptable.

One thing I’m still struggling with is a webcam and a microphone. I haven’t managed to make it work well enough for video calls. It stutters, there’s awful background noise etc. I suppose that’s due to having to pass the data from the sys-usb qube. I ended up simply doing calls using a dedicated tablet / phone.

Conclusions

So this is why I like Qubes OS. It “forces” me to separate stuff in a sensible way. I should have done that anyway, but without the concept of qubes it’d be hard to stick to it.

Would I recommend Qubes OS for non-technical users? Say, to run on devices used by family members. Probably not. Running Qubes requires some basic understanding of how virtualization works, and willingness to occasionally investigate how to do certain tasks.

Not everyone actually needs to compartmentalize stuff this way, especially on a personal device.