A detection method for container resource escape defects

By creating two containers with a shared namespace in the kernel, resource escape during container restart is detected, solving the exhaustion problem caused by unsynchronized resource destruction during container restart, achieving early discovery of vulnerabilities, and applicable to environments with multiple container tools.

CN119166274BActive Publication Date: 2025-09-05HUAZHONG UNIV OF SCI & TECH
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
CN202411130263.4
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2024-08-16
Publication Date
2025-09-05
Estimated Expiration
2044-08-16

AI Technical Summary

Technical Problem

In container technology, when multiple containers share a namespace, previously created resources are not destroyed synchronously during container restart, causing the cgroup resource record values ​​to be cleared, resulting in escaped resources that gradually accumulate and lead to resource exhaustion.

Method used

By creating two containers with a shared namespace in the kernel, using one container to run system calls to create resources and restart, and the other container to query whether the resources exist, the difference between the cgroup resource record value and the initial value is compared, the degree of resource escape is evaluated, and the detection results are output.

Benefits of technology

Discover vulnerabilities in container creation tools in advance to avoid resource exhaustion. This solution is applicable to environments built with different container tools and does not require kernel modifications.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119166274B_ABST
    Figure CN119166274B_ABST
Patent Text Reader

Abstract

The present invention belongs to the technical field related to computer resource management, and discloses a detection method for container resource escape defects, including: using a container creation tool to be detected to create a first container and a second container in a shared namespace, obtaining the sum of the current resource record values ​​of the two containers as a reference value; running a test project in the first container; restarting the first container; querying whether the resources created when running the current test project still exist in the current namespace: if so, obtaining the sum of the current resource record values ​​of the two containers as a target value, and then deleting the created resources; calculating the difference between the target value and the reference value, and outputting a detection result reflecting the degree of resource escape based on the difference; if not, outputting a detection result indicating that there is no resource escape defect. Through the above method, a container production environment with a shared namespace in a real environment can be simulated, container tools can be detected in advance, and resource exhaustion vulnerabilities can be avoided in actual applications.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present invention belongs to the technical field related to computer resource management, and more specifically, relates to a detection method for container resource escape defects. Background Art

[0002] Container technology has been widely applied in a wide range of fields, such as cloud computing, edge computing, and autonomous driving. Container technology has two cornerstones: namespaces and control groups (cgroups).

[0003] A namespace can isolate a group of processes and maintain resources specific to them, isolating them from global kernel resources. For example, a process namespace (PID) has a linked list independent of other PID namespaces. This linked list is used only to maintain all processes belonging to that PID namespace. When the last process in a namespace exits, the namespace disappears, and the kernel traverses all resources maintained by that namespace and destroys them.

[0004] Cgroups can implement statistics and limits on a set of resources (such as memory, I / O rate, network bandwidth, etc.). When a container is created, the runtime automatically creates a cgroup for the container. When a process is executed in the container, the container's own cgroup is used to limit the process's use of resources.

[0005] When using container technology in practice, problems with abnormal resource consumption may occasionally occur. That is, while the host is running the container service, some resources are gradually consumed, and the host may even crash, but the cgroup resource records of each container are not high. Summary of the Invention

[0006] In response to the above-mentioned defects or improvement needs of the existing technology, the present invention provides a detection method for container resource escape defects, the purpose of which is to detect whether there are problems with the container creation tool beforehand, so as to avoid resource exhaustion vulnerabilities during the use of container technology.

[0007] To achieve the above objectives, the present invention provides a method for detecting container resource escape defects, which includes:

[0008] Step S1: Using a container creation tool to be tested, create a first container and a second container sharing a namespace in the kernel, generate a first control group for limiting resources for the first container, and generate a second control group for limiting resources for the second container, obtain the sum of the currently recorded resource amounts of the first control group and the second control group as a reference value, and determine a test item set, where the test items in the test item set are system calls adapted to the current namespace;

[0009] Step S2: running an untested test project in the first container for testing, creating resources required by the current test project in the namespace, and recording the amount of created resources in the first control group;

[0010] Step S3: Restarting the first container, and updating the first control group with the restart of the first container;

[0011] Step S4: Invoke the resource query method of the current test project in the second container to query whether the resources created when running the current test project still exist in the current namespace; if so, execute step S5; if not, output a detection result indicating that the current test project does not have a resource escape defect, and execute step S6;

[0012] Step S5: obtaining the sum of the currently recorded resource amounts of the first control group and the second control group as a target value, then calling the resource deletion method of the current test item to delete the resources created by the current test item; calculating the difference between the target value and the reference value, and outputting a detection result reflecting the degree of resource escape of the current test item based on the difference, where the larger the difference, the smaller the degree of resource escape;

[0013] Step S6: Determine whether all test items in the test item set have been tested. If not, jump to step S2; if so, execute step S7;

[0014] Step S7: End the detection.

[0015] Preferably, in step S5, outputting the resource escape degree of the current test item based on the difference includes:

[0016] Compare the difference with the resource escape threshold of the current test item. If the difference is less than the resource escape threshold, it is determined to be a severe defect and a vulnerability report is output;

[0017] The vulnerability report includes the current namespace, the resource creation method of the current test project, and the method of the container creation tool to create multiple containers that share the current namespace;

[0018] The resource escape threshold is greater than 80% of the amount of resources created by the current test item.

[0019] Preferably, the test items running in the first container are marked;

[0020] In step S6, it is determined whether all the test items in the test item set have been tested by determining whether there are any unmarked test items in the test item set.

[0021] Preferably, when the kernel is divided into multiple namespaces, steps S1 to S7 are performed for each namespace to obtain a detection result of the container resource escape vulnerability of the container creation tool to be detected corresponding to each namespace.

[0022] Preferably, the container creation tool is selected from any one of the docker tool and the podman tool.

[0023] Preferably, the namespace is selected from one or more of a process namespace, an inter-process communication namespace, a network namespace, and a mount namespace.

[0024] Preferably, the test items include shmget, semget, and fork.

[0025] The present invention also provides an electronic device, comprising a memory and a processor, wherein the memory stores a computer program, and the processor implements the steps of any of the above methods when executing the computer program.

[0026] The present invention also provides a computer-readable storage medium having a computer program stored thereon, and when the computer program is executed by a processor, the steps of any of the above methods are implemented.

[0027] The present invention also provides a computer program product, comprising a computer program or instructions, which implement the steps of any of the above methods when executed by a processor.

[0028] In general, the above technical solutions conceived by the present invention have the following beneficial effects compared with the prior art:

[0029] The present invention first discovered the problem of gradual resource exhaustion when using container technology. The reason is that when multiple containers share a namespace, during the container restart, the resources previously created by the container and its cgroup resource record values ​​cannot be destroyed synchronously. Its cgroup resource record values ​​can usually be cleared with the restart of the container, but the resources previously created are likely to still exist in the namespace. These resources are not recorded by the cgroup resource record values, forming escaped resources. As the number of container restarts increases, the escaped resources gradually accumulate, and the resources actually requested by the container far exceed its cgroup resource record values, resulting in resource exhaustion. Based on the root of the problem found, the present invention designs a detection method for container resource escape defects, which is used to detect vulnerabilities in container creation tools. The tool is used to build two containers with a shared namespace, one of the containers is used to run a system call, and resources are created in the namespace and then restarted. The other container is used to query whether the created resources exist in the namespace. If not, it means that no resource escape has occurred. If so, it is necessary to further compare the difference between the current cgroup resource record value and the initial cgroup resource record value to determine whether the cgroup resource record value records the remaining resources. Resources that are not recorded are escaped resources. The difference can be used to evaluate the degree of resource escape and output the detection results. Through the above method, the container production environment of a shared namespace in a real environment can be simulated, the container creation tool can be detected in advance, and the vulnerability of resource exhaustion in actual application can be avoided. The method does not require modification to the kernel, nor does it rely on a specific container tool. It can be easily used to detect resource theft or exhaustion vulnerabilities in container environments built by different container tools. BRIEF DESCRIPTION OF THE DRAWINGS

[0030] Figure 1 This is a flowchart of the steps of a method for detecting container resource escape defects in one embodiment of the present invention. DETAILED DESCRIPTION

[0031] In order to make the objectives, technical solutions and advantages of the present invention more clearly understood, the present invention is further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely for the purpose of explaining the present invention and are not intended to limit the present invention. In addition, the technical features involved in the various embodiments of the present invention described below may be combined with each other as long as they do not conflict with each other.

[0032] When creating multiple containers simultaneously, there are two scenarios: one in which the containers share a namespace and the other in which they do not. When containers do not share a namespace, each container has its own namespace and cgroup, and the coordination between the namespace and cgroup is reasonable. The namespace and cgroup are destroyed simultaneously when the container exits. All cgroup resource records and cgroup limits applied by the container disappear with the destruction of the cgroup, and the resources in the namespace itself also disappear with the destruction of the namespace. When multiple containers share the same namespace, the namespace is not destroyed when one container exits because it is still in use by other containers.

[0033] Research has found that when multiple containers share a namespace, the resources created in the namespace before the container exits may still exist in the namespace after the container exits, and the cgroup resource record value of the container may be cleared or reduced due to the exit of the container. That is, the actual resources existing in the namespace exceed the cgroup resource record value of all containers in the namespace, and the resources not recorded by the cgroup resource are escaped resources. Therefore, as the container is restarted (each restart performs an exit and reconstruction), the escaped resources increase, and the resources actually requested by the container far exceed its cgroup resource record value, resulting in resource exhaustion.

[0034] Based on the above findings, the present invention proposes the following solutions.

[0035] like Figure 1 The flowchart is a step flow chart of a method for detecting container resource escape defects in an embodiment of the present invention, which mainly includes steps S1 to S7. Each step is introduced below.

[0036] Step S1: Use the container creation tool to be tested to create a first container and a second container that share a namespace in the kernel, generate a first control group that limits resources for the first container, generate a second control group that limits resources for the second container, obtain the sum of the currently recorded resource amounts of the first control group and the second control group as a reference value, determine a test item set, and the test items in the test item set are system calls adapted to the current namespace.

[0037] Specifically, the container creation tool may be any container creation tool, such as the commonly used docker tool and podman tool.

[0038] Specifically, the namespace can be any namespace, such as a process namespace (PID namespace), an inter-process communication namespace (IPC namespace), a network namespace, and a mount namespace.

[0039] For example, in the docker tool, the "--ipc=A" option in the "docker run" command can be used to create a container that shares an IPC namespace with container A. Container A is then the first container, and the container that shares the IPC namespace with container A is the second container.

[0040] During the initial container creation phase, although system calls have not yet been executed, certain resources may have already been occupied. Therefore, the sum of the current cgroup resource records for the first and second containers is obtained as a reference value for subsequent comparisons. Each container's cgroup resource record records the amount of resources requested by the container, such as memory, I / O rate, and network bandwidth. Each container has a cgroup limit, and the total amount requested cannot exceed the cgroup limit.

[0041] Generally, different namespaces match different system calls. Therefore, a test item set may be determined based on the selected namespace. The test items in the test item set are system calls adapted to the current namespace.

[0042] Step S2: Run an untested test project in the first container for testing, create resources required by the current test project in the namespace, and record the created resource amount in the first control group.

[0043] When a system call is run in the first container, the first container applies for the resources required to run the system call and adds them to the namespace. At the same time, the cgroup resource record value of the first container is also updated to record the amount of resources requested by the first container in real time.

[0044] Step S3: Restart the first container.

[0045] Specifically, each time a container is restarted, it exits the namespace and is recreated. Conventional wisdom suggests that each time a container exits, its cgroup is destroyed, clearing its created resources and resource records. However, research has found that in reality, although the cgroup is destroyed when a container exits, the resources created by the container in the namespace suspiciously remain in the namespace. Since the cgroup is destroyed, the cgroup resource records are cleared, and the remaining resources are considered escaped resources. For example, the cgroup of the first container limits it to applying for a maximum of 1GB of memory. After the first restart, the first container creates 0.8GB of memory, and its cgroup resource record value is 0.8GB. During the second restart, the cgroup resource record value is cleared, but the previously created 0.8GB of memory is still in the namespace. After the second restart, it applies for another 0.8GB of memory, and its cgroup resource record value is 0.8GB. However, in fact, the first container has created a total of 1.6GB of memory in the namespace, exceeding its cgroup limit. As the number of restarts increases, the escaped resources that are not recorded by the cgroup resource record value gradually accumulate, resulting in the gradual exhaustion of kernel resources and causing failures.

[0046] Step S4: Call the resource query method of the current test project in the second container to query whether the resources created when running the current test project still exist in the current namespace; if so, execute step S5; if not, output the detection result that there is no resource escape defect in the current test project, and execute step S6.

[0047] It is understandable that each system call is configured with methods for creating, querying, and deleting its resources. In this step, the resource query method of the current test project is called in the second container to query whether the resources created when running the current test project still exist in the current namespace:

[0048] If it exists, it means that the resources created by the system call when the first container runs are not destroyed when the first container exits. At this time, it is necessary to continue to perform the subsequent step S5 to determine whether the cgroup resource record value of the first container records these resources;

[0049] If it does not exist, it means that the resources created by the system call when the first container runs are destroyed when the first container exits, and there is no resource escape when the first container runs the system call. The detection result that there is no resource escape when the container creation tool to be tested creates the container and runs the system call is output.

[0050] Step S5: Obtain the sum of the currently recorded resource amounts of the first control group and the second control group as the target value, and then call the resource deletion method of the current test project to delete the resources created by the current test project; calculate the difference between the target value and the reference value, and output the detection result reflecting the degree of resource escape of the current test project based on the difference.

[0051] Among them, the larger the difference, the smaller the degree of resource escape.

[0052] Specifically, after the first container is restarted, the sum of the current cgroup resource record values ​​of the first container and the second container is obtained as the target value, and the difference between the target value and the reference value is calculated. If the difference is small, it means that the target value is close to the initial reference value, that is, although there are residual resources of the first container, the cgroup resource record value of the first container is basically not recorded, and the degree of resource escape is relatively serious. If the difference is large, it means that the cgroup resource record value of the first container still records all or most of the residual resources after the restart, and the degree of resource escape is relatively light. Therefore, the detection result reflecting the degree of resource escape of the current test item can be output based on the difference.

[0053] A resource escape threshold can be set based on actual conditions. The difference is compared with the resource escape threshold for the current test project. If the difference is less than the resource escape threshold, a critical vulnerability is identified and a vulnerability report is generated. The vulnerability report includes the resource creation method for the current namespace and the current test project, as well as the method used by the container creation tool to create multiple containers sharing the current namespace. In one embodiment, the resource escape threshold is greater than 80% of the cgroup resources created by the current test project.

[0054] Thus, the test of the current test project is completed, and the resource deletion method of the current test project is called to delete the resources created by the current test project, so that the resources in the namespace and the cgroup resource record values ​​are restored to the initial state.

[0055] Step S6: Determine whether all test items in the test item set have been tested. If not, jump to step S2; if so, execute step S7.

[0056] Step S7: End the detection.

[0057] Specifically, other test items are tested one by one according to the above steps until all items are tested and the test is ended.

[0058] In one embodiment, each tested test item is marked as tested, and whether all test items in the test item set have been tested is determined by determining whether there are unmarked test items in the test item set.

[0059] In one embodiment, when the kernel is divided into multiple namespaces, steps S1 to S7 are performed for each namespace to obtain a detection result of the container resource escape vulnerability of the container creation tool to be detected corresponding to each namespace.

[0060] Example 2

[0061] The present invention also relates to an electronic device, comprising a memory and a processor, wherein the memory stores a computer program, and the processor implements the steps of the above method when executing the computer program.

[0062] The electronic device may be a computing device such as a desktop computer, a notebook, a PDA, or a cloud server. The processor may be a central processing unit (CPU), or other general-purpose processors, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The memory may be used to store computer programs and / or modules, and the processor may perform various functions of the electronic device by running or executing the computer programs and / or modules stored in the memory, and calling the data stored in the memory.

[0063] Example 3

[0064] The present invention also relates to a computer-readable storage medium having a computer program stored thereon, which implements the steps of the above method when the computer program is executed by a processor.

[0065] Specifically, the memory may include a high-speed random access memory, and may also include a non-volatile memory, such as a hard disk, a memory, a plug-in hard disk, a smart memory card (Smart Media Card, SMC), a secure digital (Secure Digital, SD) card, a flash card (Flash Card), at least one disk storage device, a flash memory device, or other volatile solid-state storage device.

[0066] Example 4

[0067] An embodiment of the present invention provides a computer program product or computer program, which includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the steps of the method of the above embodiment of the present invention.

[0068] The technical features of the above embodiments can be combined in any manner. To simplify the description, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification. It should be noted that the phrases "in one embodiment", "for example", "and another example", etc. of the present invention are intended to illustrate the present invention and are not intended to limit the present invention.

[0069] The above embodiments merely illustrate several implementations of the present invention, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the patent application. It should be noted that a person skilled in the art would be able to make numerous variations and improvements without departing from the spirit of the present invention, and all such variations and improvements fall within the scope of protection of the present invention.

Claims

1. A method for detecting container resource escape defects, characterized in that: include: Step S1: Using a container creation tool to be tested, create a first container and a second container sharing a namespace in the kernel, generate a first control group for limiting resources for the first container, and generate a second control group for limiting resources for the second container, obtain the sum of the currently recorded resource amounts of the first control group and the second control group as a reference value, and determine a test item set, where the test items in the test item set are system calls adapted to the current namespace; Step S2: running an untested test project in the first container for testing, creating resources required by the current test project in the namespace, and recording the amount of created resources in the first control group; Step S3: Restarting the first container, and updating the first control group with the restart of the first container; Step S4: Invoke the resource query method of the current test project in the second container to query whether the resources created when running the current test project still exist in the current namespace; if so, execute step S5; if not, output a detection result indicating that the current test project does not have a resource escape defect, and execute step S6; Step S5: obtaining the sum of the currently recorded resource amounts of the first control group and the second control group as a target value, and then calling the resource deletion method of the current test item to delete the resources created by the current test item; Calculating a difference between the target value and the reference value, and outputting a detection result reflecting the degree of resource escape of the current test item based on the difference, wherein the larger the difference, the smaller the degree of resource escape; Step S6: Determine whether all test items in the test item set have been tested. If not, jump to step S2; if so, execute step S7; Step S7: End the detection.

2. The method for detecting container resource escape defects according to claim 1, wherein: In step S5, outputting the resource escape degree of the current test item based on the difference includes: Compare the difference with the resource escape threshold of the current test item. If the difference is less than the resource escape threshold, it is determined to be a severe defect and a vulnerability report is output; The vulnerability report includes the current namespace, the resource creation method of the current test project, and the method of the container creation tool to create multiple containers that share the current namespace; The resource escape threshold is greater than 80% of the amount of resources created by the current test item.

3. The method for detecting container resource escape defects according to claim 1, wherein: Marking the test items running in the first container; In step S6, it is determined whether all the test items in the test item set have been tested by determining whether there are any unmarked test items in the test item set.

4. The method for detecting container resource escape defects as claimed in claim 1, wherein: When the kernel is divided into multiple namespaces, steps S1 to S7 are performed for each namespace to obtain a detection result of the container resource escape vulnerability of the container creation tool to be detected corresponding to each namespace.

5. The method for detecting container resource escape defects as claimed in claim 1, characterized in that: The container creation tool is selected from any one of the docker tool and the podman tool.

6. The method for detecting container resource escape defects as claimed in claim 1, characterized in that: The namespace is selected from one or more of a process namespace, an inter-process communication namespace, a network namespace, and a mount namespace.

7. The method for detecting container resource escape defects as claimed in claim 1, characterized in that: The test items include shmget, semget, and fork.

8. An electronic device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 7 are implemented.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 7 are implemented.

10. A computer program product comprising a computer program or instructions, characterized in that When the computer program or instruction is executed by a processor, the steps of the method according to any one of claims 1 to 7 are implemented.

Citation Information

Patent Citations

  • Container escape detection method and system, computer equipment and storage medium

    CN117648688A

  • Container communication management method and device, electronic equipment and storage medium

    CN118245170A