Non-privileged containers FTW!

Did you know that running containers with user root is not only a bad practice, but really is a security risk? You might not care when launching a single container on your laptop, but in the context of container orchestrators such as Kubernetes, this is a real problem. This site tries to explain the issue, collects data and reference material and ultimately provides you with tooling to change the status quo. We can do it, if we all work together!

The problem

Too many containers require privileges to run

A huge percentage of container images expect to be able to run as root at least briefly before dropping privileges. This leads to tons of software running with way more privileges required than are actually needed to get the job done.

Almost all software can run fine without requiring any privileges. Daemons like web service, HTTP, and databases, can easily be configured to run with only user privileges. Eliminating the need for a process to run with any Linux capacities, leads to a huge increase in security. Think of this as the security level of a multi-user system.

There is a ton of software that needs to be root, CAP_NET_BIND_SERVICE, just to bind to a port lower than 1024. After it binds to a port, it usually changes to a different user to drop privileges, but this means it needs CAP_SETUID and CAP_GID just to become less privileged. If we just stop binding to ports lower than 1024, we eliminate the need for these powerful capabilities.

A lot of work goes into attempting to keep containers from attacking each other. Most of these are around reducing the attack surface of the kernel and minimizing the power of root. If we just rework the way we run software, we decrease the attack surface of the system enormously.

Why do all the containers require privileges?

The main reason we end up with these containers requiring privileges is that we are using software packaging like rpm and deb which have built-in assumptions that you have to be root to install the software. As we move into containers, we need to stop making these assumptions.

Conclusion

So unless your application needs to:

1. run with multiple UIDs,
2. bind to a port lower than 1024, or
3. modify parts of the kernel

… it should not run as root.

Reference material

Official docs

• Docker security
• CoreOS rkt Capabilities Isolators Guide
• OpenShift Managing Security Context Constraints

Related activities and discussions

• contained.af by Jess Frazelle
• containerhardening.org by Jess Frazelle
• rootlesscontaine.rs by Aleksa Sarai
• Getting Towards Real Sandbox Containers by Jess Frazelle
• Docker and CIS Benchmark
• CIS Benchmark for Kubernetes 1.6
• The ThoughtWorks Technology Radar on container security scanning
• Privileged Docker Containers
• SO question on Privileged containers and capabilities
• Building non-ROOT containers by Sebastien Goasguen
• Understanding How UID and GID Work Inside Containers by Marc Campbell
• Running Docker Containers as non-root by Carlos Sanchez

Background

• User Namespaces: 2017 Status Update and Additional Resources, 02/17
• Phil Estes Rooting out Root: User namespaces in Docker, 09/2016
• Michael Cherny Docker Security Features, Part 3: User Namespace, 03/2016
• Dan Walsh Are Docker containers really secure?, 07/2014
• Rami Rosen Resource management: Linux kernel Namespaces and cgroups, 05/2013

Responsible security disclosure

• Docker email and webpage
• Rkt email and webpage

Tooling

• Quay Security Scanner
• Docker Security Scanning
• Aqua Security Scanning and Runtime protection
• K8Guard
• cnitch, Docker root process monitoring

Who’s behind this initiative? Check out the author listing to find out.