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

Question

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?

Answer 1

Docker and LXC technology itself is still in very early stages when it comes to exploitation testing. drewbenn is right in highlighting the difficulties of running Docker containers as a non root user - there are inherently some very low level things that need to happen in order to start up an LXC container.

Something interesting to consider though is the intended target any malware that you're trying to isolate in the container.

Say the malware was trying to exploit a flaw in a piece of local software to do privilege escalation. It might achieve that inside the container, but then it would also have to have been written specifically to attempt to break out of docker containers to do something malicious.

So the question is - will the people who are writing this untrusted code know that you're going to be running it inside a container? If they do (or if they suspect you will) there's a much higher likelyhood of a vulnerability turning up that exploits a dockerised environment directly.

Answer 2

An application running in a standard Docker container as a non-root user is essentially just a non-privileged process running on the host, with additional restrictions applied to it.

Firstly, the application will reside within its own set of namespaces (e.g. mount, net) restricting it's view of the host's resources.

Then assuming a standard Docker configuration, on debian derivatives, there will be an AppArmor profile applied to the application, restricting some access.

Additionally (assuming it's not running under Kubernetes), a seccomp profile will be applied to the application process restricting its access to specific syscalls.

In terms of breakout opportunities, assuming that the container is non-root and was not run with the --privileged flag or mounting files from the underlying host, the attacker's on-host breakout opportunities primarily relate to attacking the underlying Linux kernel. If there are unpatched privesc issues in the running kernel the attacker may be able to exploit these, although it's possible the syscall filter or AppArmor profile would block them.