Container, as defined in the dictionary, is an object that can hold something. Extending its meaning: a place where some correlated items can be stored or move together; a separator of things; a constrain for the contained things.

Starting in 1982 with chroot, to BSD-jails, Solaris Containers, LXC, OpenVZ, and Docker, container systems try to keep something isolated from the host system, to keep related things together, to limit the resources a thing can utilize: all focusing and prioritizing different aspects.

This class of technologies is a so called OS-Virtualization technology, to distinguish them from the Full-Virtualization (Type-One: Hyper-visor on bare metal like XEN, ESXi, KVM; Type-Two: Hyper-visor on standard kernel, like VMware Workstation, VirtualBox, QEMU).

Full-virtualization:

Guest process ---\
Guest process -----> Guest OS ----> Host OS ----> Hardware
Guest process ---/

OS-virtualization:

Guest process ---\
Guest process --------------------> Host OS ----> Hardware
Guest process ---/

Containers are so popular because they are very useful, as example:

• For testing and/or development: It is possible to maintain different version of the same system’s components (dependencies) at the same time on the same disk, contained or jailed in dedicated space.
• In production: Deploying different versions of the base application in containers make it easier to fail-back in case of problems.
• As security addon: Jailing applications may help to keep resources with different privileges separated.

They try to resolve a long annoying and costly problem: easier the application life cycle, from the development to the decommissioning. This was the primary goal of Docker in its infancy, regardless to security.

Docker

During the last years of the last decade, the advent of hardware virtualization caused a large offer of PaaS, essentially cutting expenses down, that enormously expanded The Cloud. A company called dotCloud was dealing with Linux containers, and developed a framework, released in 2013 as an Open Source project called Docker.

Docker is not Docker. Up to version 1.10, Docker was running on LXC container technologies, with all the downsides. In the spring of 2014, Docker rolled out a new version: they changed from utilizing LXC to libcontainer, a library completely written in Golang and explicitly designed for containers. The library directly manages syscalls and controls the implementation of long awaited security features: Docker now supports – out of the box – namespaces, control groups, capabilities, apparmor profiles, network interfaces and firewalling rules – all in a consistent and predictable way, and without depending on LXC. This improves the isolation of Docker from the side-effects introduced across versions and distributions of LXC.

Today, Docker is not only a daemon, but contains Docker Hub, Registry, Swarm, Compose and diverse supporting tools, like Docker Notary for trusted images, and Docker Machine for provisioning. Look at Docker Security for more information.

The impact of Docker in the next years will still grow; aside the official 64-bit Linux, clients are ready to use on many platforms (Linux, Windows, macOS, FreeBSD), even Microsoft Windows is including support for Docker, and don’t forget the support in IoT world! For additional information, I strongly suggest to take a look at DockerCon 2016 – conferences

Weaknesses and benefits of Containers

Like any technology, containers suffer from some problems but also offer some benefits. On the weaknesses side, we can summarize:

• Mixed security levels: Makes it easy to run multiple applications on the same host and may lead indirectly to a mix of security level applications mixing at kernel level.
• Poor implementation of namespaces: Isolation of a Container is not the isolation of a virtual machine that is not the isolation of a physical machine.
• Single layer of security: All protections are software protections.
• Single or very limited OS: Single environment where kernel remains the same, may lead to mass vulnerabilities.
• Single point of failure: The kernel brings the major risk.
• Not well understood: Possibilities offered by a container are not – yet – well understood by operators, developers, managers and also by most auditors.

On the benefit side, we can list:

• Speed: Launching a container is almost starting a new process.
• Management: A container helps in upgrading application and related components, avoiding the static-system running insecure code for years: operating and patching of application can happen with higher frequency, minimizing the effort of application validation.
• Security: Containers, maintaining the separation grade between the application and components, make easier to control what is installed and avoid the hidden impact of inter-dependent libraries. In addition offers a higher grade of segregation for those applications normally running on the same host.
• Efficiency: Container consumes fewer resources, in power and storage.

Updating the threats map

New technology poses new risks; to deal with them, we need to start from the threats the OS-Virtualization introduces in our infrastructure. Some of them are container specific, others are just classic threats:

• Escaping: Breaking the constraints and operate directly in the host. Can be caused by many reasons, but the most common are: (1) Lack of user namespaces or privileged capabilities: The ability to map container privileged users in host unprivileged users, reduces or even eliminates many of the threats in this category. Allowing privileged operations, like those provided by CAP_SYS_ADMIN capability may lead to guest escaping and host manipulation; (2) Insecure default configuration: defaults are normally trusted, but in many cases they are open; a classic example is the CAP_NET_RAW capability, that can be easily used to perform network attacks; (3) Misconfiguration or weak configuration of networks of procfs or sysfs may facilitate a large range of attacks against the host system.
• Cross-container attacks: The host is a primary target, but also attacks against other containers may be valuable. This type of attacks does not necessarily require a vulnerability in the container implementation, but can be carried out in a “old fashion way” like the classic attacks via network. Other kind of attacks may involve the use or abuse of resources that can impact a container running in parallel causing a DoS. Depending on the design and implementation of the system, some containers may share partitions or resources with other containers: This mix may allow cross – unexpected – access from one container to another.
• Inner-container attacks: This is the classic category where the vulnerabilities impact on the container itself. May be caused by unpatched software, lack of hardening, weak application security and so on.
• DoS: Classic Bash Fork Bomb; direct or indirect exposure of hardware resources may lead to CPU, memory or network consumption; depending on the logging/audit configuration of the guest/host, accessing a file at high speed may impact the host audit system and – in extreme cases – may halt the host; exposure of the PRNG device may weak or completely deplete the entropy pool, heavily impacting on the encryption mechanism of the system.
• Images attacks: Docker has contained a number of vulnerabilities related to image processing or verification; the game is changing with the introduction of Docker Notary, but it’s still a new component.
• New code: On top of new code. As any new piece of software, new logical or syntactical mistakes may be present in the code and some of them will manifest themselves as vulnerabilities. The list of CVE-IDs related to container or components like namespaces is quite long.

Summary

We are the Container. Your physical and virtual distinctiveness will be added to our own. Resistance is futile.

OS-virtualization isn’t really a new technology, but in the last years has been adopted by a very large number of companies, and the number is still growing rapidly.

Docker, in particular, is spreading across infrastructure because it is a great help for operators in application maintenance. At the same time, it is not always clear enough where the limitations or the problems of these technologies lies and how can they be mitigated or controlled. In this article, we recapitulated the key points of the technology and identified some attack scenarios.

About the Author

Rocco Gagliardi has been working in IT since the 1980s and specialized in IT security in the 1990s. His main focus lies in security frameworks, network routing, firewalling and log management.

Links

• http://shop.oreilly.com/product/0636920035671.do
• https://www.oreilly.com/topics/infrastructure
• https://www.youtube.com/playlist?list=PLkA60AVN3hh9gnrYwNO6zTb9U3i1Y9FMY
• https://www.youtube.com/watch?v=A32Yjizt2_s