User-mode Linux on host "gateway"

The Project

Create a fast-startup, fast-teardown User-Mode Linux machine environment for users and students where they:

  • Have full root access to the machine,
  • Have access to their own system home directory as themselves (i.e., not as root),
  • Can install new software packages as they choose,
  • Can run servers on restricted ports (e.g., web servers),
  • Have full, transparent network access (i.e, no NAT).

User-Mode Linux (UML) uses a special Linux kernel built from standard Linux kernel source code. This kernel won't boot on physical or virtial hardware, but instead runs from the command line or from a script as a standard program under Linux.

Once started, the UML instance operates like a real Linux system. It can run web servers, database servers, SSH servers, X servers (and, therefore, XFCE4, Gnome, KDE, FVWM, etc., and LibreOffice, FireFox, Chromium, etc.) and so on, just like the real thing because it basically is the real thing.

Specifics

We use a custom UML kernel where each running instance operates in a copy-on-write gaol created inside a btrfs filesystem. The gaol content comes, in the first instance, from archlinux subdirectory in the same btrfs filesystem.

The contents of this archlinux subdirectory are rsync'ed from an auto-updating ArchLinux master system at intervals.

This means that users inside one of the UML systems have apparent root access inside the machine, but when they change anything a separate copy(-on-write) instance of whatever-it-is is created both for security (so no user can change the master files) and for speed (of initially setting up the gaol).


Create btrfs filesystem and mount at /uml so we can use btrfs' clone-on-write via /bin/cp's --reflink option.

Create /uml/archlinux for the copy of the ArchLinux filesystem from the master system (runs on QEMU/KVM on vmfram5 [sic]). This is copied/updated using rsync.

Create /uml/bin for scripts, etc., including:

  • /uml/bin/startenv - run inside the gaol, this scripts sets up /proc, /dev, etc.; starts /usr/bin/haveged (to feed the kernel's random number generator code because without haveged bits of entropy get generated really slowly and sshd takes a very long time to start), /usr/bin/dhclient (so the virtual machine can get an IPv4 address) and /usr/bin/sshd with a custom /etc/ssh/sshd_configfile.