risks and safety measures
Gainullina Ekaterina, information security engineer, Security Vision development department
Introduction
Docker containers have long been an integral part of modern IT infrastructures due to their lightness and flexibility. However, despite all their advantages, they also have serious security drawbacks. One of these drawbacks is the lack of reliable isolation between the host and the container. Security Vision, understanding the critical importance of protecting container environments, implements strict security measures to minimize risks. Comprehensive measures allow Security Vision to effectively protect container environments, providing a high level of security for its customers and minimizing potential risks.
Imagine a container with root access. It’s like having a door with a lock, but the key to it would fit all the locks in the house. Attackers who gain access to such a container can easily access the host system’s resources. Using privileged containers gives them full access to the system, allowing them to bypass many security mechanisms. This opens up a huge opportunity for attackers, allowing them to do things that previously seemed impossible.
Exploiting Docker Socket for Privilege Escalation: A Detailed Overview
The attacker gains access to the Docker Socket (/var/run/docker.sock). This socket is an interface for managing the Docker API, which allows them to perform various operations on Docker containers and images. It’s like giving them a remote control with which they can start and stop containers, change their configurations, and even run containers with root access. This access allows attackers to take control of the entire system, including the ability to execute arbitrary code on the host. By using the ability to mount the host filesystem into the container with the -v /:/host option, the attacker gains access to host files and directories directly from the container. This is an important step for examining and manipulating files that may contain sensitive information or data, including /etc/shadow for privilege escalation.
Next, various options and flags are used to remove the restrictions imposed on containers:
–privileged: This flag removes all isolation measures and restrictions, giving the container full access to the host system. This is a very dangerous practice, as the container loses all the isolation and security benefits provided by Docker.
–cap-add=ALL: Add all Linux capabilities to the container, which may allow an attacker to perform privileged operations.
–security-opt apparmor=unconfined and –security-opt seccomp=unconfined: Disables the AppArmor and Seccomp security profiles for the container, reducing the level of protection provided by Docker. Attackers often try to access the host filesystem by mounting disk devices directly into the container. For example, the –device=/dev/sda1 –cap-add=SYS_ADMIN –security-opt apparmor=unconfined combination can mount a specific disk device into the container. The attacker can then use the mount /dev/sda1 /mnt command in the container to access the host disk contents via the /mnt mount point.
Attackers often find writable directories on the host that can be mounted into the container. For example, -v /tmp:/host can be used to mount the host's /tmp directory into the container. The attacker can then create an SUID executable in the mounted directory, allowing the attacker to execute it with elevated privileges on the host. If root privileges are obtained in the container, the attacker can modify host system configuration files, such as /etc, which can lead to serious privilege escalation on the host. For example, modifying /etc/shadow can open access to host system user accounts. To escape from the container, attackers use the –privileged flag or add the appropriate capabilities while disabling other security measures. This allows the attacker to break out of the container's isolation and gain full access to the host system.
OWASP's Quick Guide to Docker Security
Update host and Docker
To protect against known vulnerabilities such as “Leaky Vessels”, which typically allow an attacker to gain root access to a host, it is critical to regularly update both the host itself and Docker. This includes regularly updating the host kernel and the Docker engine.
Don't expose Docker daemon socket
The Docker socket /var/run/docker.sock is a UNIX socket that Docker subscribes to and through which the Docker API is available. This socket is owned by root. Granting access to it is equivalent to granting unrestricted root access to your host. If you run your Docker image with -v /var/run/docker.sock:/var/run/docker.sock or similar, you should change this. Remember that mounting a socket as read-only is not a solution, it just makes it more difficult to exploit. An equivalent declaration in a docker-compose file might look like this:
volumes:
- "/var/run/docker.sock:/var/run/docker.sock"
Set user
Configuring a container for use by an unprivileged user is the best way to prevent privilege escalation attacks. In Kubernetes, this can be configured in the security context using the runAsUser field with the user ID, like this:
apiVersion: v1
kind: Pod
metadata:
name: example
spec:
containers:
- name: example
image: gcr.io/google-samples/node-hello:1.0
securityContext:
runAsUser: 4000 # <-- This is the user ID of the pod
As a Kubernetes cluster administrator, you can set up a hardened configuration using the Restricted level with the built-in Pod Security Admission Controller, and if more customization is required, consider using Admission Webhooks or alternative third-party solutions.
Limit your options
Limit container privileges to only provide the capabilities needed.
Don't run containers with the –privileged flag!!! In Kubernetes, this can be configured in the security context using the capabilities field, for example:
apiVersion: v1
kind: Pod
metadata:
name: example
spec:
containers:
- name: example
image: gcr.io/google-samples/node-hello:1.0
securityContext:
capabilities:
drop:
- ALL
add: ["CHOWN"]
Prevent privilege escalation inside a container Run your Docker images with the –security-opt=no-new-privileges flag to prevent privilege escalation.
In Kubernetes, this can be configured in the security context using the allow privilege escalation field, for example:
apiVersion: v1
kind: Pod
metadata:
name: example
spec:
containers:
- name: example
image: gcr.io/google-samples/node-hello:1.0
securityContext:
allowPrivilegeEscalation: false
Limit resources (memory, CPU, file descriptors, processes, restarts) The best way to avoid DoS attacks is to limit resources.
Set the file system and volumes to read-only mode
Run containers with filesystem in read-only mode.
Integrate container scanning tools into your CI/CD pipeline
CI/CD pipelines are an important part of the software development lifecycle and should include various security checks such as container scanning.
Conclusion
Access control over the Docker Socket is critical, as it can become a tool in the hands of attackers. Security Vision strictly limits access to it, preventing unauthorized management of containers and hosts. Running containers as unprivileged users helps minimize the risk of privilege escalation. To prevent DoS attacks, container resources such as memory and CPU are limited. Containers are launched with the file system in read-only mode, which limits the ability of attackers to modify data. Security Vision integrates container scanning tools into its CI/CD pipelines, ensuring security at all stages of development. These measures allow Security Vision to effectively protect container environments, minimizing risks and providing a high level of security for its customers.
