By Rayne Cafaro
The Qubes OS project is an initiative started by forward thinking computing security professionals. These professionals realized that the general approach that is taken to operating system security does not keep up with the current challenges posed by today’s adversaries. In the current landscape of computing security, it is mere fantasy to believe that by employing the best security practices, a person can ensure they do not become compromised by some malicious attacker. This is why the Qubes OS project’s main goal is not to completely mitigate the possibility of a breach, but rather to minimize or completely eliminate the potential fallout in the case that a breach does occur.
Security by Compartmentalization
Image courtesy of the Qubes OS screenshot gallery: https://www.qubes-os.org/screenshots/
The main security approach taken by the Qubes OS project in their construction of Qubes linux is the concept of security by compartmentalization. Qubes linux is not built in similar fashion to most other operating systems designed to be used by individual end users. The Qubes OS project undertook the challenge of building an operating system that enables users to run virtual machines that segment the different components of a standard operating system into different integratable “compartments”. Qubes accomplishes this segmentation by running all individual operating system components on top of the Xen hypervisor. A hypervisor is a piece of software used to allocate a system’s hardware resources to one or multiple virtual operating systems. The Xen hypervisor is what is known as “type-1” hypervisor. Type-1 hypervisors interact directly with the hardware of the system that they are installed on. This is in contrast to a type-2 hypervisor, which has an intermediary, (typically a host operating system), between it and the hardware. The Qubes OS project chose to utilize a type-1 hypervisor as opposed to a type-2 hypervisor, because it reduces the attack vector for an attacker trying to compromise the system. Since a type-2 hypervisor is installed on top of a host os, if the host os becomes compromised, so does the hypervisor.
How Qubes uses Xen
Image courtesy of the Xen wiki: https://wiki.xen.org/wiki/File:Xen_Arch_Diagram.png
In the current version of Qubes linux (Qubes OS 3.2), many of the virtual machines that make up the components of Qubes consist of paravirtualized virtual machines. Paravirtualized VMs (PV-VMs) are virtual machines that do not require the CPU to support hardware virtualization extensions (such as AMD-V or Intel VT). In order to operate without CPU virtualization extensions, PV-VMs require the guest operating system kernel to support paravirtualization. The linux kernel used by Qubes OS 3.2 is the linux 4.4.x kernel. Given that the linux kernel has had support for paravirtualization since kernel version 2.6.24, many people would assume that deploying PV-VMs is the obvious choice for Qubes. Using PV-VMs allows Qubes to support a larger pool of hardware. Unfortunately, the Qubes OS project recently announced their intention to do away with PV-VM support in the next major release of Qubes linux (Qubes 4.0). The Qubes OS project feels as if the linux kernel does not yet have sufficient support for paravirtualization, so as to ensure continued security for users of Qubes linux. Over the last eight years, there have been four instances where Qubes linux whole platform became compromised due to a critical vulnerability found in the Xen hypervisor. All four of these vulnerabilities were vulnerabilities found in the way that Xen handles memory virtualization for PV-VMs. Until patched, every one of these vulnerabilities could have allowed attackers to break out of a breached virtual machine and gain access to all the other virtual machines running on a Qubes OS system.
Looking forward to the future, instead of using paravirtualization for its VMs, the Qubes OS project will be utilizing Hardware-assisted virtualization (HVM) alongside paravirtualization drivers (PVHVM). The drawback to this approach is that HVMs require CPU virtualization extensions to run. Other than the hardware requirements, the main reason the Qubes OS project attempted to avoid HVMs had to do with a significant decrease in speed and performance from PV-VMs. Now that PV drivers exist for HVMs, Qubes can deploy HVMs with performance the same or even better than a PV-VM, without the risks associated with using a fully paravirtualized VM.
Qubes and the End User
Image courtesy of the Invisible Things blog: https://blog.invisiblethings.org/2011/09/28/playing-with-qubes-networking-for-fun.html
In Qubes OS, the different components that make up a standard operating system are segmented, when possible, into different virtual machines. Upon a fresh installation of Qubes, there are a few different types of VMs that are readily available for the end user to start using the operating system. These VMs include Net VMs, Firewall VMs, App VMs (for work and personal use), and disposable VMs. Net VMs are the location of virtual network adapters, which are segmented into their own untrusted virtual machine. In the basic Qubes OS networking topology, a Net VM is set to forward traffic to a Firewall VM. App VMs then connect to the Firewall VM and traffic is relayed to them, based on what traffic makes it past the ruleset of the Firewall VM. Firewall rules can be implemented on the Firewall VM to allow or deny different types of traffic to different App VMs. App VMs are the location where end users perform their computing tasks. By default, Qubes OS provides a template for a personal App VM and a work App VM. Delegating all work tasks to the work App VM and all personal tasks to the personal App VM, guarantees that if a personal activity goes awry and data becomes compromised, it has no bearing on work data and vice-versa. The last type of default VM available to a Qubes linux end user is the disposable VM. This is a VM that destroys all data as soon as it is closed. Any task that an end user feels has potential to allow malicious data onto their device should be done in a disposable VM. An example of this would be downloading a file that the end user doesn’t necessarily trust.
Image courtesy of the Qubes OS screenshot gallery: https://www.qubes-os.org/attachment/wiki/QubesScreenshots/r2b2-software-update.png
The premiere feature of Qubes linux that makes it an extremely versatile operating system for the end user, is the fact that templates for VMs can be created using any distribution of linux, and as a bonus, full Windows VMs can be created to run alongside the other Qubes OS VMs. By default, Qubes creates templates for Fedora, Debian, and Whonix based environments. It is worth mentioning that Whonix is a debian-based linux distribution that routes all of its traffic through the Tor network.
What distinguishes Qubes OS from a glorified virtual machine manager is the seamless integration of applications from different VMs on the desktop environment (Qubes default is XFCE). In Qubes linux the desktop manager is located on a privileged VM known as Dom0. The concept of Dom0 comes from the Xen hypervisor, where on any Xen system, Dom0 is a privileged domain (virtual environment) tasked with spawning all other unprivileged domains. On Qubes, Dom0 also has the responsibility of rendering all the different applications from the different virtual machines on the system into a single unified user experience for the end user. Dom0 has no network access whatsoever, so it is very difficult for it to become compromised.
The Qubes OS project has provided an operating system that gives end users the best chance of keeping their data secure, while allowing for an end user to perform day to day computing tasks without extreme paranoia. By segmenting everything that an end user does into different virtual machines, even if one of those virtual machines becomes compromised, the data on any of the other virtual machines remains completely inaccessible to an attacker. An attackers only chance of breaking out of these virtual machines and accessing another virtual machine on a Qubes system, requires them to find vulnerabilities within the Xen hypervisor. This leaves attackers with a relatively small attack vector. Currently there are a few quirky limitations imposed by Qubes linux that might deter prospective users, such as a lack 3D graphics rendering allowed in any VM that isn’t Dom0. This means that tasks such as computer gaming aren’t yet viable on Qubes linux. The Qubes OS project imposes restrictions like this in order to prevent any way for an attacker break out of a VM. (In this case, there is currently no safe way to ensure that an attacker can’t access the graphics memory of another VM.) Aside from anyone concerned with these quirks, Qubes OS is the obvious choice for any linux user concerned with security.