Docker vs Podman: a Hacker’s perspective

Docker vs Podman: A Hacker's Perspective

When container technology comes to mind, Docker is often the first name we think of. It's the powerhouse that popularized containerization and fueled the rise of DevOps. But recently, a new contender, Podman, has entered the ring, touting itself as the more secure alternative. For hackers, developers, and sysadmins, it raises an important question: which one is truly better?

Docker Recap

Docker brought container technology into the mainstream, simplifying the concept of lightweight, portable environments that "just work." It's a set of platforms as a service (PaaS) that uses OS-level virtualization to deliver software in packages called containers. Docker uses a client-server model, where the docker client interacts with a daemon called dockerd to build, run, and manage containers.

Podman: The Secure Newcomer

Podman is an open-source container engine developed by Red Hat, designed to manage and run containers without the need for a central daemon. Unlike Docker, which uses a client-server model with a root-running daemon, Podman operates in a daemonless mode and can run containers rootlessly, meaning users don’t need elevated privileges. The name "Podman" comes from its ability to manage pods, which are groups of one or more containers sharing resources, similar to Kubernetes pods. This allows Podman to integrate well with Kubernetes and simplify container orchestration.

Podman’s core design focuses heavily on security by addressing Docker's inherent vulnerabilities related to root access and reducing attack surfaces associated with centralized daemons.

Key Differences: Docker vs Podman

• Daemon Architecture: Docker relies heavily on its daemon, which runs as root. If an attacker compromises the Docker daemon, they essentially gain root privileges over the entire system. Podman, on the other hand, doesn't require a central daemon. Instead, each container is run as a child process of the user, reducing the risk of privilege escalation.
• Rootless Containers: Podman runs containers in rootless mode by default, ensuring that users don’t need elevated privileges. Docker can also run in rootless mode, but it’s more of an add-on feature rather than an inherent part of its design. Rootless containers reduce the attack surface significantly and add an extra layer of security.

Exploiting Docker vs Podman: A Hacker's Playground

Exposed Docker Socket: The Achilles' Heel

The Docker socket (/var/run/docker.sock) is often exposed to the host system. By accessing this socket, an attacker can interact directly with the Docker daemon, execute arbitrary commands, and potentially get root access to the host. This is one of Docker's biggest security flaws since Docker runs as root, making it a prime target for lateral movement and privilege escalation attacks.

Imagine a scenario where a misconfigured container is running with access to the Docker socket. A malicious user inside that container can easily access the host and run commands as root, leading to a full system compromise.

Another example of exploitation involves CI/CD pipelines that mount the Docker socket to containers. In such setups, if an attacker gains access to a container used in the pipeline, they can interact with the Docker daemon directly, effectively compromising the entire pipeline infrastructure. Attackers can create new containers, manipulate existing ones, or even tamper with build processes, leading to a severe breach of the software supply chain.

In cloud environments, compromised containers with Docker socket access can be used to launch attacks across multiple hosts. Attackers can use the socket to perform lateral movement, creating privileged containers on other nodes within the cluster, further increasing the scope of the attack. This makes exposed Docker sockets a significant weakness in both single-host and multi-host deployments.

In the example below I am running two python http servers, one using docker and one using podman

Podman's Safety Net: Eliminating the Docker Sock

Podman doesn't have a single, centralized daemon that requires privileged access, meaning there is no equivalent to /var/run/docker.sock. This eliminates the common attack vector of compromising the host through a single socket.

That said, Podman isn’t impervious. If an attacker gains access to a privileged container, there are still ways they can wreak havoc, but with Podman, it requires more deliberate misconfiguration, and the damage is much more contained because it is rootless by design.

Docker Containers Running as Root: The RCE Threat

Another major vulnerability with Docker is that, by default, containers often run as the root user. This creates opportunities for Remote Code Execution (RCE) if the container has a vulnerability, making it easy for attackers to escalate privileges from the container to the host.

For instance, consider an outdated web application running inside a Docker container. If an attacker finds an RCE vulnerability, they can execute commands as root and potentially take over the host due to Docker's design. Since Docker has elevated privileges, the host system is directly in jeopardy.

Another common scenario involves poorly configured Dockerfiles or container images that inadvertently allow root access. If an attacker exploits a vulnerability, they can execute commands that impact the entire host environment. Attackers may install malicious software, extract sensitive data, or use the compromised container as a launching point for further attacks.

Attackers may also exploit containers that run with overly permissive capabilities or privileges, such as --privileged mode, which grants almost full access to the host. This configuration makes it easier for attackers to break out of the container and compromise the underlying host system.

In environments where multiple services are containerized using Docker, an RCE exploit in one container can provide an attacker with an entry point to compromise other services running on the same host. This lateral movement is especially dangerous when containers have network connectivity or shared volumes.

Podman's Approach: Default User Privilege

Podman reduces the risk by defaulting to a non-root user when creating containers. Even if a container is compromised, the attacker is less likely to gain significant access to the host. Running rootless by default means that even with an RCE vulnerability, the attacker’s capabilities are limited to the container, minimizing risk to the host system.

Showing root programs vs rootless

In the example below, I’m running a Python HTTP server in both Docker and Podman.

The Python server running in Docker is running as root, while the same server is running as the host user instead.

Demonstrating exploiting Docker vs Podman

Here is an example Python Flask app that demonstrates an RCE vulnerability and how it can be exploited when running with Docker or Podman:

Flask App Code (vulnerable_flask_app.py)

This is a Flask web application that accepts user input through a form and directly executes it as a system command using os.popen(). It's vulnerable because it performs no input validation or sanitization, allowing an attacker to execute arbitrary system commands.

Dockerfile

Building and Running the App in Docker and Podman

Running with Docker and Expose Docker Socket

What Happens with Docker Running as Root

By default, Docker containers run as the root user. If a container has an RCE vulnerability and the container itself is running as root, it can lead to serious consequences because the attacker can execute privileged operations within the container and eventually break out to the host system.

Let's extend the previous Python Flask app example to demonstrate how an attacker could escalate the attack without having direct access to the Docker socket.

This is how the web app appears after loading it up and executing commands in the container using RCE.

Now the juicy part

With these commands, we can download the Docker binary and run Docker commands in the container itself, just with the Flask app.

Now doing the same with podman

The application, despite its vulnerability, prevents the execution of privileged commands.

Preventative Measures with Podman or Docker (Rootless Mode)

• Use Podman in Rootless Mode: Podman containers run as the same user as the host (non-root by default). Even if RCE occurs, the attacker is limited by the privileges of that user and cannot perform operations that require root access.
• Run Docker with -user Option: When using Docker, always specify a non-root user for your container to reduce the damage an attacker can do:

  This ensures that, even with RCE, the attacker’s access is significantly restricted.

Threat Models and Attack Vectors: A Comparison

Developer Experience and Kubernetes with Podman

Docker has long been a favorite for developers, mainly because of its mature tooling and widespread adoption. Podman, however, is gaining traction for its Kubernetes integration. Podman can generate Kubernetes YAML manifests natively using podman generate kube, which simplifies deploying containers to a Kubernetes cluster. This built-in functionality makes Podman a powerful ally for developers looking to build Kubernetes-native solutions.

Podman also allows for easy orchestration with pods, which are similar to how Kubernetes organizes its containers. This makes transitioning from local development to production Kubernetes deployments smoother and more intuitive.

Drawbacks of Podman

While Podman provides a more secure container experience, it's not without its drawbacks. For instance, the lack of a central daemon means that managing multiple containers can sometimes feel a bit cumbersome compared to Docker. Docker's ecosystem of tools, such as Docker Compose, is still ahead in terms of developer convenience and community support.

Moreover, some developers might find Podman’s commands less intuitive since Docker has set the de facto standard. Migrating from Docker to Podman can involve a learning curve, and some Docker-specific tooling may not have direct Podman equivalents yet.

Conclusion: A Hacker's Takeaway

From a hacker's perspective, Docker's reliance on root privileges and its daemon architecture create opportunities for exploitation, making it a lucrative target. Podman takes a different approach, focusing on rootless containers and eliminating the single point of failure that Docker's daemon represents.

That said, no container solution is perfectly secure. Misconfigurations, particularly with privileged containers, can still lead to breaches. But Podman mitigates some of the key weaknesses of Docker, making it a more robust option for those concerned with security, especially in environments like Kubernetes.

For developers, the move to Podman means greater security at the cost of a slightly different workflow. While Docker remains more polished in terms of developer experience, Podman is quickly closing the gap—and doing so with security at the forefront.

Final Thoughts

The container ecosystem is evolving, and with it, our approach to security must evolve as well. Podman offers a compelling alternative to Docker, particularly in environments where reducing the attack surface is a priority. While it may not be perfect, it’s undoubtedly a step in the right direction for securing containerized applications.

If you're a developer or security engineer, it's worth considering making the switch to Podman—not just to protect your infrastructure, but to sleep a little better at night, knowing you've eliminated some of the most common attack vectors that make Docker a hacker's playground.