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