Linux Containers for Event Training
by Jon Schipp
Goal: To enable organizers and presenters of information security conferences, Linux user groups, and 2600 meetings to quickly prepare and serve training environments that teach and demonstrate Linux-based software to participants. By reducing the administrative overhead and the barrier to participation, we can improve the overall quality of training at events.
It can take hours to package and distribute a virtual machine with the necessary tools for training, and now it can be done in minutes including deployment using Docker containers.
Background
Software demonstration and hands-on training improve the experience of attendees during community events by not only sharing information, but allowing it to be practiced, which yields greater retention, understanding, participation, and fun. However, the logistics come at a high cost for both the user and the administrator. Virtual machine, or virtual appliance, based training tends to be the most common form, allowing a large number of participants to follow an instructor through an isolated environment, each running on their own computers. Using virtual appliances, while a workable solution, is not ideal due to the amount of time involved in their preparation, distribution, and configuration. Shared machine training is another form where users are given accounts to a UNIX-like system which they can remotely access.
The concerning problems of both methods can be summarized in a brief list:
- Too much time is spent distributing, downloading, or copying virtual appliances.
- Conference networks are slow and VM files are big.
- Technical difficulties can and often will occur which end up putting some students behind others.
- Hypervisor image compatibility, e.g. VirtualBox, VMware, etc.
- VM bus and network configuration.
- Account management is repetitive and time consuming on shared systems.
- Changes are not easy in virtual appliances.
- Insertion of wrong exercises, versions, mistakes, etc. How is this handled?
Linux-based Containers
Linux kernel 3.8 introduced the building block for containers, a form of lightweight process virtualization, or operation system level virtualization.1
The two building blocks are namespaces and cgroups.
Namespaces provide resource isolation, effectively making a system resource believe it's a part of a global resource through abstraction. There are six namespaces at present and they include: pid, net, mnt, ipc, uts, user
pid, for example, allows processes applied to a namespace to be isolated from processes in other namespaces.
Control groups, or cgroups, is the mechanism to which constraints can be applied to resources such as limiting the CPU and RAM usage to processes in a particular cgroup. This type of virtualization is done at a higher level, as opposed to the lower-level hardware virtualization used in virtual machine technology. A benefit is that containers do not impose as large a cost by sharing the same kernel. Container startup time can be around 100 ms, reaches near bare-metal performance, and outperforms KVM virtual machines in a wide array of applications from disk to memory.2
With this comes greater density, where hundreds or thousands of containers can run on a single system. In addition, from the general user's perspective, having a shell inside a container or virtual machine is indistinguishable.
There are a number of userspace container runtime implementations, including LXC, Google's lmctfy, systemd-nspawn, Docker, and the newly announced Rocket runtime. Docker, a container runtime and deployment platform, is currently the most widely used, and for this reason my choice as the technology behind ISLET.
Isolated, Scalable, and Lightweight Environment for Training (ISLET)
ISLET is a solution for teaching Linux-based software with minimal participation effort by using Linux containers, and satisfactorily addresses each item in the aforementioned list of problems.
It's a wrapper around Docker, SQLite, and a few other tools that in effect reduces preparation and deployment of training environments to a simple three step process, enabling you to have ready to go training environments in minutes rather than hours. Account management is automated and handled internally by ISLET and is separate from the host, which allows users to resume their work (by reattaching to their container) should training events span multiple days.
ISLET is intended to be run as a server which students can remotely access.
One single host account is required for ISLET which can be shared with all participants, its shell is set as islet_shell which handles everything after the initial authentication to the host. The participation barrier is set very low, and students only need an SSH client to access the ISLET menu which launches available configurations upon selection. Building on a cross-platform and proven remote access tool like SSH opens the door to greater accessibility that wouldn't otherwise be possible when hypervisors are required, e.g., using smart phones, tablets, and other mobile devices to access training environments.
The three step process to create and deploy a training environment with ISLET is as follows:
1.) Have a docker image with the tools needed for training, installed and configured.
2.) Create an ISLET configuration file for the image describing its functionality and resources.
3.) Place the ISLET configuration file into the /etc/islet directory. After the final step, students can connect to the system and launch the new configuration which will place them into a container based on their image configuration of choice.
A 64-bit Linux operating system is required to run Docker.
The recommended operating system for ISLET is Ubuntu, and installation plus configuration for this operating system is very simple with the following make targets:
You can then use ISLET by SSH'ing to the system with a user account and password of demo.
Hundreds of training environments for different pieces of software can be made available on an ISLET server from which a user can choose to begin work instantly.
Future work includes porting ISLET to FreeBSD by using jails and implementing a distributed setup to handle large participant numbers seen in Massive Open Online Courses.
Use Cases
At BroCon 14, the precursor to ISLET was introduced to aid in teaching the Bro programming language to participants.
The ISLET system ran on Amazon EC2 as a m3.xlarge instance and handled 50+ users simultaneously without issue. The University of Illinois at Urbana-Champaign is using ISLET in their Digital Forensics II course to teach Volatility, Bro, The Sleuth Kit, SIFT Kit, and BitCurator.
The Open Network Security Monitoring group (OpenNSM) has used ISLET to teach OSSEC, among other tools, and had its first case where a student followed along on their smart phone via an SSH application. The UIUC Linux User Group uses ISLET to teach a C programming series each week, in addition to other Linux tools.
Try It Out
If you would like to try out ISLET, I have two publicly available servers for experimenting and a Vagrant Box3:
References & More Information