2.9. Recap

We saw how to run containers and how to secure them avoiding root, dropping capabilities, mounting filesystems read-only, and using Linux Security Modules such as seccomp. However it is important to say that because of the architecture of docker, anyone who can start a container has more privileges on the host.

It is still important to secure the Host Operating system and maybe to run a deamonless container technology like podname. What we did not touch are things like network security and monitoring. More on that in the Kubernetes Security lab.

Addendum: Most Common Container Escape Techniques

Well we learned alot about defense and saw some common attacks (runc vulnerabilities, kernel vulnerabilites, user mode helper (deprecated), kernel module insertion, docker sockets…). What else are common pattern?

SUID Privilege Escalation via Shared User Namespace

If your container is running as root, you have a host mount and usernamespaces are not enabled you could leverage this to create a suid binary like so:

docker run -it \
  --name tmp_bind_test \
  --mount type=bind,source=/tmp/mydata,target=/container/temp \
  ubuntu /bin/bash

Now inside the container you can do the following:

cp /usr/bin/sh /tmp/mydata/
chmod 0:0 tmp/mydata/sh
chmod 4755 /tmp/mydata/sh

You succesfully placed a root shell to /tmp which could be executed by a local user on the host.

Sensitive Host Mounts

Containers sometimes mount sensitive host directories (e.g., /etc, /root, /var/lib/docker).
Attackers can directly read or modify host files if these mounts are writable or misconfigured.
This is a misconfiguration-based escape rather than a vulnerability.

Final Thoughts

This was it for Container Security, you should have now the necessary knowledge to build & run containers and container infrastructure.

Now on to Kubernetes Security.