The -v flag gives us the ability to mount a volume, so we mount / volume from the host and we specify that it will be available at /home/notImportantDir/. Let’s run this very innocent docker image and give the container / directory as volume. We build the image with Dockerfile from the current directory and we specify a friendly name with the -t option. We want to use the debian:stretch base image, and then execute the rm -rf /home/notImportantDir command. Bare with me as we go through some of the dark scenarios of malicious Docker images.
What can possibly go wrong? Well… a lot of things. So when you run a docker process, it gets the privileges of the root. For details on how this impacts security in your system, see Docker Daemon Attack Surface. The docker group grants privileges equivalent to the root user. When we install the docker, we go through docker post-install. Wait… What? Yes, the user with uuid=0 is a root. It relies on the host kernel, so the user inside of the docker container with uuid=0 is the same user on the host system with uuid=0. The great part of the Docker is that it is lightweight, but what does it entail? The Docker container does not have its own kernel. Docker is sharing a kernel with the host machine Moreover, we’ll tackle the uid and gid mechanism in linux kernel. We will consider some scenarios of malicious Docker images and how to protect your host machine from that. In this article, we’ll look under the hood of Docker container privileges. A significant part of the IT world relies on Docker containers as they are easy to use and portable.
0 kommentar(er)
