The new Docker 1.10 release has a host of new features, among them several security improvements that merit the attention of anyone using Docker to develop and run applications. I’d like to focus on three of these features in a short series of blogs: Seccomp profiles, Authorization Plug-in, and User Namespace Support.
Seccomp is an existing open source project originally created for Google Chrome. It enables you to control which system calls are disabled– and this applies to containers as well, when applied via Docker. In addition, Docker implemented a default setting which is now part of the Docker daemon, though this can be changed.
By default, the new Docker Seccomp profile disables 44 system calls, out of 313 available in 64bit Linux systems. For example, the system call for reboot is disabled, since it’s hard to imagine a container that would need to reboot the host machine.
Another good example is keyctl – a system call for which a vulnerability was recently found (CVE 2016-0728). Keyctl is also disabled by default now.
What does this mean? Well, for one thing, the default setting is a good move because it reduces the attack surface somewhat. The problem is, it still leaves nearly 270 calls open – which is still a large enough attack surface to be susceptible to attacks. For example, CVE 2014-2153 is a vulnerability that was found in the futex system call, which enables privilege escalation through a kernel exploit– and that system call is still enabled. This is inevitable since this system call has legitimate use for implementing basic resource locking for synchronization needs.
Docker couldn’t make this default setting much stricter because there are so many types of containers, and between them they use pretty much all of the remaining system calls.
The other significant novelty here is the ability to set Seccomp profiles individually for containers. This provides the necessary flexibility to further harden specific containers based on their actual needs. However, it requires intimate knowledge of container behavior and the system calls it uses, and it’s likely that most developers and Docker users simply won’t have the wherewithal to carry out such changes judiciously. From a programmer’s perspective, it’s better to leave things open rather than risk a bug in the application behavior by mistakenly barring access.
Rome certainly wasn’t built in a day and not all the wrinkles have been ironed out, but the Seccomp addition is certainly an important step in building a more secure container environment.
Here’s a demo I made of Seccomp in Docker 1.10:
Want to know more? Stay tuned for another tip on Docker 1.10 in our next post on Authorization plugins.