1. Introduction §
Qubes OS can appear as something weird and hard to figure for people that never used it. By this article, I would like to help other understanding what it is, and when it is useful.
Qubes OS official project page
Two years ago, I wrote something that was mostly a list of Qubes OS features, but this was not really helping readers to understand what is Qubes OS except it does XYZ stuff.
While Qubes OS is often tagged as a security operating system, it only offers a canvas to handling compartmentalized systems to work as a whole.
Qubes OS gives its user the ability to do cyber risk management the way they want, which is unique. A quick word about it if you are not familiar with risk management: for instance, when running software at different level, you should ask "can I trust this?", can you trust the packager? The signing key? The original developer? The transitive dependencies involved? It is not possible to entirely trust the whole chain, so you might want to take actions like handling sensitive data only when disconnected. Or you might want to ensure that if your web browser is compromised, the data leak and damage will be reduced to a minimum. This can go pretty far and is complementary to in-depth defense or security hardening of operating systems.
2023-06-17 Why one would use Qubes OS?
In the article, I will pass on some features that I do not think are interesting for introducing Qubes OS to people or that could be too confusing, so no need to tell me I forgot to talk about XYZ feature :-)
I like to call Qubes OS a meta operating system, because it is not a Linux / BSD / Windows based OS: its core is Xen (some kind of virtualization enabled kernel). Not only it's Xen based, but by design it is meant to run virtual machines, hence the name "meta operating system" which is an OS meant to run many OSes make sense to me.
Qubes OS comes with a few virtual machines templates that are managed by the development team:
- debian
- fedora
- whonix (debian based distribution hardened for privacy)
There are also community templates for arch linux, gentoo, alpine, kali, kicksecure and certainly other you can find within the community.
Templates are not just templates, they are a ready to work, one-click/command install systems that integrate well within Qubes OS. It is time to explain how virtual machines interact together, as it is what makes Qubes OS great compared to any Linux system running KVM.
A virtual machine is named a "qube", it is a set of information and integration (template, firewall rules, resources, services, icons, ...).
3. Virtual machines synergy and integration §
The host system which has some kind of "admin" powers with regard to virtualization is named dom0 in Xen jargon. On Qubes OS, dom0 is a Fedora system (using a Xen kernel) with very few things installed, no networking and no USB access. Those two devices classes are assigned to two qubes, respectively named "sys-net" and "sys"usb". It is so to reduce the surface attack of dom0.
When running a graphical program within a qube, it will show a dedicated window in dom0 window manager, there are no big windows for each virtual machine, so running programs feels like a unified experience. The seamless windows feature works through a specific graphics driver within the qube, official templates support it and there is a Windows driver for it too.
Each qube has its own X11 server running, its own clipboard, kernel and memory. There are features to copy the clipboard of one qube, and transfer it to the clipboard of another qube. This can be configured to prevent clipboards to be used where you should not. This is rather practical if you store all your passwords in a qube, and you want to copy/paste them.
There are also file copy capabilities between qubes, which goes through Xen channels (some interconnection between Xen virtual machines allowing to transfer data), so no network is involved for data transfer. Data copy can also be configured, like one qube may be able to receive files from any, but never allow file to be transferred out.
In operations involving RPC features like file copy, a GUI in dom0 is shown to ask confirmation by the user (with a tiny delay to prevent hitting Enter before being able to understand what was going on).
As mentioned above, USB devices are assigned to a qube named "sys-usb", it provides a program to pass a device to a given qube (still through Xen channels), so it is easy to dispatch devices where you need them.
4. Networking §
Qubes OS offer a tree like networking with sys-net (holding the hardware networking devices) at the root and a sys-firewall qube below, from there, you can attach qubes to sys-firewall to get network.
Firewall rules can be configured per qube, and will be applied on the qube providing network to the one configured, this prevents the qube from removing its own rules because it is done at a level higher in the tree.
A tree like networking system also allow running multiple VPN in parallel, and assign qubes to each VPNs as you need. In my case, when I work for multiple clients they all have their own VPN, so I dedicate them a qube connecting to their VPN, then I attach qubes I use to work for this client to the according VPN. With the firewall rule set on the VPN qube to prevent any connection except to the endpoint, I have the guarantee that all traffic of that client work will go through their VPN.
It is also possible to not use any network in a qube, so it is offline and unable to connect to network.
Qubes OS come out of the box (except if you uncheck the box) with a qube encapsulating all traffic network through Tor network (incompatible traffic like UDP is discarded).
5. Templates (in Qubes OS jargon) §
I talked about templates earlier, in the sense of "ready to be installed and used", but a "Template VM" in Qubes OS has a special meaning. In order to make things manageable when you have a few dozen qubes, like handling updates or installing software, Qubes OS introduced Templates VMs.
A Template VM is a qube that you almost never use, except when you need to install a software or make a system change within it. Qubes OS updater will also make sure, from time to time, that installed packages are up-to-date.
So, what are them if there are not used? They are templates for a type of qubes named "AppVM". An AppVM is what you work the most with. It is an instance of the template it is configured to use, always reset from pristine state when starting, with a few directories persistent across reboot for this AppVM. The directories are all in /rw/
and symlinked where useful: /home
and /usr/local/
by default. You can have a single Template VM of Debian 13 and a dozen AppVM with each their own data in it, if you want to install "vim", you do it in the template and then all AppVM using Debian 13 Template VM will have "vim" installed (after a reboot after the change). Note that is also work for emacs :)
With this mechanism, it is easy to switch an AppVM from a Linux distribution to another, just switch the qube template to use Fedora instead of Debian, reboot, done. This is also useful when switching to a new major release of the distribution in the template: Debian 13 is bugged? Let's switch back to Debian 12 until it is fixed and continue working (do not forget writing a bug report to Debian).
6. Disposables templates §
You learned about Templates VM and how a AppVM inherits all the template, reset in fresh state every time. What about an AppVM that could be run from its pristine state the same way? They did it, it is called a disposable qube.
Basically, a disposable qube is a temporary copy of an AppVM with all its storage discarded on shutdown. It is the default for the sys-usb qube handling USB, if it gets infected by a device, it will be reset from a fresh state next boot.
Disposables have many use case:
- running a command on non-trusted file, to view or try to convert it to something more trustable (a PDF into BMP?)
- running a known to work system for a specific task, and be sure it will work exactly the same every time, like when using a printer
- as a playground to try stuff in an environment identical to another
7. Automatic snapshot §
Last but not least, a pretty nice but hidden feature is the ability to revert the storage of a qube to a previous state.
Qubes OS documentation: volume backup and revert
qubes are using virtual storage that can stack multiple changes, from a base image with different layers of changes over time stacked on top of it. Once the number of revisions to keep is reached, the oldest layer above the base image is merged. This is a simple mechanism that allows to revert to any given checkpoint between the base image and the last checkpoint.
Did you delete important files, and restoring a backup is way too much effort? Revert the last volume. Did a package update break an important software in a template? Revert the last volume.
Obviously, it comes as an extra storage cost, deleted files are only freed from the storage once they do not exist in a checkpoint.
8. Downsides of running Qubes OS §
Qubes OS has some drawbacks:
- it is slower than running a vanilla system, because all virtualization involved as a cost, most notably all 3D rendering is done on CPU within qubes, which is terrible for eye candy effects or video decoding. It is possible, with a lot of efforts, to assign second GPU when you have one, to a single qube at a time, to use it, but as the sentence already long enough is telling out loud, it is not practical.
- it requires effort to get into as it is different from your usual operating system, you will need to learn how to use it (this sounds rather logical when using a tool)
- hardware compatibility is a bit limited due Xen kernel, there is compatibility list curated by the community
Qubes OS hardware compatibility list
9. Conclusion §
I tried to give a simple overview of major Qubes OS features. The goal was not to make you reader an expert or be aware of every single feature, but to allow you to understand what Qubes OS can offer.