Docker Escalation Privileges and Remediation

This isn't exactly the post I planned on writing to break my writers block, but it's the one I needed.

I was listening to the podcast Linux Unplugged episode #395 and they had a little hacker challenge to see who could get root access with a non privileged user the quickest. The winning method was someone who realized the user had misconfigured access to run docker ps -a and mount / into a container to do gain the access to make the changes needed to complete the challenge.

Listening to this, I realized I'm just as guilty at configuring my docker access the same way. So I wanted to test the escalation method and play with the different methods to secure access to the docker socket (other than switching to Podman). The conventional recommendation to give access to docker is to give them access to the docker group that gets created with Docker's installation. This should really only be done with users who already have access to sudo and understand the risks that this entails. My team at work is guilty of giving access to the docker group on our sandbox server instead of using a proper method.

To prepare for this, lets set the scene:

There's a server inside a company that runs their company website using nginx and php in docker. There's a developer named Jeff who has an account on that server, but he has made the cardinal sin... His password is password. Jeff was granted access to the folder /data/website as well as the docker group to manage the website. His personal machine was compromised and a bad actor has used the bad password to gain access to the server.

The sysadmin for the server has also left a bunch of corporate passwords in a place they feel is safe, /root, but was smart enought to make sure the file was only available to the root user and nobody else.

Each of the examples will be done and shown on both debian and rhel based systems unless otherwise specified.

Lets go from easiest to less easy for things the bad actor can do with jeff's docker access. Lets steal the corporate passwords.

The bad actor got a tad lucky when mounting root and finding those passwords. They could have easily just mounted / and found that file sitting in /root.

This behavior is exactly what is expected when you create a container and mount a path. Docker has access to SUID, which grants any container with a mounted folder to read any file.

Gaining access to the system and mucking around isn't much more difficult, but depending on your server's base OS, the behavior is different.

By using chroot on the container you're able to get a root shell into the host system. Interestingly enough (was not aware of this prior to testing) the network stack isn't properly setup in the chroot shell so depending on things that are cached you may be able to install a package. Though That probably won't really stop someone trying to compromise your system.

But unfortunately that's not all someone can do with that chroot session. With it, they'd be able to create themselves new users, or even change the root password to give themselves easier access to the system.

See? jeff really didn't have permission.

Using the docker group, you are given an extremely wide berth to do nefarious things if you know what you are doing. But leveraging docker doesn't have to be all doom and gloom. There are ways to make modifications to your processs instead of just accepting this is the only way to do it.

For this next bit, we're only going to use our RHEL based system. We're going to remove jeff's access to the docker group and setup  ACL rules for him to interact with the docker socket. Unfortunately, this still has the privilege escalation problem and would allow you to much around with the system.

Depending on you're use case, which should always be taken into account when deciding access to tools, you may want to leave docker only available to root and then breaks the ability to user the docker group. This will require people to either be in the sudoers group (either passwordless or regular) to be able to interact with the docker socket. With this restriction, you can also then give specialized access with scripts to specific commands for people like jeff to be able to still work.

Docker now does have the option to run as rootless, but it's a bit more involved to get up and running. The next time you visit, I'll show how you can migrate your workflow from Docker to Podman, including using docker-compose.