well gentlemen, that was one hell of a conversation.
thank you all kindly. as a lowly network designer, i learned a lot. didn't cost anything, either.
whattaya youse guys think of Qubes, and their 'security by isolation' approach?
i've got no dog in the fight - but i'd really like to know what your opinions are.
I only just read over this and someone correct me if I'm wrong but this appears to be using Xen to isolate (groups of) applications in their own VM on a single host.
My short answer:
This is at best a one trick pony and it's possibly the wrong approach.Why (or my long answer):
I'm going to talk about some "classes" of defense here (and these are terms I just made up so feel free to take some shots at them):
i) A defense which foils an attack (or some significant percentage of attacks) forcing attackers to use a completely different approach (ALSR - I'm sure everyones sick of me mentioning this)
ii) A defense which introduces a measurable and significant increase in difficulty to exploiting an existing flaw. (Password complexity rules, firewalls)
iii) A defense that removes one attack vector with known problems and replaces it with another which is less known. (Switching from IIS to Apache in an IIS shop)
I submit that i) is intrinsically superior to ii) and both are superior to iii)
VM isolation is at best
a "Type II" defense, as it introduces the problem of detecting and compromising the hypervisor before compromising the machine and at worst it could be considered a Type III defense. My assumption here is that a successful attack on the hypervisor means complete ownership of the machine. Ergo, we have reduced the problem for attackers from attacking application X from a very large selection of applications. To attacking Hypervisor X for which the list is much smaller. The upside is that - hopefully this also reduces the attack surface for the defenders. This would normally be a good thing but it's only true if you assume the hypervisior is more secure than your other applications.
e.g. If I had a machine that had to run a webserver and Tomcat to provide a very simple web service to a very targeted application. Removing that and replacing it with a few lines of well audited code could be considered reducing the attack surface of that machine. However the hypervisor isn't a small piece of software and it's attack surface isn't well known.
It might be safer if I couldn't already do half the job: Detect running in a VM. For lots of people who haven't installed the vmware tools on their host a simple check of the time with an external source will tell you that you're running on a VM. Depending on the guest OS I've read about at least fifty different markers for VM detection.
Also it's worth noting that the point of Qubes seems to be the antithesis of what I understand to be best practice with regard to VM's these days. Some of us think that depending on VM isolation is a bad idea. It violates the principle of DiD. So, like in my shop we consider it a bad idea to mix VMs with differing security privileges on the same host. In other words we don't run the payment gateway software on a VM on the same machine we are running the Drupal VM. Yet this seems to be the whole point of Qubes.
This is a good presentation. http://handlers.sans.org/tliston/ThwartingVMDetection_Liston_Skoudis.pdf
More info on the VMChat teaser at the end: http://www.foolmoon.net/cgi-bin/blog/index.cgi?category=Security%20News