Docker's Role in Simplifying Deployments

With Docker, operations teams can deploy applications and websites effortlessly without needing to concern themselves with dependencies, configuration settings, or package versions on the server. Its ease of use—simply pulling an image from the registry and running it with a command (docker run)—often leads us to overlook the necessity of robust security measures, similar to any other critical component.

Previously, we published articles detailing Docker security best practices, which you can find here and here. In this post, we will delve into more advanced Docker security concepts that will be invaluable for those managing multiple containers and seeking to prevent privilege escalation.

Nologin Shell

Your Docker container can support multiple user accounts. The root account holds the highest privileges; thus, if a malicious user gains root access, they can execute root commands and perform extensive actions within the container. To mitigate the risk of unauthorized privilege escalation, even if the user has the root password, you can configure the shell to nologin. Alternatively, employing restricted shells is also a viable option. To disable root login within the container, modify your Dockerfile to include the following line:

RUN chsh -s /usr/bin/nologin root

Using nologin shells denies login access to an account, ensuring that even if a malicious actor acquires the root account credentials, they cannot log in since access is blocked by the nologin file.

Preventing Privilege Escalation with SUID

Before discussing mitigation techniques, it's important to understand SUID (Set Owner User ID upon execution). This special file permission can be assigned to executables, allowing them to run with the privileges of the file owner (often root). Should a root user grant SUID permission to an executable, it can be exploited for privilege escalation. Setting a SUID bit is as simple as typing:

chmod +x <binary_name>

Such vulnerabilities are often exploited to escalate privileges within Docker containers. To prevent this, you can use the security option — --security-opt="no-new-privileges" when launching your Docker container. This option ensures that processes and their child processes do not gain additional privileges through SUID or SGID bits.

For instance:

docker run -it <image_id> --security-opt="no-new-privileges" /bin/bash

Note: To find your container's image ID, simply run docker image ls.

Create a Read-Only File System

Implementing a read-only file system prevents users from creating files within the system. This measure protects against downloading and installing malicious software, which could lead to threats like malware or backdoor shells. Therefore, safeguarding Docker from unauthorized access by establishing a read-only file system is essential.

To create a read-only file system, use the following command:

docker run --read-only -it <image_id> /bin/bash

While a container without write permissions may pose some challenges for users, you can configure a temporary file system. For example, you can designate your /opt directory as a temporary file system, allowing users to download files only within this specified directory:

docker run --read-only --tmpfs /opt -it <image_id> /bin/bash

Preventing Inter-Container Communication

In a production environment, it's common to deploy multiple containers, each serving distinct purposes. For instance, you might run MongoDB in one container while hosting an application in another. However, inter-container communication can pose significant security risks. Consider a scenario where a Docker container hosts a vulnerable application exposed via a port. An attacker within another container could potentially compromise the application's security.

To mitigate this risk, inter-container communication should be disabled unless necessary. Start by reviewing the default networks provided by Docker:

docker network ls

Next, inspect the bridge network type:

docker network inspect bridge

You'll find that com.docker.network.bridge.enable-icc is set to true. This configuration allows multiple devices and containers to communicate over the bridge connection. To prevent inter-container communication, create a new network and set this option to false:

docker network create --driver bridge -o "com.docker.network.bridge.enable-icc":"false" testnet1

After establishing the network, you can run a Docker container within this isolated network:

docker run -it --network testnet1 <image_id> /bin/bash

Note: To determine your container's image ID, run docker image ls.