Root Access Series: I see (docker) daemons.

Discover how misconfigured Docker daemons can be leveraged to access restricted files and escalate privileges. This guide walks you through mounting volumes, exploiting containers, and securing your system. A must-read for hackers and sysadmins alike!

Root Access Series: I see (docker) daemons.

Would you believe me if I told you that Docker could be a hacker’s best friend? Let me show you how to leverage Docker containers to access high-privilege files or execute commands as root.

Docker: Friend or Foe?

If you’re familiar with Docker, you know that processes inside each container are isolated from one another. However, they share the same system kernel as the host. And if you’re new to Docker—well, now you know the basics!

Let the Fun Begin!

Feel free to follow along and replicate the commands I’m about to show you. Let’s kick things off by running a sample Alpine container. We’ll keep it simple by putting it to sleep for a while:

docker run -d alpine sleep 1d

Now, let’s find that process and check which user is running it:

ps aux | grep sleep

Hmm… that’s odd.
The output shows the process is running as root, not oriana. But it must just be matching the container’s internal userid with the host system’s userid, right? Surely the process inside the container is running as a non-root user. That must be it!

Testing the Theory

To confirm this behavior, let’s try a different experiment. I’ll create a sensitive file on the host as root and restrict its permissions so that only root can read or modify it:

echo "secret" > /tmp/supersecret.txt 
chmod 0600 /tmp/supersecret.txt

We now have a supersecret file that only root can access. No other user should be able to read or modify it.

Next, we’ll log in as our low-privilege user Simba (yes, the same name as my mischievous cat!) and create a Docker container with /tmp mounted as a volume. Simba shouldn’t be able to open the secret file… right? Let’s try:

docker run -v /tmp:/tmp -it alpine sh

Inside the container, Simba attempts to access /tmp/supersecret.txt.

Wait, what?!

Simba can read the file. How is that possible? Is this some kind of sorcery?

The Truth Behind the Magic

Not magic—just Docker daemons running as root.

Docker daemons often run with root privileges on the host system. This means any user who can create Docker containers can potentially access or modify files they shouldn’t have permission to touch, as long as they can mount directories as volumes.

This could be a significant vulnerability on your system. If your Docker server isn’t properly configured, it might allow low-privileged users to exploit this flaw.

How do we fix this?

To mitigate this risk, you can adjust your Docker configurations:

  1. Enable User Namespace Remapping.
    Configure Docker to create userids and groupids outside the host system’s range (typically 0-1000) by editing /etc/docker/daemon.json:
{
  "userns-remap": "default"
}

This has some limitation, which you can read and learn more about on Docker’s official documentation. After enabling this, verify the changes by reviewing /etc/subuid.

Enabling this feature will delete all your current Docker images and containers because Docker must update the associated IDs.
  1. Configure Docker Daemon as Rootless.
    Alternatively, you can configure Docker to run as a rootless daemon. However, this approach has limitations and additional restrictions, so ensure you fully understand the implications before implementing it. For more details, refer to Docker’s official documentation here.

Conclusion

With great power comes great responsibility! As you’ve seen, Docker’s default settings can leave your systems vulnerable to privilege escalation attacks. Understanding and addressing these misconfigurations is crucial to keeping your environment secure.

If you enjoyed this post and want to follow Simba’s hacking adventures, be sure to check Part I and II and follow me on X and LinkedIn for updates on new articles in the Root Access Series

Happy Hacking!