Easier and Safer Drupal Development with Virtualbox / Virtualization

As a developer there is often a point in your career where you take a look at the number of client databases installed on your hard drive and start thinking "boy, I hope that data never falls into the wrong hands." And, if you're like most web developers and use a laptop, the chances of having a laptop lost or stolen are surprisingly high. It happens to the best of us.

Further, chances are quite good that you are using Windows or Mac for your working environment but want to run your sites in a Linux environment just like you have on your servers.

How about this: create a Linux server that runs inside of a virtual environment and then put the disk image for that virtual server into an encrypted drive image. Perfect! This tutorial assumes you use Mac OSX - but the same principles could be applied to any operating system. This setup is meant to be reasonably safe against typical thieves, but doesn't protect the data completely.

Virtualbox Virtualization to the Rescue

Of course I'm mostly an open source fan so I'll try the Open Source virtualization option first. And...Virtualbox works quite well.

First create some space for your disk image. I fired up the Mac Disk Utility, selected compressed and 128 bit encryption like so:

Give yourself enough disk space - at least 5-10GB depending on what you'll do with the server. Creating a "sparse" image just means that it will create the image at a relatively small size and then increase the size as necessary. It's a performance trade-off to save disk space which is worth it for development.

The decision to use 128 or 256bit encryption is up to you and how sensitive your data really is. I'd rather get slightly better performance than have super-duper encryption.

Next, install Virtual box and follow their documentation to setup a Linux environment, like Ubuntu. I chose the 9.04 Desktop version of Ubuntu so that I can use some of the Linux GUI tools directly (that's especially handy to show how Ubuntu works to someone who is interested in it). Virtualbox 3.0 just came out with lots of improvements like faster Disk I/O. In my testing so far, it's good enough.

Once you've got Virtualbox open, click the "New" button where you'll get a wizard. Answer the questions depending on your preferences, the only important step is the "Virtual Disk Location and Size" where you should be sure to put your disk image inside the encrypted disk (which you may have to mount by double clicking on it).

I chose to use a "Bridged" adapter for the network where the guest operating system (Linux in my case) latches onto whatever network device my host is using and grabs an extra IP address from the DHCP server. This has the benefit of allowing other people in the office to quickly and easily connect to your Linux Virtualbox server directly using an IP address.

I spent a bunch of time messing with shared folders and couldn't get it to work. My solution now is simple: sshfs via macfuse.
1. Install macfuse.
2. Create a directory to use as the mount point like mkdir ~/shared_directory
3. Find the IP of your virtualbox and run the command sshfs [email protected]:/ ~/shared_directory

That's it - you've now got the entire root filesystem of your Linux virtualbox mounted at /Users/greg/shared_directory. From the Host maching you can now navigate this directory using Finder, use shell commands from the Mac terminal or edit files using Mac based editing software (in my case the big one is Eclipse). If you change networks and get a new IP address your mount will stop working and you'll need to create it again. I've gotten pretty quick at re-establishing the mount point.

If you have extra RAM and want to run the Linux system with a GUI, go for it. I did this at first but found I was running out of RAM. So, I used a command to remove the destkop manager from my startup scripts and now the box hums along nicely at 256MB of RAM.

sudo update-rc.d -f gdm remove

If I ever want to add Gnome's desktop manager back, it's a simple command:

sudo update-rc.d -f gdm defaults

Virtualbox and Ubuntu Resources

Data Privacy Considerations with Drupal in Encrypted Virtualbox

So, is this really safer? Consider a typical Drupal development environment: someone who gets physical control of your machine and can login as you will be able to read your settings.php files which contain credentials to get all the information out of the database. So, the first steps are:
1. Use a username/password to login to your operating system rather than having it automatically log in.
2. Set your system to "lock" itself and require the credentials if it is unattended for more than a few minutes or is hibernated.
3. Use a firmware level password
4. Use decent passwords ;)

Someone might be able to override this information using the password reset "feature" of the operating system. Ok.

That's where the virtual disk image and encrypting the disk image comes in. If someone reboots the machine to reset the password then the drive will no longer be mounted. Mounting it requires the drive's password which only you know. Yay.

There are probably some areas where this system is vulnerable to an attack. My goal is not to completely prevent a talented attacker from getting my data (it's unlikely that a talented attacker would happen to steal specifically my machine...). My goal is to protect the data if a casual thief steals it. A casual thief presented with this scenario is likely to replace the hard drive and toss out the old one, in which case the data would be lost but not exposed.

Update: Automatically Mount the SSHFS Drives

I've attached a little script that automatically mounts the external drives.

mounter.txt684 bytes


Clever, but I'm thinking it

Clever, but I'm thinking it may be possible to skip the virtualization step by simply configuring the web and database servers on the primary operating system to use data files on an encrypted disk image. Have you tried something along those lines?

Also, I know Mac OS X (and presumably other operating systems) can do full-disk encryption, but the performance hit might not be worth it and, in the case of OS X, I've heard there's some reliability problems, though they may have been sussed out with later versions.

the purpose is two fold

Sure, the purpose here is twofold:

  1. Provide extra security
  2. Provide a development environment that is more like the production server environment.

The additional effort to install, configure, and upgrade the AMP stack in OSX is something that I'm quite pleased to get to completely avoid by using this setup.

Check out TrueCrypt

It's worth it to check out TrueCrypt as well, since it's cross platform. That way you can access your VM on any platform you need to access it on.

Or, better yet, encrypt the disk from within the virtualized OS itself using LVM + LUKS.

Browser testing too

Great write up Greg,

I was also interested in this from a themer's perspective [rather that a security angle].
While I haven't quite got there yet, the plan is to have multiple VMs available running Windows & IE, plus a Ubuntu VM, which will allow me to test from both a broswer and server perspective.

The little note about using a bridged connector, as opposed to NAT, solved the problem of routing the traffic to the VM. Port forwarding had been working but it took a bit of wrangling to get it right.


Hi Greg Spotted a little

Hi Greg
Spotted a little problem wtih bridged networking - it won't work when you are off-line!
Wrote a little bit about how I got around the issue.


wonderful, thanks for the followup

Whenever I don't have internet I just work strictly in the guest OS alone, but that's a great point.

Also, I updated the article with a little script I use to make the mounting easier. Put that script somewhere in your $PATH and run "mounter" at the command line - all set!

os x default volume access

By default OS X mounts disk images at /Volumes with "ignore permissions for this volume" set.

Doesn't that mean anyone on a network could copy and or delete the entire machine image once it's mounted?

file sharing?

I disable file sharing from my laptop immediately.

My impression from reading around is that if you have file sharing enabled AND someone has an account on the local machine they could access the drive. So, the question is why they have an account on the machine. This is written from the perspective of a single user in a single user environment - not a directory controlled environment. But even then, folks in that environment should hopefully trust the people that are part of their directory.

Shared folders

I got shared folders going following these instructions: http://www.valibuk.net/2009/03/accessing-mac-os-x-harddrive-from-ubuntu-...