Qubes 4.0.1
Maybe security by isolation is what management had in mind when they relocated Jonni Bidwell to the far corner of the office.
Our disc is a little different this month, as you’ll have noticed if you eagerly fired it up before reading this. The usual boot menu isn’t there because we’re running with just a single distro: Qubes 4.0.1. Regular readers will recall the last time this happened was back in LXF220, when we featured the full-fat edition of OPENSUSE Leap. Much as we like making the discs and (painstakingly) getting different distros to all play along, it’s nice to showcase one of the fully featured distros every once in a while (also, you snuck off to the other side of the world and no one else
knows how to make discs – Ed). Especially when it’s something a bit different like Qubes.
While we’re being a bit different, let’s devote a whole four pages to this, in the developers’ refreshingly modest words, “Reasonably Secure Operating System” – do they know nothing of unbridled hyperbole and how it’s the best way to promote things? Incidentally, it is said that legendary rapper Ice Cube got his name from his brother threatening to lock him in a freezer, so perhaps if timelines were different and virtualisation had evolved quicker than hip hop, and ‘security by isolation’ was in common parlance, then we’d all be sitting in our lowered vehicles listening to Ice Qube.
Usually when we talk about privacy-conscious Linux distros, we don’t get far before Tails (The Amnesic Incognito Live System) is mentioned. Sadly we often don’t get to mention the other players here, of which Qubes is surely one of the more noteworthy (we should also, for completeness, mention Whonix and Subgraphos). Qubes takes a bold approach to security by running every application in its own virtual machine (a ‘qube’), providing security by compartmentalisation. Not only that, but different peripherals can be isolated in hardware qubes. Furthermore, Qubes can be configured to open files (in particular email attachments) in their own ‘disposable’ qubes.
All this segregation is achieved through the respected Xen hypervisor. This is what runs directly on the bare metal that is your PC. On top of that we have a privileged domain (dom0 in Xen parlance), and as many subordinate VMS (domus in Xen speak, ‘qubes’ hereafter) as we need. As a security precaution, dom0 doesn’t have access to network or USB hardware. It is used to run the desktop and window manager, and to administer the other Qubes.
If each of these unprivileged VMS was a traditional VM, in the sense that each required its own OS, then this model would not scale well at all. Fortunately that’s not how things work in Qubes. VMS can piggyback off so-called Templatevms, adopting their root filesystems (read only) and storing any additions or changes separately, much like how Overlayfs, as used in
Docker, works. Templatevms can be used to build and customise any operating system you like, and Qubes can manage these from a single point of contact. So for example you can update them all in a single click.
Unlike Docker containers though, VMS (even ones built off the same template VM) maintain isolation at the hardware level. Qubes can also be grouped together into domains (not the same as Xen domains), so you might have two different qubes for work-related applications with similar privilege levels, in a domain imaginatively titled Work.
Installing Qubes
With the default software selection, Qubes (which includes Debian and Whonix templates) requires a hefty 25GB for installation. It uses the same stylish Anaconda installer as Fedora, which will help you partition your disks and customise the install. If you’re not familiar with Anaconda, don’t worry; the only slightly left-field feature is the vague nonlinearity of the install process – you can start the install without having set up a user account. Your username and password can be chosen during or after the install.
Dual-booting Qubes is certainly possible, but we strongly recommend exercising caution here. As well as the risk of something going wrong, there’s a potential security issue if one of your other Oses is (or can be) compromised. From that point, it may be possible to interfere with the Qubes bootloader and undermine all of Qubes’s security – and that would be bad. That’s not really an issue if you’re just wanting to try out Qubes though, and as we mentioned before trying it out in a virtual machine is not so much fun.
By default Qubes will install with full-disk encryption (the /boot partition remains unencrypted, which is not usually a concern), which requires an additional password to be set up and entered at boot time. This is a sane default, since otherwise anyone could boot with a Live disc and with very little effort grab, say, the disk image file for the Vault domain, which (in the absence of further layers of encryption) would provide easy access to a seasoned Qubes user’s most sensitive bits.
Qubes takes the rather paranoid position that the system is already compromised on some level – at least to the extent that any new qube you spin up can be compromised, or any USB device you plug in or network you connect to is hostile. But that shouldn’t matter, so long as dom0, or any Templatevms in use, aren’t tarnished – then only data in a compromised qube could possibly be at risk. Unless of course you move data from that compromised qube into another one. This becomes all the more catastrophic the higher up the privilege chain you go, so a good rule of thumb is not to move data from a lesser privileged qube (say, the one running your malware-magnet of a web browser) to a more important one.
For this reason, your interaction with dom0 should be minimal; it’s not for running user programs in, and lots of the convenience features of other qubes (in particular the shared clipboard) have been disabled, so it’s actually quite hard to do so. Dom0 runs the Xfce desktop and hosts the administration tools for the other domains. The latter are all accessible from the former, so you shouldn’t even run any terminal commands in dom0, except in exceptional circumstances. If dom0 were to be compromised, then the game would be up for all the other domains too, so tread carefully.
One thing that might seem alarming at first is that dom0 runs Fedora 25, when the current version is 29 and 25 went EOL at the end of 2017. This isn’t as dire as it first appears, though; dom0 has no direct network access and other domains can only access securitycritical interfaces of dom0. The code that provides these interfaces and administration facilities is dutifully kept up to date by the Qubes team, so even though there are known vulnerabilities in Fedora 25, they are in components that either aren’t used by Qubes or have already been worked around.
The other qubes set up by default are all based on Fedora 29 (or Whonix – see later), though a Debian 9 Templatevm is also available for those who prefer to do things the Debian way.
With all these different VMS spun up, you might think keeping track of them would be difficult. Not so – you can assign a colour to each domain, and then applications will have their window borders coloured according to the security context in which they are running . A handful of colour-coded security contexts (domains) are created on install, including: Work (blue), Personal (yellow), Untrusted (red) and Vault (black, intended for storing passwords, crypto keys and the like). You can create others, but these four cover most people’s compartmentalisation requirements, at least in the beginning.
From the main application menu, it’s possible to start browsers and terminals in any of these domains. You can customise which applications are available in which domains, by selecting the appropriate domain from the menu, choosing Qube Settings and then visiting the Applications tab. In a fresh install only a minimal selection of applications are available. This isn’t to discourage you using different tools, but rather to encourage you to add those you need only to the contexts where they’re needed. You shouldn’t be adding a password manager to the Untrusted domain, for example. Besides customising the application selection, Qube Settings enables you to configure memory and VCPU usage for each qube, as well as firewall settings and the virtualisation mode.
Also set up are three Service VMS for network, firewall and USB devices, as well as one for administering the Whonix gateway. It’s worth familiarising yourself with the Qubes nomenclature; if nothing else it’ll help you understand how all the initially set up VMS rely on each other, and where any you want to build fit into the scheme of things
Templatevm: a barebones VM that can be customised as you see fit.
NETVM: a VM that connects to a network. ‘sys-network’ is the default NETVM. Other machines may connect directly to this, or via a Proxyvm.
Proxyvm: a VM that marshalls/restricts/ignores traffic to a NETVM. The qubes set up out of the box connect via the ‘sys-firewall’ Proxyvm.
APPVM: the most common kind of VMS you’ll work with in Qubes, these may be based on a traditional VM or a Templatevm, and are designed for running general applications in.
Disposablevms: a lightweight VM that can be spun up quickly and is designed to host a single application. When you’re done, the VM and everything in it vanishes.
Gleaming the Qube
Creating new qubes based on the preconfigured Template VMS (Debian, Fedora and Whonix) is easy. Just go to the Qube Manager or choose Create New Qubes VM from the main menu, choose a name and label, and in the Type drop-down select ‘Standalone qube based on a template’. If you want to create a Qube based on something else, that’s easy too. Just choose ‘Standalone qube not based on a template’ from the Type drop-down. You can either use an existing block device here, or boot an installation medium – typically an ISO file stored in another qube – to make your own standalone VM.
Templatevms for Fedora 29 and Debian 9 are installed by default, but other community-maintained ones are available. For example, Invisible Things Lab (https://invisiblethingslab.com) maintains a minimal (1.2GB uncompressed) Fedora 29 template. Installing new templates, or updating old ones, is one of the few
situations where you’ll interact directly with dom0. Start the Terminal Emulator, the second entry in the Application menu – it should give you a prompt of the form user@dom0 . From here you can install the template with:
$ sudo qubes-dom0-update qubes-template-fedora-29minimal
Since this template (and the other official templates) are considered secure, it’s highly recommended to clone it and work with the clone. This way the original remains intact in the event you become suspicious of your customisations. Cloning the template is just a matter of running:
$ qvm-clone fedora-29-minimal fedora-29-minimallxfcustom
Now we can customise the VM to our heart’s content, and then build more specialised Appvms based on that template. By default, networking is disabled. This may or may not be desirable, so your first step may be to enable it. From the Application menu go to ‘Template: fedora-29-minimal-lxfcustom’ and select ‘Qube settings’. In the Basic tab change the Networking setting to ‘sys-firewall’ and click Apply. Our Templatevm now has the same network access as the other domains; outgoing connections can be restricted in the Firewall rules tab, or more advanced control is available by creating a custom Proxyv, which we haven’t got room to go into here.
You can add software by starting a terminal in the cloned VM and using the dnf command. The minimal template only includes the Run and Terminal utilities. Once you’ve installed what you need, you can go on to build Appvms from the Template. Appvms have some persistence – the /home, /usr/local and /rw
directories will survive being shut down, but everything else will disappear and are copied from the appropriate Templatevm when the APPVM is restarted.
It’s possible to update the software in dom0 with:
$ sudo qubes-dom0-update
but in general this is only needed in very specific situations. You should be more concerned with keeping your Templatevms up to date. This is done exactly as you would on a normal Fedora install ( sudo dnf upgrade ), only you have to ensure you start a Terminal in the appropriate domain.
Hiding with Whonix
Seamlessly, then, let’s take this opportunity to talk about Whonix (www.whonix.org). This is a security and privacy-centric distro that forces traffic over the Tor network and uses several layers of virtualisation to keep things isolated. In fact, the whole OS is shipped as a VM, which makes it ideal for pairing with Qubes. Whonix itself spans two VMS: a gateway, which handles all the Tor routing; and a workstation, which runs user-level applications. The only ‘way out’ of the workstation VM is via the gateway, so applications trying to connect over the clearnet (whether maliciously or by accident) are forced over the Tor network. This precludes lots of deanonymisation vectors, including the DNS leaks that so often plague VPN users.
Whonix has a few features which make it superior to just Tor-ifying applications on your standard distro. Most notably, it uses stream isolation which prevents multiple applications bundling data over the same circuit. A determined attacker can correlate traffic when there’s enough of it and the same entry and exit nodes are used, so using different data paths goes some way toward thwarting this type of attack. In Qubes (if you didn’t deselect the option during install) these are called ‘sys-whonix’ and ‘anon-whonix’, and are based on the latest version, Whonix 14.
We can use the anon-whonix APPVM as a base for installing applications we’d like to use securely over Tor. But for heightened security we can make use of the disposable Whonix VM that comes preconfigured with Qubes. For example, to launch a Tor Browser choose ‘Disposable: whonix-ws-14-dvm’ > Tor Browser. Unless you have a particularly funky network setup, the default Connect option should get you connected – this worked at Future Towers, so we suspect it’ll work almost anywhere – and launch the browser.
When you’ve finished browsing whatever it is the authorities have no business knowing about, close the browser. The whole VM and any temporary data it created will more or less vanish. If these things ran entirely in RAM, we could be more reassuring about this, but as it stands we can’t. There’s always the remote possibility that data downloaded in a Dispvm will somehow find its way into some quiet corner of RAM or a swapfile. If you really need to leave no trace, consider using Tails.