CN113220417B - Safety protection method for limiting Docker container behaviors - Google Patents

Safety protection method for limiting Docker container behaviors Download PDF

Info

Publication number
CN113220417B
CN113220417B CN202110487711.6A CN202110487711A CN113220417B CN 113220417 B CN113220417 B CN 113220417B CN 202110487711 A CN202110487711 A CN 202110487711A CN 113220417 B CN113220417 B CN 113220417B
Authority
CN
China
Prior art keywords
container
configuration file
access
docker
host
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN202110487711.6A
Other languages
Chinese (zh)
Other versions
CN113220417A (en
Inventor
马文平
王�琦
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Xidian University
Original Assignee
Xidian University
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Xidian University filed Critical Xidian University
Priority to CN202110487711.6A priority Critical patent/CN113220417B/en
Publication of CN113220417A publication Critical patent/CN113220417A/en
Application granted granted Critical
Publication of CN113220417B publication Critical patent/CN113220417B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/455Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533Hypervisors; Virtual machine monitors
    • G06F9/45558Hypervisor-specific management and integration aspects

Abstract

The invention discloses a safety protection method for limiting Docker container behaviors, which mainly solves the problem of insufficient safety of the existing Docker. The implementation scheme is as follows: respectively creating AppArmor configuration files comprising behavior specification rules on each container, each running tool and the Docker engine to limit respective access functions and realize forced stopping of the containers when illegal behaviors occur; a visual behavior monitoring platform is established, the behavior specification of the Docker container is monitored in real time, the platform can give an alarm when the container is forcibly stopped, and the platform can give an alarm in time before the container is forcibly stopped when illegal behaviors occur again. The invention can protect the container from being attacked by illegal behaviors, monitors the container behaviors from the aspect of operation and maintenance, reduces the loss caused by the forced stop of the container, further ensures the safety performance of the container, and can be used for a safety protection system.

Description

Safety protection method for limiting Docker container behavior
Technical Field
The invention belongs to the technical field of computer security, and particularly relates to a security protection method for limiting Docker container behaviors, which can be used for a security protection system.
Technical Field
Docker is an open source application container engine that can easily create a lightweight, portable, self-sufficient container for any application. Lightweight virtualization, typified by container technology, has become increasingly popular and is an essential technology for supporting cloud computing. Docker is a container engine developed from the early Linux container technology, and although the content of applications, development environments and running environments developed by developers are different, docker provides a migratable mirror image storage mode, and developers can pack various applications into a mirror image and then run on a machine on which Docker is installed. Docker by itself is extremely simple and low in resource consumption to quickly capture the computing resource isolation market.
With the popularity of containers, containers have been successfully used in various use cases, and the technologies surrounding them have been valued accordingly. Nevertheless, as can be seen from the observation of the Cloud Foundation, the adoption rate of container technology is still low, and many studies have made safety issues as a decisive factor. In practice, safety is not considered when designing containers. Although isolation may be provided for processes, file systems, networks, etc., and quotas may be implemented for CPU, RAM and disk usage, the containers are more vulnerable than the virtual machine VMs due to the lack of a virtual machine monitor, undoubtedly adding to these additional burdens of the isolation layer between the application and the host.
The most effective way to enforce container security is to use tools like AppArmor or SElinux to perform the mandatory access control MAC at the kernel level to prevent unnecessary operations between the host and the container. However, this is an extremely cumbersome process that requires knowing the characteristics and requirements of the application running within the container and manually creating the specific security rules to be applied. Most of the extraction MAC rules that have been tried so far operate on a per-image basis rather than per-container basis, leaving room for attacking containers.
In an article issued in 2014 by Steven Vaughan-Nicols of scientific observers in the united states, a Docker company adds digital signature authentication to a Docker mirror image, uses an asymmetric key encryption technology and a digital digest technology to achieve the purpose of identifying digital information, and reinforces the container security at the mirror image level. Matthew Bajor proposes a method of using a Docker daemon enabled with TLS encryption, which, to use the corresponding program, must provide a client certificate in accordance with the Docker company official usage rules. Both of these authentication techniques are inevitably corrupted by some attack on the container, since they operate on a per-image basis rather than on a per-container basis.
The american scholars Daniel Walsh proposed using the SELinux mandatory access control system to control access rights to the Docker container process. The system marks all processes and files with labels, when the processes enter a container, a user controls how the processes access resources according to label strategies, namely, the container is limited to access the resources, the strategies are made from the global perspective, the whole system is forced to follow, the specific user setting is not needed, an attacker is difficult to break through, the security of the system is very excellent, and the system is not suitable for being managed and used by common users due to high complexity and cost of the system.
The Immunix company develops an access control system Apparmor similar to the SELinux, and the Apparmor allows a system administrator to associate each program with one security configuration file, so that the functions of the programs are limited, and the problems that the SELinux system is high in complexity and difficult to manage by common users are solved. Through the security profile, the user can specify which files the program reads, writes, or runs, whether a network port can be opened, and the like. However, the policy rules in the security profile can only be created manually and cannot be implemented to protect a particular container.
An Indian scholars S.Dhakate and the like designs a lightweight distributed monitoring system based on a Docker container, closely combines the functions of detection, reporting, monitoring and alarming, and is integrally applied to a cloud monitoring platform. However, the existing monitoring platform still does not combine data and views, and the flexibility and observability on the operation and maintenance level are still far from sufficient.
Disclosure of Invention
The invention aims to provide a safety protection method for limiting the behavior of a Docker container, aiming at the defects of the prior art, so as to limit the access function of the container, protect the container from being attacked by illegal behaviors, monitor the behavior of the container from the aspect of operation and maintenance and reduce the loss of the container caused by forced stop of operation.
In order to achieve the above purpose, the invention provides a security protection method for limiting Docker container behaviors, wherein the limiting Docker container behaviors refer to the limitation on three components, namely a container, a running tool and a Docker engine, and the method is characterized by comprising the following implementation steps of:
(1) Create AppArmor profile on each container and restrict its access functions:
(1a) During container initialization, a static analysis mechanism is adopted to collect important static information about a container and access thereof, a configuration file is created, the most basic access rule during initialization is formed according to a volume of the container and user information, and the rule is added into the configuration file;
(1b) During the operation of the container, a dynamic monitoring method is adopted to standardize the behaviors of network access and file access by the collection container in a specified training time to form a rule, the rule is added into a configuration file and compared with the configuration file generated during initialization, unnecessary rules in the configuration file generated during initialization are abandoned, and finally the configuration file containing new rules of container access is generated;
(1c) When the container operates again, the configuration file automatically judges whether the access of the container meets the rules according to the new rules of the container, and if the network access and the file access of the container violate the rules in the configuration file, the container is forced to stop operating;
(2) Creating an AppArmor profile on each running tool and limiting its execution functions:
(2a) During container initialization, collecting root installation point information of a container, creating a separate temporary configuration file for each running tool, forming an execution rule of the running tool during initialization according to the root installation point information, and adding the rule into the temporary configuration file;
(2b) During the operation of the container, in the set training time, converting the temporary configuration file generated during the initialization into a final configuration file by using a one-way configuration file conversion function, wherein the final configuration file comprises a rule for judging whether a host process accessing the container is legal or not;
(2c) When the container operates again, the final configuration file automatically judges the legality of the host process, if the illegal process of the host accesses the container, the rule in the final configuration file is violated, and the operation tool forces the container to stop operating;
(3) Creating an AppArmor configuration file on a Docker engine, namely setting the Docker engine to be a mode specified by the AppArmor configuration file, limiting the engine according to official default rule requirements, and forcing the container to stop running when a vulnerability of the Docker engine appears;
(4) Establishing a visual behavior monitoring platform, monitoring the behavior specification of the Docker container in real time, recording the behavior of the three components as illegal behaviors and starting an alarm after the container is forcibly stopped if the behavior of the three components is not in accordance with the rules in the configuration file, and directly sending an alarm before the container is forcibly stopped if the illegal behaviors occur again.
Compared with the prior art, the invention has the following advantages:
1. according to the invention, appArmor configuration files are provided for the three major components of the Docker, and a layer of rules is added on the basis of the safety of the components, so that the three major components can be in a safety protection state, the container can be directly stopped due to illegal actions of the container, and the safety performance of the Docker container is greatly improved.
2. According to the invention, when the configuration file is created for each container component, a method combining a static analysis mechanism and dynamic monitoring is adopted, the rules are summarized from the static aspect and the dynamic aspect, different rules are formulated according to different behavior specifications of each container, and the efficiency of maintaining the container safety is improved.
3. When the configuration file is created for the operation tool, the invention uses the one-way configuration file conversion function to convert the rules in the temporary configuration file into the one-way access container only allowing the host process, and the access direction of the process between the host and the container does not need to be judged, thereby simplifying the judgment operation of the system and greatly reducing the performance overhead.
4. The invention establishes a visual behavior monitoring platform, monitors the behavior specification of the container in real time, and sends out an alarm in time when the illegal behavior reappears, thereby reducing the performance loss of the container caused by forced stop.
Drawings
FIG. 1 is a schematic diagram of three major components in a Docker framework subject to configuration files;
FIG. 2 is a flow chart of an implementation of the present invention;
FIG. 3 is an architecture diagram of a visualization platform for monitoring Docker container behavior in accordance with the present invention.
Detailed Description
Referring to fig. 1, a Docker is an open-source application container engine, and an overall framework thereof includes a Docker client, a Docker host, a Docker engine, a running tool, and a container. The Docker client is a user interface of Docker, which interacts with a Docker host through a Docker engine, which is used to build, run, and distribute containers in the host, the running tool being a tool to create containers. The three components of the container, the running tool and the Docker engine are components limited by the configuration file.
Referring to fig. 2, the security protection method for limiting behavior of a Docker container includes limitation of three components, namely, a container, a running tool, and a Docker engine, and is implemented as follows:
the method comprises the following steps: under the Debian operating system, docker is installed, and AppArmor application programs are started.
Step two: a visualization platform is created that monitors the behavior of the Docker container.
Referring to fig. 3, the platform was constructed from cAdvisor, prometheus and Grafana tools. The cAdvisor is a practical tool for packaging in a Docker container, and can collect the behavior of each container in real time; prometheus is a database used to store information about container behavior; grafana is a graphical tool that can visually represent information in the Prometous database. The platform can be used for conveniently storing and monitoring the container behavior.
Step three: an AppArmor profile is created on each container and its access functions are restricted.
3.1 During container initialization, a static analysis mechanism is adopted to collect important static information about a container and access thereof, a configuration file is created, a user acquires volumes and user information of the container according to an official specified mode, a specific folder and a specific file of a host computer which can be accessed by the container and a specific user which can access the container are formed, a rule which can be used by the container to access the files and folders in the host computer and the user to access the container is formed, and the rule is added into the configuration file;
3.2 During the operation of the container, a user defines a period of designated training time by self, a dynamic monitoring method is adopted, behavior analysis is carried out on an access process which is interested by the user according to a designated mode for starting training, network access and file access information of the container are collected, which network ports can be accessed by the container and which file systems in the host can be accessed are restrained according to the collected behavior information of specific network ports which can be accessed by the container and specific file systems which can be accessed by the host, so as to form a rule, the rule is added into a configuration file, the configuration file is compared with the configuration file generated during initialization, unnecessary rules in the configuration file generated during initialization are abandoned, and the configuration file containing new rules for accessing the container is finally generated;
3.3 On a visual platform for monitoring the behavior of a Docker container, a Prometous tool collects information in a configuration file containing new rules as standard rules of the container, and in the monitoring process, when the behavior of the container does not accord with the standard rules of the container, the container stops operating forcibly, records the behavior as illegal behavior, starts alarming, and when the illegal behavior occurs again, directly sends out an alarm before the container stops forcibly;
3.4 A behavior A meeting the standard rule of the container and a behavior B violating the standard rule of the container are specified by a user, the same container which does the behavior A and does the behavior B is respectively started, the container which does the behavior B is forcibly stopped by the system, the monitoring platform gives an alarm, and the container which does the behavior A can be successfully operated.
Step four: an AppArmor profile is created on each running tool and limits its execution functionality.
4.1 During container initialization, the user collects root installation point information of the container according to an official designation manner, creates a separate temporary configuration file for each running tool, and forms a rule according to the root installation point information, which processes can run bidirectionally between the container and the host, adds the rule to the temporary configuration file;
4.2 During the operation of the container, a user defines a set training time by self, and a one-way configuration file conversion function is used for converting a temporary configuration file containing a rule allowing a two-way process between the container and a host into a final configuration file containing a rule only allowing the host process to access the container in one way, wherein the final configuration file contains a rule for judging whether the host process accessing the container is legal or not;
4.3 On a visual platform for monitoring the behavior of a Docker container, a Prometous tool collects information in a final configuration file as a standard rule of an operation tool, and in the monitoring process, when an execution rule of the operation tool does not accord with the standard rule of the operation tool, the operation tool forces the container to stop operating, records the operation tool as an illegal behavior, starts an alarm, and when the illegal behavior occurs again, the alarm is directly sent out before the container is forced to stop;
4.4 A host process A meeting the standard rule of the operation tool and a host process B violating the standard rule of the operation tool are specified by a user, the operation tool comprising the host process A and the host process B is used for starting the container, the operation tool comprising the host process B fails to execute, the container is forced to stop operating, the monitoring platform gives an alarm, and the operation tool comprising the host process A succeeds in executing, and the container succeeds in operating.
Step five: an AppAArmor profile is created on the Docker engine.
The method comprises the steps of setting a Docker engine to be a mode specified by an AppArmor configuration file, limiting the engine according to official default rule requirements, and forcing a container to stop running when a vulnerability of the Docker engine appears.
Step six: and testing the alarm function of the monitoring platform.
6.1 Repeat step 3.4) above), for the container making action B to run again, the monitoring platform will issue an alarm directly before the container is forced to stop;
6.2 Repeat step 4.4) above) and for the running tool containing the host process B to run again, the monitoring platform will issue an alarm directly before the container is forced to stop.
And the third step, the fourth step and the fifth step have no requirement on the sequence.
The foregoing description is only an example of the present invention and is not intended to limit the invention, so that it will be apparent to those skilled in the art that various changes and modifications in form and detail may be made therein without departing from the spirit and scope of the invention.

Claims (5)

1. A safety protection method for limiting Docker container behaviors refers to the limitation of three components, namely a container, a running tool and a Docker engine, and is characterized in that the implementation steps comprise the following steps:
(1) Create AppArmor profile on each container and restrict its access functions:
(1a) During container initialization, collecting important static information related to a container and access thereof by adopting a static analysis mechanism, creating a configuration file, forming a most basic access rule during initialization according to a volume of the container and user information, and adding the rule into the configuration file;
(1b) During the operation of the container, a dynamic monitoring method is adopted to standardize the behaviors of network access and file access by the collection container in a specified training time to form a rule, the rule is added into a configuration file and compared with the configuration file generated during initialization, unnecessary rules in the configuration file generated during initialization are abandoned, and finally the configuration file containing new rules of container access is generated;
(1c) When the container operates again, the configuration file automatically judges whether the access of the container meets the rules according to the new rules of the container, and if the network access and the file access of the container violate the rules in the configuration file, the container is forced to stop operating;
(2) Creating an AppArmor profile on each running tool and limiting its execution functions:
(2a) During container initialization, collecting root installation point information of a container, creating a separate temporary configuration file for each running tool, forming an execution rule of the running tool during initialization according to the root installation point information, and adding the rule into the temporary configuration file;
(2b) During the operation of the container, in the set training time, converting the temporary configuration file generated during the initialization into a final configuration file by using a one-way configuration file conversion function, wherein the final configuration file comprises a rule for judging whether a host process accessing the container is legal or not;
(2c) When the container operates again, the final configuration file automatically judges the legality of the host process, if the illegal process of the host accesses the container, the rule in the final configuration file is violated, and the operation tool forces the container to stop operating;
(3) Creating an AppArmor configuration file on a Docker engine, namely setting the Docker engine to be a mode specified by the AppArmor configuration file, limiting the engine according to official default rule requirements, and forcing the container to stop running when a vulnerability of the Docker engine appears;
(4) Establishing a visual behavior monitoring platform, monitoring the behavior specification of the Docker container in real time, recording the behavior of the three components as illegal behaviors and starting an alarm after the container is forcibly stopped if the behavior of the three components is not in accordance with the rules in the configuration file, and directly sending an alarm before the container is forcibly stopped if the illegal behaviors occur again.
2. The method of claim 1, wherein the most basic access rules during initialization are formed in (1 a) based on the volume of the container and the user information, and the rules are used to specify the behavior of the collected container to access the specific folders, files of the host and the specific users who can access the container, i.e. the container can access the specific folders, files of the host and the specific users who can access the container, and the rules are made as to which files and folders of the host and which users can access the container.
3. The method of claim 1, wherein the behavior of the container on network access and file access is specified in (1 b) based on constraints on which network ports the container can access and which file systems in the host can be accessed based on behavior information collected on which network ports the container can access and which file systems in the host can be accessed.
4. The method according to claim 1, wherein the forming of the execution rule of the runtime during initialization tool in (2 a) based on the root installation point information is to make a specification of which processes can run bidirectionally between the container and the host for information of a specific process that runs bidirectionally between the container and the host to be collected.
5. The method of claim 1, wherein the step (2 b) of using a one-way profile transformation function to transform the temporary profile generated during initialization into the final profile is to transform the temporary profile containing rules that allow bi-directional processes between the container and the host into the final profile containing rules that allow only one-way access to the container by the host process.
CN202110487711.6A 2021-05-06 2021-05-06 Safety protection method for limiting Docker container behaviors Active CN113220417B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202110487711.6A CN113220417B (en) 2021-05-06 2021-05-06 Safety protection method for limiting Docker container behaviors

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202110487711.6A CN113220417B (en) 2021-05-06 2021-05-06 Safety protection method for limiting Docker container behaviors

Publications (2)

Publication Number Publication Date
CN113220417A CN113220417A (en) 2021-08-06
CN113220417B true CN113220417B (en) 2022-10-04

Family

ID=77090817

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202110487711.6A Active CN113220417B (en) 2021-05-06 2021-05-06 Safety protection method for limiting Docker container behaviors

Country Status (1)

Country Link
CN (1) CN113220417B (en)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104601580A (en) * 2015-01-20 2015-05-06 浪潮电子信息产业股份有限公司 Policy container design method based on mandatory access control
CN107608757A (en) * 2017-08-29 2018-01-19 华为技术有限公司 A kind of isolation processing method and relevant device based on container
CN110851241A (en) * 2019-11-20 2020-02-28 杭州安恒信息技术股份有限公司 Safety protection method, device and system for Docker container environment

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180167415A1 (en) * 2016-12-08 2018-06-14 Wanclouds Inc. System and Method for Simplifying Mandatory Access Control Policies

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104601580A (en) * 2015-01-20 2015-05-06 浪潮电子信息产业股份有限公司 Policy container design method based on mandatory access control
CN107608757A (en) * 2017-08-29 2018-01-19 华为技术有限公司 A kind of isolation processing method and relevant device based on container
CN110851241A (en) * 2019-11-20 2020-02-28 杭州安恒信息技术股份有限公司 Safety protection method, device and system for Docker container environment

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
"Docker容器安全隔离机制研究";胡家发;《中国优秀硕士学位论文全文数据库 信息科技辑》;20180615(第06期);第I138-148页 *
"Enhancing security of Docker using Linux hardening technique";Amith Raj MP等;《2016 2nd International Conference on Applied and Theoretical Computing and Communication Technology (iCATccT)》;20170427;第94-99页 *
基于Docker的容器虚拟化技术;林跃等;《中国新通信》;20200505(第09期);全文 *

Also Published As

Publication number Publication date
CN113220417A (en) 2021-08-06

Similar Documents

Publication Publication Date Title
US8955108B2 (en) Security virtual machine for advanced auditing
US20070261120A1 (en) Method & system for monitoring integrity of running computer system
CN106687971A (en) Automated code lockdown to reduce attack surface for software
KR102542720B1 (en) System for providing internet of behavior based intelligent data security platform service for zero trust security
Patrascu et al. Logging system for cloud computing forensic environments
US20150222666A1 (en) OWL-Based Intelligent Security Audit
US9268492B2 (en) Network based management of protected data sets
Luo et al. Virtualization security risks and solutions of cloud computing via divide-conquer strategy
Onarlioglu et al. Privexec: Private execution as an operating system service
Zhu et al. General, efficient, and real-time data compaction strategy for APT forensic analysis
CN103347027A (en) Trusted network connecting method and system
WO2021046637A1 (en) Methods and systems for data self-protection
Jamkhedkar et al. A framework for realizing security on demand in cloud computing
CN115904605A (en) Software defense method and related equipment
CN113220417B (en) Safety protection method for limiting Docker container behaviors
CN117032894A (en) Container security state detection method and device, electronic equipment and storage medium
CN115906184B (en) Method, device, medium and electronic equipment for controlling process to access files
Wang et al. The researches on public service information security in the context of big data
Zhan et al. Cfwatcher: A novel target-based real-time approach to monitor critical files using vmi
CN105120010A (en) Anti-stealing method for virtual machine under cloud environment
Wongthai et al. A generic logging template for infrastructure as a service cloud
CN105701400A (en) Virtual machine platform safety control method and device
WO2020102925A1 (en) Method for monitoring tampering of static objects in mixed environment
Cai et al. Medical big data intrusion detection system based on virtual data analysis from assurance perspective
Jinbo et al. Research on Operating System Kernel Security Based on Mandatory Behavior Control Mechanism (MBC)

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant