Kernel-level high-speed docker container internal process quantity measuring method and device

Abstract

The application provides a kernel state high-speed docker container internal measurement method and device, belongs to the container measurement technical field, and includes a kernel state measurement function component and a user state auxiliary function component, wherein the user state auxiliary function component is in communication connection with the kernel state measurement function component, is used for assisting the kernel to obtain a container image name of a running container, solidifying and storing a measurement strategy based on the image name, and assisting the kernel state measurement function component to complete a measurement function; and the kernel state measurement function component includes a strategy library cache, a container image name cache and a measurement task queue thread. The method of the application reduces strategy configuration redundancy, optimizes the interaction logic of the kernel state and the user state, controls the interaction and control of the user state and the kernel state to be minimum, and reduces system resource occupation during overall operation.

Description

TECHNICAL FIELD

[0001] The present application relates to a process for measuring the degree of progress, in particular to a kernel state high-speed docker container process for measuring the degree of progress and a device thereof, and belongs to the technical field of container process degree of progress. BACKGROUND

[0002] During system operation, business software may be subjected to remote malicious attacks. Some attack behaviors may tamper with the read-only data segment or code segment of the program to change the local behavior of the program and thus achieve the purpose of executing malicious code. A measurement verification technology based on detecting the read-only data segment and code segment of the running process emerges as the times require. The main logic is to configure an anchor point through the execution program file path for strategy to decide which running processes need to be measured. This way, the user can configure the strategy before the program runs and start the memory state measurement detection automatically after the program runs. Or, the pid is used to decide which processes need to be measured, but the user needs to configure it temporarily after the software is executed, which has limitations in use scenarios.

[0003] In actual business, some users' core applications are deployed in the form of docker containers. For practicality, the user administrator needs to configure the strategy before or after the business deployment, but at this time, the information that the administrator can usually obtain is the container image name and the program file path in the container. Therefore, a method is needed in actual use that can configure the progress measurement strategy through the container image name and the container kernel software execution file path to monitor whether the process has been tampered with.

[0004] The existing related technologies can be divided into two schemes.

[0005] a scheme: based on user state monitoring target measurement program execution and exit, and issuing pid to the kernel for measurement processing, the kernel state determines whether the target needs to be measured according to the pid.

[0006] b scheme: the kernel state monitors process creation and transfers information to the user layer to decide whether measurement is needed, and then issues the result to the kernel for processing.

[0007] The two schemes have the following problems:

[0008] The a scheme uses pure user state to monitor process creation, which has the problem of large performance consumption no matter whether it is based on proc file system scanning or based on monitoring whether the execution program file is called. At the same time, based on proc scanning, there is a real-time problem that may cause missed scanning or repeated false judgment (the core reason is that process creation is dynamic).

[0009] The b scheme needs to perform kernel state and user state interaction every time the process creation is monitored, although the real-time problem of the target process monitoring can be solved, the system overhead is still large. SUMMARY

[0010] In view of the above problems, the present application provides a kernel state high-speed docker container internal process degree measurement method and device, which reduces policy configuration redundancy, optimizes kernel state and user state interaction logic, and reduces system resource occupation.

[0011] To achieve the above object, the technical scheme of the present application is as follows: a kernel state high-speed docker container internal process degree measurement device, the device comprises a kernel state measurement function component and a user state auxiliary function component, wherein,

[0012] The user state auxiliary function component is in communication connection with the kernel state measurement function component, and is used for assisting the kernel to obtain the container image name of the running container, solidifying and saving the measurement policy based on the image name, and assisting the kernel state measurement function component to complete the measurement function;

[0013] The kernel state measurement function component comprises a policy library cache, a container image name cache and a measurement task queue thread, wherein the policy library cache is in communication connection with the user state auxiliary function component, and is used for saving the measurement policy written by the user; the container image name cache is in communication connection with the user state auxiliary function component, and is used for saving the id and the container image name of the running container obtained by the user state auxiliary function component; the measurement task queue thread is in communication connection with the policy library cache, and is used for querying the container image name related to the process in the container image name cache, and executing the process degree measurement based on the measurement policy of the process matched by the kernel from the policy library cache.

[0014] A method for measuring the degree of a docker container process, which is realized by using the above-mentioned kernel state high-speed docker container internal process degree measurement device, and comprises the following steps:

[0015] a. The kernel state monitors the process creation behavior,

[0016] b. When the process creation is monitored, the kernel state determines whether the process belongs to the container process through the cgroup hierarchical structure of the current process, and if yes, further determines whether it is a docker container process;

[0017] c. If it is a docker container process, the next step is executed, otherwise the measurement decision flow is exited and the process itself continues to run;

[0018] d. The container image name to which the process belongs is queried from the container image name cache list according to the cgroup id of the current process, if not queried, step e is executed, and if queried, step f is executed;

[0019] e. Pack the current process pid information and the cgroup id information to which the process belongs, and send the information to the user layer through the netlink communication mechanism to trigger the container image name query event, and jump out of the measurement decision-making process to continue running the process itself;

[0020] f. The process belongs to the container image name obtained by the query action in step d, and the current process file path information is combined to query the policy library cache; if the policy matching is queried, the process object information is transmitted to the measurement task queue, otherwise the measurement decision-making process is jumped out to continue running the process itself;

[0021] g. In a separate thread, the process execution measurement is performed on the measurement task queue.

[0022] Further, in step a, the kernel state monitors the creation behavior of all processes through the hook function in the standard LSM framework.

[0023] Further, in step b, whether the process belongs to the container process and whether it is a docker container process is determined by communicating with the user layer to obtain process information through the sysfs communication mechanism.

[0024] Further, step e further comprises the following steps:

[0025] e.1 After receiving the container image name query event, the user layer queries the container image name to which the cgroup id belongs;

[0026] e.2 The user layer transmits the queried container image name and cgroup id key-value pair back to the kernel and writes it to the kernel container image name cache;

[0027] e.3 The queried process information is issued to the kernel to inform the kernel to reattempt measurement in order to create a baseline value;

[0028] e.4 The kernel obtains the target process information according to the user issued instruction, and executes step b.

[0029] Further, in step e.1, the container image name to which the cgroup id belongs is queried by using the docker tool or api interface.

[0030] Further, in step e.2, the queried container image name and cgroup id key-value pair are written to the kernel container image name cache through the sysfs communication mechanism.

[0031] Further, the measurement policy in the policy library cache in step f is written by the user through the sysfs communication mechanism.

[0032] Further, when the kernel state checks the cgroup_rmdir action, the corresponding cgroup id and container image name key-value pair in the container image name cache is cleaned up.

[0033] An electronic device, the device comprising: a processor and a memory storing computer program instructions;

[0034] The processor implements the method of measuring the degree of process in the docker container as described above when executing the computer program instructions.

[0035] The kernel state high-speed docker container process in-degree measurement method and device of the application has the beneficial effects that:

[0036] When the user side configures the strategy, only the container image name and the process path in the container that needs to be monitored need to be known. For example, the / usr / bin / test program in the Ubuntu-test container running instance created by the container image ubuntu-1.0. The previous method is to retrieve the process pid in the container through the user layer, and then implement target locking according to the pid under the kernel. Once the process is re-run or multi-process runs, it is necessary to re-detect which processes need to be monitored or controlled. The process has hysteresis and is easy to miss.

[0037] Using the method of the application, the target can be directly locked through the image name ubuntu-1.0 and / usr / bin / test, and the strategy configuration only needs to be issued to the kernel once, and there is no need to repeatedly issue the strategy subsequently. The specific process tracking is completely implemented in the kernel state, and no missing tracking can be guaranteed. At the same time, since the main logic is all in the kernel, only the user side container image name query request will be triggered once when a new container is started. After the container image name of the running container instance is cached, the container image name of the detected process no longer needs to go through context switching, and the timeliness can also be guaranteed. Through extension, the method can not only be used for dynamic measurement components, but also be used for container execution control, static measurement and other security function fields that need to identify process identity. BRIEF DESCRIPTION OF DRAWINGS

[0038] The application will be further described in detail below in combination with the drawings and specific embodiments.

[0039] Figure 1 is a general idea schematic diagram of a kernel state high-speed docker container process in-degree measurement method of the application;

[0040] Figure 2 is a specific application workflow schematic diagram of a kernel state high-speed docker container process in-degree measurement method of the application. DETAILED DESCRIPTION

[0041] The technical solutions in the embodiments of the present application will be described clearly and completely below with reference to the drawings in the embodiments of the present application. In the following description, a large number of specific details are set forth in order to facilitate a thorough understanding of the present application, but the present application can also be implemented in other manners different from those described herein, and those skilled in the art can make similar generalizations without departing from the spirit and scope of the present application, so the present application is not limited to the specific embodiments disclosed below.

[0042] Terminology

[0043] cgroupid: Control group (cgroup) is a function of the Linux kernel, which is used to limit, isolate and monitor the resource usage (such as CPU, memory, disk I / O, etc.) of processes, and cgroup id is a 64-bit hexadecimal number allocated by the kernel to each cgroup. It is used here to assist in querying the container image name.

[0044] pid: A numerical symbol used to identify a process in a Linux system.

[0045] Code segment: The area in memory where the executable code of a program is specifically stored, containing the machine instructions of the program. It is usually read-only to prevent the code from being accidentally modified. The code segment is mapped into memory when the program is loaded, and the CPU reads instructions from it during execution.

[0046] Read-only data segment: A memory area in a program that stores constants or unmodifiable data.

[0047] Container instance: A container running entity that is unfolded and deployed from a container image locally, which contains all the necessary program software for the relevant business, and can be understood as a decompression of a container image. One container image can be decompressed into multiple container instances.

[0048] Embodiment 1

[0049] The present application is a kernel-level high-speed docker container internal process quantity method and device, and when configuring the strategy, the user only needs to care about which container image the business software belongs to and the container internal running program file path (i.e. the execution file path in the following), and does not need to pay attention to the state information after the container runs during the strategy configuration process, thereby reducing the strategy configuration redundancy. At the same time, the interaction logic between the kernel state and the user state is optimized, the user state and the kernel state interaction control is minimized, and the overall running reduces the system resource occupation. The overall idea is as follows:

[0050] The implementation of the present application is completed by two parts of a kernel state measurement function component and a user state auxiliary function component, wherein the main function of the user state auxiliary function component is to assist the kernel to obtain the container image name of a running container, to solidify and save the measurement policy based on the image name, and to assist the kernel state measurement function component to complete the measurement function. The kernel state measurement function component is the main body of the measurement function, mainly including a policy library cache, a container image name cache, and a measurement task queue thread.

[0051] In combination Figure 1 As shown, the user state auxiliary function component first scans the running containers on the system when the query function is started, and assists the kernel to write the id and container image name of the known running containers on the system (which can also be the running container id and container image name and container instance name) into the container image name cache in the kernel, wherein the query function is to query the relevant information by using the docker tool or api interface, and the docker runtime will maintain the state of all started container instances, and the above tool can be used in the user space to query more easily, at this time, the process cgroup id consistent with the container instance id does not need to be obtained. The user state auxiliary function component receives the request of the kernel to obtain the image name to assist in query when the kernel state measurement function component cannot query the container image name, and writes the queried container image name and running container id into the container image name cache in the kernel. The user state auxiliary function component is also responsible for writing the localized storage of the measurement policy based on the image name into the policy library cache in the kernel. The running container id is the same as the cgroup id, and in the concept of docker container, there is a container image entity first, and then a specific container running instance is released based on the container image; the isolation of the container and the host system is realized by relying on the namespace and cgroup mechanisms, and the implementation manner is that each "container instance" will be allocated a unique "cgroup id" when it is expanded, and all processes in the present "container instance" will inherit and use this cgroup id (which can be logically understood as belonging to this cgroup id); according to this characteristic, the "cgroup id" can be used to reversely deduce which container instance the process belongs to, and which container image the container instance belongs to is also obtained; that is, the cgroup id of the container instance is the same as the cgroup id in the process attribute of the container, and more accurately, the cgroup id of the container instance determines the cgroup id of the process in the instance.

[0052] When the kernel mode measurement function component detects process creation, the container image name in the container image name cache is queried to determine whether the process belongs to a container process, and whether measurement is required according to the container image name and the execution file path. If measurement is required, the measurement strategy in the strategy library cache is queried to build a measurement task and deliver it to the measurement task queue. If the container image name of the current process cannot be found in the kernel state, the information is reported to the user state auxiliary function component, and the container image name is queried by the user layer program and returned to the kernel, and the process measurement task is triggered again to ensure that the new process can create a measurement benchmark value in time. For system security monitoring or system bottom layer execution process control, the granularity of the controlled object is usually a process, and the process is born from an executable program. In the conventional security policy configuration, the subject object (the object that will operate other resources or the monitored object) will use the full path of the executable file as the identity identification when configuring the static policy, such as / usr / bin / ls. For example, we can save the hash value of / usr / bin / ls in the container instance Ubuntu-1.0-test1 expanded by the container image Ubuntu-1.0 to a separate database, and if the saved index value uses Ubuntu-1.0: / usr / bin / ls --> original hash, it is used for hash comparison when the ls command is tampered. Similarly, the ls command can be granted specific permissions or certain restrictions. In addition, it is relatively easy to obtain the container process execution file path of a container in the kernel state and the cgroup id of the container, but the original kernel resource cannot directly obtain the container name or container image name of the process. The present application mainly solves the problem of immediate information acquisition and uses it for security control policy configuration and measurement, and can also be used to optimize the readability of kernel output logs.

[0053] In addition, when a container instance starts running, the container will automatically assign a cgroup id that has been preset when the container instance is first created locally, and use the id to build a cgroup attribute directory. For the kernel state, if the cgroup_rmdir action is checked, it means that a container instance may have exited, and the cache is cleaned up when the container instance is not running to avoid memory occupation under extreme conditions and prevent the container instance from being deleted at the user layer container management tool level and using the id for other newly constructed container instances.

[0054] The overall implementation effect of the present application is that: after any container object runs, at most only one kernel state and user state interaction is triggered, and thereafter the container can query the container image name through the kernel state container image name cache regardless of whether it is restarted or not, greatly improving the running efficiency.

[0055] Embodiment 2

[0056] This embodiment is based on Embodiment 1, combined with Figure 2 Further introduce the specific application of the kernel state high-speed docker container process measurement method, the specific steps are as follows:

[0057] a. The kernel state monitors the creation behavior of all processes through the standard LSM framework, that is, when a process is created, the hook function in the LSM framework is used for monitoring.

[0058] b. When the process creation is monitored, the kernel state preliminarily determines whether the process belongs to the container process through the cgroup hierarchical structure of the current process, and if so, further determines whether it is a docker container process; wherein determining whether the process belongs to the container process and whether it is the docker container process is determined by communicating with the user layer through the sysfs communication mechanism to obtain process information.

[0059] c. If it is a docker container process, the next step is executed, otherwise the measurement decision flow is exited and the process itself continues to run (corresponding to Figure 2 measurement decision detection is exited, and the business process continues to execute).

[0060] d. According to the cgroup id of the current process, the container image name to which the process belongs is queried from the container image name cache list, if not queried, step e is executed, if queried, step f is executed;

[0061] e. Package the current process pid and other information and the cgroup id information to which the process belongs, send the information to the user layer through the netlink communication mechanism to trigger the container image name query event, and exit the measurement decision flow and continue to run the process itself. The present application mainly describes the measurement of the process (that is, dynamic measurement). Due to technical reasons, the process measurement is allowed to have hysteresis. When e is executed, it means that kernel to user layer interaction is generated. If blocked and waited, it will cause large delay, and improper logic processing may even affect the container startup running time sequence. Therefore, the process itself continues to run by exiting the measurement decision flow, that is, this time the measurement is not performed, and e1, e2 and e3 in the following are user behaviors. When e3 is executed, the user layer gives the kernel the measurement task, and then the kernel executes e4 measurement action. The purpose is to reduce the communication busy waiting between the kernel and the user layer.

[0062] e.1 After the user layer receives the container image name query event, the container image name to which the cgroup id belongs is queried by using the docker tool or api interface.

[0063] e.2 User layer passes the queried container image name and cgroup id key-value pair back to kernel, writes to kernel state container image name cache through sysfs communication mechanism.

[0064] e.3 Once the queried process information is issued to kernel, the kernel is informed to retry the measurement in order to create the baseline value (corresponding to Figure 2 the retriggered task-sysfs communication mechanism-get process information).

[0065] e.4 Kernel gets target process information according to user issued instruction and executes b step. The execution of b step here takes advantage of docker implementation feature, which can check whether the current process is the process of docker container kernel according to the cgroup level information available in kernel. If yes, it will contain obvious "docker" field. If not, it will not process the process.

[0066] f. Through d step query action, the container image name to which the process belongs is obtained, and the current process execution file path information is combined to query the policy from policy library cache. If the policy matching is queried, the process object information (here, the process object information includes container image name + container execution file path + policy configuration for the process, etc.) is passed to the measurement task queue. Otherwise, the measurement decision flow is exited and the process itself continues to run. User policy issuance is also written into policy library cache through sysfs communication mechanism.

[0067] g. In a separate thread, the process in the measurement task queue is executed (the purpose is to minimize the impact on the time slice of the current process).

[0068] Wherein, the above-mentioned netlink is a socket communication mechanism for direct communication between kernel and user layer program, which can realize the logic similar to network communication between two application software. Sysfs is a "fake file" that can be built in kernel, which is different from traditional file, and it has no entity content. If the user reads the file, the read function registered by the kernel to the file will be called, and the write function registered in the kernel will be called when writing the file. In this way, the user layer program can pass data to the kernel code like writing a file, and the kernel code is further processed. The process is usually a synchronous communication process. The files under / proc and / dev are similar to such files. There is no essential difference in / sys / kernel / security.

[0069] In summary, the present application has the following technical features:

[0070] The application configures a measurement strategy by using a container image name, or configures a measurement strategy by using a container image name + a program path executed in a container; an association cache of a container image name-cgroup id is established in a kernel, necessary information is only obtained by a user layer, complete measurement control logic is put into the kernel, and attack resistance is improved; for a single execution program, a strategy only needs to be issued once to the kernel, and the user layer does not need to continuously track process creation and exit and repeatedly issue strategies for multiple processes of the same program.

[0071] Obviously, the described embodiments are only part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative labor belong to the protection scope of the present application.

Claims

1. A method for measuring processes within a Docker container, implemented using a high-speed kernel-level Docker container process measurement device, characterized in that... The device includes a kernel attitude function component and a user-mode auxiliary function component, wherein, The user-mode auxiliary function component is communicatively connected to the kernel attitude quantity function component, and is used to assist the kernel in obtaining the container image name of the running container, permanently saving the measurement policy based on the image name, and assisting the kernel attitude quantity function component in completing the measurement function. The kernel attitude measurement function component includes a policy library cache, a container image name cache, and a measurement task queue thread. The policy library cache is communicatively connected to the user-space auxiliary function component and is used to store the measurement policies written by the user. The container image name cache is also communicatively connected to the user-space auxiliary function component and is used to store the ID of the running container and the container image name obtained by the user-space auxiliary function component. The measurement task queue thread is communicatively connected to the policy library cache and is used to perform process measurement based on the measurement policy of the process matched by the kernel from the policy library cache, provided that a container image name related to the process is found in the container image name cache. The method includes the following steps: a. Kernel-mode monitoring of process creation behavior b. When process creation is detected, the kernel mode initially determines whether the process belongs to the container process through the cgroup hierarchy of the current process. If so, it further determines whether it is the process inside the Docker container. c. If it is a process inside a Docker container, proceed to the next step; otherwise, exit the metric decision process and continue running the process itself. d. Based on the cgroup ID of the current process, query the container image name to which the process belongs from the container image name cache list. If not found, proceed to step e; otherwise, proceed to step f. e. Package the current process PID information and the cgroup ID information to which the process belongs, send the information to the user layer through the netlink communication mechanism, trigger the container image name query event, and exit the metric decision process to continue running the process itself; f. Using the container image name of the process obtained through step d, combine it with the current process's executable file path information to perform a policy query from the policy library cache; if a policy match is found, pass the process object information to the metric task queue; otherwise, exit the metric decision process and continue running the process itself. g. Perform process metrics on processes in the metric task queue in a separate thread.

2. The method according to claim 1, characterized in that, In step a, the kernel monitors the creation behavior of all processes through the hook function in the standard LSM framework.

3. The method according to claim 1, characterized in that, In step b, determining whether a process belongs to a container process and whether it is a Docker container process is done by communicating with the user layer through the sysfs communication mechanism to obtain process information.

4. The method according to claim 1, characterized in that, Step e also specifically includes the following steps: e.1 After receiving a container image name query event, the user layer queries the container image name belonging to the cgroup ID to which the process belongs; e.2 The user layer passes the retrieved container image name and cgroup id key-value pair back to the kernel and writes it to the kernel-mode container image name cache; e.3 Send the queried process information to the kernel to inform the kernel to retry the measurement in order to create a baseline value; The e.4 kernel obtains target process information based on user-issued instructions and executes step b.

5. The method according to claim 4, characterized in that, In step e.1, the container image name to which the cgroup ID of the process belongs is queried using Docker tools or API interfaces.

6. The method according to claim 4, characterized in that, In step e.2, the queried container image name and cgroup id key-value pair are written to the kernel-mode container image name cache through the sysfs communication mechanism.

7. The method according to claim 1, characterized in that, The metric policies in the policy library cache in step f are written by the user through the sysfs communication mechanism.

8. The method according to claim 1, characterized in that, When the kernel detects a cgroup_rmdir action, it clears the corresponding cgroup id and container image name key-value pairs from the container image name cache.

9. An electronic device, characterized in that, The device includes: a processor and a memory storing computer program instructions; When the processor executes the computer program instructions, it implements the method for measuring processes within a Docker container as described in any one of claims 1-8.

Images