Yesterday saw the long-awaited release of Qubes OS 4.0. The new version of Edward Snowden’s favourite operating system is the product of some fundamental re-engineering including some major changes to the underlying architecture, hence the long wait since the last official release, version 3.2 in 2016.
There has been a complete rewrite of the core stack to allow Qubes OS to be much more modular, with the eventual aim of eventually expanding its scope from the current single-user single-machine model to take in multi-user, server-based and even (whisper it) cloud-based deployment. The redesign is also intended to make things simpler for developers of Qubes-specific apps and services.
Before proceeding with this review, here’s a declaration of interest. I like Qubes. It’s a maverick among increasingly similar Linux distros (arguably it’s not even a Linux distro at all, but rather a Xen distro). I like the audacity of the project, following the logic of security rather than shiny things. I like the spiky Twitter persona of lead developer renowned security engineer Joanna Rutkowska, who seems to inhabit the description “doesn’t suffer fools gladly” with relish (I’ve never met her in person) – which is exactly what you want in a cryptologist, I’d argue. I like what a small team of developers has achieved since 2010 in creating “a reasonably secure operating system”, and I approve of the modesty and realism of that strapline: you’re not going to find a more secure general purpose operating system than Qubes, but at the same time it’s only as safe as the underlying hardware it runs on (Intel ME, Spectre) and software of which it is comprised (Xen bugs, Linux flaws) allows it to be.
So trust nothing, least of all this review. That’s the whole Qubes message. Trust nothing and assume you’ve already been breached. Now, how can you limit the damage your attacker can do?
What is Qubes OS?
Rather than a collection of services built around a single kernel in the conventional way, Qubes OS is actually made up of multiple virtualised OSs atop a hypervisor. It’s an amalgam of many interconnected parts that’s designed in such a way that no one part need ultimately trust any other more than is absolutely necessary for the system to work: so-called ‘security by isolation’. If any one part is compromised by an attacker, the rest of the system should remain secure.
The base layer, AdminVM, of Qubes OS is currently Xen, the open source hypervisor. It controls all the virtual machines (VMs) that make up the system but is locked down, with no direct connection to the Internet.
On top of AdminVM sit a couple of Fedora-based VMs (called qubes in version 4.0) that take care of networking and firewall duties. Then there are Template qubes which are Fedora 26 and Debian 9 VMs on which applications are installed. Coloured black by default, the Templates are connected via the networking and firewall qubes to their respective software repositories but not, by default, to the Internet more generally.
Generated from these Templates are the AppVM qubes which provide the colour-coded user interfaces for day-to-day use. Importantly, software installed on these AppVMs is ephemeral; it will not survive a reboot unless specifically installed in the user’s home or /rw directory. That includes any malware or other nasties inadvertently downloaded from the web which is banished as soon as the AppVM is shut down. Only software installed on the Template qubes is persistent.
So if you want to use LibreOffice, say, assuming you wish to use it next time you reboot you install it on a Template qube. Thereafter any AppVM qubes based on that Template will be able to use LibreOffice with no risk of corrupting the original installation – security by isolation again. Plus, only one qube need be updated each time.
In essence, Qubes OS users run multiple machines on the same physical device and are able to copy files and text securely between them. Each AppVM qube is isolated from the other AppVM qubes and the Templates and it is only by “breaking out” of a qube that an attacker can hope to take control of the system as a whole by compromising the AdminVM – and this is an eventuality that Qubes OS makes as difficult as possible.
Sounds complicated? Well it is, and that’s just scratching the surface. We haven’t yet touched on the Whonix qubes that route all traffic through Tor, or the disposable one-use-only AppVM qubes, but that’s the basic picture.
The real marvel of Qubes OS, though, is that it doesn’t feel that complex in use. Delivering cutting-edge security with usability is what Qubes OS really brings to the table.
There is a learning curve though. Windows users hoping for a secure drop-in
replacement will be disappointed (unless they want to install Windows in a qube – yes, it can be done!). We’re talking Linux after all, and at the no-frills bleeding edge end too. So you’ll need to resort to the command line at some stage, such as when installing or updating software. There are some other idiosyncrasies too such as the hot key sequences ctrl-C shift-ctrl-C and shift-ctrl-V ctrl-V to copy and paste test between qubes (qubes do not share a clipboard) which takes a bit of getting used to, and copying files between qubes has it’s own procedure. Overall though, for anyone already familiar with Linux using Qubes OS is not really that much of a leap.
Review: Qubes OS 4.0
Save this article