Podman with capabilities on Fedora

Containerization is a booming technology. As many as seventy-five percent of global organizations could be running some type of containerization technology in the near future. Since widely used technologies are more likely to be targeted by hackers, securing containers is especially important. This article will demonstrate how POSIX capabilities are used to secure Podman containers. Podman is the default container management tool in RHEL8.

Determine the Podman container’s privilege mode

Containers run in either privileged or unprivileged mode. In privileged mode, the container uid 0 is mapped to the host’s uid 0. For some use cases, unprivileged containers lack sufficient access to the resources of the host machine. Technologies and techniques including Mandatory Access Control (apparmor, SELinux), seccomp filters, dropping of capabilities, and namespaces help to secure containers regardless of their mode of operation.

To determine the privilege mode from outside the container:

$ podman inspect --format="{{.HostConfig.Privileged}}" <container id>

If the above command returns true then the container is running in privileged mode. If it returns false then the container is running in unprivileged mode.

To determine the privilege mode from inside the container:

$ ip link add dummy0 type dummy

If this command allows you to create an interface then you are running a privileged container. Otherwise you are running an unprivileged container.

Capabilities

Namespaces isolate a container’s processes from arbitrary access to the resources of its host and from access to the resources of other containers running on the same host. Processes within privileged containers, however, might still be able to do things like alter the IP routing table, trace arbitrary processes, and load kernel modules. Capabilities allow one to apply finer-grained restrictions on what resources the processes within a container can access or alter; even when the container is running in privileged mode. Capabilities also allow one to assign privileges to an unprivileged container that it would not otherwise have.

For example, to add the NET_ADMIN capability to an unprivileged container so that a network interface can be created inside of the container, you would run podman with parameters similar to the following:

[root@vm1 ~]# podman run -it --cap-add=NET_ADMIN centos
[root@b27fea33ccf1 /]# ip link add dummy0 type dummy
[root@b27fea33ccf1 /]# ip link

The above commands demonstrate a dummy0 interface being created in an unprivileged container. Without the NET_ADMIN capability, an unprivileged container would not be able to create an interface. The above commands demonstrate how to grant a capability to an unprivileged container.

Currently, there are about 39 capabilities that can be granted or denied. Privileged containers are granted many capabilities by default. It is advisable to drop unneeded capabilities from privileged containers to make them more secure.

To drop all capabilities from a container:

$ podman run -it -d --name mycontainer --cap-drop=all centos

To list a container’s capabilities:

$ podman exec -it 48f11d9fa512 capsh --print

The above command should show that no capabilities are granted to the container.

Refer to the capabilities man page for a complete list of capabilities:

$ man capabilities

Use the capsh command to list the capabilities you currently possess:

$ capsh --print

As another example, the below command demonstrates dropping the NET_RAW capability from a container. Without the NET_RAW capability, servers on the internet cannot be pinged from within the container.

$ podman run -it --name mycontainer1 --cap-drop=net_raw centos
>>> ping google.com (will output error, operation not permitted)

As a final example, if your container were to only need the SETUID and SETGID capabilities, you could achieve such a permission set by dropping all capabilities and then re-adding only those two.

$ podman run -d --cap-drop=all --cap-add=setuid --cap-add=setgid fedora sleep 5 > /dev/null; pscap | grep sleep

The pscap command shown above should show the capabilities that have been granted to the container.

I hope you enjoyed this brief exploration of how capabilities are used to secure Podman containers.

Thank You!

FAQs and Guides For System Administrators

13 Comments

  1. Thanks, finally switching from docker to podman everywhere on Fedora to reduce privilege whenever possible, so this handy guide is extremely timely.

  2. Pavan Wankhade

    Nice, Helpful tricks are included.

  3. Joe

    Thanks for that! A lot of good commands.

    I also spent some time playing with getting a LAMP stack running in across 3 Podman containers. The SELinux and network setup threw me a bit, but got it working. Details below in case it’s helpful for anyone else.

    https://opensourcetechtrn.blogspot.com/2020/08/yet-another-lamp-stack-build-podman.html

  4. Lakshya Tyagi

    This article is very helpful

  5. heiko

    Podman is really a great approch. Unfortunately I still don’t find a working CUDA intergration for GPU and have still to use Docker

  6. laolux

    Great article. Setting capabilities in podman seems to be straight forward. However, I have trouble finding out which capabilities are actually needed. For example, when I want to run a postgres container which is only available in the same pod, then what capabilities are required to run and which are safe to drop?

    • I believe that capabilities are more for the level of isolation between the host and the container. The infra container of the pod you want to run a postgres container in should be where the capabilities are set I would think. The containers in the pod would then only have the capabilities of the infra container. If you go to Opensource.com and search there is some article on this topic.

      • laolux

        Thanks for pointing me to opensource.com, where I have found some info related to SELinux, but capabilities with podman are quite scarce.
        About trying to set the capabilities of an entire pod: podman pod create does not allow for capabilities to be set. And it works perfectly fine to set the capabilities of the containers added to a pod. They can even have different capabilities.
        However, all of this does not solve my underlying problem of finding out which capabilities are required by a container during normal operation.

  7. Ondrej

    Podman is so nice. I really love it. The way it integrates with systemd + auto-updates, it makes it very simple to create an deployment well integrated in one infra container.

    I just really love it!

  8. William Whinn

    Great stuff, thank you! I use toolbox more for bootstrapping an R/RStudio and C/C++ development environment but it has made me interested in containers as a technology. This’ll make a great first step in digging a bit deeper into the technology I take for granted everyday.

Comments are Closed

The opinions expressed on this website are those of each author, not of the author's employer or of Red Hat. Fedora Magazine aspires to publish all content under a Creative Commons license but may not be able to do so in all cases. You are responsible for ensuring that you have the necessary permission to reuse any work on this site. The Fedora logo is a trademark of Red Hat, Inc. Terms and Conditions