//THE ACADEMY IS GROWING DAILY. CHECK OUT THE FIELD NOTES FROM TECHS HERE AT THE ACADEMY
>_DAEMONCORE // ACADEMY
← FIELD NOTES

Container privilege escalation via Docker socket mounts and writable procfs

2026.10.11//12 MIN READcontainersprivilege-escalationpenetration-testingsecurity-architecture

// Overview

Docker containers run in a controlled environment, but misconfigurations can lead to significant security vulnerabilities. Two common attack vectors for privilege escalation in containers are mounting the Docker socket and manipulating the proc filesystem. When these are combined, the potential for escalation can be considerable. This piece will outline how you can exploit these mechanisms in a controlled environment and highlight defensive measures.

// Prerequisites

1. A Docker installation. 2. Access to a Docker container with the Docker socket mounted. 3. Basic Linux command line skills.

// Creating the Environment

Set up a test environment that mimics a vulnerable scenario. You’ll want a Docker container that has access to the host’s Docker socket. A common setup is to run a Docker container with the following command:

docker run -it --rm -v /var/run/docker.sock:/var/run/docker.sock --name test-container ubuntu:latest /bin/bash

This command does the following:

  • -it: Runs the container in interactive mode with a terminal attached.
  • --rm: Removes the container once it exits.
  • -v /var/run/docker.sock:/var/run/docker.sock: Mounts the host's Docker socket into the container, granting the container the ability to communicate with the Docker daemon on the host.

Once inside the container, you can check that the Docker socket is accessible:

ls -la /var/run/docker.sock

You should see permissions that indicate the socket is there and accessible.

// Understanding Procfs

Procfs (/proc) is a virtual filesystem that provides an interface to kernel data structures. It can be manipulated to inspect or modify the behavior of processes on the system. If the container has writable access to /proc, it can potentially be exploited.

To check the access to procfs from within your container, run:

mount | grep proc

If you see something like proc on /proc type proc (rw,...), you have writable access. If not, you might need to mount it as writable, which isn't common for secure setups but could happen in misconfigured environments.

// Escalation via Docker Socket and Procfs

With both the Docker socket and writable procfs, you can escalate privileges. Here’s how:

1. Create a New Container with Elevated Privileges Using the Docker socket, you can spawn a new Docker container with root privileges. Execute the following command from your vulnerable container:

   docker run -it --privileged --name escalated-container ubuntu:latest /bin/bash

The --privileged flag gives the container extended privileges, effectively removing isolation between the host and the container.

2. Access the Host Filesystem Once you have your elevated container running, you can mount the host filesystem. This can be done by adding a -v flag:

   docker run -it --privileged -v /:/mnt --name escalated-container ubuntu:latest /bin/bash

You now have access to all the files on the host system under /mnt.

3. Manipulate Procfs If you have writable access to /proc, you can modify process behavior. For instance, running:

   echo '0' > /proc/sys/kernel/cap_last_cap

This command can lower the effective capabilities of the kernel, which might be useful in specific privilege escalation techniques. Be cautious with such commands, as they can impact system stability.

// Common Mistakes

  • Not Checking Permissions: Always verify the permissions of the Docker socket and proc filesystem. If you don't have writing permissions where you expect, the escalation won't work.
  • Assuming Isolation: Containers are isolated environments, but with the proper mounts and permissions, they can act as if they are root on the host. Always evaluate what mounts are in use.

// Defensive Implications

Understanding these vectors is critical for building secure containerized applications. Here are some defensive strategies:

  • Restrict Docker Socket Access: Avoid mounting the Docker socket into containers unless absolutely necessary. If mounting is required, consider using specific user permissions to limit what the container can do.
  • Use User Namespaces: Enabling user namespaces can help mitigate risks by remapping user IDs and group IDs in the container to the host.
  • Implement Read-Only Filesystems: Where possible, run containers with read-only filesystems to limit the potential for modification.

// Summary Checklist

  • Verify Docker socket and procfs permissions.
  • Create a test container with socket access.
  • Attempt privilege escalation using the aforementioned methods.
  • Evaluate your environment for potential misconfigurations.

Test these techniques in a controlled laboratory environment and never against unauthorized systems. Understanding these vulnerabilities can help reinforce a more secure deployment.

--- // FIELDOPS REPORT AUTHORIZED BY: Theodore O. //