[euank]

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

[sept]

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

[euank]

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.

[dobbsbob]

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

[A1kmm]

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).

[kyboren]

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.

[throwaway7767]

> 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.

[kyboren]

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 :).

[euank]

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?

[zurn]

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.

[throwaway7767]

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.

[zurn]

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.

[XorNot]

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?