Docker Container Security

Editor's Notes

• #4: How many of you have heard this from developers? Quite a lot right? So this is essentially one of the most important challenges that containers solve for us. So using docker you can simply create a compact runtime environment for your application to run without worrying about the dependencies on your host.
• #8: The idea of containers is very old. Dating back to 1979. A chroot jail is a way to isolate a process and its children from the rest of the system. The idea is that you create a directory tree where you copy or link in all the system files needed for a process to run. You then use the chroot() system call to change the root directory to be at the base of this new tree and start the process running in that chroot'd environment.
• #9: Process containers in 2006 was designed for limiting, accounting and isolating resource usage. It was renamed Control groups(cgroups)
• #10: You can think of a vm as a self contained computer packed in a single file but something needs to be able to run that file. Thats where the hypervisor comes into play. Guest OS. For eg: you want to run 3 applications on an isolation. You will need to spin up 3 Guest OS. The problem here is that each guest os would need min 700MB ram. So 3 applications running in an isolation would require a min of 2.1GB of resources + CPU power + HD space + each resource would need its own set of binaries and libraries for it to run. … A lot of resources wasted. So what docker helps, you is in just having the essential libraries and binaries required to run the application. So you would have around 100-200 MB of a base image, 10 MB of your code and 50MB of RAM Now lets compare that to docker containers – here we have a docker daemon instead of a hypervisor. The docker daemon is a service that runs on the background on your host os and manages everything required to run and interact with docker containers. Next we have our bin/libs just like we do on our VMs. But instead of them being run on a guest os, they get built into special packages called docker images, then the docker daemon runs those images. Then we have the applications that would be run and managed independently by docker daemon. Typically each application and its dependencies get packed into the same docker image and each application is isolated.
• #15: ps -ef --forest
• #16: -v what it is trying to do is mapping the unix socket of the docker to inside a container. CI/CD pipelines used container pipelines to run jobs. So what they do is rather than giving host access, they perform docker in docker. Which means that they will run your code inside a docker environment which is already running inside a docker
• #17: What makes containers possible. What makes it possible to run a process in isolation. And without an overhead of boointng an os. Answwer to that lies in linux kernel which offers us these features that makes it possible to run these processes in isolation and sandboxed environment. File stystem namespace. Each container can have its own OS/filesystem. Each container can have its own network namespace and have its own ip address and interface. Each container can have its own hostname. A new security feature has been added where we can have a user namespace. Earlier if you were a root user inside the container, if you could breakout of the container, you could gain root access on the system but its no more possible because you can map it to a non-root user on the system even if you breakout of the container. So that’s what makes running processes in isolation possible. UnionFS Union file systems, or UnionFS, are file systems that operate by creating layers, making them very lightweight and fast. Docker Engine uses UnionFS to provide the building blocks for containers. Docker Engine can use multiple UnionFS variants, including AUFS, btrfs, vfs, and DeviceMapper.
• #18: Namespaces Docker uses a technology called namespaces to provide the isolated workspace called the container. When you run a container, Docker creates a set of namespaces for that container. These namespaces provide a layer of isolation. Each aspect of a container runs in a separate namespace and its access is limited to that namespace. These are running in a vm but appear to run in isolation because these are namespaces. What you have inside a container is a list of namespaces or pid for your own process itself and that gets mapped to certain pids on the host system. Inside containers the pids are 1,2,3,4 they are actually mapped to the process on the host There are other namespaces which make it look like running a vm and that’s what isolates one container from another.
• #19: Namespaces Docker uses a technology called namespaces to provide the isolated workspace called the container. When you run a container, Docker creates a set of namespaces for that container. These namespaces provide a layer of isolation. Each aspect of a container runs in a separate namespace and its access is limited to that namespace. These are running in a vm but appear to run in isolation because these are namespaces. What you have inside a container is a list of namespaces or pid for your own process itself and that gets mapped to certain pids on the host system. Inside containers the pids are 1,2,3,4 they are actually mapped to the process on the host There are other namespaces which make it look like running a vm and that’s what isolates one container from another.
• #20: Namespaces Docker uses a technology called namespaces to provide the isolated workspace called the container. When you run a container, Docker creates a set of namespaces for that container. These namespaces provide a layer of isolation. Each aspect of a container runs in a separate namespace and its access is limited to that namespace. These are running in a vm but appear to run in isolation because these are namespaces. What you have inside a container is a list of namespaces or pid for your own process itself and that gets mapped to certain pids on the host system. Inside containers the pids are 1,2,3,4 they are actually mapped to the process on the host There are other namespaces which make it look like running a vm and that’s what isolates one container from another.
• #21: Namespaces Docker uses a technology called namespaces to provide the isolated workspace called the container. When you run a container, Docker creates a set of namespaces for that container. These namespaces provide a layer of isolation. Each aspect of a container runs in a separate namespace and its access is limited to that namespace. These are running in a vm but appear to run in isolation because these are namespaces. What you have inside a container is a list of namespaces or pid for your own process itself and that gets mapped to certain pids on the host system. Inside containers the pids are 1,2,3,4 they are actually mapped to the process on the host There are other namespaces which make it look like running a vm and that’s what isolates one container from another.
• #22: Namespaces Docker uses a technology called namespaces to provide the isolated workspace called the container. When you run a container, Docker creates a set of namespaces for that container. These namespaces provide a layer of isolation. Each aspect of a container runs in a separate namespace and its access is limited to that namespace. These are running in a vm but appear to run in isolation because these are namespaces. What you have inside a container is a list of namespaces or pid for your own process itself and that gets mapped to certain pids on the host system. Inside containers the pids are 1,2,3,4 they are actually mapped to the process on the host There are other namespaces which make it look like running a vm and that’s what isolates one container from another.
• #23: Control groups Now when these processes are run in isolation, and run multiple containers on the same host, there is a possibility that there is a container that has a memory leak for eg: it would affect the rest of the system / containers. This is where cgroups come into play. What control groups allow you to do is control as the name says. Control the resource utilization and keep a limit on the memory CPUs etc. Cgroups are also used for monitoring the containers
• #24: Control groups Now when these processes are run in isolation, and run multiple containers on the same host, there is a possibility that there is a container that has a memory leak for eg: it would affect the rest of the system / containers. This is where cgroups come into play. What control groups allow you to do is control as the name says. Control the resource utilization and keep a limit on the memory CPUs etc. Cgroups are also used for monitoring the containers
• #25: Control groups Now when these processes are run in isolation, and run multiple containers on the same host, there is a possibility that there is a container that has a memory leak for eg: it would affect the rest of the system / containers. This is where cgroups come into play. What control groups allow you to do is control as the name says. Control the resource utilization and keep a limit on the memory CPUs etc. Cgroups are also used for monitoring the containers
• #26: This Breaking down of root privileges into granular capabilities allows you to: Remove individual capabilities from the root user account, making it less powerful/dangerous. Add privileges to non-root users at a very granular level. By default, Docker drops all capabilities except those needed, using a whitelist approach. Lets take an example if you want to perform logging of containers. This would require your In each node of your cluster, you should have an agent running to make sure logs are coming into the system. To gather information from the container namespace, they need to have this visibility. These logging tools require additionacl privileges than your normal containers. So this attack will on abusing such capabilities. One such capability is sys_ptrace which allows to trace the host process. Going ahead we assume that we have a shell access on the container. And we will try break out of it.
• #27: This Breaking down of root privileges into granular capabilities allows you to: Remove individual capabilities from the root user account, making it less powerful/dangerous. Add privileges to non-root users at a very granular level. By default, Docker drops all capabilities except those needed, using a whitelist approach. Lets take an example if you want to perform logging of containers. This would require your In each node of your cluster, you should have an agent running to make sure logs are coming into the system. To gather information from the container namespace, they need to have this visibility. These logging tools require additionacl privileges than your normal containers. So this attack will on abusing such capabilities. One such capability is sys_ptrace which allows to trace the host process. Going ahead we assume that we have a shell access on the container. And we will try break out of it.
• #28: This Breaking down of root privileges into granular capabilities allows you to: Remove individual capabilities from the root user account, making it less powerful/dangerous. Add privileges to non-root users at a very granular level. By default, Docker drops all capabilities except those needed, using a whitelist approach. Lets take an example if you want to perform logging of containers. This would require your In each node of your cluster, you should have an agent running to make sure logs are coming into the system. To gather information from the container namespace, they need to have this visibility. These logging tools require additionacl privileges than your normal containers. So this attack will on abusing such capabilities. One such capability is sys_ptrace which allows to trace the host process. Going ahead we assume that we have a shell access on the container. And we will try break out of it.
• #33: We assume that we already have a shell inside the container with a web application vulnerability or an insider who administers one of the containers. We assume there is a command injection vulnerability, application used is DVNA by appseco We get a reverse shell We upload docker binary Check if docker.sock exists in /var/run/docker.sock Run another container which is volume mounted on the host ./docker run -i -v /:/host debian:jessie /bin/bash Change the root directory to /host - chroot /host cat /etc/hostname – we see that we can read files from host
• #34: We assume that we already have a shell inside the container with a web application vulnerability or an insider who administers one of the containers. We assume that we have access to a container with a web application vulnerability and this container runs in privileged mode with pid of the host shared with the container for debugging purposes by the developer. So if we see ps aux we can see the host system processes and we need to inject our payload on one of the process. But how will we know that which process is of host and container? cat /proc/444/cgroup find /proc/*/cgroup -type f -print -exec cat {} \; | grep docker -B4 We perform process injection in this case because we can view processes on the host as well as have all privileges to do debugging.
• #35: Nmap –p2375 If port 2375 is open for you on a network pentest, then there is a high possibility that it is docker daemon service. You can try docker -H 1.1.1.1:2375 ps to run commands on the host