Security question for guest VMs

[kitt001]

Hi All,
I have a scenario where several users are asking to install VirtualBox on their windows laptops, however, a straight installation will breach our network security policies. As I'm not super familiar with VirtualBox, I apologize if this question is answered elsewhere, and I just can't find it.

As far as I can tell, VB does not support any type of user rights to limit configuration options (this would help a lot, so please correct me if I'm wrong) ... but I am wondering if there is any way to remove certain capabilities or create firewall-ish rules that would just block things from working.

One example, I wouldn't want the VMs to be able to NAT behind the machines IP, so could certain features (like that) just be disabled/blocked at installation?

A second example, is there any way to block VMs from being able to access certain address space? Initially I thought that perhaps this could be done with the Windows firewall, but since the machines would be connected via bridged interfaces, it would be outside the scope of that solution ... but maybe VB has some routing or access rules that could be imposed by the system in security context outside of the user?

I realize there may be no way to provide this within our security guidelines, but its worth asking. Perhaps someone else has already been down this road and can offer up another approach.

Thanks

[scottgus1]

Virtualbox does not have any ways to lock down the interface to prevent certain VM setups or network types. There are settings to hide certain GUI features, but the configurations are kept as text files that the standard non-admin user has write permissions to access. So any such "locking down" could easily be undone by the standard user.

Filtering done within the network can limit what the VM can access on Bridged, but NAT will ride on top of the host's traffic, so NAT may not be fiterable.

[kitt001]

If the settings in this file are changed manually, how are they applied? A VM reboot, a service restart? I’m wondering if I could monitor the files and police them back to permit-able settings via script.

The problem I have is that our environment is software controlled and no one has admin rights, however, a few people want the ability to have portable test/demo environments and they have an ok justification for the requests. The issue then becomes the fact that in these VMs that they can now create outside of our data centers, they can install and run unapproved software in open space on our network … this is the root of the problem. The intent is to let them create the machines/environments as they need them … there just needs to be a few guide rails to keep everything in its proper lanes so that this doesn’t become a security bypass tool.

[scottgus1]

If the settings in this file are changed manually, how are they applied? A VM reboot, a service restart?

Virtualbox reads the configuration files into its memory when the background VboxSVC service is started. Opening the main Virtualbox window, running a vboxmanage command, or starting a VM will start the VboxSVC service. This service remains running until about 10 seconds after every Virtualbox window, VM, and command have finished and quit. Before the service quits, it will write the contents of its config settings in memory back to the configuration files. Changes to Virtualbox or VM settings may also result in a write-out of the config files at any time.

So, theoretically, one may edit the main configuration file before any Virtualbox process starts, then get the main Virtualbox window open right away, and get full access to Virtualbox while the VboxSVC service is running off that edited configuration file. Whether your police script can check and block saving of the manual edits fast enough is going to be an interesting challenge, and may result in race conditions and failed security.

One possibility is to set up a set of physical servers in the data center that your users can check out and remotely test on, with appropriate firewalling on the servers, no Virtualbox involved. Another idea is to use a more corporate-security-oriented hypervisor, if such exists.

[kitt001]

The datacenter hosted test/demo resources are the preferred approach, and are already available to to the users (many racks worth of said resources). Unfortunately, the use case here involves scenarios where the end user may not be attached to the corporate environment, so the argument is being made that a local solution is the only workable option. The problem is when they re-attach and bring all the security issues with them, or get creative with their new found power and start using it to circumvent the security enforced on the host machine.

My thinking around the police script is that it would be subscribed to filesystem events .. specifically, any change operation committed to the files of interest. That way, the instant the file is created or updated , it's settings are inspected and triaged as required ... not a "check it every 5 minutes" approach. I'd need to play with this, but I guess it sounds like it could be possible.

I'm certainly open to using a hypervisor better suited to the task if you (or anyone) can suggest one that's worth looking at - I know I'm not the only person to have this kind of problem; someone has already solved it somewhere. My quick searches didn't get me anything useful ... I'm more of a datacenter guy, so outside of google, I don't have a lot of knowledge around to the desktop hypervisor options.