Does your computer respect your rights? Part 2/2

Thomas Roka-Aardal
8 min readApr 8, 2021

--

A story about nostalgia, freedom and laptops

This is a follow-up to part 1 of this blog post, written after a couple of years of use and experience. You can read part 1 here.

After living with the Librem setup mentioned in part 1 for quite some time I felt that I wanted to learn even more, and I noticed that our security experts were using virtualisation a great deal. Not just to be able to run various operating systems on the same machine, but also to isolate certain things from others. Like having a pentesting VM with the relevant tools installed to be able to spin up and use without it messing up their development environment. Other reasons for using VMs could be to have more control over the operating system, where a certain VM could be trusted only for some things, and others could be trusted for more — almost like “isolation layers”. Thinking even further, those isolated components could be even more fine-grained, such as for a single application or for hardware devices, networking etc.

And once I started researching that I found the Qubes OS project (https://www.qubes-os.org/). Based on research from 2010 it defines a new computing platform based on bare-metal virtualisation (Xen) and modern technologies such as VT-d and Trusted Execution Technology to create a complete compartmentalised operating system.

The Qubes OS

(Note: you need supported hardware to be able to run Qubes — check out https://www.qubes-os.org/doc/system-requirements/ if you want to run this yourself.)

If your browser is compromised today because of a certain exploited bug, the operating system is usually not able to protect the rest of your system. Also, if something lower in the stack (like your network driver) gets compromised, something running on top of it cannot be easily defended.

The Qubes research project decided that modern operating systems are so complex and intertwined that they simply cannot be made secure. The project took “VM isolation” to another level and paved the way for choosing how to separate various computing, storage, device and networking components.

The Qubes OS architecture from their early research

Using the isolation approach, a user can define certain VMs which are given different levels of trust, and the Qubes OS makes sure the VM interaction is prohibited or strictly controlled. In the above diagram from the 2010 research paper, the VMs are given colors to represent risk, so the “red” VM is used for insecure things like surfing the internet on various sites. The “yellow” VM could be your business apps, e-mail etc. And the “green” could be your banking VM with a secure ssh key perhaps. So far so good. But what does this look like in practice, and can it really be productive?

Before answering that, let’s look at how Qubes OS of 2021 has evolved:

The Qubes OS virtual machine landscape and trust levels

The operating system has an administrative VM (called “dom0”) which is a bare-bones OS running the Xen hypervisor and having access to the lower-level hardware. It is very limited, because any vulnerability there might easier spread to the other VMs due to its somewhat elevated access and control.

Then there is the GuiVM, which controls the display and graphics hardware. Above that are VMs one can create for any purpose — there is a concept of a “template VM”, which is almost like a VM golden image, which you can use as a template for “AppVMs” which are the VMs you actually run and use. The template VMs can be spun up, but that is only so they can be configured as you want, so your App VMs have what they need. Anything in the Template VM is available to all App VMs using that template.

Then there are certain VMs which the Qubes OS system have prepared for special purposes which you can choose to use if you want — and these are very interesting: the “sys-net” VM (for networking), “sys-firewall” VM (for firewall rules), “sys-usb” VM (for USB device access) and the “sys-whonix” VM (for anonymous access to the internet). All of these are also VMs which can be modified, upgraded, changed, copied etc.

When you then create an AppVM, you choose a Template VM (templates can be any operating system you can install, like “Windows 7”), select which VM should provide networking, which should provide upgrades and more. That way you can create endless combinations and complexity (or simplicity) in your VMs and isolation.

The “sys-whonix” VM is a very interesting one. Qubes has mentioned in their research that “fingerprinting” is a serious privacy issue which is very difficult to avoid. Mechanisms out there try to look at every single little breadcrumb we leave behind, piece a lot of those together, and find out who we are (or as close to that as is practical) even though we have taken a lot of precautions. This VM uses the Tor browser and network to route internet traffic, and is used by special Qubes VMs for upgrades. That means when you do your “apt upgrade” or your Microsoft Update, it can route you through anonymous channels to avoid as much fingerprinting as possible which you would normally leave behind in your default VM.

Being anonymous on the internet is hard, and sometimes (for certain sites) impossible, and in some cases not even desirable. But the ability to be as anonymous as possible is definitely a value we should cherish and protect. Also want to add that it doesn’t help to just “anonymise” your laptop configuration (even though you do things like randomise your hex device codes and more) if you are still leaking DNS information or want to filter information. If you want to look into this, check out using Pi-hole or other similar sandboxes for more DNS control.

Getting back to the thread — now, with modern technology it is possible (as many virtualisation vendors already do) to present virtualised apps “natively” in a single desktop environment.

Isolating VMs but keeping them integrated from a desktop perspective

Qubes integrates and displays the separate VM apps on your desktop while still enforcing the isolation rules in place for each of them. For example, if you try to “copy-paste” between them, rules kick in, and ask you if this is what you really mean (if at all enabled).

Also, to visualise this even more Qubes gives you the ability to assign a specific colour to your individual VMs. This colour is reflected in all applications running under that VM, showing you physically that these are different, isolated components.

Example applications running in different VMs with different colored frames

Imagine creating a complete stack of template VMs, which use a certain networking stack, another stack which uses a completely different networking setup, uses a specific VPN etc. And because of the isolation, you are not routing your network through the customer VPN for your business email (subject to certain hw limitations). Amazing!

Also, storage is equally isolated and partitioned, so that there is no “shared disk”, everything is either direct storage or through another VM. So whether or not you want to isolate based on work vs. personal, secure vs. insecure, travel vs. home is entirely up to you.

Example custom VM configuration for work, personal, shopping etc

By the way, these kind of setups are often used by security professionals as mentioned initially, since they provide many benefits for them. Also, they allow you to do ethical hacking where you will need to avoid any form of cross-contamination between customer environments, and many other use-cases involving isolation. All you need to do is throw away the compromised VM and fire up a new one.

Another very cool thing is the concept of “disposable” VMs. This is a VM which works like any other VM, except that when it is stopped everything is removed. These VMs usually have very limited privileges, but are extremely useful for things like reading a USB drive which could contain malicious code, or browsing a potentially harmful website. You can be reasonably confident that whatever happens, nothing can harm the rest of your VMs, and once you kill it, it is gone.

So I went for this setup on my Purism laptop: Librem hardware, the Heads anti-evil-maid setup, and the Qubes operating system. While supported, it took a little while to get used to, and I must admit the threshold is a little high for a newbie. But after using Qubes for a while I really liked it, and just like the Librem laptop it makes for very good conversation once people see weird desktop things like different coloured window frames.

After being tried and tested for a while I found the first things I wanted to do was to have a more customised template VM setup. I created multiple Debian and Windows templates for various use cases. Note that Windows 10 is not a huge fan of Xen and needs full virtualisation, which eats a bit more resources. Also, the “pass-through” hardware functionality is not ideal, so if you depend on a certain VM for doing Teams calls it could be a little hit-and-miss as to whether your webcam works.

I created various work and personal VMs and used different ones for various customer engagements and similar. All in all very interesting and a steep but valuable learning curve, and one that worked quite well in a business setting for a year.

Using Qubes on the Librem worked fairly well, but there were a couple of things for me that ultimately made me switch back to PureOS:

  • Xen does not like hibernation, so the VMs never go to sleep, which means if you are moving around with a laptop a lot, you are going to need power.
  • Qubes isolation restrictions can be annoying for normal usage. Simple things like changing the desktop background image needs to be done on the dom0 (most trusted) VM, which is highly discouraged.
  • If something stops working (like the microphone) for some reason, it really won’t come back unless you reboot. This might be due to my somewhat non-standard hardware, but it caused me to be less productive and more stressed.

Also, to be honest, my threat model really does not require me to go this far, so there is no real need for me to live with this restricted setup, but I do understand the use cases for our pentesters, journalists and those who really have that kind of threat model to deal with.

So Qubes OS is not really for the faint of heart, but definitively a learning experience I can recommend for those interested. For more information, look at the main website at https://www.qubes-os.org/ and the various sites (like on Reddit) discussing Qubes and privacy.

Onwards!!

All images © 2021 The Qubes OS Project and others

--

--

Thomas Roka-Aardal

Identity & architecture geek, CTO @ Nagarro, BU Head Information Security