There is a similar concept coming to Windows: http://www.bromium.com/innovations/micro-virtualization.html

There was a good presentation from the Chief Security Architect at Bromium from DerbyCon last year: http://www.irongeek.com/i.php?page=videos/derbycon3/4303-san...

He absolutely tears apart application sandboxes like "Sandboxie".

From what I've been hearing they seem to already have big customers using it. I wonder if it'll ever be available to individuals and small businesses.

It's pretty cool in that it appears to have some tripwire-esque stuff so that you get useful logs when malware does try to do dodgy things in their sandbox. It sounds like it can alert the user with something like, "your browser might be compromised, start a new session" and everything is captured/saved so that admins can come back later to do forensics with the session that went bad.

Technical info: http://www.slideshare.net/xen_com_mgr/xen-14203926

Microsoft App-V has been around for 5+ years though it sounds like it would be a Docker to Bromium's Xen.

Sandboxie was one of the original Windows application virtualization options 10 years ago.

I was hoping something would become the 'Docker for Windows' but these programs are being snapped up by software security companies.

Might want to check out spoon.net - they are working on containers for Windows. Been doing app virt for a long time. I use them for side by side browser testing : )

Sandboxie is still available, and free for home use (with a small 5 second nag screen to pay).

Take a look at cameyo.com

I think I've seen this before, in a post somewhere by one of their developers. I think it was about how insecure X11 is, because any X11 app can listen for all keystrokes made by the user. AFAIK people jumped on that post as "it's a known property of X11, stop making drama about it."

This article [1] is a good overview.

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

> The Qubes Windows Tools are proprietary but we distribute the binaries for free with current Qubes OS releases.

Out of curiosity: What's the reason for them being proprietary while the rest of the system seems to be free software?

Step 3: profit!

So... my question is: How does this work with things like games or other hardware-acceleration-intensive programs?

If there's no performance loss, great.

3D graphics are not supported. It is listed in the FAQ, found at https://wiki.qubes-os.org/wiki/UserFaq

It doesn't: https://qubes-os.org/wiki/UserFaq

This would perhaps be doable with something like VMGL[0].

[0] http://sysweb.cs.toronto.edu/vmgl

Isn't it the same as Sandboxie? http://www.sandboxie.com/

Qubes is an Xen-based Operating System while Sandboxie is an application for Windows.

But both provide secure application isolation, don't they?

Linux and Windows both allow you to run Firefox so they must be the same thing right?

They are not at all similar.

:) btw if you're looking for virtualization of apps (not security), Cameyo is great.

While I am all for virtualizing, it doesn't help security. It just moves the exploit from your OS into your hypervisor. Even worse, you add a whole new level of exploitable code.

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.

Nope. If somebody exploits your PDF reader, they still have to circumvent the OS. Sound familiar?

Now instead of one layer with hardware contact, you have two (assuming you want performance too). Twice the attack surface.

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?

Just pick one that gives the feature I described without being a pain to the user.

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 difference here is, you might feel safer but you are still in the exact same position as before, a bug in your hypervisor/Meta-OS screws you. I'd argue that is a harmful comfort.

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.