File capabilities allow users to execute programs with higher privileges. Best example is network utility ping.
A ping binary has capabilities CAP_NET_ADMIN and CAP_NET_RAW. A normal user doesn’t have CAP_NET_ADMIN privilege, since the executable file ping has that capability you can run it.
which ping /usr/bin/ping = cap_net_admin,cap_net_raw+p Which normally works as follows:
$ ping -c 1 126.96.36.199 PING 188.8.131.52 (184.108.40.206) 56(84) bytes of data. 64 bytes from 1.
Here are simple steps that you can follow to prove that the root user inside container is also root on the host. And how to mitigate this.
Root in container, root on host I have a host with docker daemon running on it. I start a normal container on it with sleep process as PID1. See in the following output that the container clever_lalande started with sleep process.
$ docker run -d –rm alpine sleep 9999 6c541cf8f7b315783d2315eebc2f7dddd1f7b26f427e182f8597b10f2746ab0b $ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 6c541cf8f7b3 alpine "sleep 9999" 12 seconds ago Up 11 seconds clever_lalande Now let’s find out the process sleep on the host.
There are always scripts that you write to automate some mundane tasks. And then you put that script in a directory that is in your PATH. But what this does is that it pollutes your system global PATH and shows up in places you wouldn’t want it to be in.
I was struggling with this issue for a while and struggling to get a proper solution. But there is a very simple and clever trick to solve this problem.
This blog shows you how you can copy stuff from your host machine to the running container without the docker cp command that we usually use.
Steps in text Here I have a script on the host, which looks following:
#!/bin/bash tput bold echo "OS Information:" tput sgr0 echo cat /etc/os-release After running which looks like following:
$ ls script.sh $ ./script.sh OS Information: NAME="Flatcar Linux by Kinvolk" ID=flatcar ID_LIKE=coreos VERSION=2079.