The Operating System That Can Protect You Even if You Get Hacked
This was originally published on the Freedom of the Press Foundation’s blog.
We wrote about the importance of the Tails operating system to all of the NSA journalists last week, but there’s also another little-known operating system that journalists should consider using if they find themselves in high-risk scenarios. It’s called Qubes.
I’ve only been using Qubes for a few weeks, but I feel like my operating system is now a digital fortress. Let me try to explain why, and how Qubes differs from Tails.
If any piece of software gets compromised, your whole computer is compromised. The attacker can look at your files, log your keystrokes, take screenshots, steal your encryption keys, and read the emails that you type before you even have a chance to encrypt them.
Developers can (and should) try to make their software more secure, but software will never be perfect. Trying to not get hacked is difficult when you have powerful adversaries, yet still have to get work done. Short of never connecting your computer to the internet, the best way to stay secure is to minimize the damage caused when you do eventually get hacked and “sandbox” the most vulnerable programs away from the rest of your computer. Qubes makes this more straight-forward than any other operating system I’ve used.
Qubes uses virtual machines to let you manage separate “security domains”. A virtual machine (VM) is basically a tiny operating system running inside of your real operating system. If your VM gets hacked, the attacker is able to access the files and read keystrokes in that VM, but not in other VMs or on your host computer. In Qubes all software (besides the desktop environment) is running inside of VMs, and you can easily and efficiently make as many as you need for whatever purposes you need. It’s also designed in such a way that if one VM gets infected with malware, the malware won’t be there the next time you reboot that VM.
For example, you may want to use Pidgin, an instant messaging application with OTR encryption capability, to chat with people securely. But Pidgin is notorious for its memory corruption vulnerabilities: the kind of bug that attackers can use to take over your computer by IMing you a weird-looking message. (All publicly known Pidgin vulnerabilities have been fixed if you’re using the latest version, but there’s always the possibility that there are vulnerabilities that have never been reported to the developers. These are called zero day vulnerabilities, and agencies like NSA and FBI spend lots of money to buy information about them.)
In order to use Pidgin as safely as possible, you can create an AppVM (the Qubes word for a VM to run specific apps in) that you use only for Pidgin. If a Pidgin-zero-day-wielding attacker sends you a weird-looking message that takes over your computer, all it will actually take over is your Pidgin AppVM. The worst that the attacker can do is steal your OTR keys and spy on your chat conversations. Everything else on your computer, such as your work documents, your PGP key, and your password database, will remain safe from the attacker.
Another example that would be useful to journalists: if you’re writing an article about sensitive documents, you can create an “air-gapped” AppVM that contains these documents, and any files or drafts associated with the story. If you open a document in this AppVM that tries to phone home to alert someone that it’s been opened, it will fail because this AppVM doesn’t have internet access. And if you open a malicious document that hacks this AppVM, the malware won’t be able to exfiltrate any of your files because it won’t have internet access. And finally, if some other part of your computers gets compromised, like your web browser, the attackers won’t have access to these sensitive work files.
You can also easily use “disposable VMs”, AppVMs that you create for a specific purpose and delete when you’re done with them, to open documents that you don’t completely trust. If that PDF someone emailed you is actually malicious and tries to take over your computer, it will only take over the disposable VM. But if it actually contains something useful, you’ll still be able to read it.
You can do this all on one computer using a single desktop manager. This is one of the most powerful features about Qubes.
You can always choose to isolate software like this on traditional operating systems using tools like VirtualBox or VMWare, but it’s impossible to do as good a job of locking down your computer as you can with Qubes.
Current state of the project
At the moment you have to be pretty tech savvy in order to get the full benefits of Qubes. And it doesn’t hurt if you’re already a Linux nerd. I think this can be improved, but Qubes will never be a “turn on and forget” security tool. Which security domains each user needs is completely dependent on their preferences and security needs. But if you understand your needs and understand how to use and configure AppVMs to fit them, you’ll be able to use your computer with much higher security than if you were using a traditional OS.
The places where usability could be greatly improved is hardware support inside of VMs. I spent hours trying to figure out how to make my laptop’s internal webcam accessible to an AppVM. The solution finally ended up being to give the AppVM control of my USB controller and to change permissions on /dev/video0 to be world-writable inside of the AppVM — at the expense of having access to one my USB ports, and while opening up other USB-related security problems (which normal OSes always have). Hardware issues like this keep popping up for me: USB sticks work fine, but USB ethernet cards don’t; I can’t easily import photos from my Android phone. I have enough patience, googlefu, and Linux experience to solve them, but I think many users would be lost.
Qubes vs Tails?
Qubes and Tails have fundamentally different use-cases. They’re both very important, and I use both operating systems every day.
Tails is for staying anonymous. When you use it on a computer, it doesn’t leave a trace that it was ever booted. It changes your MAC address before you connect to a network, and it forces all traffic to go over the Tor network, ensuring that you don’t make a technical mistake and accidentally leak your IP address. When you use the web browser that comes with Tails, your traffic looks exactly like the traffic of all other Tor users.
Qubes is for staying secure while still being able to use a wide variety of software that might contain zero day vulnerabilities, but it’s not for staying anonymous. Qubes supports cool networking tricks, like making an AppVM where all traffic is forced to go through Tor, but this doesn’t incorporate most of the anonymity tricks that Tails excels at.
For maximum security, I would recommend that people use Qubes on their computer for all their everyday, non-anonymous needs: checking email, chatting, using social media and browsing the web, developing software, doing research, writing articles. Since you do all of this work in AppVMs that run Linux (and optionally some of it in AppVMs that run Windows), you get the latest and best tools to work with, and it’s simple to install new software. For more sensitive needs where anonymity is important, you can use Tor Browser Bundle inside of an AppVM.
And for the most sensitive needs, as the NSA journalists explained, you should boot to Tails.
Legacy comments, imported from previous version of this blog:
As long as the Von Neumann model is followed, i.e. code and data in the same memory space is continued to be used, nothing is "secure." It's not necessarily the OS's problem, it's the processor's problem.
You remind me of a fellow that insisted that as long as you can get a pointer, you can do anything on a system. His mental model of computers was based on pre-386 machines without an MMU. He didn't realize that paging meant that pointers were virtual, and having one doesn't grant you any access to real hardware memory.
I'm not sure if you're making that exact error, or if you're making a similar one. In any case, the VMX CPUs (i.e., Intel's VT-x and AMD's AMD-V) do the same thing for the CPU that the 386 did for memory. All CPU access is now virtualized. The "guest" OS does not have access to the hardware address space, whether that means memory or the system bus, and it does not have hardware access to privileged CPU instructions.
So the CPU is already providing the security support that is necessary. There are still some tactics for VMs to leak information between one another through cache invalidation and CPU usage, which can be observed cross-VM, but the kind of attack you are suggesting is not possible with modern hardware.
Qubes is great. I also have working break-out-of-VM exploits for Xen, KVM, and ESXi. The one for Xen is weaponized for Firefox and Chrome. Have a nice day.
One of them was even created by the Qubes development team.
Are you talking about this bug? https://groups.google.com/forum/#!msg/qubes-devel/JIpZoQUP6dQ/g6TvtpUHzBQJ
Or do you claim that you have zero day that works against current versions of Qubes?
"The one for Xen is weaponized for Firefox and Chrome" -- so you also have a Firefox and Chrome code exec zero day?
Can you boot Tails in an AppVM in the Qubes OS?
Yes, though technically it's an HVM not an AppVM (you can boot to any ISO in an HVM). You can't do stuff like secure file transfer or secure copy/paste between the Tails HVM and other AppVMs though. And of course Tails warns you that you're running in a VM, and creating a persistent volume is hard. But it's certainly doable.
What about Whonix?
This is timely and interesting. You mention Linux (and Windows in parentheses). I'd like to see a system that supports OS X and other flavors of *nix as well.
App sandboxing can only do so much. So I see this as the future of operating systems (or at least popular OSes taking cues from this and improving).
The biggest problem with OSX is ridiculous terms that you agree in the license. For the longest time you were only allowed to virtualize OSX Server, but not the desktop version. Apparently this changed with Lion?
But in any case, you're only allowed to run virtual OSX on Mac hardware, which really puts a monkey wrench into all of this. It's also hard to get OSX working well in normal VM environments like Xen, VirtualBox, etc. because it normally violates the license so most people don't put serious resources into it.
But if Apple ever stops being stupid and restrictive, I'm sure you'll easily be able to run Mac software in Qubes. Knowing Apple, that probably won't happen for some time.
What about something like LXC?
Qubes OS has a stronger security requirement. With LXC, you still have a shared kernel. The reason Qubes OS has VMs for things like storage and network is that it even distrusts your kernel. If a bug in your ethernet card's driver is found, Qubes OS's VM isolation will contain the breach. Even if your ethernet adapter contains a hardware backdoor or your wifi adaptor contains malicious firmware, Qubes OS will use your IOMMU to prevent these from accessing anything outside the NetVM.
When I was first looking into this sort of isolation security stuff a lot of people recommended both Qubes and LXC. I actually haven't tried LXC at all myself, but this is the same impression that I get.
[…] de la privacidad, incluidos Edward Snowden y varios periodistas, entre los que se encuentra Micah Lee de la publicación The […]
Take a look at mempo. All in one. Still in early process though.
can't copy & paste from vmware or (ubuntu) to Tails browser help
[…] written in the past about how awesome Qubes is, which is also a reasonably secure operating system. So how does it […]
Hey A noob question here. The base OS can still be compromised by a virus transferred physically (by a USB) right? By Base OS I mean the OS used to manage all the 'APPVMs'. If that happens, does it mean all the 'APPVMS' are compromised too?
Yes, but the whole idea of virtualisation is that you dont use your base system for anything apart from hosting all the AppVms. This the reason for hosting the drivers of e.g. USBs in seperated AppVMs (netvm, usbvm). If you use this and assign usb devices very carefully you can protect against such threads.
And Qubes website is served in plain text http. What if you are owned when u try to download Qubes?
Qubes provides digital signatures: http://qubes-os.org/trac/wiki/VerifyingSignatures and at the moment you can confirm the fingerprint over https from here: https://groups.google.com/forum/#!msg/qubes-users/CLnB5uFu_YQ/ZjObBpz0S9UJ
Though since verifying gnupg signatures is hard, and most people have no idea what it even means, they really they should use HTTPS, and it looks like setting it up is in the works: https://groups.google.com/forum/#!searchin/qubes-users/https/qubes-users/d9HtPr-E6aI/vLibCaM5D6kJ
Thanks for ur reply.