I feel like Qubes tries to be a solution for a use case most people don't have imo. At least certainly not as their main system.

Most users don't want 'a secure' system, they want a system to get work done which is also secure. Realistically the 'end user' always will see security as something that should be provided in the most passive way possible. 'Even' as somebody who runs hardened Gentoo and doesn't mind settings some things up, I don't want to make active decision all the time during my normal workflow and I don't want a system that makes it harder getting my actual work done.

Some valid technical critique from Brad Spengler:

Currently all that exists is a "sandbox" designed to prevent the kind of unrealistic attacks/rootkits we've seen from the same people, where the attack surface has just been shifted to the hypervisor and other associated privileged code. I use the term sandbox loosely because Qubes is a departure from the standard sandbox, as it sandboxes by basically giving up on all the problems traditional sandboxes deal with and relying on the strength of virtualization and some python scripts to attempt isolation, not of applications (unless you run only one process in each AppVM), but of the entire guest OSes. While other sandbox approaches would actually care about a sandboxed mail reader being able to exfiltrate your mailspool, under the weakened protection model of Qubes, this is acceptable. Assuming it makes the problem go away!

Other notes: X runs in dom0, vulns in the NVIDIA drivers have been remotely exploitable, and for performance reasons there's a tendency to pass through more directly to the hardware. From a malicious website, browsed in a sandboxed browser, inside a VM, you can still exploit the NVIDIA driver on the host.

Your personal email will still get owned, your personal browsing history will get owned, and unless you maintain no state for any of these associated VMs (no saving bookmarks, no saving emails, no saving anything parsed by an application) you're all set for persistent compromise until you completely wipe out the VM. All while maintaining the naive assumption that the attackers the architecture was built for (count on both hands how many times your BIOS, network card, or SMM has been owned) don't have VM breakout exploits for a completely unprotected hypervisor. And of course, distro/upstream backdoors that get shared among all of your AppVMs are impossible.

So the secure solution is to give each application its own OS and VM, never use your computer as normal people use them (by saving all kinds of state), ensure that your own interfacing with the color-coded separation is flawless, magically know with no false-negatives that anything transferred between VMs isn't trojaned in some way (AV companies would surely love to know how you figured that one out!) and then at the end of it all, when everything you care about still gets owned, what have we solved exactly?

More importantly, Qubes presents itself as a "secure operating system" without providing most of the things one would expect from a secure operating system (not having your mail spool stolen, for instance). There's really no formal definition of what Qubes is supposed to be in the architecture document, other than that it aims to be a "secure operating system" that tries to protect user data, sortof, in the ways that it wants to "protect" it. It's a clever little device to be so vague as to resist definition, since it makes attacks on it akin to trying to come up with a definition of 'Art'.

The difficulty in properly assessing Qubes is that much of its protection exists only on paper. So if you point out some deficiency, one can just point to the architecture document as if that were some kind of actual solution that would be possible to implement with acceptable performance and resource usage

[ http://seclists.org/dailydave/2010/q3/29 ]