Of course it improves security. On Qubes, someone who can exploit your browser (pdf reader, word processor) doesn't automatically get free rein on your machine. They still need to escape Xen.

Not just apps, it even routes physical USB devices to specific VMs, which potentially mitigates BadUSB type attacks against the dom0.

And I really appreciate that they've tried to solve XDMCP weaknesses.

This would be sound logic if existing desktop operating systems had actual good security models.

In the real world, if someone exploits your PDF reader, they don't have to circumvent your OS: your OS hands over everything you can access, by design. One could argue that a better security model baked into the OS would make more sense than a virtualization hack, but the latter has the advantage of actually existing.

What would be the better security model?

Somebody exploiting your PDF reader can't upload all your email.

That's not a model. What's the model that prevents this? User performs a 2-step auth every time code executes?

I know of no such models. Perhaps someone smarter than me has thought of them, that's why I asked the question initially.

Sandboxing, where each process is only allowed to use a precise set of system resources.

Any attempt to use anything else leads to termination.

Which resources are they allowed to use? What defines which resources they are given?

> Which resources are they allowed to use?

The system administrator at installation time.

> What defines which resources they are given?

Applications just have a request list of what they require.

If the administrator doesn't allow them for the given application modules (executable, dynamic library, function call,...), bad luck.

Sandboxing. It's present on OS X.

I'm confused. The original person I responded to said that no desktop OSes had good security models. On OSX I can write a script that, when run as a user, has access to everything the user has access to. So what exactly are you talking about?

I'm talking about OS X sandboxing. The hypothetical PDF reader doesn't have access to the email.

> If somebody exploits your PDF reader, they still have to circumvent the OS.

That is correct. This is probably why privesc exploits are much more expensive than adobe reader exploits.

You are kind of arguing against yourself here.

> Now instead of one layer with hardware contact, you have two (assuming you want performance too).

Could you expand on that statement? By definition, only one layer can own each hardware component.

That's nonsense. It doesn't automatically help security.

But compartmentalization does mean that barring a hypervisor exploit, each exploit can potentially be prevented from affecting more than a small part of the system.

I care a whole lot less if Chrome is exploited if it can't access my ssh keys, for example (not that I wouldn't still care, but the potential damage would be limited).

Why don't you just use different user accounts and permissions? That way you don't have to trust extra code and can achieve the same goal.

Edit: But the way you talk to me, obviously I must be stupid.

I'd say the reasoning is that you then have to trust there are no privesc/bypass opportunities in your environment. Trusting that all your dbus/pulseaudio/network-manager/cups/fuse/display manager & friends aren't going to give your rogue chrome process on one account some kind of access to another (thanks to X11/XDMCP, they'll at least have keylogging) - that's a big surface area, aas in: space is big. Really big. You just won't believe how vastly, hugely, mind-bogglingly big it is.

Compared to the few hundred lines in the hypervisor providing VM-level isolation you'd be a bit mad to say that these are equivalent means of isolation.

This document[1] talks about that risk and what they've done to mitigate it at the bottom of page 10.

[1] http://www.invisiblethingslab.com/resources/2014/Software_co...

I take it you've not heard of the phrase "defensive depth".

Shouldn't that be "defense in depth"?

for those unaware: http://en.wikipedia.org/wiki/Defense_in_depth_%28computing%2...

The idea is that hypervisor is significantly smaller than the OS/kernel, so there will be less bugs. Not that they never happen, Xen had one recently.