freeVSD Enables Safe Experimentation

The freeVSD dæmon follows the Sysvinit startup conventions and can be controlled via:

/etc/rc.d/init.d/vsd start
/etc/rc.d/init.d/vsd stop
/etc/rc.d/init.d/vsd restart
/etc/rc.d/init.d/vsd status

(though this may not yield accurate results).

Several options are configurable through the file /etc/vsd.conf. You may also start or restart a given virtual server with the /usr/sbin/vsboot command.

The /usr/sbin/vsdadm command, introduced during the installation process, can be used to create and delete virtual machines and to manage user accounts. It works by issuing commands to the vsd dæmon that runs on port 1725. This approach enables alternative front ends to manage freeVSD. This includes the administration suite, which consist of tools developed by Idaya, Ltd., some of which run in a web browser or under Microsoft Windows.

The program /usr/bin/bevs (become a virtual server) allows a user on the host to quickly assume the role of root on the virtual machine, without Telneting or otherwise connecting to the virtual machine. Most notably useful is the ability to set the Admin password initially or manage files not owned by Admin or a virtual user.

The following scripts, while useful during install, may become liabilities afterward. You may wish to issue the command chmod a-x on them to avoid inadvertently executing them again:

/usr/sbin/vsd-genskel.pl
/usr/sbin/vsd-install.pl

The program /usr/sbin/vsd-refreshskel.pl will update the freeVSD skeleton and then relink files in the root filesystems on each virtual machine. This enables you to add, remove or update applications available to the virtual servers. Be sure to read the documentation or scan the source code before trying this command. Packages you wish to make available to the virtuals, but not to the host, may be installed with the command

rpm -ivh --force --root=/home/vsd/skel/ file.rpm

rpm -ivh --force --root=/home/vsd/vs/some-vs file.rpm

Since /usr/sbin/vsd-refreshskel.pl will refresh the skeleton, it's useful to propagate upgrades to system software on every virtual machine. Please note that this utility seems to be broken for Red Hat 7.x in freeVSD version 1.4.6.

The /usr/share/doc/freevsd-1.4.6/ directory contains documentation and is made available to each virtual machine by default. Finally, /usr/share/freevsd/ contains scripts useful for site customization.

Giving superuser capabilities to regular users is serious business. We frequently see root exploits via shell accounts, so one must wonder if these problems could be compounded in the chroot environment provided by freeVSD.

On the other hand, one operating system patch can instantly improve security for up to 250 web site administrators. Further, having dedicated httpd processes prevents many of the problems usually present in a typical shell environment, where one user's actions could inadvertently disrupt another user's service.

An ordinary user on the host can see the processes of every user on every virtual machine. Further, using the bevs -r command, they can become root on any of the virtual servers by default! The bevs command is suid root, so apparently this is intentional. I recommend changing the permissions in order to disable this (e.g., chmod o-xr /usr/bin/bevs will do the trick), while still enabling members of the root group to run bevs.

The virtual server administrative dæmon /usr/sbin/vsd listens on port 1725. Out of the box, it is a trivial task to query a virtual server for user lists, change user privileges—in effect, fully control the vsd dæmon remotely, with no authentication. As suggested in the file security.txt, it is imperative that you control this with commands on the host, such as these (which should be placed in rc.local):

ipchains -A input -p tcp -s W.X.Y.Z
<@cont_arrow>å<@$P>--dport 1725 -j ACCEPT
ipchains -A input -p tcp -s 0/0 --dport 1725 -j REJECT

Because of the complexity of propagating operating system updates to the virtual machines, it is prudent to run a stable distribution.

Perhaps the simplest way to test out a new application is to keep a spare machine around on which you can safely format the drive and re-install it. While reinstallation can be a good experience builder, continually installing and tweaking becomes a nuisance.

Another option is to create disk images. After you have freshly installed the operating system and have it configured to your satisfaction, a command such as

dd if=/dev/hda1 of=/tmp/image

can create an image file that can be used to restore the operating system at a later date. Beware of the 2GB file size limitation if using this strategy—the split utility will be helpful.

The commercial application, VMware, fully simulates an x86 PC, right down to a full-featured Phoenix BIOS. For maximum performance, VMware directly utilizes the host processor to execute most instructions, instead of emulating the CPU. The VMware approach is not particularly efficient from a disk utilization standpoint: each session must have the operating system completely installed. VMware can create virtual disks from files, so multiple drives are not necessary. In addition to being disk-intensive, memory must be dedicated to each running virtual. However, with VMware, you are not limited to a single Linux distribution or even to the Linux operating system. It offers a more complete virtual server environment but is more resource-intensive, including the need to administer and update each operating system separately. Note that Plex86 (http://www.plex86.org/) is a free alternative to VMware under development.

User Mode Linux offers yet another means. In short, the Linux kernel has been ported to another architecture—a process running inside a regular Linux kernel. Full details are available at http://user-mode-linux.sourceforge.net/.