Security [1] seems to be lagging behind the pace of other developments in the Docker camp. Although increasing numbers of enterprises are using Docker at the data center, the technologies administrators use to safeguard containers are only slowly establishing themselves. In many cases, it is precisely the features that make Docker popular that also open up vulnerabilities (Figure 1).

Figure 1: The Docker website lauds its containers as an instant solution.

What the Kernel Does Not Isolate

Docker relies on the Linux kernel's ability to create reciprocally isolated environments in which applications run. These containers are lean because they share the same kernel but are executed in separate run-time environments, thanks to cgroups [2] and namespaces [3], which define which resources a container can use. At the same time, the container itself only sees certain processes and network functions.

Although an attacker will find it difficult to interact with the host's kernel from a hijacked virtual machine, container isolation does not provide the same defenses. The attacker can reach critical kernel subsystems such as SELinux [4] and cgroups, as well as /sys and /proc, which means attackers can potentially work around the host's security features. At the same time, containers use the same user namespace as their host systems. In other words, if the process is running with root privileges in a container, it keeps these privileges when it interacts with the kernel or a mounted filesystem. Admins are thus well advised not to run software with root privileges in containers; in fact, this is something that is only rarely necessary.

Risks: Docker's Daemon

The Docker daemon needs root privileges, however. It manages the containers on the host and needs to talk to the kernel that provides the isolated environments. Users who interact with the daemon are thus given privileged access to the system. This situation would be particularly critical if a hosting service provider were to offer containers as a self-service option via a web interface.

Although using the docker group is an option, it is unlikely to improve security, because the group members can create containers in which, first, a root shell can be run and, second, the host's root filesystem can be mounted. The only option here is to regulate access strictly to the Docker service to avoid undesirable privilege escalation.

Moreover, Docker's daemon can communicate through a REST API via HTTP(S). If you use this function [5], you will want to restrict access to the API to a trusted network or restrict it through SSL client certificates or the like.

Countermeasures

New versions of Docker come with features for mitigating the effect of the described attack scenarios. Docker mounts read-only the /sys filesystem and important files in /proc. The container cannot write to them, thus preventing privileged processes in containers from manipulating the host system.

The kernel breaks down root privileges into capabilities [6] and assigns capabilities individually to processes. By default, Docker blocks important capabilities, to keep privileged processes in the container from creating mischief. These capabilities include network configuration, the ability to load kernel modules, or access to the audit subsystem. If a special application needs the blocked capabilities, Docker allows them for an individual container.