Hacker News new | comments | show | ask | jobs | submit login
The Operating System That Can Protect You Even if You Get Hacked (micahflee.com)
64 points by ryutin on Apr 14, 2014 | hide | past | web | favorite | 51 comments

"You are absolutely deluded, if not stupid, if you think that a worldwide collection of software engineers who can't write operating systems or applications without security holes, can then turn around and suddenly write virtualization layers without security holes."

Theo de Raadt, 2007

The idea behind qubes is to use the security properties of virtualization layers to enable a secure , easy to use system. Given that virtualization layers are relatively small ,code wise ,that's a good place to start.

Given that amazon uses xen in the EC2 platform(as many others), we're not only talking only about "worldwide collection of software engineers " but also of some serious commercial interests in it's security.

And XEN might not be the end point of that approach. There has been some research on formally verified hypervisors.While it's not 100% foolproof since you still have to depend on hardware security, which is a unknown(does intel cooperate with NSA?), that could give great assurances for system security.

> does intel cooperate with NSA?

Intel and NSA are not the problem. The real problem are hackers who want to steal our bank accounts, or the commercial providers who want to have all our private data to sell it secretely. For such daily problems I consider Qubes a very good protection. It's very nice to be able to do banking or web browsing in isolated VMs. It's also nice to have insecure OS like Windows run almost securely in a VM.

xen is over 100k lines of code, not counting the kind of interfaces software exposes using its APIs, and stuff like drivers.

its not small

You don't need to review all that code. From the qubes architecture document:

"it is possible to move all the drivers and driver backends out of Dom0. The same is true for moving the IO Device Emulator (ioemu) out of Dom0."

Did anyone claim qubes does not have security holes? The point of qubes is not to "solve security", it's to make a useable everyday OS that offers better security than other general-purpose OSs. It does this by isolation and minimizing attack surfaces between moving parts.

EDIT: Here is some documentation that describes the security stance of the Qubes OS project. As you will see, being security-bug-free is not a goal, and in fact, the guiding principle is that all code has security bugs, hence everything is isolated to prevent escalation. http://files.qubes-os.org/files/doc/arch-spec-0.3.pdf http://qubes-os.org/trac/wiki/SecurityCriticalCode

I agree. Formal methods is the best technology I know of that has a hope of eliminating a large class of security vunerabilities. Projects like seL4 have a lot of promise: small, formally verified kernels or virtualization layers that provide separation and provable security guarantees.

Of course, the entire premise of this operating system is that VMs are secure, even though there have been exploits targeting them in the past [0].

Disabling virtualization capabilities in the bios is a semi-common recommendation for securing a computer... Still, this OS is a darn sight better than nothing and it'll certainly protect against most things. However, touting it as perfect is misleading.

[0]: https://en.wikipedia.org/wiki/Blue_Pill_%28software%29

You do know that the Blue Pill exploit was created by the developers of Qubes, right?

No, I had no clue that was the case! That's pretty reassuring to know. It still doesn't change that my confidence in the Hyperviser has been shaken a little, but I trust this more knowing that, and I do think the premise of Qubes is great and relatively secure - if not certainly perfect.

If they can break out of Chrome sandboxes they can target Qubes

Defense in depth is a good thing, and this adds another layer.

If an attacker has to exploit the browser to get access as an unprivileged user, then find a local exploit to get root on the VM, then circumvent SELinux on the VM, then load a kernel module on the VM that exploits the hypervisor to get DOM0, then the attacker needs to burn a lot more 0-days and considerably increase their chances of getting caught compared to just exploiting the browser and going straight to accessing the information they want.

Unfortunately, some types of attacks might bypass multiple layers in one hit (e.g. exploit graphics driver on X server VM through WebGL, install keylogger on X server).

I've been using Qubes every day for well over a year now, and I know enough about the architecture to dispel a few of these assumptions.

1. By default, there is no need for an attacker to find a local exploit to get root--the user account has unrestricted password-less sudo authorization. This is one of the things I disagree with the developers about.

2. SELinux is disabled in AppVMs by default.

3. The GUI virtualization architecture takes this into account, and uses Xen shared memory to blindly copy a framebuffer prepared by the domU X server. Exploiting the dom0 X server should be very difficult.

Also, one main attractive feature of Qubes is the networking architecture: so long as iptables is not compromised by an attack, and there is no Xen sandbox breakout, it's fairly easy to set very restrictive or specific firewall and routing rules which will thwart many zero-day threats.

Further, VMs externally look no different than any other Fedora 18/20 installation, so even if an attacker had a Xen sandbox exploit, they would have to have specific knowledge that you run Qubes (e.g. you posted to Hacker News saying so ;)) in order to own your system, which is security 'by obscurity' but is still useful.

Qubes is more of a powerful security-enabling tool than a 'secure by default' distribution. Non-technical people (e.g. human rights lawyers, national security reporters) should probably use Tails unless they have a high degree of technical sophistication. It's very easy to shoot yourself in the foot.

> 1. By default, there is no need for an attacker to find a local exploit to get root--the user account has unrestricted password-less sudo authorization. This is one of the things I disagree with the developers about.

I've been using qubes for a little while myself. I agree that it should be harder to go from domU user to domU root. However I think having to manage passwords for every AppVM also negates a lot of the benefits of the template setup in qubes (I currently have about 30 AppVMs).

My ideal solution to this problem, which I might implement at some point, would be to implement a PAM module for domU that asks dom0 whether escalation to root is okay. That way, dom0 can prompt the user whether to allow it or not, and no per-AppVM passwords have to be remembered.

That's a neat idea; I'd like to have that. Please really consider contributing some code, or at least an initial proposal on the qubes-devel list :).

I don't see how that follows or relates; chrome's sandboxes are definitely not VMs... VMs are in general better understood and far better isolated.

Can you expound on that comment?

How is the isolation in Xen better than Chrome sandboxes - do you mean the attack surface is smaller, the code quality better, or the task somehow inherently simpler/easier?

From where I sit, vulnerabilities in virtualization have seen less public scrutiny than the Chrome sandbox. Eg none of the hypervisor vendors have a bug bounty program, which would be at least some kind of signal.

The attack surface of a paravirtualized Xen VM to its hypervisor is much smaller than a linux application talking to the linux kernel.

Of course it's not perfect, but xen has a pretty good track record. And a significant chunk of the flaws that have been found xen were found by the qubes devs.

The Chrome sandbox setup doesn't correspond to a regular linux application talking to the kernel though. It has a 2-layer sandbox, with the seccomp-bpf and setuid sandboxes. They restrict the kernel interface to a whitelisted subset.

At some level to use an OS, Qubes need to be able to talk to each other. We've had hacks which break TCP stacks, OpenSSL (recently) and practically every other type of subsystem.

Hell, Cryptolocker shows up that fundamentally the whole thing is solving the wrong problem in the first place for ordinary users, which is who cares if the OS survives if your data doesn't?

> 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

Yes, the only thing the attacker can do is compromise all of your chat conversations and impersonate you on an ongoing basis. Maybe you keep a separate browser VM for sensitive work: good, but only secure as long as you never ever accidentally visit a site you don't completely trust, such as any HTTP site.

Don't get me wrong, I think Qubes is really cool, but our ultimate goal, collectively, should be an OS where the entire stack, except possibly a few lowest level components (but not including things like filesystems and network drivers), is written in a higher level language than C/C++ and guaranteed free of memory corruption vulnerabilities in the first place. While non-memory corruption vulnerabilities exist, they're generally drastically easier to reason about and prevent, while C vulnerabilities can be anywhere, with exploit mitigations that make most attacks only harder, not impossible.

In the meantime, I guess you could always browse using Chromium with ASan enabled :)

Every time I hear about moving the entire stack to high level languages I have two thoughts:

* I love high level languages, but is there even a toy OS that provides a decent amount of functionality with tolerable performance without cheating? * There is no silver bullet to anything, let alone security. Automatic bounds checks only solve that one problem.

For instance, most would consider this an order of some of the vulnerabilities that potentially exist in increasing severity. And note that the first one is what Heartbleed is qualified as.

* Buffer overrun on read * Buffer overrun on write * Arbitrary code execution

Also good would be taking better advantage of hardware protection, kernel api design, and app permissions, so that even when something is compromised it can't just start poking around doing whatever it wants.

The 3 people who work on Qubes [0] are very good security researchers and I have more faith in their work than most.

It should be noted that the OS's VM'ing is based on the Xen bar-metal VM kernel which is pretty well researched, small, and elegant.

[0] http://invisiblethingslab.com/itl/About.html

I've recently switched to using VMWare for everything, and disabling networking on the host (use a pfSense VM for networking). It's quite handy, but still feels a bit heavyweight. Of course, I'm sort of forced to run Windows as the host to ensure best driver/battery support.

I really hope these approaches like Qubes take off and that things get optimized for this type of workload. I'm not sure why Microsoft has ignored lightweight virtualization, both on client and server.

That sounds great, but how many other virtual machines are you using, what is your heuristic for deciding what task is run in which virtual machine, and how strict are you about which sensitive data is used on multiple VMs?

(note: genuinely curious. I've gone down this route before myself before realizing there was simply too much overlap between my "sensitive" and "normal" work. I still employ similar configurations but for protection against data corruption, ease of system administration, and R&D purposes only.)

Right now, just games/junk browsing, home (personal email, browsing, projects), work (per customer). On Windows I use Sandboxie to further isolate things like browsers.

It's not perfect, but at least when a client wants me to run some damn .exe to join their oh-so-great screen-sharing platform, my home environment isn't messed up. And I can run random games or utilities and quickly revert to a snapshot.

The most sensitive keys stay in the host partition.

As an attacker I care only about the data and don't give a a shit if it is a real machine or a virtual one. If I can sniff the passwords in your browser or just have a keylogger in one of the VMs I am fine. Not sure if that solves a thing.

edit: I remember there were similar concepts a decade or so ago. where you had your "green" desktop for intranet or whatever and then a seperate "red" desktop which you could switch to and go to the evil internet. hint: no benefit gained

It seems likely that this indeed will give you increased security.

But it is dangerous to educate non-technical people that this VM-based OS gives you absolute guarantees of security.

And please don't start redefining the term "air-gapped" such that it applies to a VM that doesn't have network access. "air" "gapped" is a pretty absolute concept, and does not mean a VM without network on a host that does.

I love Qubes; the people involved are awesome.

What I'd really like to work on is Compartment Mode Workstation with physically distinct hardware.

Essentially, a "windowing KVM" frontend to a bunch of physically separated processor/memory subsystems, connected via well-defined networking interfaces. Essentially X Windows, but actually secure. This is sort of how desktop virtualization (VDI) works today, but with a separate instance per application.

Weird thought: that raspi module sells for $30 in quantity, you could easily run one process on that, and use the gpio pins to communicate with a host. One user visible process, one subsystem.

It would be reasonably affordable.

Upper limits on the number of processes you could run would be dictated by how many modules you plug in, you could make a backplane like model where you daisychain multiple backplanes for more processes.

I do everything these days in a VM, Virtualbox at the moment. A different VM for different classes of task. With the shared clipboard and shared folder options it is still pretty convenient. Of course, my laptop has 16gb of ram which helps if I want to run multiple VMs at once with more than a few gb each. It's nice to have a base VM for each OS I use and just branch off that for new VMs.

If someone is wondering, Qubes (and all Linux based distros) are not Macbook friendly [1]. But honestly, if security or privacy are a priority for you then you are probably not using a Macbook anyway.

[1]: https://groups.google.com/forum/#!topic/qubes-devel/uLDYGdKk...

Why would you not be using a Macbook if you want security or privacy?

If you are referring to Mac OSX and its integrations with App Stores and social media systems, note that it is entirely optional (I don't use any of the social media guff bundled into the OS).

Unless you are referring to something else and think that buying a piece of hardware somehow means you don't care about privacy, regardless of which software you are running on that piece of hardware?

I don't think the piece of hardware is relevant?

If security and privacy are of absolute priority to you (journalist, activist) then using a OS with closed source essentials is absolutely absurd.

If security and privacy are of some importance to you then using a OS with closed source essentials due to ease of use or development environment only increases the number of years until a strong privacy easy to use OSS system gets rolled out more widely. Your actions have broader impact than just your priorities.

Finally, there is more than just the software. Getting closer to the metal you have to contemplate bootloaders trust and verifiability.

Personnally, I would not be speaking about Apple hardware, I don't know it well enough. But in general, hardware is relevant to security, simply because most of them nowadays contain firmwares. In some cases, that firmware can even be a small embedded OS. If that particular piece of software happens to deal with inbound data (think WiFi controller), then you have a potential security hole _which you have no control on_.

Love the comment by "z". :)

The people working on this are sharp, for sure.

But I will never think of VM's as a path to "security".

Xen is useful for a variety of purposes (including resiliency, which can help if you are hacked), but I'll never rely on it for "security".

Curious what bootloader they are using for the Xen kernels.

GRUB2, and optionally tboot for "anti evil-maid" (http://theinvisiblethings.blogspot.com/2011/09/anti-evil-mai...).

Can the user use their own choice of bootloader (besides those two)?

The bootloader I use can boot Xen kernels; no need for GRUB2. Is the Qube boot process described somewhere?

I don't see why not in theory, but in practice GRUB2 is the only available option out-of-the-box. I'm curious why you're so interested in this, though. Care to explain your ostensible desire for an alternative bootloader?

I just like the one I have been using.

I understand it reasonably well and am hesitant to switch.

I have tried others and have not been impressed.

I am a connoiseur of bootloaders I guess.

It's an important program, maybe the most important one.

Based on my limited knowledge of other computer users, I believe we all have what we consider a "trusted" program that does some task for us over and over again. We come to rely on it and appreciate it (for our own idiosyncratic reasons). We are hesitant to switch to something else.

For me, that program is my bootloader.

Could you share the name of your trusted, Xen-aware bootloader? Is it something other than syslinux or uboot (ARM)?

For x86, it is something other than those two.

If this was to catch on, would the NSA (assuming they don't already) throw more resources at building viruses that attack the CPU directly - intercepting any of the instructions sent by the VMs?

Those that gave this negative points, care to share why?

Isn't Bromium also doing this with vSentry?


I'm really hoping they do a server-oriented flavor of Qubes -- would be tremendously useful.

Wouldn't that just be regular Xen?

No, Qubes is a lot more than just that.

i'm not sure i'd feel comfortable with the webcam streaming as people visit :P

It's just a very boring video, I watched it to make sure.

Applications are open for YC Winter 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact