Secure Desktops with Qubes: Introduction

on May 27, 2016

This is the first in a multipart series on Qubes OS, a security-focusedoperating system that is fundamentally different from any other Linuxdesktop I've ever used and one I personally switched to during the pastcouple months. In this first article, I provide an overviewof what Qubes is, some of the approaches it takes that are completelydifferent from what you might be used to on a Linux desktop and someof its particularly interesting security features. In future articles,I'll give more how-to guides on installing and configuring it and howto use some of its more-advanced features.

When it comes to Linux security, server security tends to get the mostattention. When you are hardening servers, you generally try to limit whatany individual server does and use firewalls to restrict access betweenservers to only what is necessary. In a modern environment where a serveris running only SSH plus maybe one or two other networked services,there are only a few ways for an attacker to get in. If a particularserver does get hacked, ideally you can detect it, isolate that serverand respond to the emergency while the rest of your environment stays up.

Desktop Linux security is a completely different challenge because of justhow manydifferent things you do with yourdesktop. Each action youtake with your desktop computer opens up a new way to be compromised. Webbrowsing, especially if you still have certain risky plugins like Flashinstalled, is one major way a desktop can be compromised. E-mail is anotherpopular attack vector since you need to open only one malicious e-mailattachment or click on one malicious phishing link for an attack tosucceed. Linux desktops also often are used as development platforms,which means users might be downloading, building and executingsomeone else's code or running services directly on their desktop totest out their own code. Although some Linux users are smug when they thinkabout all of the malware on other platforms, the fact is that the dayswhen Windows was the only desktop OS in town are over, and these days,much of the malware is written in a cross-platform way so that it canrun on many different operating systems.

The biggest issue with desktop Linux security is what's at risk ifyou do get hacked: all of your personal data. This could be anythingfrom user names and passwords to important accounts like your bank orcredit-card accounts, your social-media accounts, your domain registraror Web sites you shopped at in the past that have your credit-card datacached. An attack could expose all of your personal photos or access toprivate e-mail messages. Attackers could leave behind a Remote Access Trojanthat lets them get back into your machine whenever they want, and in themeantime, they could snoop on you with your Webcam and microphone. Theyeven couldcompromise your SSH, VPN and GPG keys, which opens up access toother computers.

The core idea behind how Qubes provides security is an approach calledsecurity by compartmentalization. This approach focuses on limitingthe damage an attacker can do by separating your activities and theirrelated files to separate virtual machines (VMs). You then assigneach VM a certain level of trust based on the level of risk that VMpresents. For instance, you may create an untrusted VM that you usefor your generic, unauthenticated Web browsing. You then might have aseparate, more-trusted VM that you use only to access your bank. You maydecide to create a third highly trusted VM that has no network accessat all that you use to manage off-line documents.If you also work fromyour personal computer, you may create separate VMs for personal versuswork activities, with the work VM being more trusted. If you browse toa malicious Web site with your untrusted Web browser, the attacker won'thave access to your banking credentials or personal files since you storethose on different VMs. Qubes even provides disposable VMs: one-time-useVMs that are deleted completely from disk after the application closes.

How Qubes Works

Although you certainly could use any of the virtual machine technologiesout there to set up multiple VMs on your regular Linux desktop, that kindof arrangement can end up being pretty clunky, especially if you don'twant multiple desktop environments running inside their own windows. Therealso are all kinds of mistakes you could make with that kind of set upthat would eliminate any security benefits you might get. For instance,how should you share files or copy and paste between VMs securely, andhow do you keep all of those VMs up to date with security patches?

Wherea traditional Linux distribution made it easy for you to get all of thesoftware you wanted to use without having to download and compile it all,Qubes provides a number of extra tools that makes it easy to manage adesktop full of different virtual machines all with different levels oftrust. Qubes also approaches all aspects of the desktop with securityat the forefront and uses secure defaults throughout the OS. In doingso, Qubes makes it more difficult (but not impossible) for you to shootyourself in the foot.

Qubes uses Xen to provide all of its virtualization (if you want toknow why Qubes chose that over other technologies, see theFAQ on the Qubes site). Instead of each VM having its own complete desktopenvironment, Qubes uses the more-privileged dom0 Xen VM as a host forthe desktop environment (currently Qubes gives you the choice of KDE orXFCE, although the community has contributed others), and the other VMsdisplay individual application windows within dom0's desktop environment.

So, launching Firefox in Qubes behaves much like you would expect in anyother desktop distribution. The main difference, however, is that Qubeslets you color-code each of your VMs based on level of trust rangingfrom red (untrusted) to black (ultimately trusted) with a number ofdifferent rainbow colors in between.

When you launch an application froman application VM (appVM, in Qubes parlance), the VM starts up if it wasn'tstarted before, then the application appears with a window border thatis colorized based on the color you assigned its appVM. So, if you havetwo instances of Firefox on your desktop at the same time, you can tellyour untrusted Web browser from your banking Web browser, because theuntrusted one might be colored red while your banking browser might becolored green. Figure 1 provides a screenshot from Qubes' documentationthat demonstrates the point.

Figure 1. Multiple Windows with Different Colors

Since the dom0 VM has privileged access to data about the other VMs inXen, Qubes goes to extra lengths to protect it by having only the desktopenvironment run from it and by removing all network access from dom0. Youare encouraged to do as little as possible in dom0, and instead, you shoulduse appVMs for any applications you want to run. Qubes even intentionallymakes it more difficult to copy files to or from dom0 compared to copyingthem between appVMs. In the dom0 desktop environment's application menu,each VM has its own submenu where you can launch each of its applications(Figure 2). Qubes provides tools so all of those submenus don't becometoo unwieldy, and you can select which applications appear under whichappVM's menu.

Figure 2. Qubes Application Menu

Sharing Information between AppVMs

When you have multiple windows open, however, that raises the questionof how do you copy and paste? An insecure approach might be to sharethe clipboard between all windows, but then the risk would be that if youlogged in to a Web site in a trusted Web browser by copying and pastingfrom your password manager, that password would be readable by any otherappVMs that happened to be running. Instead, Qubes provides a two-tierapproach to clipboards. Each appVM has its own clipboard, and you can copyand paste within that appVM as normal. If you want to copy from one appVMand paste to another, once you have put the data in one appVM's clipboard,you press Ctrl-Shift-c to put it in the global clipboard, then highlightthe window you want to paste into and press Ctrl-Shift-v to paste that datainto that VM's clipboard and wipe it from the global clipboard. Then youcan paste inside that application as normal. It's definitely an extracumbersome step, but you would be surprised at how quickly you adapt to:Ctrl-c, Ctrl-Shift-c, change window, Ctrl-Shift-v, Ctrl-v. It definitelyhelps you prevent accidentally pasting information into the wrong window.

Qubes also provides a command-line tool and right-click menu options inthe GUI file manager so you can copy or move a file between appVMs. Whenyou attempt this, you get a prompt in a black-bordered window theappVM doesn't control so you can accept this file transfer. Eventhen, the file doesn't appear wherever you want on the destination VM(otherwise an attacker could overwrite important files with backdooredversions). Instead, the files show up in a QubesIncoming directory insideyour home directory.

TemplateVMs, Persistence and Backdoor Protection

Another area where Qubes provides an extra level of protection for adesktop user is in how it handles persistence. If attackers compromisea normal desktop, they can install backdoored versions of utilities, like lsor bash, or add extra programs that are triggered to start at boot. WithQubes, appVMs are based off templateVMs that have base installs ofFedora, Debian or Whonix by default (the community has provided templatesfor other popular distributions). When you create a new appVM, you choosewhich template it is based from, and when you start it, that appVM getsa read-only version of that template's root filesystem. Although the userinside the appVM still can install software or change the root filesystem,when that appVM shuts down, all of those changes are erased. Onlythe /rw, /usr/local and /home directories persist. This means yourbrowser history and settings will stick around, but if an attacker didcompromise your browser and tried to install a backdoor into bash orFirefox, the next time you rebooted that appVM, the backdoor would begone.

Also by default, appVMs do not launch any common initservices like cron automatically. That means attackers also couldn't just add a usercron entry that launched the backdoor. Although it's true that attackerscould store a malicious program in your appVM's home directory, thenext time you reboot the appVM, the program no longer would be running,and they would have no way to launch it again automatically.

So, how do you install software? Because each appVM uses a root filesystembased on its templateVM, when you want to install new software, you launchthe software manager from the templateVM and install the applicationwith yum, apt-get, the GUI equivalent or whatever other methodyou normally would use to install the software. Qubes then detectsany new application menu items you've added and makes them availableto the appVMs based on that template.

The only gotcha is that thosenewly installed applications are unavailable to appVMs until those appVMsrestart. Because compromising the templateVM compromises every appVMbased on it, Qubes generally encourages you to leave templateVMs off,to not run general applications from them and to turn them on only whenyou add trusted software. Although this does add an extra bit of work whenyou want to install software, it also provides a nice benefit in thatwhen you need to apply a security update, you just need to update thetemplateVM, and when you restart each appVM, it will get the update.

Network Security with netVMs

Another way Qubes provides security is by compartmentalizing thenetwork. Upon installation, Qubes will create a few special systemVMs called network VMs (netVMs), named sys-net, sys-firewall andsys-whonix. The sys-net netVM is assigned any networking hardware onyour host, so it's unavailable to any other VM. Because this netVM is theonly one with an IP on the external network, it's considered untrustedand colored red. You use Network Manager to configure this netVM withany credentials it needs to connect to wireless networks, and its NetworkManager applet shows up on your desktop as normal. The sys-firewall VM(technically classified as a proxyVM) is colored green and connects tosys-net for its network access. By default, any appVMs you create thenuse sys-firewall for their network access.

Why all this complexity? First, sys-firewall acts as a true firewallfor all of your appVMs. Although by default all appVMs can talk to theInternet unrestricted, Qubes provides a GUI tool that makes it easy tolock down individual appVMs so that they can access only certain hostson the network. For instance, you could restrict your banking appVM sothat it can talk only to port 443 on your banking Web site or restrictan e-mail appVM to talk only to your remote mail server. You even couldrestrict other VMs so that they could talk only to hosts on your internalnetwork. Anyone who wants to attack one of your appVMs has to go throughsys-net and sys-firewall. This also means if attackers do compromisean appVM, they don't have direct access to network hardware, so they can't,for instance, automatically connect to a different wireless access point.

The sys-whonix VM acts like sys-firewall except that it automaticallysets up a secure Tor router. Any appVMs that use sys-whonix insteadof sys-firewall or sys-net for their network have all of their trafficrouted over Tor automatically. Qubes also provides an anon-whonix appVM bydefault that uses the security and anonymity-focused distribution Whonix,and it includes the Tor browser and routes all traffic through sys-whonixby default.

I'm sure you already can see a number of areas where Qubes providesgreater security than you would find in a regular Linux desktop. Hopefully,you have a sense of what a different approach Qubes takes from what youmight be used to. With Qubes, you find yourself thinking much more abouthow you should isolate files and information and what attackers couldget if they successfully compromised one of your appVMs. Even the extracopy-and-paste and file-copy steps force you to confront whether you aretransferring information between an untrusted VM to a trusted one andthink through the implications. I've found the extra security measuresactually let me relax a little bit more than I would otherwise, becausefor instance, I know an e-mail attachment I open in a disposableVM can't do me much harm, or a malicious Web site in my untrusted Webbrowser can't access anything of value.

I've touched only on some of the higher-level security features in Qubeswith this article. In my next article, I will describe how to download andinstall Qubes, explain how to use Qubes as a desktop OS, including someof the basic features of the Qubes VM Manager and other Qubes-specifictools, and give some examples for how you might organize your day-to-daydesktop use across appVMs. I'll follow up with an article describingmore-advanced Qubes features, including split-GPG (a method that allowsappVMs to use your GPG private key without having direct access to it),how to manage links more securely with default application handlers,how to open e-mail attachments automatically in disposable VMs, and howto create a usbVM that isolates all of your USB devices for you (andwhy you would want to do that).

Kyle Rankin is a Tech Editor and columnist atLinux Journal and the Chief Security Officer at Purism. He is the author ofLinux Hardening in Hostile Networks,DevOps Troubleshooting,The Official Ubuntu Server Book,Knoppix Hacks,Knoppix Pocket Reference,Linux MultimediaHacks andUbuntu Hacks, and also a contributor to a number of other O'Reilly books. Rankin speaks frequently on security and open-source software including atBsidesLV, O'Reilly Security Conference, OSCON, SCALE, CactusCon, Linux World Expo and Penguicon. You can follow him at @kylerankin.

Load Disqus comments