Securing Linux Containers: Docker and Beyond

Wylie Bayes

• 3 min read

The shift from monolithic virtual machines to microservices and containers has revolutionized software development. Containers are lightweight, start in milliseconds, and ensure that an application runs identically on a developer's laptop as it does in the production cloud.

However, this agility comes with a new set of security challenges. A common, dangerous misconception is that a container is a virtual machine, providing a secure, isolated boundary. It is not. Containers share the host operating system's kernel. If an attacker breaks out of a container, they have the potential to compromise the entire host node and every other container running on it.

In this post, we will explore the core concepts of Linux container security, focusing on Docker, and how to harden your deployments against container escape attacks.

The Threat: Container Escapes

To secure a container, you must understand how an attacker breaks out of one. Container escapes generally occur due to:

  1. Over-privileged Containers: Running a container with the --privileged flag gives the container almost all the capabilities of the host machine, including direct access to hardware devices. If an attacker gains a shell inside a privileged container, escaping to the host is trivial.
  2. Kernel Vulnerabilities: Because the container uses the host's kernel, an unpatched vulnerability in the host's Linux kernel (like Dirty COW) can be exploited from inside the container to escalate privileges and break out of the isolation.
  3. Exposed Docker Socket: The Docker daemon listens on a socket (usually /var/run/docker.sock). If this socket is mistakenly mounted inside a container, an attacker can use it to send commands directly to the host's Docker daemon, allowing them to spin up a new, fully privileged container to take over the host.

Hardening Strategy 1: Least Privilege and User Namespaces

The most fundamental rule of container security is: Never run your application as root.

By default, the process inside a Docker container runs as the root user. If an attacker exploits a vulnerability in your web app, they get a root shell.

  • Create a Non-Root User: Modify your Dockerfile to explicitly create a standard user and switch to it using the USER instruction before executing the application.
  • User Namespaces (userns): Enable user namespace remapping on the Docker daemon. This maps the root user inside the container to an unprivileged, high-numbered UID on the host. Even if an attacker breaks out as container-root, they will have zero privileges on the actual host OS.

Hardening Strategy 2: Drop Capabilities

Linux capabilities break down the all-powerful root privileges into smaller, distinct units. For example, CAP_CHOWN allows changing file ownership, and CAP_NET_BIND_SERVICE allows binding to ports below 1024.

By default, Docker drops many dangerous capabilities, but it still grants more than most applications need.
You should explicitly drop all capabilities and only add back the ones your application strictly requires:

docker run --cap-drop=ALL --cap-add=NET_BIND_SERVICE my-app

Hardening Strategy 3: Read-Only Filesystems

Attackers often need to drop malware, scripts, or configuration files onto the disk to establish persistence or execute an exploit.

You can thwart this by running the container's root filesystem as read-only. If the application legitimately needs to write data (like logs or temp files), you can mount specific, isolated tmpfs directories.

docker run --read-only --tmpfs /tmp my-app

Hardening Strategy 4: System Call Filtering (Seccomp and AppArmor)

If an attacker tries to execute a malicious binary or exploit a kernel flaw, they rely on System Calls (syscalls).

  • Seccomp (Secure Computing Mode): Docker applies a default seccomp profile that blocks around 44 dangerous syscalls. You can write custom, highly restrictive seccomp JSON profiles that only allow the specific syscalls your application uses, blocking everything else.
  • AppArmor / SELinux: These Mandatory Access Control (MAC) systems provide an additional layer of isolation, restricting what files, network ports, and resources a containerized process can access, even if it is running as root.

Hardening Strategy 5: Image Scanning and Supply Chain

The container is only as secure as the image it was built from. If you pull a base image from a public registry that contains a severely outdated version of OpenSSL, your container is vulnerable on day one.

  • Use Minimal Base Images: Avoid large base images like ubuntu or debian. Use minimal images like alpine, or even better, Distroless images from Google, which contain absolutely no package managers, shells, or standard Linux utilities, drastically reducing the attack surface.
  • Integrate Image Scanning: Integrate tools like Trivy, Clair, or Anchore into your CI/CD pipeline. These tools scan your Docker images for known CVEs before they are deployed to production.

Conclusion

Securing containers requires shifting your mindset from "endpoint protection" to "workload isolation." By stripping away root privileges, dropping capabilities, enforcing read-only filesystems, and scanning your images, you can safely harness the power of containers without exposing your host infrastructure to devastating escape attacks.