On Mon, Aug 24, 2009 at 6:18 AM, 7v5w7go9ub0o
<7v5w7go9ub0o@xxxxxxxxx> wrote:
But ISTM that small, optimized, hardened little VMs would be ideal -
additionally protecting anonymity; perhaps reasonably allowing the use
of JS on your browser within your browser VM.
Agreed.
Your post begs the questions:
1. Which VM software are the most breakout proof, should an attacker
gain access with a root shell?
This is a tricky question which depends on your requirements. Before I get into which is better than which VM engine, I first must understand what it is I want to do with my browser.
Do I want to be able to download data and save it, or just be able to observe it?
If you want to save data, where/how do I store it in such a way that I can securely access it from other mini VMs without compromising that VMs integrity?
Older vulnerabilities exist for both VMware and Qemu that allowed access to the host OS through the guest OS because the VM engine itself was "folder sharing" from the host to the guest OS.
These have been patched for quite some time, but such a feature that allows "guest to host" sharing makes me nervous, and I think should be avoided *at the VM engine level* at all cost.
The downside is, I'm not sure how to save my downloads from the VM to another VM or the host OS itself without opening up a whole for an attacker to get through assuming a root compromise inside the VM.
2. Which VMs' guest software are the most opaque - i.e. have NO
information available to a roving root?
I'm a fan of having a base ISO and storing any changes made in memory. If I do get infected by some 0day, the only information they could pull would be any existing cookies, cache, or history I may have from my browser (depending on my browser's settings). Not to mention, since it's a read only ISO, no permanent changes can be made.
3. Which VMs require the least overhead?
VMware fails right there. The installer is 175+ MB compressed, and the software is not portable (literally or legally).
I've been a fan of Qemu the last few years. It's open, portable, small foot print and low on memory usage.
With Qemu, I was able to create a Linux OS in ISO format that contained a Win32 version of Qemu , Autorun.ini, and a win32 batch script that would launch Qemu (in Windows) using the CD-ROM drive as the Boot device, and it worked great. This enabled both a both bootable CD and a Windows supported VM all from the CD-ROM. You wouldn't be able to do that with VMware based on the size of the engine and it's dependencies, it would take up almost the whole CD.
4. IIUC, one can attach a VM to his existing OS, or one can first
install some sort of hypervisor followed by a primary OS, and a series
of secondary OS's? If this is true, what are the pros and cons of either
approach. (I presume that you want a number of VMs - each containing
sensitive or vulnerable applications)
Take a look at Moka5(.com). This is pretty much what we were aiming to do at one point.
Moka5 is however based on (funded by) VMware , and vmware totally jacked this idea from two guys after sending them a siest and desist letter first....errr.
Back to the hypervisor; this would be really nice. I have see some problems though.
If I have a browser VM (B-VM), and a email VM (E-VM), how does the B-VM communicate with E-VM through things like the "e-mail:" URI type?
Should B-VM and E-VM even be able to know about each other?
Perhaps having a virtual "clipboard" that supports copy and paste functions between VM's, or does that open another security hole?
To bring up another point, do all them VMs you want to be anonymous use the same instance of Tor, perhaps running in it's own VM, or do they use their own instances of Tor?
Lets say my E-VM is set to check my e-mail every X minutes. Does my E-VM use the same circuit as my B-VM is current using?
So what happens if an attacker puts the client into a .exit loop, keeping them stuck on their exit node (is this still a problem..?)?
I think this gets deeper in the sense of how much an application that uses Tor can control Tor *without access to the control port*. In this case, having the .exit notation enabled would probably be bad if two or more applications / VM's are sharing the same instance of Tor, as one infected VM could affect the traffic on the other VMs. There are lots of tricky security issues that need to be taken into account when working on multiple VM systems, or worse, VM to host OS solutions.
Well, that's pretty much what I've been thinking about for quite some time now. I've spent a ton of time looking into this and discussing it with coderman.
It takes soooo much time to do all this, and it can become a bit mind numbing if you do it for too long.
In my opinion, good security for your anonymity and privacy is a bitch in a Web 2.0 world. It seems like all of our browsers, media players, IM clients, and games are now being integrated to communicate with each other. While this seems great to the user's experience, it can be very destructive to one's privacy and anonymity.
- Kyle