Rootless Docker and Its Hidden Security Trade-Offs

Docker Rootless introduces a new approach to Docker security by running the daemon as an unprivileged user instead of the root user. This change aims to minimize the risk of a compromise causing root-level access on the host system. Rootless Docker achieves this by creating a user namespace, which allows the daemon to create necessary namespaces without needing root privileges.

However, this architecture introduces its own set of security trade-offs. While the unprivileged user cannot alter the UID mappings, the process still requires CAP_SYS_ADMIN and CAP_NET_ADMIN capabilities to function. These capabilities allow the unprivileged user to access kernel interfaces that were historically only available to trusted root processes.

The networking configuration API, mount system, and iptables (kernel's firewall rule engine) rule processing become accessible to any unprivileged user who creates a user namespace. This means that latent vulnerabilities in these code paths, such as buffer overflows or use-after-free errors, can now be exploited by any unprivileged user on the system. Additionally, changes made at this level can potentially affect the entire system.

Despite these risks, Docker Rootless remains an improvement over the previous root daemon model. It reduces the required privileges and moves them inside a user namespace, limiting the scope of access. However, it's crucial to understand that the user namespace itself comes with security implications. The kernel was designed with the assumption that only a fully trusted root process would access these interfaces, which may lead to less rigorous input validation and fewer safety checks.

In summary, Docker Rootless introduces an alternative to the root daemon model, but it's essential to recognize the trade-offs and potential security risks associated with this approach.