Sandboxing

Unknown and Untrusted

If you're like me, you love to test new software, and therein lies one of the huge advantages of the open source world. Almost everything is just a short wget, ./configure; make; make install away, and there's no need to pay, register, provide personal information, wait a week for the CD to arrive, and so forth. But how can you be certain that the software won't interfere with your system, overwrite something, or otherwise behave badly?

Or what if you want to run a web service that you know has a history of problems allowing for remote code execution on the web server?

Sandboxing

A common programming and system administration technique is to use sandboxes, which essentially are restricted areas for the software (or in some cases, an entire operating system or group of systems) to run where it can't interfere with production systems. By setting up a walled-off testing area, you know that if anything does go wrong, it is less likely to cause severe problems, such as affecting your real file server or web server. Additionally, it is easier to observe and verify the behavior of the software because there is less going on within the sandbox.

This leads to the two main requirements of a sandbox: You need to be able to isolate the software, and you need to be able to monitor what the software is doing and control it.

Fortunately, over the past few years, a number of advancements in computing have made the first requirement much easier to meet. Faster CPUs, larger hard disks, and cheap memory, combined with widespread virtualization software, now mean that almost anyone with a recent computer – at least 1-2GHz and 512MB of RAM – can easily run at least one entire operating system on top of their existing operating system.

Unfortunately, many of these products do not address the second requirement very well, with many either requiring the virtualized operating system (also known as the guest) to be modified significantly or to use virtual files to hold the hard-drive contents for the guest.

Sandboxing an OS with VMware Server

The good news is that VMware Server is free to download and use. The bad news is that it is a closed source product. Please note that I haven't covered all the possible options, such as Bochs [1], Xen [2], User-Mode Linux [3], VirtualBox [4], KVM [5], OpenVZ [6], QEMU [7], etc.) because there are simply too many to fit within the pages of this article.

Additionally, I like VMware Server [8] because it only requires a few kernel modules (vmnet, vmmon) and can run almost any operating system as a guest without any modifications to the guest operating system.

Installation is relatively straightforward: You simply download and unpack the file and run the vmware-config.pl script. After you answer a few quick questions, you are ready to run. The major downside to VMware Server is that it uses disk-based image files for the guest operating system, so to examine the "hard drive" for the guest operating system, you will either need to stop or suspend it and then mount the disk image (Listing 1).

The advantage is that you can literally stop an operating system in its tracks, examine a frozen snapshot of it at your leisure, then resume it when you're done.

01 # vmware-mount.pl -p Centos.vmdk
02
03 Nr      Start       Size Type Id System
04 -- ---------- ---------- ---- -- ------------------------
05  1         63     208782 BIOS 83 Linux
06  2     208845     530145 BIOS 82 Linux swap
07  3     738990   20225835 BIOS 83 Linux
08
09 # vmware-mount.pl Centos.vmdk 3 /mnt/vmware/
10
11 # df
12 Filesystem           1K-blocks      Used Available Use% Mounted on
13 /dev/nb0               9796164   2548372   6742148  28% /mnt/vmware