1. Intro §

Hello, I've been talking a lot about Qubes OS lately but I never explained why I got hooked to its offer. It's time to tell why I like it.

Qubes OS official project website

Artwork by Prahou

2. Presentation §

Qubes OS is like a meta system emphasizing on security and privacy. You start on an almost empty XFCE interface on a system called dom0 (Xen hypervisor) with no network access: this is your desktop from which you will start virtual machines integrating into dom0 display in order to do what you need to do with your computer.

Virtual Machines in Qubes OS are called qubes, most of the time, you want them to be using a template (Debian or Fedora for the official ones). If you install a program in the template, it will be available in a Qube using that template. When a Qube is set to only have a persistent /home directory, it's called an AppVM. In that case, any change done outside /home will be discarded upon reboot.

By default, the system network devices are assigned to a special Qube named sys-net which is special in that it gets the physical network devices attached to the VM. sys-net purpose is to be disposable and provide network access to the outside to the VM named sys-firewall which will be doing some filtering.

All your qubes using Internet will have to use sys-firewall as their network provider. A practical use case if you want to use a VPN but not globally is to create a sys-vpn Qube (pick the name you want), connect it to the Internet using sys-firewall, and now you can use sys-vpn as the network source for qubes that should use your VPN, it's really effective.

If you need to use an USB device like a microphone and webcam in a Qube, you have a systray app to handle USB pass-through, from the special Qube sys-usb managing the physical USB controllers, to attach the USB device into a Qube. This allows you to plug anything USB into the computer, and if you need to analyze it, you can start a disposable VM and check what's in there.

2.1. Pros §

• Efficient VM management due to the use of templates.
• Efficient resource usage due to Xen (memory ballooning, para-virtualization).
• Built for being secure.
• Disposables VMs.
• Builtin integration with Tor (using whonix).
• Secure copy/paste between VMs.
• Security (network is handled by a VM which gets the physical devices attached, hypervisor is not connected).
• Practical approach: if you need to run a program you can't trust because you have too (this happens sometimes), you can do that in a disposable VM and not worry.
• Easy update management + rollback ability in VMs.
• Easy USB pass-through to VMs.
• Easy file transfer between VMs.
• Incredible VM windows integration into the host.
• Qubes-rpc to setup things like split-ssh where the ssh key is stored in an offline VM, with user approval for each use.
• Modular networking, I can make a VPN in a VPN and assign it to other VM but not all.
• Easily extensible as all templates and VMs are managed by Salt Stack.

2.2. Cons §

• No GPU acceleration for rendering (no 3D programs, high CPU usage for video/conferencing).
• Limited hardware support due to Xen.
• Requires a powerful system (high CPU requirement + the more RAM the better).
• Qubes OS could be a choice by default because there is no competitor (yet).
• The project seems a bit understaffed.
• Hard learning curve.
• Limited templates offer: Fedora, Debian and whonix are officials. The community provides extra templates based on Gentoo, Kali or Cent OS 8.
• It's meant for a single person use only for a workstation.

3. My use case §

I tried Qubes OS early 2022, it felt very complicated and not efficient so I abandoned it only after a few hours. This year, I did want to try again for a longer time, reading documentation, trying to understand everything.

The more I used it, the more I got hooked by the idea, and how clean it was. I basically don't really want to use a different workflow anymore, that's why I'm currently implementing OpenKuBSD to have a similar experience on OpenBSD (even if I don't plan to have as many features as Qubes OS).

My workflow is the following, this doesn't mean it's the best one, but it fits my mindset and the way I want to separate things:

• a Qube for web browsing with privacy plugins and Arkenfox user.js, this is what I use to browse websites in general
• a Qube for communication: emails, XMPP and Matrix
• a Qube for development which contains my projects source code
• a Qube for each work client which contains their projects source code
• an OpenBSD VM to do ports work (it's not as integrated as the other though)
• a Qube without network for the KeePassXC databases (personal and per-client), SSH and GPG keys
• a Qube using a VPN for some specific network tasks, it can be connected 24/7 without having all the programs going through the VPN (or without having to write complicated ip rules to use this route only in some case)
• disposable VMs at hand to try things

I've configured my system to use split-SSH and split-GPG, so some qubes can request the use of my SSH key in the dom0 GUI, and I have to manually accept that one-time authorization on each use. It may appear annoying, but at least it gives me a visual indicator that the key is requested, from which VM, and it's not automatically approved (I only have to press Enter though).

I'm not afraid of mixing up client work with my personal projects due to different VM use. If I need to make experimentation, I can create a new Qube or use a disposable one, this won't affect my working systems. I always feel dirty and unsafe when I need to run a package manager like npm to build a program in a regular workstation...

Sometimes I want to experiment a new program, but I have no idea if it's safe when installing it manually or with "curl | sudo bash". In a dispoable, I just don't care, everything is destroyed when I close its terminal, and it doesn't contain any information.

What I really like is that when I say I'm using Qubes OS, for real I'm using Fedora, OpenBSD and NixOS in VMs, not "just" Qubes OS.

However, Qubes OS is super bad for multimedia in general. I have a dual boot with a regular Linux if I want to watch videos or use 3D programs (like Stellarium or Blender).

Qubes OS blog: how to organize your qubes: different users share their workflows

4. Why would you use Qubes OS? §

This is a question that seems to pop quite often on the project forum. It's hard to reply because Qubes OS has an important learning curve, it's picky with regard to hardware compatibility and requirements, and the pros/cons weight can differ greatly depending on your usage.

When you want important data to be kept almost physically separated from running programs, it's useful.

When you need to run programs you don't trust, it's useful.

When you prefer to separate contexts to avoid mixing up files / clipboard, like sharing some personal data in your workplace Slack, this can be useful.

When you want to use your computer without having to think about security and privacy, it's really not for you.

When you want to play video games, use 3D programs, benefit from GPU hardware acceleration (for machine learning, video encoding/decoding), this won't work, although with a second GPU you could attach it to a VM, but it requires some time and dedication to get it working fine.

5. Security §

Qubes OS security model relies on a virtualization software (currently XEN), however they are known to regularly have security issues. It can be debated whether virtualization is secure or not.

Qubes OS security advisory tracker

6. Conclusion §

I think Qubes OS has an unique offer with its compartmentalization paradigm. However, the required mindset and discipline to use it efficiently makes me warn that it's not for everyone, but more for a niche user base.

The security achieved here is relatively higher than in other systems if used correctly, but it really hinders the system usability for many common tasks. What I like most is that Qubes OS gives you the tools to easily solve practical problems like having to run proprietary and untrusted software.