CTS 2311 (Unix/Linux Security) Project #7
Using Virtualization

 

Due: by the start of class on the date shown on the syllabus

Description and Background Information:

Virtualization (a.k.a. para-virtualization) is a technique used for (among other things) isolating sets of processes (services) running on the same hardware from each other.  Each service (a set of processes) may run in a separate instance of the operating system or otherwise isolated from other services.  Each instance is called a virtual machine (or VM).

All computers support virtualization to some level, for example virtual memory has been in use for at least 20 years.  Mounting an image file makes it appear as a disk.  Virtual NICs are common too.  Until recently only a few of a host's resources were virtualized; today virtualization generally implies everything is virtualized, giving us a virtual host commonly called a virtual machine (or VM).

Some virtualization systems allow different operating systems per VM, while other require (or will work much better if) the same type and version OS is used for all VMs.  Some support 32-bit systems only, while others can support 64 bit hardware.

Usually you set up these VMs with virtual disks, virtual NICs, and other virtual hardware.  No two VMs directly share anything.  Each sees it's own disks, memory, and NICs.  So no matter what sad fate befalls one service in one VM, the remaining services in other VMs are unaffected.

Some virtualization technologies emulate the hardware using software (called machine emulators).  Examples include QEMU (if not accelerated), Virtual PC, Bochs, and the Hercules emulator.  Application level virtualization is also common, including Microsoft's CLI (used with .net) and Sun/Oracle's JVM (used with Java).  Others only emulate a few critical components and allow the guest OS instance to access the rest of the hardware directly, saving and restoring the machine state when switching between instances.  Examples of this type include KQEMU (QEMU with acceleration), KVM (the Kernel-based Virtual Machine, backed by Red Hat), Win4Lin, and VMware (both client and server versions; see also the free VMware Player).

Some types of virtualization run as an application on some operating system that manages the hardware.  In this common case, the OS running the virtualization software is known as the host OS.  All other OS instances are booted by the virtualization software (when it powers on a virtual machine).  These are known as guest OSs.

Other types of virtualization are possible.  OS virtualization is the name sometimes used when a single OS manages isolation for sets of processes.  Solaris zones and BSD jails fall into this category.  Virtualization is sometimes used to permit running applications designed for a different OS or even different hardware (e.g., wine).  Application level virtualization is also common, including Microsoft's CLI (mono) and Sun's JVM.

The virtualization or emulator software that does all that is variously known as hypervisor, (virtual machine) monitor, system emulator, and other terms.  (Xen refers to the virtual machines as domains.)  Some technologies require applications or OS drivers (or whole operating systems) to be made compatible.  Examples include Denali and Xen.  Other technologies can run unmodified applications or guest operating systems.  To simplify PC and workstation support (with their many devices) some technologies both virtualize some things and emulate others.

VMware Client does this, requiring a hosted or underlying OS on top of which runs VMware.  VMware Server enables one host to appear as a pool of secure (i.e., isolated) virtual servers which can run several different operating systems.  Unlike the client version, VMware Server does not need a host operating system (except to boot the server).  (Xen refers to the (initially booted) host OS, used to create and manage other virtual machines, as domain 0 or dom0.)

Virtualization software generally is designed for a specific CPU architecture.  The i386 family of CPUs was not originally designed for this purpose and many emulators have difficulty with at least some applications.  However today's (post-2006) CPUs do provide some features to support virtualization, increasing both performance and security.  And some virtualization technologies require these newer CPU features to run.  Intel calls their virtualization technology VT and CPUs with this enabled show the flag vmx.  AMD calls theirs Pacifica and CPUs with this enabled show the flag svm.  You can check with 

grep -E '^flags.*(vmx|svm)' /proc/cpuinfo

Virtualization may require kernel support in the host OS.  The hypervisor usually runs as a daemon, and each virtual machine as a separate process.  Additionally there is a set of utilities that allow one to create virtual machine instances (and virtual disk image files) and to manage and monitor the hypervisor and the virtual machine instances.

There are commonly two types of virtual hard disk: a fixed disk has a predetermined size and is created at once; the guest OS sees this as one large unformatted disk.  A dynamic disk starts of taking almost no disk space at all, and will grow as needed; however the guest OS still sees it the same way, but as writes will need to grow the file holding the virtual hard disk's data, it can be much slower than for fixed.

Network support has three different modes (not counting non-networked mode).  For each mode there is a separate virtual hub which the virtual NICs (vNICs) connect to. 

In local (or host-only) mode each guest VM and the host OS have vNICs connected to the local hub.  They can communicate with each other but not with the physical NIC and in this mode there is no Internet access.  The SysAdmin will need to assign each vNIC an IP address in the same network.

In bridged mode the Virtual NICs as well as the physical NIC are connected to the bridged hub.  In addition the Host OS gets a vNIC connected to this hub too, and this becomes the default NIC for the host OS.  The vNICs need IP addresses in the same network as the physical NIC.  Bridged mode VMs can directly communicate with each other and the Internet (and any other reachable networks).  Bridged mode causes heavy LAN traffic and problems due to delays when switching between VMs.

With shared mode, each vNIC connects to the shared hub.  This is exactly the same as local mode, except a virtual router with NAT connects the shared hub to the physical NIC.  External hosts only see the host OS's IP address, not the guest VM IP addresses.  Most virtualization products include a DHCP server with the virtual router to configure the vNICs automatically.

It is possible for some VMs to use one mode and others to use a different mode.  But since each mode uses a separate hub, only VMs using the same mode can directly communicate.  Note some products refer to the hubs as switches or bridges.

Virtualization can be a great way to practice system administration for various operating systems, networking (when you don't have many hosts and network hardware available), and system security.

Requirements:

Part I:  Planning, Preparing the Host OS, and Installing VirtualBox

Many virtualization packages are available, but the best are often commercial.  VMware Server would provide excellent security but would be complex to set up without disturbing your existing installation.  VMware Player is easy to setup but can't use Fedora as the host OS.  So we will the popular VirtualBox product by Oracle, which is free, works well, and has a simple user interface.  (VirtualBox is sometimes called vbox or even vb.)  We will install a guest OS which you will configure to run the Apache web server as the only service.

Answer the following questions and perform the following tasks:

  1. Compare the features, cost, host OS requirements, guest OSes supported, and license terms for each of the following:
    • VMware Player
    • VirtualBox
    • Xen

    (Use a table, or a few sentences of description of each.)  Since of the free and open solutions, only VirtualBox will support Fedora as a host OS, we will use that in this project.

  2. Check your system resources available for virtual machines. 
    1. Does your CPU have hardware virtualization support enabled?
    2. How much physical RAM do you have installed?  How much is required by your host OS to run acceptably?  Without enough physical RAM your guest OS will have terrible performance.
    3. How much virtual disk space and memory is needed for a Windows XP install?  For a Fedora Linux install?  For a Puppy Linux (or DSL) install?  For an OpenSolaris install?  For a FreeBSD install?  (Of course the amount varies depending on what extra software and data you plan to host, so assume a default install.)
    4. Which disk partition has sufficient free space in which to create the virtual hard drives?  This is usually in /home or /var.  If created in your home directory you won't need to be root to create the virtual machine instance, but beware of disk quotas!
  3. What system will you use for the guest OS?  (You are free to use any one you wish that will meet the requirements of VirtualBox and your available memory and disk space.)
  4. Download the installer CD or DVD (ISO) image file for the chosen OS.  This should be an .iso file, which can be downloaded to any place with enough free space.  What version of this guest OS are you using?  Verify the downloaded file isn't corrupted.  How did you validate the file?
  5. Prepare your system to install VirtualBox.  (For this project you should NOT use the version found in the standard Fedora yum repositories; you will install with yum from a different repository.)  You should update all installed packages, make sure the dependent software has been installed, and possibly reboot (if the kernel or critical DLLs have been updated.

    The following software should be installed: make, automake, autoconf, gcc, kernel-devel or kernel-PAE-devel (it depends which kernel you have), dkms, qt, and SDL.  (Most of this is needed to update the VirtualBox loadable kernel module (LKM)when the host OS's kernel gets updated.  You may also need these on the guest OSes to support the Guest Addons.)

    What software did you need to install?  Investigate the packages qt, and SDL to see what they are for.  What part of VirtualBox do you think will require these packages?

    The PAE kernels support the Physical Address Extensions.  This is used on otherwise 32-bit kernels to support memory above 2 gibibytes.  To see what kernel your host OS is running you can use the uname command.  (Guest OSes will also need a PAE kernel if you give them more than 2 GB of memory, and they are 32-bit kernels.)

  6. Using what you have learned, download, enable, and install a yum repository config file for virtualbox.org: 
    wget http://download.virtualbox.org/virtualbox/rpm/fedora/virtualbox.repo

    Exactly what did you do to install the config file and enable this repo?

  7. Now, using yum, install the VirtualBox-4.1 package.  (Use a more recent, stable version if available.)
  8. The next step is to compile and load the VirtualBox LKM.  This is done automatically with the (newly installed) vboxdrv daemon that runs at boot time.  You should run that manually now, with an argument of setup.  What was the exact command you ran, and what was the output?
  9. When you installed VirtualBox a new group was created, vboxusers.  Only root or members of this group can run VirtualBox.  Add your (non-root) username to this group.

Part II:  Creating a Virtual Machine and Installing a Guest OS

VirtualBox includes several tools and utilities:  VBoxManage is a command line utility that allows you to control every aspect of VirtualBox.  VirtualBox is the standard GUI tool that allows you to create, start, stop, and manage most aspects of your VMs.  VBoxSDL is an alternative utility with a very simple and limited GUI.  VBoxHeadless that provides no user interface at all, and merely acts as a VRDP (VirtualBox Remote Desktop Protocol) server that allows tools to manage VMs remotely.  Vboxwebsrv is a web server that also allows remote management.  For this project only the VirtualBox GUI tool is used.

Answer the following questions and perform the following tasks:

  1. Start VirtualBox and create a virtual machine for your selected guest OS.  Keep in mind the disk space and memory requirements for your host and guest systems.  (If you specify less than 256 megabytes you may have a very slow GUI; it could take many minutes to boot up!  But if you specify too much, your host OS will end up using the swap partition and again performance will be bad.)  The only other requirement is to make sure your guest system can access the network.  (So pick an appropriate networking mode.)  Record all the choices you made and the resulting hardware list in the a new system journal you will start for the guest system.
  2. Start virtual machine, with the guest system's install CD or DVD ISO image (downloaded earlier) mounted in the virtual CD-ROM drive. 
  3. Install the guest system, using a minimal install.  Keep track of all the steps, in detail, in the separate system journal.
  4. After the install is complete, you can restart the virtual machine and reboot the guest system without using the CD image.  What changes to you make to the virtual machine?
  5. Practice using VirtualBox:
    1. How can you run the guest OS in full screen mode?  How do you restore windowed mode?
    2. In windowed mode, the guest OS grabs control of the mouse and keyboard.  How do you make the mouse release from the guest?
    3. Install the VirtualBox Guest Addons, if possible for your chosen guest system.  Do not forget to record all steps and changes made!
  6. Confirm the guest OS networking is up and running.  Configure it if necessary, of course remembering to record any changes in thye system journal.  Now login from the guest OS to the host OS, using either telnet or ssh.  What is the IP address of the virtual NIC?  What trouble-shooting steps did you need to perform (if any) to get this to work?  (Be specific!)
  7. Why might it be difficult to telnet or ssh from your host OS to the guest system?

Part III:  Using Docker Containers

Containers are an alternative to full virtual machines.  The main difference is all containers share a single OS, which is responsible for enforcing the isolation between containers.  So a service may be composed of one or more containers (guests) running on a single server (host).  (In some cases, containers run on top of virtual machines.) To support management and other services, often a daemon is needed.

Docker is a popular (2015) container technology based on Linux support for containers (LXC).  Each running container is created from an image (which can be exported as a tar archive), just like a virtual machine.  Each image is fully described in a simple text file, “Dockerfile”.  By fully specifying the versions of everything in the image, new containers can be launched identical to some older one, which is important for repeatability.  (Or, simply make a repo of container images to reuse as needed.)

In this part of the project, you will install Docker and create a web server as a container.

Answer the following questions and perform the following tasks:

Show all commands you ran for this part (use script).

  1. Ensure sufficient free space remains for Docker images (10+ GiB). Grow the volume group if not.
  2. Install, start, and test Docker.
  3. Setup an Apache web server as a Docker container, using Debian.  Show the Dockerfile you created.
  4. Start the server, and using the command line interface provided by Docker, add a default web page to identify your server uniquely.
  5. Test it out.  What URL did you use?
  6. Power down your container.  Verify it is no longer running.

Part IV:  Cloud Computing

Background goes here...

  1. Create Amazon EC2 academic (free) account.
  2. Create Fedora web server.
  3. Secure and configure the web server.
  4. Add a default web page to identify your server.
  5. Test it out.
  6. Power down your cloud web server (or you will exhaust your $100 allowance).

Hints:

You will find lots of documentation on the VirtualBox wiki site at http://www.virtualbox.org/wiki/Documentation.

If you find that you're getting SELinux errors or denials, it may be the install didn't correctly label the VirtualBox DLL correctly.  You can relabel VirtualBox.so with this command: 

su -c 'chcon -t textrel_shlib_t /usr/lib/virtualbox/VirtualBox.so'

Use what you have learned to locate documentation.  Apply the trouble-shooting techniques discussed in previous classes.

The host OS may need some kernel parameters adjusted.  The Linux kernel is not setup for virtualization and running VMware or other virtualization that hosts guest OSes can easily cause out of memory errors even when there might be enough.  Two (poorly documented) kernel parameters can be adjusted to help: 

vm.lowmem_zone_ratio = "100 32 32"

(the first value is the one to change, defaults to 256) and 

vm.dirty_ratio = 5

(defaults to 10%.)  The first change more aggressively protects the memory used by the hypervisor to prevent crashes.  The second change causes unused memory to be reclaimed more frequently by the kernel's background memory thread.

For Docker containers, see the Docker Setup Demo and the other information available in the class resources.

If you get stuck remember you can ask your instructor for help.

To be turned in:

A copy of your journal pages (both journals!), describing each task you performed and the answers to the questions asked above.  You can send as email to (preferred).  If email is a problem for some reason, you may turn in a hard-copy.  In this case the pages should be readable, dated, and stapled together.  Your name should appear on the first page. 

Don't turn in your whole journal, just a copy of the relevant sections.  It is common in fact to keep the journal as a text file on the system (with a paper backup of course).

Please see your syllabus for more information about submitting projects.