The idea: - Run Windows in Virtualbox - For the host, use a very minimal Linux/X11 system - Allocate most RAM for the VM, leave a bit for the host - Use Virtualbox snapshots for instant rollback This way the snapshot/rollback mechanism runs mostly outside of Windows. The problems: - Performance. Driver support on a Linux virtualbox host will not be as good as native. - Security. I frankly do not trust the Virtualbox guest extensions. - More security. Virtualbox is hard to confine effectively via access control. - Even more security. Virtualbox does not run at all under GrSec kernels. - Memory management. With Xen you can allocate a small contiguous chunk for the host, and leave the rest for guests. AFAIK this cannot be done with Virtualbox, which might be an issue when allocating over half the RAM for the guest. Any thoughts on this? I actually tried to set something like this up last weekend (using Debian 8 as the base), which is how I discovered that GrSec and VBox don't get along. Needless to say I did not get very far.
I've done this with VMware Workstation, on a windows host. Moreover I've got all the VMware processes guarded by Appguard to help memory isolation. Does it work, sure. But unless you are testing malware, the over head isn't worth it. Rollback techniques on the host work just as well, aka Shadowdefender, AX64 TM, etc.
A question regarding VirtualBox guest extensions. I don't know how they compare to VPC additions. Do these extensions install to individual guest operating systems? If you were to set up a dual boot guest system, can the extensions be installed to just one of the two guest systems?
In that respect, they are similar to those used by VPC. A dual boot guest system could mitigate much of the risk. What if you add a 2nd OS? Give it no internet access. Install the extensions to the 2nd guest. The operating systems would use 2 different file systems. The internet-able guest (Windows) wouldn't be able to read the file system of the 2nd guest (possibly a compact linux) but the 2nd guest could read and write to the Windows guest. It wouldn't give you clipboard integration but it would provide an easier way to transfer files to and from the guest systems without creating a potential escape from the virtual system.
I don't think it will work that way. A second VM isn't going to read and write to the file system of another VM, especially if you only install the extensions to one and don't allow clipboard access. You best bet here would be a network shared location that could be accessed by both, or a flash drive or external drive that could be mounted in each, one at a time of course.
This idea never panned out FWIW, mostly because of performance problems. Without hardware virtualization extensions, Windows 7 performance on a VM is not good enough. Which makes sense; it's Windows on top of Virtualbox on top of Xorg on top of Linux. Too many layers of indirection maybe, too many function calls. ... Though there might be something else to it. Memory management maybe? Might be worth looking into again.
Whoops, didn't realize this was from January... anyway... You might do some testing with VMWare to see if you get the same results. I have had situations where something was really slow with VirtualBox that ran at an acceptable speed in VMWare. I believe they have trial versions if you have not already previously burnt up the trial period.
Whether or not it would work will depend on how VirtualBox stores virtual machines and images of the individual virtual hard drives. The version of VPC I'm using doesn't store complete virtual machines as files. It creates images of the individual virtual hard drives they use. The machine settings and the names of the virtual hard drives each VM uses are stored separately in the registry. The virtual dual boot systems I've set up are one virtual machine that uses 2 separate hard drive images. The images can be shared between virtual systems. Changes made on a virtual drive on one VM carry over to other VMs that use the same image. With this arrangement, one can install the additions to just one OS in a dual boot virtual machine, leaving the other image free of the additions. I don't know if VirtualBox will allow you to do something similar.
You can mount the virtual hard drive of any VM elsewhere, I guess I am missing the point. It sounds like the long way around to accomplish something you could get done with a shared folder.
Gullible Jones mentioned that he didn't trust the guest extensions from a security perspective. One of their functions was creating the ability to share files between the host and guest systems. I suggested a dual boot guest system with 2 different operating systems, the Windows install and a lightweight linux. The linux system could read and write to Windows but not vice versa. This way, the linux system with the extensions installed to it could be used to transfer files in either direction, but when Windows is running, it's effectively isolated as it can't read or write to the linux file system and the extensions are not installed to it. The user can choose to save changes to Windows when they import files from the host or treat it as a reboot to restore whenever they choose.
This whole thing is kind of like scratching your left ear with your right hand. If you want the extra security just run windows, and a virtual machine in it. That will probably achieve 98% of the objective with 10% of the hassle
Yup, I also won't install guest extension to keep full isolation. I even say I don't much trust VBox as they don't follow security standard in development process like VMWare, and wonder they finally adopted ASLR support but maybe not yet. (FWIW, VBox kernel driver was abused by x64 rootkit to gain system priv.) But I'm going to install VBox on Windows host as I can't afford VMWare workstation which have snapshot function. I don't know what Linux host GJ assume regarding OP, but as he says minimal system Arch or its sisters would be good candidate.
I've been working on a similar idea with a virtual XP. This version of VPC allows me to use drive images on more than one virtual system. If I want to add or remove files or data from the virtual XP, I attach the disk as a 2nd drive to another virtual system that has the extensions installed and extract the files. If all I need to do is transfer files to it, I can use the CD burner to create an ISO, which the virtual system treats like a CD. The more that I use this pre-MS version of VPC, the more I appreciate its simplicity and straight-forward design, its lack of privacy compromising "features", and the total lack of logs. The drive images work just like physical hard drives. The "bios" and virtual system settings are stored separately. I can add, remove, and swap hard drives in any fashion I choose. It doesn't have USB capability and all of the bells and whistles of virtualbox and the newer versions of VPC. It just creates basic virtual PCs, which is all that I need. Since the core hardware of the virtual systems are all basically the same, there's no piracy complaints from XP. IMO, the lack of features just means that there's fewer potential escape routes out of the virtual system.
There is another possibility for this thread, which is to run Qubes R2 with the W7 HVM (hardware virtual machine). Being (currently) Xen based, and with VT-x VT-d, that allows good hardware based performance, as well as revert-only VMs. Effectively, the Xen is taking the place of the minimal OS, and Qubes does a bunch of stuff to isolate the networking/firewall/usb.
