Container CAP_NET_ADMIN Host Access

TL;DR

Yes, a container with CAP_NET_ADMIN capability can access and modify the host network namespace. This is powerful but dangerous – it effectively gives the container root-like control over the host’s networking. You should avoid granting this capability unless absolutely necessary and understand the security implications.

Understanding CAP_NET_ADMIN

CAP_NET_ADMIN allows a process to perform network administration tasks, such as configuring interfaces, routing tables, firewall rules, and more. Within a container, this normally applies only to the container’s own network namespace. However, when combined with techniques like unprivileged namespaces or specific Docker/containerd configurations, it can be used to escape into the host’s network.

How a Container Can Access the Host Namespace

1. Unprivileged Namespaces: If the container is running in an unprivileged namespace (e.g., using --net=host or similar configurations), it directly shares the host’s network namespace. In this case, CAP_NET_ADMIN within the container *will* affect the host’s networking.

   docker run --net=host -it ubuntu bash

2. Network Namespace Injection: More complex setups involve injecting a specific network namespace into the container. This is less common but allows for targeted access to particular host networks.
3. Exploiting Container Runtime Vulnerabilities: In rare cases, vulnerabilities in the container runtime (Docker, containerd, etc.) could allow a container with CAP_NET_ADMIN to escape its network isolation and manipulate the host’s networking. This is why keeping your container runtime up-to-date is crucial.

Steps to Demonstrate Host Network Access (with caution!)

WARNING: The following steps are for demonstration purposes only. Executing these commands can compromise the security of your host system. Perform them in a controlled environment, such as a virtual machine.

1. Start a Container with CAP_NET_ADMIN and Host Network Mode: This is the simplest way to demonstrate access.

   docker run --cap-add=NET_ADMIN --net=host -it ubuntu bash

2. Verify Access Inside the Container: Once inside the container, try modifying a host network interface. For example, you can list all interfaces:

   ip addr show

   You should see the host’s network interfaces listed.

3. Attempt to Modify Host Routing Table (Example): Add a temporary route on the host (again, be careful!):

   ip route add 192.168.50.0/24 via 192.168.1.1 dev eth0

   (Replace interface names and IPs with your actual host network configuration.)

4. Verify the Change on the Host: Exit the container and check the host’s routing table:

   ip route show

   You should see the route you added from within the container.

Mitigation Strategies

• Avoid CAP_NET_ADMIN: The best approach is to avoid granting this capability unless absolutely necessary. Carefully consider if there are alternative solutions that don’t require network administration privileges.
• Use Least Privilege: If you must grant network capabilities, only grant the specific capabilities required and nothing more.
• Keep Container Runtime Updated: Regularly update your container runtime (Docker, containerd) to patch security vulnerabilities.
• Network Policies: Implement network policies to restrict communication between containers and the host network. This can limit the impact of a compromised container.
• Seccomp Profiles: Use seccomp profiles to further restrict the system calls that a container can make, reducing the attack surface.