A first look at Qubes OS

April 20, 2013

Qubes is a security-oriented OS that is designed to provide strong security through isolation. Built upon Xen, X Windows, and Fedora Core 18 (as of Qubes R2 beta 2), in Qubes both the components of the operating system and the user workspaces are isolated into functional domains, such as Dom0 for the GUI and user interaction through keyboard and mouse, NetVM and FirewallVM for the network stack, network drivers and network access control, and various user AppVMs for your applications and data. The mindset behind the design of Qubes is that the compromise of a domain (ex: your personal workspace) does not compromise the entire system or your entire data. Before continuing further we wish to clarify that we are not affiliated with Qubes OS or the Qubes developers in any way.

Perhaps one way to somewhat explain this architecture at a high level is to imagine a user who runs a VMware server that has multiple guest OS in which he/she uses each OS separately for different purposes: One system for casual web browsing, one for work, one for personal documents, and one with no network access to store their encrypted password database and other highly sensitive data. By default each of these guest OS are independent and do not communicate with one another. When the user wishes to browse the web they use their casual web browsing guest OS. When they wish to access work-related documents they use their work guest OS. Both guest OS can be running at the same time on the system and the user simply interacts with the desired application in the appropriate guest OS. Should they accidentally get infected while doing casual web browsing, only the data that's contained in that guest OS is jeopardized.

In Qubes, the user labels each AppVM (the guest OS) with a name and border color. When you launch your web browser in your personal AppVM, the browser application window is bordered in the color that you chose for that AppVM. If you launch another application within that same AppVM (ex: LibreOffice) it is also bordered with the same color. To clarify, each application within an AppVM are not isolated from the other applications within that same AppVM. Instead, all applications within the same AppVM belong to the same domain and are isolated from the other domains. You can create as many domains as fits your needs.

Each AppVM has its own custom X server and by default has 400 MB of RAM assigned. However given that each AppVM doesn't have any desktop environment running (no KDE, Gnome, etc.) the 400 MB default allocation is more ample than what that would normally provide on a regular desktop.

You may be asking, does simply installing and using Qubes without separating my work in different domains make my system more secure than using a regular Linux distro? The answer to this depends on what you define as "more secure" and how you intend on using your system. The Qubes OS itself has isolation of critical components already in place (User I/O, networking, storage) so that a serious vulnerability in one component doesn't result in a compromise of the whole system. For example the networkVM is purposely placed in a unprivileged domain, and Dom0 (the GUI) does not have network access and therefore cannot directly exfiltrate information to remote attackers (ignoring the possibility of covert channels). However an application vulnerability (for example in Firefox) will still allow access to whatever Firefox has access to within that domain. So for example if you use Qubes to do your online banking via Firefox in your banking domain AppVM, and Firefox gets compromised while accessing your bank (happens), your banking session could get hijacked and they could access and modify the data that's stored in that banking domain, but whatever data you have in other domains would stay unscathed, and they wouldn't be able to take screen captures of your entire GUI in Dom0 - they would only be able to take screen capture of your banking domain. Think of Qubes as a ship with multiple compartments that can contain and restrict water when a breach occurs. Whatever was in that flooded compartment might be compromised but the others should still be intact.

One thing to keep in mind is that just because you are isolating an attacker to a specific domain doesn't mean that you no longer have to worry about attacks in general. You still need to consider things such as certain types of physical or local network attacks (evil maid, ARP spoofing, rogue DNS servers, etc.)

System requirements

Before installing Qubes, you can check to see if your system supports hardware virtualization technologies (VT). Although VT aren't technically necessary in order to install Qubes, they are recommended from a performance and security perspective. So what you want to determine is whether your processor features virtualization extensions through Intel's VT-x (or AMD-V for AMD processors) and I/O MMU virtualization through Intel's VT-d (AMD-Vi for AMD).

For checking whether your system features VT-x, you can use the following instructions (taken from Ubuntu's documentation):

Intel and AMD both have developed extensions for their processors, deemed respectively Intel VT-x (code name Vanderpool) and AMD-V (code name Pacifica). To see if your processor supports one of these, you can review the output from this command:

egrep -c '(vmx|svm)' /proc/cpuinfo

If 0 it means that your CPU doesn't support hardware virtualization.
If 1 or more it does - but you still need to make sure that virtualization is enabled in the BIOS.

Although the output from above can return you a 1, you may still need to enable VT-x in your BIOS. See the following for instructions. As a side note as to why VT-x isn't always enabled by default, when virtualization first came to PCs there was a worry that malware could use the virtualization feature in order to sit under the operating system like a hypervisor, and become especially hard to remove. Therefore virtualization can be completely disabled at boot time, requiring a reboot and manual BIOS configuration to enable it. You may find that even though your processor supports virtualization, it is not featured in the BIOS (hence impossible to enable), or the BIOS may contain bugs that prevent you from enabling it. In such situations your options are to try updating the BIOS or replacing the hardware.1

Determining whether your system has VT-d is more tricky. Both your CPU and motherboard (chipset) must support it, and you may need to check your BIOS to confirm that it hasn't been disabled by your hardware manufacturer. See the following for more detail. The image below showing an example of how to enable VT-d in the BIOS is taken from Intel's page.

In terms of memory requirements for Qubes, 4 GB of RAM is what is recommended however you can install Qubes on systems that have just 2 GB, albeit if you look at the MEM column of the Qubes VM Manager in this screen capture of a Qubes system with 3 AppVMs running, you'll understand why you'll want as much RAM as possible. The system that we used to test Qubes is an older 2007 Dell desktop with 3 GB of RAM and VT-x.

As you can imagine with its design architecture it certainly isn't a performance-oriented OS. However it wasn't as slow as what we had expected it to be, in fact it was only the system shutdowns that we felt took longer than expected.


Download the Qubes ISO, verify the signatures to confirm its integrity, and burn it to DVD or copy it to USB for installation. Below are the hashes for Qubes-R2-Beta2-x86_64-DVD.iso at the time of this writing:

md5     ef4cc652d3e38cdf5414426d3a58a074
sha1    574a57e51571236f5f417aec723deb1859857661
sha256  a85b8a3fe0261341f801b50121feca86f1680edb34a210c4030073633baa855f

The installation is quite easy: You will be prompted for the usual things, such as keyboard settings, time zone, the destination where it should install to, and whether to encrypt the disk. You also pick whether to install KDE, Xfce, or both (default) for your Windows Manager. On our system we've set it up so that Qubes is installed on /dev/sda (overwriting a different Linux distro) with Windows already present on /dev/sdb. Make sure to take a backup of your system if you are planning a dual-boot environment.

Post Installation

The first thing you may wish to do after installing Qubes is to update your TemplateVM in order to apply all the latest security patches. Launch a terminal session for the TemplateVM, then in the command line enter yum check-update and yum update. Once done shut down the TemplateVM, and all AppVMs that are based off that TemplateVM and aren't currently running will have the updates when they are started up. Any currently running AppVM will update once they are restarted.

The next thing might be to change your default resolution as for us it picked a rather low resolution for our monitor. To do so click on the KDE start menu | System Tools | System Settings, scroll down and click on Display and Monitor. After selecting the proper resolution, click on Apply, and make sure to click on the Save as Default button.

Now you may wish to begin configuring your domains. In your TemplateVM use yum to install any new software that you need. In the AppVMs you can add to the list of applications listed in that AppVM menu by selecting the Applications tab in the respective AppVM settings of the Qubes VM Manager. Note that adding extensions to Firefox in the TemplateVM will not replicate this to the AppVMs - the extensions should be added in the appropriate AppVMs instead.

Brief explanation of common tasks and questions

The Qubes VM Manager in Dom0 is how the domains are managed. From here you can start, pause, shutdown, or kill each of the VM, perform updates, and modify settings such as the total disk storage allocated, memory reservations, the domain firewall rules in order to restrict whether that domain has network access and what it can access over the network, as well as what physical devices and what applications are available in that domain's menu.

If you wish to install an application that you don't fully trust, you can either install it in an existing AppVM where it'll get removed when that AppVM restarts, or if you want it to stay persistent you will need to setup a Standalone VM and install that software inside of it. Keep in mind that Standalone VMs will need to be updated manually as opposed to the centralized updates that AppVMs get from their TemplateVM.

By default Dom0 doesn't have network access and should be kept that way. Be careful with what and how you install new software in the TemplateVM since this will get replicated in all AppVMs that are based off that template. The FirewallVM and NetVM should be left alone to do their thing. The latter point should probably be repeated. The default configuration for these domains is secure. Don't change anything in their settings unless you have a good reason and know what you are doing.

To copy & paste text between different domains, in the application running in the source domain copy the text as normal (ctrl+c), then press ctrl+shift+c, then select the application in the destination domain, hit ctrl+shift+v, then ctrl+v. When you do this you will see a notification window informing you of this action as shown below.

In Qubes you can create a Hardware VM (HVM) which is a standalone domain that's running a different operating system. Below as an example are the commands that would be entered in Dom0 for installing Kali Linux from an ISO file that's stored on a USB drive:

qvm-create kali --hvm --label green
qvm-start kali --cdrom=/run/media/user/volume/kali.iso

While the Linux distro begins installing, in the Qubes VM Manager access the VM settings for the newly created Kali domain and select the Basic tab. At the bottom right the networking information (IP address, subnet, default gateway) for this domain is shown. Write this down as you will need to provide this during installation since DHCP will fail and will require that you manually set the network settings.

For More Inforamation

The Qubes devel group is the current official Qubes mailing list. It is worth reading through to not only find out more about Qubes but also some of the discussions regarding OS security that involve the Qubes developers are quite interesting.

The Qubes Documentation are well written and should be consulted whenever you run into problems or have questions.

Other useful links to review include:

  1. The Qubes FAQ
  2. Understanding Qubes networking and firewall
  3. How to Customize disposable VM
  4. The Qubes roadmap


Our overall impression of Qubes is positive. Its design is well thought out. Everything worked after installation without issues (network, video, sound, USB, DVD-ROM, etc.) and without the need to manually edit files. The performance, although certainly not blazing fast, was better than expected when considering what Qubes is doing in the background. The software is still in beta and so we did run into a couple of bugs however they were mostly pop-up messages that did not prevent us from doing what we were trying to do. We did not experience any problems creating, deleting, and updating the software in AppVMs. We were expecting to experience at least a few technical issues after installing Kali Linux in a new HVM, however it booted up fine with no errors and Qubes didn't erroneously get in the way as we started using nmap to scan external systems. We are reassured by the discussions of the developers in the Qubes mailing list which show that they understand information security and are implementing measures to protect against various types of attack scenarios that others don't even consider. All that to say we are quite pleased with this OS and are planning on keeping it installed. This is one to keep watching for its eventual non-beta release.

1. "How to check if your hardware supports virtualization", Red Hat, June 14, 2011