3 Answers
3

Depending on the host and guest operating systems, you may need additional security here. For example, I have a couple of Windows VMs from which I can remove any dodgy programs onto the samba share without too much fear that the linux host will be infected by the presence of these files. However, there is the possibility that a virus exploiting a vulnerability in the linux samba daemon could well exploit my host (I just accept that risk).

One solution to this is rather than using disk images, write the virtual machine disks directly to disk, i.e. to a partition. This means IO isn't virtualised, which is faster, and it means you can literally modify the filesystem direct from the host. Of course, your VM software must support this.

A third alternative is to mount the filesystem. qemu, for example, is capable of mounting qcow images and retrieve content that way.

Yes, absolutely. Very necessary. Must happen. You should do all you can to defend the guest from attack because it may well become compromised.

Another point to make here is that you have one additional defence - every so often, take a known clean snapshot of the system. Then, if you get an infection, roll the system back. Of course, you must know you've been infected and not back up an infected system.

If you really want to revert the system after each browsing session, you will have a lot of extra work to do. You'll need to have sessions where you patch the baseline and do not browse, and browsing sessions which you roll back after to that baseline.

You're certainly not the first to practise this kind of setup. The security researcher Joanna Rutkowska did an interview with Tom's Hardware detailing her virtual machine setup and the concept of having different levels of virtual machines she cared about, with increasing security setups, and doing different browsing on different machines. It's a very interesting read; for me, it's a little on the paranoid side.

Now, to virtual machine security:

A compromised virtual machine has whatever access you give it to the local network. This could be nothing (safer) or it could be limited access to services on the host (SMB, SSH) or it could be all access. The point is, you are increasing the attack surface potentially, especially if you ignore point 2 in your question. If you're using NAT, be aware both your virtual machines share the same IP to the outside world, so it might appear like your host is doing things it shouldn't.

There is active research in red pill techniques, i.e. escaping the hypervisor. I am not qualified to say exactly how likely these are to be in the wild now, but I can tell you detecting being in a virtual machine is not that difficult and like anything else, the more prevalent the virtual machine becomes, the more appealing red pill code will be.

Some attacks are not prevented by virtual machines. Session hijacking, cross site scripting attacks. Anything that attacks the application layer of the web site or application you're using rather than trying to attack your host may be something you overlook.

The host can still be attacked through alternative mechanisms (flaws in any network related services or indeed the content you pull onto it "securely").

Is it secure? That question can only ever be answered in the context of what you want to protect. Personally, for me, I weighed up the value of the information I have to protect versus the effort of maintaining several or one virtual machine(s) and decided the maintenance burden was probably not worth it. My host is reasonably well protected as is and I think it adds additional complexity to my setup. I prefer to defend one point of entry, not two or three. However, assuming you are skilled at maintaining all your virtual machines and have a need for this level of security, I would say the separation from the host and the ease with which you can roll back machines make it an addition to your defences.

Btw, Joanna Rutkowska doesnt just have a bunch of VMs set up, anymore - she's actually gone and written a whole new OS, Qubes, that is based on using different VMs for everything.
–
AviD♦Jun 29 '11 at 21:11

Nice response. I liked how you went through the OP points.
–
this.joshJun 29 '11 at 22:05

@AviD: Qubes is more like a security concept for using virtualization as a better isolation mechanism, not a 'whole new OS'. In the post before the first announcement she made a big fuss about the problem she's trying to solve and what great solution they will present. When I pointed out back then that this was done in larger industry research projects and several research papers with little outcome, she simply deleted the comment. Like she did with several others.
–
pepeJun 29 '11 at 22:33

@pepe heh, seems you have longstanding issues with her :). But yes, while Qubes was not written completely from scratch, it is a whole new OS.
–
AviD♦Jun 29 '11 at 22:36

2

@Ninefingers: InvisibleThingsLabs themselves repeatedly discover substantial security flaws in virtalization and trusted execution technologies, the last one in April showing that isolated driver domains in Xen are still exploitable. Side-channel attacks on other VM's SSL, PGP or AES software are almost trivial. And as you point out, the highest risk in any case remains in the application layer, esp. the browser.
–
pepeJun 29 '11 at 23:15

Depending on what assets you're expecting the virtualzation to defend, this could easily result in a false sense of security.

Simply separating your "online habits" from your "offline habits" via virtualization will only go so far as to help protect one from the other. To better clarify, here's an example of a scenario in which the virtualization you've described could be a generally effective defense, and one in which it would not.

Effective: You have some personal financial records on your "offline" machine which you would like to keep confidential. Your "online" machine is infected with a Trojan via browser exploit. Presuming there's no data connection (file shares, network, etc) between the two, the data on the "offline" machine is probably safe.

Ineffective: You do your banking, e-mail, and shopping all on the "online" machine. Someone sends you a phishing message to which you become an unwitting victim, and the system is infected with a Trojan. All of your online account credentials can now be considered compromised.

Perhaps a better approach would be, instead of isolating "online" activities from "offline" activities, separate "high risk" activities from "sensitive" activities. Use one system for your day to day browsing and overall leisure activities, and use another for things like banking, shopping, and other sensitive things. Fully secure both systems as usual, and isolate them from one another as much as possible. Make sure that all activities on the "sensitive" system only involve connections to known-good and trusted networks.

Simple answer: Essentially, virtualization will create a layer of obfuscation for you that will successfully keep standard malware contained to guest VMs. This is what you care about as home user. Install anti-virus and always apply patches and you're good. If something goes wrong, reset the VM to a known-good state.

For more involved attack scenarios, you can make a lot of fuss about isolating drivers and reducing your TCB. Look at the Qubes documentation or better the various documents from the OpenTC or EMSCB projects and previous publications on OS security and information flow control for the details on this. In the end, you will still not be able to prevent targeted attacks due to (1) convenient data transfer between VMs and (2) remaining bugs in hypervisors and hardware. Neither problem is trivial at its core. Here is a rather accessible, non-academic source that can get you an insight to the rather complex problems: http://invisiblethingslab.com/itl/Resources.html

Would you explain the issues related to data transfer? Do you believe that data transfer between application VM and host file system is less secure than between a application on the host and the host file system?
–
this.joshJun 29 '11 at 22:14

What I called data transfer is a basic question of interfaces and possible information flow restrictions. Leaving all the side-channel and covert-channel attacks and interface bugs aside, a "securely isolated" guest VM means that it should not be able to read data from other VMs and any write access should be "blind" and non-overwriting. People gave up on this kind of isolation 20 years ago. Specifically to your question: No, data transfer between VMs is not less secure, but more importantly, it is also not any more secure.
–
pepeJun 29 '11 at 22:27

1

To elaborate: It all comes down to the interface design and if it allows good info flow control and fault isolation. But for this you don't need virtualization, there is no reason why you cannot implement such improvements in a regular OS kernel. However, when you want to do this and you're serious about it (like in Qubes) you will quickly notice that you need fast IPC, or otherwise the "disk encryption VM" or "network card VM" will be extremely slow due to massive context swichting overhead. You get back to uKernels: ok-labs.com/blog/entry/microkernels-vs-hypervisors
–
pepeJun 29 '11 at 22:37