Summary
Docker is an open source application container engine, which allows users to package applications and rely on packages into portable containers. However, Docker also has security issues. This article analyzes the vulnerabilities of Docker from four aspects: file system isolation, process and communication isolation, device management and host resource constraints, network isolation, and mirror transmission. Interact with the security module of the Linux kernel and take active and effective measures to improve the security of Docker. This article introduces the current situation of Docker security research, discusses and prospects the development trend of Docker security research, and lays a good foundation for better application of Docker in production.
Section 1. Introduction to Docker
Cloud computing can provide flexible services, has the characteristics of rapid deployment and portability, and occupies most of the market share in today’s computing field [1]. Among them, resource virtualization technology [2] has played an important role in realizing the on-demand distribution of cloud computing infrastructure services. Traditional hardware-level virtualization such as VMware, Xen, KVM, and Microsoft Hyper-v must reduce resource utilization by virtualizing a complete operating system layer. In order to find a more efficient alternative to isolation technology, Docker launched some open source container projects Docker in March 2013 [3]. In order to find a more efficient alternative to isolation technology, Docker has successfully been widely used in various scenarios. Its wide application makes the research on Docker security more urgent and practical.
Docker[3] is an open source engine. Docker can automatically deploy development applications to containers. In the virtualized container execution environment, an application deployment engine is added. The goal of the engine is to provide a lightweight and fast environment that can run the developer’s program, and deploy the program from the developer’s notebook to the test environment easily and efficiently. Then deploy to the production environment.
A. Vulnerability analysis of Docker host
Docker uses a client-server model. The Docker client communicates with the Docker daemon. The Docker daemon handles complex and heavy tasks such as building, running, and publishing Docker containers. The Docker client and the daemon can run on the same system. You can also use the Docker client to connect to the remote Docker daemon. Docker client and daemon communicate through socket or RESTful API [4]. Docker Client acts as a communication client to communicate with Docker Daemon daemon to manage Docker.
The Docker mode is shown in Figure 1.
B. Docker remote API and Dockerswarm
Docker Remote API [5] is a REST API that replaces rcli (remote command line interface) to help send requests, obtain and send data, and retrieve information.
Swarm is a relatively simple tool launched by Docker in early December 2014 to manage Docker clusters. Swarm transforms a group of Docker hosts [6] into a single virtual host. Swarm uses a standard Docker API interface as its front-end access entry, that is, various forms of Docker Client (Docker, Docker), Docker, etc. can directly communicate with Swarm.
The structure of Swarm is shown in Figure 2.
Part 2. Docker vulnerability analysis
The vulnerabilities of Docker are mainly reflected in four aspects: file system isolation, process and communication isolation, device management and host resource restrictions, network isolation, and image transmission. Research on the vulnerabilities of Docker can provide a basis for finding targeted security reinforcement measures.
A. File system isolation
The realization of the file isolation function in Docker is based on the Mount namespace. Different files [7] are stored in different namespaces to avoid interaction between file structures. However, the root authority in the container is similar to the authority of the root user of the host, especially when the RW mount is installed on the host and the container has root authority, the root authority in the container is even greater. Once the container executes “Chmod a +s[program file]”, the user running the program can obtain root privileges, which greatly increases the probability of related information leakage.
B. Remote isolation and communication isolation
Docker uses PID namespace [8] to isolate processes and separate the PID of the process. There is a separate counting program. The system kernel implements the maintenance of the PID namespace through the tree, where the root namespace is at the top level, and the parent node can obtain the child node information, but the child node cannot obtain the parent node information. But it needs to be clear: when it is 1, the PID is terminated, causing the container to stop completely and denial of service.
C. Device management and host resource constraints
The isolation of domain names and host names in Docker containers is achieved through the UTS namespace, and Cgroups [9] are used to limit the use of resources. But it is closed by default, which easily increases the probability of exhaustion of device resources, network bandwidth, and memory space. In addition, considering that users can obtain resources in the container, user-defined codes are not appropriately restricted. It will cause the host to deny service, especially when using SaaS, PaaS, IaaS, should pay enough attention to prevent the occurrence of denial of service.
D. Network isolation and image transmission
The network namespace in Docker is responsible for isolating network resources, such as IP routing tables, TCP/IP protocols, and network equipment isolation. But by default, Docker assigns the IP and network namespace to the container, and then connects with a bridge. This method only forwards the traffic without filtering, which will face a greater risk of MAC Flooding. When the image is transferred, Docker will not check the pulled back image. If some data is replaced, a man-in-the-middle attack may occur.
Section 3 Docker and Kernel Security System
The existence of some kernel security systems can be used to enhance the security of Docker and the kernel, including Linux functions [10] and Linux security modules (LSM). Linux functions limit the permissions assigned to each process. LSM provides a framework that allows the Linux kernel to support different security models. LSM has been integrated into the official Linux kernel, including AppArmor, SELinux and AppArmor.
A. Linux features
Docker containers run on a kernel shared with the host system, so most tasks can be handled by the host. Therefore, in most cases, it is not necessary to provide full root permissions for the container. Therefore, deleting some root functions in the container will not affect the usability and functions of the container, and can effectively improve the security of the system. For example, CAP_ can be deleted from the container to modify the network function of the system. Because all network configuration of Docker can be handled by the Docker daemon before starting the container, Docker can delete the .NET_ADMIN function before starting the container.
Docker allows the configuration of functions that can be used by the container. By default, even if the intruder gains root access in the container, Docker can ban a large number of Linux functions in its container to prevent the intruder from destroying the host system. Some features are disabled by Docker. The functions of Docker containers are shown in TABLE I and can be found in the Linux manual page.
Table 1 Some functions disabled by docker container
B. Apparmor
AppArmor [11] is also a Linux security enhancement model based on mandatory access control (such as SELinux), but it limits the scope to a single program. It allows the administrator to load a security configuration file in each program, thereby limiting the functionality of the program.
On AppArmor-enabled systems, Docker provides an interface to load a predefined AppArmor configuration file when starting a new container. The configuration file will be loaded into the container in forced mode to ensure that the processes in the container are restricted by the configuration file. If the administrator does not specify a configuration file when starting the container, the Docker daemon will automatically load the default configuration file into the container, which will deny access to important file systems on the host, such as Isys/fs/cgroups/ and /sys/kerne /security/.
C. Capability mechanism
The capability mechanism makes the division of Linux permissions more detailed, changing the previous phenomenon of all permissions of the root user. The capability mechanism subdivides permissions into 37 different capabilities, covering operating permissions for documents, processes, networks, systems, and equipment. Docker provides limited capabilities for containers under the condition of silent identification. The user can also increase or decrease the capability authority during runtime according to actual needs. The problem with the capability mechanism is that decentralization is not enough in some aspects, and it cannot meet the requirements of container restrictions. CAP _ SYS _ADMIN covers many permissions and needs to be further subdivided. When assigning permissions to a container, it is difficult to know which permissions are required in the container. For this reason, the default capability permission list provided by Docker includes a wider range. From a security perspective, this is not a good strategy.
D. Seccomp
Seccomp[12] can limit the system calls of user processes and filter system call parameters. System calls are the most important interface between user state and kernel state. By restricting it, it can be ensured to a large extent that the process runs in a safe and controllable range. Docker uses a whitelist mechanism by default, and specifies which system calls are allowed through the Seccomp configuration file, and more than 50 systems will be blocked. Some system calls will also be blocked under certain parameters. Under the configuration file, most containers can run normally.
E. Mandatory admission control
Compared with discretionary access control (DAC), mandatory access control can provide more stringent protection [13]. Since users cannot change their own security levels and the security attributes of objects, they can only make objective and specific decisions based on the pre-defined user and data security level matching results. In this way, the user’s subjective factors can be shielded, and the security of the system can be better protected. In Linux systems, mandatory access control is usually used in conjunction with DAC, and the specific security module is implemented under the framework of LSM (Linux Security Module). Currently, the security modules that have been incorporated into the kernel mainline are SELinux, AppArmor, Yama, SMACK, and Tomoyo. These security modules can provide enhanced security protection for Docker containers. In addition to Yama, there will also be mutual exclusion between modules. Under normal circumstances, different security modules are selected according to different distributions of Linux. The Debain series usually use its own AppArmor, and the Redhat series release SELinux security modules.
The main problem with SELinux is that the operation is too complicated. Developers and actual production departments resist the use of SELinux, which is incompatible with the BTRFS driver. AppArmor is unique in that it does not pay attention to the security of the entire system, and only enforces access control to specified processes. Other processes are working in an uncontrolled state. The LiCShield security framework is used to integrate Linux containers. The framework automatically generates AppArmor configuration files by tracking and analyzing the permissions required by the container to ensure the safe and controllable operation of the container. In addition to these security modules, users can also design more suitable security modules based on the LSM framework.
F. Network framework
In the Linux kernel, there are some network frameworks that can be used to solve Docker’s network security problems, including Netfilter [14] framework and TC (tracfic controller) framework. Including Netfilter [14] framework and TC (tracfic controller) framework. Netfilter focuses on firewall data filtering, while TC focuses on traffic bandwidth control. Docker can enable Iptable firewall by modifying the configuration file and configure firewall policies to control the communication between containers. TC can restrict the traffic of virtual network interfaces on the host through TC, or use the Cgroups subsystem to mark network packets, and use the classification queue in TC to limit the traffic of containers, thereby effectively preventing exclusive network bandwidth denial of service attacks.
G, integrity protection
The integrity protection technology in the Linux kernel can be well applied to Docker to ensure the integrity of the image and container operation. The technologies involved include the dm-verity sub-module and Device Mapper of the Trusted Computing Group (TCG) that implement the integrity check function in some modules of Linux. These technologies can be used to protect the integrity of Docker images.
H. Log audit
Although Docker has a relatively systematic implementation plan for log visualization auditing, it still needs further research in large-scale log data mining and automatic analysis. In terms of operating environment audit, you can refer to the security assessment documents developed by Docker and CIS (Internet Security Center). The specific assessment implementation tool is Docker bench for security.
I. Security threat detection
In terms of security threat detection against Docker, although traditional host-based threat detection and data stream-based threat detection technologies can be used, it is still necessary to combine the characteristics of Docker to further strengthen the application. This method is an example of applying traditional host threat detection technology to a specific Docker environment.
J. Streamline the operating system
From another perspective, there is a lot of research on the security of Docker. For example, in order to provide a safer container operating environment, a batch of streamlined operating system projects have been proposed, including CoreOS and Ubuntu Core, which are more suitable for container operation. Among them, a new lightweight architecture solution is proposed, with the help of a customized kernel, allowing applications to run directly on the bare metal without sharing the kernel system with each other. Representative programs include Unikernels and so on. Catuogno compared and compared the container security standard model proposed by CCRA (common criteria recognition arrangement) under the Docker environment and Reshetova and other security models, and pointed out the essential equality of the two security models. Sharath N and others introduced how to use the Stackelberg model to find the best combination point that can not only take into account the security of Docker but also ensure the efficiency of operation through the method of linear programming.
K. Other relevant security reinforcement measures
Although Docker has a more systematic implementation plan for log visual auditing, it still needs further research in large-scale log data mining and automatic analysis. In terms of operating environment audits, you can refer to the security assessment documents developed by Docker and CIS (Internet Security Center). The specific assessment implementation tool is Docker bench for security.
In terms of Docker’s security threat detection, although traditional host-based threat detection and data stream-based threat detection technologies can be used, how to combine Docker’s own characteristics for targeted applications requires further enhancement. Abed AS and others introduced in detail how to detect the Docker process through system calls and perform cluster analysis on the defined call frequency. This method is an example of applying traditional host threat detection technology to a specific Docker environment.
From a different perspective, there has been a lot of research on the security issues of Docker. For example, in order to provide a safer container operating environment, a batch of streamlined operating system projects have been developed, including CoreOS and Ubuntu Core, which are more suitable for container operation. A new lightweight architecture solution was proposed, with the help of a customized kernel, allowing applications to run directly on the bare metal without sharing kernel systems with each other. Representative programs include Unikernels and so on. Catuogno compared and compared the container security standard model proposed by CCRA (Common Criteria Recognition Arrangement) [15] in the Docker environment with Reshetova and other security models, and pointed out that the two security models are essentially equivalent. Sharath N and others introduced how to use the Stackelberg Model (Stackelberg Model) to find the best combination of Docker security and operating efficiency through linear programming.
Section 4. Conclusion
With the increasing popularity of container applications, more and more sensitive applications will be migrated to containers. How to improve the security of containers while providing convenient deployment and high resource utilization will become an issue of increasing concern. First, this article briefly introduces the main structure of Docker, and then sorts out the vulnerabilities of Docker. It is pointed out that it is mainly reflected in four aspects: file system isolation, process and communication isolation, device management and host resource restriction, network isolation and mirroring transmission. Then, the Docker and kernel security system are summarized, and the current security research measures of Docker are summarized. Compared with traditional virtual technology, the security of Docker containers needs to be improved. These two kinds of containers are not relative. Under the same virtual isolation effect, they also play a complementary role. Try to make up for the shortcomings of Docker’s security, which will give full play to the advantages of Docker in virtual containers.
Quote
1.T. Bui “Analysis of Docker Security[J]” Computer ence 2015.
2.T Combe A Martin and R D. Pietro “To Docker or Not to Docker: A Security Perspective[J]” Cloud Computing IEEE vol. 3 no. 5 pp. 54-62 2016.
3.AR Manu Jitendra Kumar Patel and Shakil Akhtar “A study analysis and deep dive on cloud PAAS security in terms of Docker container security[C]//” International Conference on Circuit 2016.
4. Holger Gantikow Christoph Reich and Martin Knahl “Providing Security in Container-Based HPC Runtime Environments [C]//” International Conference on High Performance Computing 2016.
5. Yasrab R. Mitigating Docker Security Issues[J] 2018.
6.S Garg and S. Garg “Automated Cloud Infrastructure Continuous Integration and Continuous Delivery using Docker with Robust Container Security[C]//” Automated Cloud Infrastructure Continuous Integration & Continuous Delivery Using Docker with Robust Container Security 2019.
7.D Sever and T. Kisasondi “Efficiency and security of docker based honeypot systems[C]//” International Convention on Information & Communication Technology Electronics & Microelectronics 2018.
8. LI Fuling and H E. Haoxian “Implementation of online evaluation system security based on Docker[J]” Journal of North China Institute of Science and Technology 2018.
9. LI Chun-Lin L Zheng-Jun W Ye et al. “ModifiedConstruction Method of Docker-based Network Security Experimental Platform[J]” Communications Technology 2019.
10.Fotis Loukidis Andreou Ioannis Giannakopoulos and Katerina Doka “Docker-Sec: A Fully Automated Container Security Enhancement Mechanism[C]//” Ieee International Conference on Distributed Computing Systems 2018.
11.A Zerouali T Mens G Robles et al. On The Relation Between Outdated Docker Containers Severity Vulnerabilities and Bugs[J] 2018.
12.Chin – Wei Tien Tse – Yung Huang Chia – Wei Tien et al. “KubAnomaly: Anomaly detection for the Docker orchestration platform with neural network approaches[J]” Engineering Reports vol. 1 no. 5 2019.
13.A Martin S Raponi T Combe et al. “Docker ecosystem – Vulnerability Analysis[J]” Computer Communications pp. 30-43 2018.
14.J Xiang and L. Chen “[ACM Press the 2nd International Conference – Guiyang China (2018.03.16–2018.03.19)]” Proceedings of the 2nd International Conference on Cryptography Security and Privacy – ICCSP 2018 – A Method of Docker Container Forensics Based on API[J] pp. 159-164 2018.
15.MP Amith Raj A Kumar SJ Pai et al. “Enhancing security of Docker using Linux hardening techniques [C]//” International Conference on Applied & Theoretical Computing & Communication Technology 2016.
16.Fathollah Bistouni and Mohsen Jahanshahi “Evaluation of Reliability in Component-Based System Using Architecture Topology” Journal of the Institute of Electronics and Computer vol. 2 pp. 57-71 2020.