312-50 Question 436
Single answer▪ Container TechnologyDuring an authorized assessment of a Linux host running Docker, you discover a web application container started with the Docker socket mounted from the host as /var/run/docker.sock. The container runs as root, and you have command execution inside the container. The client wants to understand the most serious security implication of this configuration. Which action would BEST demonstrate the primary risk?
- A
Use the mounted Docker socket to start a new privileged container with the host filesystem mounted, then access files on the host
- B
Modify the container's EXPOSE directive to publish additional host ports and intercept other containers' traffic
- C
Use the mounted Docker socket to dump the image layer history, which only reveals application source code but not host impact
- D
Restart the current container in --network=host mode without interacting with the Docker daemon
Show answer and explanation
Correct answer: A
Explanation
In Docker environments, access to /var/run/docker.sock is widely recognized as highly sensitive because the socket exposes the Docker API. A container that can talk to this socket can often perform the same actions as a user who can run Docker commands on the host. In practice, that means creating containers, setting bind mounts, enabling privileged mode, joining host namespaces, and accessing host resources. From an ethical hacking perspective, the strongest demonstration of impact is to show that socket access can be translated into host compromise, for example by launching a privileged container with the host root filesystem mounted.
This aligns with Docker security guidance and common hardening best practices: do not mount the Docker socket into untrusted containers, avoid running containers as root where possible, minimize capabilities, and use least privilege. Docker documentation on bind mounts, the Docker daemon socket, and privileged containers supports why this configuration is dangerous. The scenario tests whether the candidate understands container escape paths caused by management-plane exposure, not just application-layer weaknesses.
- A. Correct.
Correct. Mounting /var/run/docker.sock into a container effectively grants that container control over the Docker daemon on the host. If the process in the container can communicate with the socket, it can ask the daemon to create new containers with dangerous settings such as --privileged and bind mounts like /:/host. That can lead to direct access to the host filesystem and practical host compromise. This is one of the most serious risks of exposing the Docker socket to a container.
- B. Incorrect.
Incorrect. EXPOSE is image metadata and does not itself publish ports or reroute traffic on the host. Port publishing is controlled at container runtime, and changing EXPOSE from inside a running container would not demonstrate the primary impact of having access to the Docker socket. The bigger risk is daemon-level control that can be leveraged for host access.
- C. Incorrect.
Incorrect. Image history and layers may reveal sensitive information such as embedded secrets or build steps, but the statement that it only reveals application source code and not host impact is misleading. More importantly, this is not the primary risk in this scenario. Control of the Docker socket can be escalated to host-level actions, which is much more severe than simply inspecting image metadata.
- D. Incorrect.
Incorrect. A process inside the container cannot simply restart its own container with different runtime flags unless it already has a way to control the Docker daemon or host runtime. The key issue here is the mounted Docker socket itself. Without using the daemon interface, the container cannot directly reconfigure its runtime isolation settings.