Caution!

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).

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.

SELinux Limits

SELinux [4] is a security framework that assigns a multipart label to each file and each process. A policy defines which process label can access which file label. Docker supports two variants: type enforcement and multicategory security (MCS).

Type enforcement restricts access by containers to the host filesystem. All container processes run as the same type, which allows access to files in the container and a number of host system files but also prevents access to most folders on the host (i.e., /var, /root, /home).

If only type enforcement were used, containers would be able to access the data in other containers easily. Thanks to MCS, SELinux assigns a container a random MCS label when the container starts up; the Docker daemon tags all the files in the container with this label, and the kernel prevents processes with a different MCS label from accessing the files in the container.

In many enterprises, SELinux has been viewed as an undesirable feature and is one that admins love to disable. However, the security of Docker containers relies on features such as secure virtualization (sVirt) [7]. With virtually no help from other applications, sVirt alone is enough to prevent users from other containers reading your files.

Future

For the future, the Docker developers are planning to improve container security and isolation. Three features will help, including user namespaces, Seccomp [8], and role-based access control (RBAC) [9] for access to the Docker daemon.

User namespaces take priority. Docker maps user IDs from the container to other host IDs. The idea is to restrict substantially the ability to attack files that belong to root.

Because all the containers talk to the same kernel, an error in a kernel function can be fatal for the boundaries between host and container and for the boundaries between the containers themselves. Seccomp, from Google, prevents access to specific system calls by a process. Although a process uses system calls to access the kernel, most of the 600 available calls are only rarely used. Without them, the potential attack surface could be reduced. Daniel Walsh is working on container security at Red Hat. His guess is that developers could reduce the number of callable system calls by up to 50 percent [10].

Additionally, the developers are looking to refine access to the Docker service and to supplement the authentication options. Doing so means that users who do not have root authorization for the host could use the service. If the developers additionally introduce RBAC, the Docker admin can assign different roles to users, thus giving them restricted privileges for interacting with the daemon. With the help of these plans, it should be possible to restrict access further to containers or functions in the future.

Conclusions

In many areas, the Docker developers have already responded to improving the security of containers, and they are continuing to add new features to continue this trend. A verification system was recently introduced for Docker images in version 1.8 in the form of Content Trust [11]. Additionally, the Open Container Initiative [12] is looking to put more effort into security.

Much work is still needed in the future. For example, sustainable best practices for container management need to be defined to promote more widespread use in the enterprise.