11.5. Docker

11.5. Docker

11.5.1. Basics

11.5.1.1. Traditional virtualization technology

Traditional virtualization technology adds a hypervisor layer, virtualizes virtual hardware such as network cards, memory, and CPU, and then builds clients on it. Each client has its own system kernel. Traditional virtualization technology uses virtual machines as the management unit. Each virtual machine has an independent operating system kernel and does not share the software system resources of the host machine. Therefore, it has good isolation and is suitable for multi-tenant scenarios in a cloud computing environment.

11.5.1.2. Container technology

The container technology can be regarded as a lightweight virtualization method. The container technology is virtualized at the operating system layer and can run multiple virtualized environments on the host machine kernel. Compared with traditional application testing and deployment, the deployment of containers does not need to consider the compatibility of the application's operating environment in advance; compared with traditional virtual machines, containers can run on the host without a separate operating system kernel, achieving higher Operational efficiency and resource utilization.

11.5.1.3. Docker

Docker is currently one of the most representative container platforms, with advantages such as continuous deployment and testing, and cross-cloud platform support. In a container cloud environment based on container orchestration tools such as Kubernetes, through the scheduling of cross-host cluster resources, the container cloud can provide functions such as resource sharing and isolation, container orchestration and deployment, and application support.

Docker has three basic concepts: Image, Container, and Repository. The image is a read-only template. The container is a running instance created from the image. The repository is a place where image files are centrally stored.

Containers can be started, started, stopped, and deleted. Each container is isolated from each other. You can regard the container as a simple version of the Linux environment (including root user rights, process space, user space, and network space, etc.) and running The application in it.

11.5.2. Security Risks

When considering the security of Docker, the following points are mainly considered

• The security of the kernel itself and its support for namespaces and cgroups
• The attack surface of the Docker daemon itself
• The "hardened" security features of the kernel and how they interact with the container

11.5.2.1. Docker Security Baseline

11.5.2.2. Kernel Namespace

Docker containers are very similar to LXC containers and have similar security features. When using docker to run and start a container, Docker will create a set of namespaces and control groups for the container in the background.

Namespaces provide the most direct form of isolation: a process running in a container cannot see or influence a process running in another container or host system.

Each container also has its own network stack, which means that one container cannot gain privileged access to the socket or interface of another container. Of course, if the host system is set up accordingly, the containers can interact through their respective network interfaces. If you specify a public port for the container or use a link, IP communication is allowed between the containers.

They can ping each other, send/receive UDP packets, and establish TCP connections, but they can be restricted if needed. From a network architecture perspective, all containers on a given Docker host are located on the bridge interface. This means that they are like physical machines connected through a normal Ethernet switch.

11.5.2.3. Control Group

The control group is another key component of the Linux container, whose main role is to implement resource accounting and restriction.

Cgroup provides many useful metrics, but it also helps to ensure that each container can get fair memory, CPU, and disk I/O; more importantly, a single container cannot deplete resources to reduce system performance.

Therefore, although Cgroups cannot prevent one container from accessing or affecting the data and processes of another container, they are essential to resist some denial of service attacks. They are especially important for multi-tenant platforms, such as public and private PaaS, to ensure consistent uptime (and performance) even when certain applications start to misbehave.

11.5.2.4. The attack surface of the daemon

Using Docker to run a container means running the Docker daemon, and this daemon currently requires root privileges, so the daemon is a place to consider.

First, only trusted users can be allowed to control the Docker daemon. Specifically, Docker allows you to share a directory between the Docker host and the guest container; it allows you to do so without restricting access to the container. This means that a container can be started, where the /host directory will become the / directory on the host, and the container will be able to change the host file system without any restrictions.

This has strong security implications: for example, if you test Docker through a web server to configure containers through APIs, you should check the parameters more carefully to ensure that malicious users cannot pass the produced parameters, causing Docker to create arbitrary containers.

The daemon may also be susceptible to other inputs, such as loading an image from a disk with docker load or from a network with docker pull.

Ultimately, it is expected that the Docker daemon will run with restricted privileges and delegate operations to well-audited child processes. Each child process has its own (very limited) scope of Linux functions, virtual network settings, file system management, etc. In other words, it is very likely that part of the Docker engine itself will run in a container.

11.5.2.5. Linux kernel functions

By default, Docker uses a limited set of features to start containers.

The function transforms the "root/non-root" dichotomy into a fine-grained access control system. Processes that only need to be bound to ports below 1024 (such as web servers) do not need to run as root: they can be given the net_bind_service function.

In most cases, the container does not need "real" root privileges. Therefore, Docker can run a low-capacity collection; this means that there is much less "root" in the container than the real "root". E.g:

• Deny all mount operations
• Deny access to the original socket (to prevent packet spoofing)
• Deny access to certain file system operations, such as creating a new device node, changing the owner of a file, or modifying attributes (including immutable flags)
• Reject module loading
• other

This means that even if an intruder gains root privileges in the container, further attacks will be much more difficult.

By default, Docker uses a whitelist instead of a blacklist, removing all non-essential functions.

11.5.3. Attack surface analysis

11.5.3.1. Supply chain security

In the process of building a Dockerfile, even if the top-ranked sources are used, there may be problems such as CVE vulnerabilities, backdoors, and image pollution.

11.5.3.2. Virtualization risks

Although the basic Docker were quarantined file system resources through a namespace, but still /sys, /proc/sys, /proc/bus, /dev, time, syslogand other important system files directory and namespace information isolation is not implemented, but share resources with the host.

11.5.3.3. Use kernel vulnerabilities to escape

• CVE-2016-5195

11.5.3.4. Container Escape Vulnerability

• CVE-2019-14271 Docker cp

• CVE-2019-13139 Docker build code execution

• CVE-2019-5736 runC

  • Docker Version < 18.09.2
  • Version <= 1.0-rc6

• CVE-2018-18955

11.5.3.5. Improper configuration

• Enable privileged

  • Mount the host directory

• --cap-add=SYS_ADMIN

11.5.3.6. Denial of service

• CPU exhausted
• Out of memory
• Storage exhausted
• Network resources are exhausted

11.5.3.7. Dangerous mounting

• Mount /var/run/docker.sock
• Mount host /dev /procand other dangerous directory

11.5.3.8. Attacking the Docker daemon

Although the Docker container has strong security protection measures, the Docker daemon itself is not fully protected. The Docker daemon itself is run by the root user by default, and the process itself is not protected by security modules such as Seccomp or AppArmor. This allows an attacker to successfully find a vulnerability to control the Docker daemon to perform arbitrary file writing or code execution, and he can successfully obtain the root permission of the host without being hindered by various security mechanisms. It is worth mentioning that Docker does not enable User Namespace isolation by default, which also means that the root inside Docker and the root of the host machine have the same read and write permissions for files. This results in that once the root process inside the container gets the opportunity to read and write host files, file permissions will not become another issue. This is reflected in the use of CVE-2019-5636.

11.5.4. Security Hardening

• Minimal installation

  • Remove all development tools (compilers, etc.)

• Update system source

• Enable AppArmor

• Enable SELinux

• Restrict the kernel functions of running containers

• Remove dependent build

• Configure strict network access control policies

• Do not use root user to start docker

• Do not run the container in privileged mode

• Control resources

  • CPU Share
  • Number of CPU cores
  • Memory resource
  • IO resources
  • Disk resource

• Use a secure base image

• Regular security scans and update patches

• Delete the setuid and setgid permissions in the mirror

  • RUN find / -perm +6000-type f-exec chmod a-s {} \;|| true

• Configure TLS authentication for Docker daemon

• Prohibit inter-container communication unless necessary

11.5.5. Docker environment recognition

11.5.5.1. In Docker

• The MAC address 02:42:ac:11:00:00is-02:42:ac:11:ff:ff
• ps aux `Most of the running programs have very small pids
• cat /proc/1/cgroup docker process
• Exist in the docker environment.dockerenv

11.5.5.2. Outside Docker

• /var/run/docker.sock File exists
• 2375/ 2376Port open

11.5.6. Reference links

• A House of Cards An Exploration of Security When Building Docker Containers
• Privileged Docker Containers
• 32c3 docker writeup
• Build a secure container cloud platform
• Docker security
• Container security
• CVE-2017-7494 Docker sandbox escape
• Docker container security analysis
• AppArmor security profiles for Docker
• Docker Bench for Security
• `Docker security and attack surface analysis https://mp.weixin.qq.com/s/d9D3z13uCOJoJzplpu3WJQ `_