Container capabilities: the basics

Hacking into a container with default capabilities

How do Container and Docker Capabilities work?

A container is a process with special permissions

A container is in essence just a process that runs on the host system. The permissions the container/process receives from the host system depend on how the container was launched. In Linux there are many ways to give processes permissions. In the explanation we'll first go through the basics of file permissions and how they were extended with the concept of Linux Capabilities. From there we'll learn how we can read/set capabilities to improve security. Finally we explain how containers get launched with a default set of capabilities to give us permission to do things inside of a container.

The basics of giving permissions - setUID/setGUID

In security a big part of the job is allowing the right people access certain things while denying others.

Chances are that you've come across using the command chmod to set the permission of files and directories. For example chmod 775 somedir gives the owner and the group permission to read/write/enter the directory somedir and others only read and enter permissions. A bit more human friendly equivalent of the command would be chmod u+rwx,g+rwx,o+rx somedir basically translating these numbers into user friendly mnemonics.

mkdir somedir
chmod 775 somedir
ls -l
drwxrwxr-x 2 patrick staff 64 Sep 7 13:11 somedir/

As part of file permission options there is also the setUID (+s) or setGUID flag (+S) which allows users to become a certain user/group when they run a file. This comes in handy for a command like ping : on Linux , to send special ping packets (ICMP) it needs the root privilege (to open a NET_RAW socket) Older Linux systems therefore used the setUID flag to make the ping command run as root.

ls -l /sbin/ping
-r-sr-xr-x 1 root wheel 55344 Sep 22 2020 /sbin/ping

But ... that's a whole lot of privileges for just sending a ping! There must be a better way. That's why Linux capabilities were invented.

From setUID to capabilities

Starting with kernel 2.2, Linux divides the privileges traditionally associated with superuser into distinct units, known as capabilities, which can be independently enabled and disabled. To control the capabilities of processes and files we have a couple of useful commands. You get them as part of the libcap2-bin package (or similar to your OS).

  • capsh: cli to manage capabilities in a human friendly way
  • getcap: get the capabilities of a file
  • setcap: set the capabilities of a file

Exploring linux capabilities

To see the capabilities of your current shell process we can access the status of it.

We can find the capabilities of the current process.

Copy and paste the following into the terminal and hit enter:

grep Cap /proc/$BASHPID/status

This will give us a list of capabilities, but they aren't in an easy readable form.

Let's see how we can convert the capability number 000001ffffffffff. capsh to the rescue! We can ask it to decode these capabilities.

Copy and paste the following into the terminal and hit enter:

capsh --decode=000001ffffffffff

It will show a long list of capabilities. Each of these capabilities represent a specific set of permissions we have. For example cap_kill allows us to kill processes or cap_mknod allows us to create special devices.

Instead of decoding these capabilities one by one, we can use the command capsh --print to decode all capabilities at once.

Demo terminal

Ping capabilities - the right way

Now let's revisit our ping example, on modern versions of Linux the ping command does not have the setUID flag anymore but is given the cap_net_raw capability. This is much safer than giving the command complete root access. We can verify these capabilities using the getcap command: getcap /usr/bin/ping reports that ping now has the right privileges (= capability) and is much safer than the setUID root approach.

Copy and paste the following into the terminal and hit enter:

getcap /usr/bin/ping

Demo terminal

Default container capabilities

To relate this to containers, we must first understand how process permission delegation works.

On Linux, process ID 1 (INIT) has all the privileges after booting. After that, privileges are delegated and possibly restricted. The container system is no different, a container is nothing but a process with a set of given privileges delegated by the container system. Obviously, we want containers to only have a set of restricted permissions and in the following snippet of the Docker daemon source code you can see that it starts a container with a default set of capabilities.

This is already a very limited set of capabilities, but still it allows for example for cap_mknod, cap_net_raw. In our exploit we've shown that just by having the cap_net_raw we were able to hijack network traffic. It turns out that in most cases you can actually drop all privileges/capabilities, which results in a better security posture.

In case you do need to give your container a certain capability, it's good practice to first drop all capabilities and then allow the needed one after that. You might hesitate about the cap_net_bind_service though, isn't my app going to have to bind to the network? Well the permission only applies for binding to ports lower than 1024. So when you bind your server to for example 8080 you don't need that privilege.

A diagram that shows the difference between running with default capabilities and with restricted capabilities

Now that we know we don't need the default set of capabilities we will now move on showing you the syntax on how to drop them via configuration.

See the source code from the Docker Capabilities.

Scan your code & stay secure with Snyk - for FREE!

Did you know you can use Snyk for free to verify that your code
doesn't include this or other vulnerabilities?

Scan your code

How to improving Kubernetes capabilities configuration?

Dropping capabilities using securityContext

If we follow the principles of least privilege, the best practice from a security perspective would be to only provide the capabilities which our container actually needs. In Kubernetes, you can manage capabilities assigned to your container through the securityContext settings.

You can drop all capabilities by adding the following configuration to your .yaml file:

Dropping capabilities first, adding later

In the case where you do have to allow capabilities it is good practice to first drop all default capabilities and only then add only the ones you need. In the example below you can see how we first drop all capabilities and then add the NET_BIND_SERVICE capability.

Stop privilege escalation

As we've explained, capabilities are delegated from one process to another, but processes can also gain new privileges if they are allowed to. We can disable this behavior by:

  • not running a container as root: using the --user option, if we are regular user, the kernel will not pass us any special capabilities
  • disable privilege escalation: using the allowPrivilegeEscalation flag in the Kubernetes config, (equivalent to the Docker command line option --security-opt=no-new-privileges), we avoid that the privileges given to a process are extended

These additional measures help in creating a defense in depth by providing different layers of protection. In addition, Kubernetes and containers have other mechanisms to limit permissions: cgroups, seccomp and AppArmor. They can be used in combination with the capabilities limiting we've presented. The explanation of these concepts is beyond the scope of this lesson.

Enforcing Kubernetes securityContext capability settings

As a Kubernetes admin, the built-in Pod Security Admission Controller is one method for enforcing securityContext settings; this replaced the PodSecurityPolicy controller in Kubernetes 1.25. Alternatives include the CNCF projects Open Policy Agent or Kyverno.


You’ve learned what Linux capabilities are and how to apply them to improve container security. We hope you will apply your new knowledge wisely and make your code much safer. Feel free to rate how valuable this lesson was for you and provide feedback to make it even better! Also, make sure to check out our lessons on other common vulnerabilities.