Container does not drop all default capabilities
Default capabilities are not as strict as you think
This lesson is available in Kubernetes
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 somedirchmod 775 somedirls -ldrwxrwxr-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/pingBut ... 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 waygetcap: get the capabilities of a filesetcap: 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.
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
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.
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.
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
allowPrivilegeEscalationflag 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.
What to learn next?
NEWError messages containing sensitive information
Type confusion
