Caution!

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.