Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

What are the potential security problems running untrusted code in a Docker container as a non-root user?

I've seen plenty of ink spilled by now about how Docker is not sufficiently isolated to allow arbitrary containers to be run in a multi-tenant environment, and that makes sense. "If it's root in Docker, consider it root in the host machine." What about non-root though?

If I want to take some untrusted code and run it in a container, can it be done safely so long as the container is running as a non-root non-sudo user? What are the potential security pitfalls of doing something like that?

I'm fairly sure there are production applications doing this today (CI systems, runnable pastebins), but are they just lucky not to have had a determined attacker or is this a reasonable thing to do in a production system?

like image 862
Michael Bleigh Avatar asked Aug 27 '15 19:08

Michael Bleigh


People also ask

Why is Docker not secure?

Docker containers are, by default, quite secure; especially if you run your processes as non-privileged users inside the container. You can add an extra layer of safety by enabling AppArmor, SELinux, GRSEC, or another appropriate hardening system.

What are security measures you took to secure the Docker image?

Scan and Verify Container Images If you use a base image to create new images, any vulnerability in the base image will extend to your new images. Container image scanning is the process of analyzing the content and composition of images to detect security issues, misconfigurations or vulnerabilities.

Should you run Docker as root?

Running the container as root brings a lot of risks. Although being root inside the container is not the same as root on the host machine (some more details here) and you're able to deny a lot of capabilities during container startup, it is still the recommended approach to avoid being root .


1 Answers

As of Docker v1.12, if one runs a container as a non-root user with user namespaces enabled, there are two levels of privilege escalation a malicious actor needs to perform in order to become root on host:

  1. Escalate from non-root to root user inside container
  2. Escalate to root user in container to root user on the host

So in case untrusted code is run inside a Docker container as non-root user, it will be slightly more difficult for an attacker to become root on host, since we add an extra step of becoming root inside container. That's the only advantage in terms of security compared to running containers with root privileges.

In case of privilege escalation through both layers of security, following should help restrict the attack surface:

  1. Workloads(more specifically docker containers, in this context) with different trust levels should be isolated from each other by use of overlay networks following least privilege principle.
  2. Enabling available Linux security module in enforcement mode(e.g. SELinux, AppArmor)

References:

  • Running with non-root privileges inside containers: https://groups.google.com/forum/#!msg/docker-user/e9RkC4y-21E/JOZF8H-PfYsJ
  • Overlay networks: https://docs.docker.com/engine/userguide/networking/get-started-overlay/
  • User namespaces: https://docs.docker.com/engine/security/security/#/other-kernel-security-features
like image 141
P.J Avatar answered Oct 20 '22 18:10

P.J