Virtualization for Compartmentalization

server Clouds Computing network Concept illustration design over white

Virtualization usually first enters an organization for economic reasons. Either the cost for buying physical servers, for power and cooling needs, or else for paying the staff needed to maintain full operating systems on independent hardware platforms.

Cost is a compelling reason, but there’s more. Also consider your ability to compartmentalize processes to a degree you couldn’t practically achieve even if money were no object. You wouldn’t have space to house all the physical machines needed to accomplish what you easily can with virtualization.

Learning Tree’s Linux Virtualization course takes your through this series of choices, let’s look at an overview here.

Starting With Chroot

Chroot environments are the lightest form of virtualization. The good news is the lack of overhead, adding chroot environments adds no extra load on the server. If you ran that many processes, there is no added penalty for putting them into chroot environments.

The compartmentalization isn’t very strict. Only the normal file system permissions restrict other processes from seeing and manipulating the chroot file system trees. The processes running within chroot can still see the entire process table, and so this is unsuitable for situations where you must worry about covert communication channels.

It is possible to escape a chroot environment and so you have to trust the people you allow to use them. But given the low amount of work needed to set them up and the lack of overhead, chroot may be an appropriate choice for you.

Containers and Docker

Containers provide much more compartmentalization. A process running within a container sees a full Linux file system, but probably nowhere nearly as complete as on a typical host. It’s just what it needs to do its work, and it’s a subtree of the actual file system on the host operating system.

The container also has a process tree, although again this is a subtree of the real one. The process IDs are remapped. The init process with PID 1 within the container really has a different PID within the real process tree on the host. The same is true for all the other processes in the container.

The result is that a privileged user in the host OS can see and modify the file systems within the containers, and see and signal processes running within them. But processes within the containers, even privileged ones, cannot see files or processes outside their own environment.

There is still very little overhead for containers, as they don’t have their own kernel or the many processes you typically find in a full operating system. They typically have just their own init and a handful of other processes, only what they need to accomplish their specialized job.

Containers have obvious advantages. Docker makes their management easy and efficient.

Full System Virtualization

Full system virtualization provides even more compartmentalization. Each environment is its own virtualized full operating system apparently running on independent hardware. The hypervisor emulates a hardware platform, so you can run any operating system that runs on that hardware. And with the needed hardware emulation, you can virtualize a different architecture. Your Linux host OS running on x86_64 hardware can run guests that are Windows on ARM, Android on ARM, Solaris on SPARC, OpenBSD on Alpha, whatever you want.

Yes, we start to run into some overhead here, but it’s surprisingly small. There are two reasons that Linux is such a high performance virtualization platform. First, the hardware acceleration for virtualization supported in both Intel and AMD processors. Second, the KVM (or Kernel Virtual Machine) support built into the Linux kernel.

Full system virtualization provides the most compartmentalization, but as with everything involving computers, nothing is perfect. Xen, the Type 1 virtualization powering major cloud providers like Amazon and Rackspace, has had a series of vulnerabilities leading to significant worry and criticism. A bug discovered this past spring in the CD-ROM drive emulation allowed for “VM escape”, letting a hostile administrator of a virtual machine directly access the host operating system and thus other VMs. And late October’s Xen advisory warned of another VM escape bug that had lurked in the code for seven years.

For More Details

Check out Learning Tree’s Linux Virtualization course!

Type to search

Do you mean "" ?

Sorry, no results were found for your query.

Please check your spelling and try your search again.