Container escape detection and blocking methods, systems, devices, storage media, and program products

Abstract

The application discloses a container escape detection and blocking method, system, device, storage medium and program product, comprising: continuously collecting multi-dimensional behavior data of the container runtime, the multi-dimensional behavior data comprising system call sequences, namespace states, privileged operations, mounting behaviors, process relationships and resource accesses; jointly modeling the system call sequences and the namespace states, and capturing container escape behavior patterns in combination with the privileged operations, the mounting behaviors and the process relationships, the resource accesses being input as context correction items; extracting escape features based on joint model output of the joint modeling; calculating an escape probability based on the escape features, and determining whether an escape occurs; performing risk assessment, and calculating a risk level; selecting a blocking strategy based on the risk level, and performing real-time blocking response. The container escape detection and blocking method can effectively detect and block container escape attacks in a cloud native environment.

Description

Technical Field

[0001] This invention relates to the field of network security technology, and in particular to a method, system, device, storage medium, and program product for detecting and blocking container escape in cloud-native environments. Background Technology

[0002] With the widespread adoption of cloud-native technologies, containers have become the mainstream method for application deployment. Container escape attacks refer to attackers escaping from inside a container to the host machine, gaining higher privileges, and potentially posing a serious security threat. For a cloud-native security system, container escape detection and blocking are crucial, protecting host machine security and preventing the spread of attacks. More and more organizations are beginning to pay attention to container security threats.

[0003] Current methods for detecting container escape include:

[0004] Escape detection method based on container configuration auditing: This method detects security configuration problems by auditing container configuration.

[0005] Escape detection method based on system call monitoring: This method identifies escape behavior by monitoring system calls.

[0006] Escape detection method based on behavior analysis: This method identifies escape behavior by analyzing the behavior of containers.

[0007] While the above-mentioned container escape detection method can achieve container escape detection to a certain extent, several shortcomings have been found in practical use, preventing it from achieving optimal performance. These shortcomings can be summarized as follows:

[0008] Escape detection methods based on container configuration auditing can only detect known security configuration issues and cannot detect runtime escape behavior; the auditing cycle is long and the real-time performance is poor.

[0009] Escape detection methods based on system call monitoring have the following drawbacks: the number of system calls is huge, resulting in low analysis efficiency; it is difficult to distinguish between normal behavior and escape behavior, leading to a high false alarm rate.

[0010] Escape detection methods based on behavior analysis have the following drawbacks: difficulty in extracting behavioral features, making it hard to cover all escape methods; lack of real-time blocking capability, and can only respond after the fact.

[0011] Therefore, it is evident that the existing container escape detection methods described above still have inconveniences and shortcomings in use, and urgently need further improvement. How to create a container escape detection and blocking method that can effectively detect and block container escape attacks targeting cloud-native environments has become a pressing goal for the industry. Summary of the Invention

[0012] In view of this, embodiments of the present invention provide a method, system, device, storage medium, and program product for detecting and blocking container escape, which at least partially solves the problems existing in the prior art.

[0013] In a first aspect, embodiments of the present invention provide a method for detecting and blocking container escape, comprising:

[0014] Continuously collect multi-dimensional behavioral data during container runtime, including system call sequences, namespace states, privileged operations, mount behavior, process relationships, and resource access.

[0015] The system call sequence and namespace state are jointly modeled, and the container escape behavior pattern is captured by combining the privileged operations, mounting behavior and process relationships, with the resource access as the context correction input;

[0016] Escape features are extracted from the joint model output based on joint modeling. These escape features include system call sequence features, namespace state features, privileged operation features, mount behavior features, process relationship features, and resource access features.

[0017] Based on the escape characteristics, the escape probability is calculated to determine whether an escape has occurred.

[0018] Conduct a risk assessment and calculate the risk level;

[0019] Based on the risk level, a blocking strategy is selected, and a real-time blocking response is executed.

[0020] As a further improvement of the present invention, the continuous collection of multidimensional behavioral data during container operation includes:

[0021] Continuously collect behavioral summaries of container processes within a time window using eBPF probes, container runtime interfaces, kernel audit interfaces, or cloud platform event streams;

[0022] The data collected includes system call names and order, container identifiers, namespace inode changes, capability changes, mount source and target paths, process PID / PPID, access to sensitive paths on the host machine, and access to network or file resources.

[0023] For low-risk recurring events, only the count, time window, and calling subject are recorded, while the complete context is preserved for high-risk events.

[0024] Furthermore, the escape feature extraction based on the joint model output obtained from joint modeling includes: extracting risk indicators of multiple dimensions from system call sequence features, namespace state features, privileged operation features, mount behavior features, process relationship features, and resource access features, including high-risk system call combinations, abnormal namespace inode switching, CAP_SYS_ADMIN high-risk capability activation, host directory or Docker socket mounting, abnormal parent-child relationship between container process and host process, and access to sensitive files or network resources.

[0025] Furthermore, the determination of whether an escape has occurred includes:

[0026] The escape probability P_t is compared with the dynamic sensing threshold threshold_t; if P_t is greater than or equal to threshold_t, it is determined that an escape has occurred; otherwise, it is determined that no escape has occurred.

[0027] The dynamic perception threshold is updated based on the escape probability corresponding to the most recent N confirmed normal windows, and is expressed as threshold_t=clip(μ_t+k·s_t+r_t, threshold_min, threshold_max), where μ_t and s_t are the moving mean and standard deviation of the escape probability, respectively, k>0 is the sensitivity coefficient, r_t is the bounded context correction amount, and threshold_min and threshold_max are the lower and upper limits of the threshold, respectively, which are between 0 and 1.

[0028] When there are fewer than N valid normal windows, a preset initial threshold is used;

[0029] Windows that are identified as escaped, manually confirmed as abnormal, have an uncertain status, lack a core data collection source, or fail to be blocked will not participate in threshold updates.

[0030] Furthermore, the risk assessment and risk level calculation includes: performing a risk assessment based on a weighted sum of escape probability, impact degree, and propagation speed to calculate the risk level;

[0031] The escape probability, impact level, and propagation speed are all normalized to 0 to 1; the impact level is determined based on the activation of high-risk capabilities, entry into the host machine namespace, access to sockets during host machine sensitive directories or container runtime, and the target business level; the propagation speed is determined based on the number of associated containers, the number of associated host machines, and the number of newly added abnormal processes within a preset statistical period; all weighting coefficients are non-negative and the sum of the weighting coefficients is 1.

[0032] Furthermore, the selection of blocking strategies based on the risk level includes:

[0033] When a process is determined to be low-risk, restrict its external network connections and remove any high-risk capabilities it has been flagged for. When a process is determined to be medium-risk, freeze the process, block any abnormal mounts, and isolate the container it belongs to, in addition to the actions taken for low-risk processes. When a process is determined to be high-risk, stop the container it belongs to, block any associated processes, and isolate the relevant network.

[0034] Before execution, save the permission status, network policy, mount status, and process status. After execution, verify the blocking result through the return value of the container runtime interface and status probe. If the blocking action fails, execute the next level of isolation action and output a manual handling alarm. Synchronously generate blocking evidence and rollback records. The blocking evidence includes trigger characteristics, risk score, threshold version, model version, hit rule, container identifier, process identifier, operation time, and execution return value. If the false alarm is confirmed by manual review and the runtime environment allows recovery, restore in reverse order according to the rollback record. If the recovery fails, maintain the isolation status and output a manual handling alarm.

[0035] Secondly, the present invention also provides a container escape detection and blocking system, the system comprising:

[0036] The container behavior acquisition module is configured to continuously collect multi-dimensional behavior data during container runtime, including system call sequences, namespace status, privileged operations, mount behavior, process relationships, and resource access.

[0037] The modeling module is configured to jointly model the system call sequence and namespace state, and capture container escape behavior patterns by combining the privileged operations, mount behavior and process relationships, with the resource access as input for context correction.

[0038] The escape feature extraction module is configured to extract escape features based on the joint model output of joint modeling. The escape features include system call sequence features, namespace state features, privileged operation features, mount behavior features, process relationship features, and resource access features.

[0039] An escape probability calculation module is configured to calculate the escape probability based on the escape characteristics and determine whether an escape has occurred.

[0040] The risk assessment module is configured to perform risk assessments and calculate risk levels.

[0041] The real-time blocking module is configured to select a blocking strategy based on the risk level and execute a real-time blocking response.

[0042] Thirdly, embodiments of the present invention also provide an electronic device, the electronic device comprising:

[0043] At least one processor; and,

[0044] A memory communicatively connected to the at least one processor; wherein,

[0045] The memory stores instructions that can be executed by the at least one processor, which, when executed by the at least one processor, cause the at least one processor to perform the container escape detection and blocking method as described above.

[0046] Fourthly, the present invention also provides a computer-readable storage medium storing computer instructions that, when executed by at least one processor, cause the at least one processor to perform the container escape detection and blocking method as described above.

[0047] Fifthly, the present invention also provides a computer program product comprising computer program instructions that, when executed by a processor, implement the container escape detection and blocking method described above.

[0048] By adopting the above technical solution, the present invention has at least the following beneficial effects:

[0049] (1) Unlike alarm-only solutions: detection results directly drive real-time blocking.

[0050] (2) Fast response speed: Dynamic perception during runtime can trigger handling in the early stages of the escape link.

[0051] (3) Controllable false alarm rate: Multidimensional risk scoring avoids reliance on a single system call.

[0052] (4) Suitable for cloud-native deployment: risks can be isolated at the container and tenant granularity.

[0053] (5) Clear synergistic effect: The detection, evaluation and blocking form a closed loop, which facilitates obtaining authorization. Attached Figure Description

[0054] The above is merely an overview of the technical solution of the present invention. In order to better understand the technical means of the present invention, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0055] Figure 1 This is a flowchart illustrating a container escape detection and blocking method provided in an embodiment of the present invention. Detailed Implementation

[0056] The embodiments of the present invention will now be described in detail with reference to the accompanying drawings.

[0057] The following specific examples illustrate the implementation of the present invention. Those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of them. The present invention can also be implemented or applied through other different specific embodiments, and the details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of the present invention. It should be noted that, in the absence of conflict, the following embodiments and features in the embodiments can be combined with each other. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are within the scope of protection of the present invention.

[0058] It should be noted that various aspects of embodiments within the scope of the appended claims are described below. It will be apparent that the aspects described herein can be embodied in a wide variety of forms, and any particular structure and / or function described herein is merely illustrative. Based on this invention, those skilled in the art will understand that one aspect described herein can be implemented independently of any other aspect, and two or more of these aspects can be combined in various ways. For example, any number of aspects set forth herein can be used to implement the device and / or practice the method. Additionally, this device and / or method can be implemented using structures and / or functionalities other than one or more of the aspects set forth herein.

[0059] Furthermore, specific details are provided in the following description to facilitate a thorough understanding of the examples. However, those skilled in the art will understand that the described aspects can be practiced without these specific details.

[0060] This invention discloses a container escape detection and blocking method, specifically designed for dynamic detection and blocking of malicious container escape behavior in cloud-native environments. The principle behind this invention is to design a container escape behavior detection algorithm to accurately identify escape behaviors, construct a dynamic perception and monitoring mechanism to monitor container behavior in real time, and implement a real-time blocking response system. This invention proposes a container escape behavior detection algorithm that identifies escape behaviors through joint modeling of multi-dimensional behavioral data; constructs a dynamic perception and monitoring mechanism to monitor container behavior in real time; implements a real-time blocking response system to immediately block escape when it occurs; and designs an escape feature extraction method to extract multi-dimensional escape features. Furthermore, this invention forms a complete processing chain through steps such as a multi-dimensional escape feature acquisition method during container runtime and a dynamic perception threshold update method, enabling the detection, inference, or defense results to be verified by intermediate features and the evidence chain.

[0061] For ease of understanding, the following terms are explained:

[0062] Container escape: An attack where an attacker escapes from inside a container to the host machine and gains higher privileges.

[0063] System call sequence: The sequence of system calls generated during program execution, which can be used for behavioral analysis.

[0064] Escape characteristics: Features used to identify container escape behavior, including system calls, permissions, namespaces, etc.

[0065] Dynamic awareness: A mechanism for real-time monitoring of container behavior and detecting abnormal behavior.

[0066] Real-time blocking: Immediately execute a blocking response upon detecting escape behavior.

[0067] Risk assessment: The risk level is calculated by taking into account the probability of escape, the degree of impact, and the speed of spread.

[0068] Container escape behavior is typically not directly reflected in a single log entry. Through extensive practical experience, this invention has found that it is formed by a combination of multiple weak signals, including abnormal system call order, namespace boundary changes, privilege escalation, abnormal mount paths, and process relationship penetration. Relying solely on a single system call or single permission operation for judgment can easily misclassify maintenance, debugging, or image startup behaviors as escape; recording all runtime logs would increase collection and storage overhead. Therefore, this embodiment employs event summary collection, multi-dimensional feature joint modeling, and dynamic threshold judgment. It retains the complete context only for behaviors related to the escape chain, while retaining summary features for ordinary low-risk events, thus achieving a balance between detection accuracy, real-time performance, and resource cost.

[0069] like Figure 1 As shown, this embodiment provides a method for detecting and blocking container escape, including steps S110, S120, S130, S140, S150 and S160.

[0070] Step S110: Continuously collect multi-dimensional behavioral data during container runtime, including system call sequences, namespace status, privileged operations, mount behavior, process relationships, and resource access.

[0071] Specifically, the behavior summary of container processes within a time window is continuously collected through eBPF probes, container runtime interfaces, kernel audit interfaces, or cloud platform event streams. The collected items include system call names and sequences, container identifiers, namespace inode changes, capability changes, mount sources and target paths, process PID / PPID, host machine sensitive path access, and network or file resource access. For low-risk recurring events, only the count, time window, and call subject are recorded, while the complete context is preserved for high-risk events to avoid excessive performance overhead caused by full collection.

[0072] Collected events are uniformly converted into standard event records. These standard event records include at least the container identifier, host identifier, process identifier, parent process identifier, event time, event type, operation object, execution result, namespace (inode), capability set, mount source, and mount target. The system groups events according to the container identifier and host identifier, sorts them by time within a sliding time window of length Δ, and removes duplicates based on the event identifier and event content summary. When the collection source is temporarily unavailable, a corresponding missing flag is set. This missing flag participates in subsequent model calculations to avoid interpreting missing data directly as normal behavior.

[0073] Step S120: Jointly model the system call sequence and namespace state, and capture container escape behavior patterns by combining the privileged operations, mounting behavior and process relationships, with the resource access as the context correction input.

[0074] Specifically, a joint behavior representation is constructed using a sliding time window W as the unit. System call sequences reflect the execution order of behaviors, namespace states reflect changes in container isolation boundaries, privileged operations and mounting behaviors reflect attempts to acquire host resources, and process relationships reflect abnormal associations between processes within the container and processes in the host or other containers. During joint modeling, system call sequences are first encoded as SeqVec, namespace state changes as NsVec, and privileged capabilities, mounting paths, and process relationships as ContextVec, forming JointVec=f(SeqVec, NsVec, ContextVec). Background behaviors such as ordinary resource access are only input as context correction terms; critical behaviors such as namespace switching, privilege escalation, and sensitive mountings participate in the main model calculation, thus balancing the consistency of all collected data with the prominence of high-risk features.

[0075] Step S130: Extract escape features based on the joint model output of joint modeling. The escape features include system call sequence features, namespace state features, privileged operation features, mount behavior features, process relationship features, and resource access features.

[0076] Specifically, escape characteristics do not originate from a single system call, but rather from multiple dimensions of risk indicators extracted from the joint characteristic JointVec. These include combinations of high-risk system calls, abnormal namespace inode switching, enabling of high-risk capabilities such as CAP_SYS_ADMIN, mounting of host directories or Docker sockets, abnormal parent-child relationships between container processes and host processes, and access to sensitive files or network resources. By using these characteristics together as input for calculating the escape probability, false positives caused by fluctuations in a single characteristic can be reduced, and the ability to identify combined escape chains can be improved.

[0077] Step S140: Calculate the escape probability based on the escape characteristics and determine whether an escape has occurred.

[0078] Specifically, the system call sequence, namespace state, privileged operations, mounting behavior, process relationships, sensitive resource access, and missing flags from each data collection source are concatenated and normalized in a fixed order to obtain the escape feature vector f_t. An escape probability P_t = 1 / (1 + exp(-(w_e·f_t + b_e))) is calculated using a logistic regression model, where w_e is the escape feature weight vector and b_e is the bias. w_e and b_e are trained offline through historical time windows with normal or escape labels to form a model file with a version number. During the online detection phase, the model file is loaded to perform inference. If model loading or integrity verification fails, a preset high-risk rule detection is initiated, and a model anomaly alarm is output.

[0079] Determining whether an escape has occurred involves comparing the escape probability P_t with the dynamic sensing threshold threshold_t. If P_t is greater than or equal to threshold_t, an escape is determined to have occurred; otherwise, no escape is determined to have occurred, and an event summary for the current window is saved. The window is only added to the updated set of the dynamic sensing threshold if it is subsequently confirmed to be functioning correctly.

[0080] The dynamic perception threshold is updated based on the escape probability corresponding to the most recent N confirmed normal windows, expressed as threshold_t = clip(μ_t + k·s_t + r_t, threshold_min, threshold_max), where μ_t and s_t are the moving average and standard deviation of the escape probability, respectively, k > 0 is the sensitivity coefficient, r_t is the bounded context correction, and threshold_min and threshold_max are the lower and upper limits of the threshold, respectively, located between 0 and 1. When the business sensitivity is high, the image reliability is low, or the operating environment risk is high, r_t takes a negative correction to lower the judgment threshold; a reliable and stable operating environment corresponds to a positive correction. When there are fewer than N valid normal windows, a preset initial threshold is used; windows that escape, are manually confirmed as abnormal, have uncertain status, are missing from the core acquisition source, or have failed to block are not included in the threshold update; after a business release, image upgrade, or policy change, the window is first entered into the observation window, and the threshold is updated only after several consecutive windows are free of abnormalities.

[0081] Step S150: Conduct a risk assessment and calculate the risk level;

[0082] Specifically, risk assessment is only performed when an escape is determined to have occurred. The impact level I_t is weighted and normalized based on whether high-risk capabilities are enabled, whether the host machine's namespace is entered, whether sensitive directories or container runtime sockets are accessed, and the target business level. The propagation level V_t is normalized based on the number of associated containers, associated host machines, and newly added abnormal processes within a preset statistical period. The escape probability, impact level, and propagation speed are all normalized to 0 to 1; all weighting coefficients are non-negative and the sum of the weighting coefficients is 1.

[0083] The risk assessment expression is: R_t = α·P_t + β·I_t + γ·V_t, where α, β, and γ are all non-negative weights, and α + β + γ = 1. The risk level thresholds τ_1 and τ_2 satisfy 0 ≤ τ_1 < τ_2 ≤ 1; when R_t < τ_1, it is considered low risk; when τ_1 ≤ R_t < τ_2, it is considered medium risk; and when R_t ≥ τ_2, it is considered high risk.

[0084] Step S160: Select a blocking strategy based on the risk level and execute a real-time blocking response.

[0085] Specifically, the tiered blocking strategy selected based on risk level includes:

[0086] When a process is determined to be low-risk, its external network connections are restricted, and any high-risk capabilities are removed. When determined to be medium-risk, the suspected process is frozen, abnormal mounts are blocked, and its container is isolated, building upon the low-risk actions. When determined to be high-risk, the container is stopped, associated processes are blocked, and related networks are isolated. Before execution, permission status, network policies, mount status, and process status are saved. After execution, the blocking result is verified through the container runtime interface return value and status probe. If the blocking action fails, the next level of isolation action is executed, and a manual handling alarm is output. The system synchronously generates blocking evidence and rollback records. The blocking evidence includes trigger characteristics, risk score, threshold version, model version, hit rule, container identifier, process identifier, operation time, and execution return value. If a false alarm is confirmed by manual review and the operating environment allows for recovery, the rollback is performed in reverse order according to the rollback record. If recovery fails, the isolation status is maintained, and a manual handling alarm is output.

[0087] For example, the normalized escape feature vector for a certain time window is f_t=(0.8,1,1,0.9,0.7,0.6), and the feature weight vector is w_e=(0.20,0.20,0.15,0.15,0.15,0.15) and the bias is b_e=-0.20, resulting in an escape probability P_t of approximately 0.655. With the normal window values ​​μ_t=0.30, s_t=0.05, k=2, and r_t=-0.03, the dynamic sensing threshold threshold_t=0.37 is obtained. Since P_t≥threshold_t, escape is determined to have occurred. Further, with I_t=0.90, V_t=0.60, α=0.5, β=0.3, and γ=0.2, R_t is approximately 0.718. When τ_2=0.70, it is determined to be high-risk, and the container is stopped, associated processes are blocked, and network isolation is implemented. The above values ​​are used to illustrate the calculation process and do not constitute a limitation on the scope of protection.

[0088] This embodiment employs a container escape behavior detection algorithm to accurately identify escape behavior and reduce false alarm rates; it constructs a dynamic perception and monitoring mechanism to monitor container behavior in real time, improving detection real-time performance; and it implements a real-time blocking response system to immediately block escape when it occurs, preventing the spread of attacks. This significantly distinguishes it from existing technologies, which often rely on configuration auditing, single-point detection, or only alerts without blocking. This invention continuously collects multi-dimensional features during runtime, including system call sequences, namespace changes, privileged operations, mounting behavior, and process relationships, dynamically calculating escape risks. Once the risk exceeds a threshold, it performs tiered blocking based on container, process, network, and file system dimensions, and outputs the blocking criteria.

[0089] This embodiment also provides a container escape detection and blocking system corresponding to the above-described container escape detection and blocking method, the system comprising:

[0090] The container behavior acquisition module is configured to continuously collect multi-dimensional behavior data during container runtime, including system call sequences, namespace status, privileged operations, mount behavior, process relationships, and resource access.

[0091] The modeling module is configured to jointly model the system call sequence and namespace state, and capture container escape behavior patterns by combining the privileged operations, mount behavior and process relationships, with the resource access as input for context correction.

[0092] The escape feature extraction module is configured to extract escape features based on the joint model output of joint modeling. The escape features include system call sequence features, namespace state features, privileged operation features, mount behavior features, process relationship features, and resource access features.

[0093] An escape probability calculation module is configured to calculate the escape probability based on the escape characteristics and determine whether an escape has occurred.

[0094] The risk assessment module is configured to perform risk assessments and calculate risk levels.

[0095] The real-time blocking module is configured to select a blocking strategy based on the risk level and execute a real-time blocking response.

[0096] The container behavior acquisition module outputs standard event records and acquisition status; the modeling module and escape feature extraction module output escape feature vectors with model versions; the escape probability calculation module outputs escape probability, dynamic perception threshold and judgment result; the risk assessment module outputs risk score, risk level and hit feature; the real-time blocking module outputs execution status, blocking evidence and rollback record; the real-time blocking module also feeds back blocking success, blocking failure and manual review results to the threshold update and rule review process, thus forming a closed loop of detection, handling, verification and feedback update.

[0097] This invention also provides an electronic device, which includes:

[0098] At least one processor; and,

[0099] The memory is communicatively connected to the at least one processor; wherein,

[0100] The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the container escape detection and blocking method in the foregoing method embodiments.

[0101] This invention also provides a non-transitory computer-readable storage medium storing computer instructions for causing the computer to execute the container escape detection and blocking method in the foregoing method embodiments.

[0102] This invention also provides a computer program product, which includes a computer program stored on a non-transitory computer-readable storage medium. The computer program includes program instructions that, when executed by a computer, cause the computer to perform the container escape detection and blocking method in the aforementioned method embodiments.

[0103] In particular, according to embodiments of the present invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of the present invention include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts.

[0104] It should be noted that the computer-readable medium described above in this invention can be a computer-readable signal medium, a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this invention, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this invention, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wires, optical fibers, RF (radio frequency), etc., or any suitable combination thereof.

[0105] The aforementioned computer-readable medium may be included in the aforementioned electronic device; or it may exist independently and not assembled into the electronic device.

[0106] The aforementioned computer-readable medium carries one or more programs. When the aforementioned one or more programs are executed by the electronic device, the electronic device performs steps S110 to S160, including: collecting container runtime behavior events, constructing joint behavior features, calculating escape probability and comparing it with a dynamic perception threshold; calculating risk level, selecting blocking strategy, performing blocking operation, and generating blocking evidence, execution result and rollback record when it is determined that escape has occurred.

[0107] The one or more programs also enable the electronic device to read the return value of the container runtime interface and the status probe result after the blocking operation is executed, and verify the blocking result; when the blocking fails, it performs upgraded isolation and outputs a manual handling alarm; when the manual review confirms that the false alarm is false, it restores the permissions, network policies, mount status or process status that are allowed to be restored according to the rollback record.

[0108] Computer program code for performing the operations of this invention can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0109] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0110] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A method for detecting and preventing container escape, characterized in that, include: Continuously collect multi-dimensional behavioral data during container runtime, including system call sequences, namespace states, privileged operations, mount behavior, process relationships, and resource access. The system call sequence and namespace state are jointly modeled, and the container escape behavior pattern is captured by combining the privileged operations, mounting behavior and process relationships, with the resource access as the context correction input; Escape features are extracted from the joint model output based on joint modeling. These escape features include system call sequence features, namespace state features, privileged operation features, mount behavior features, process relationship features, and resource access features. Based on the escape characteristics, the escape probability is calculated to determine whether an escape has occurred. Conduct a risk assessment and calculate the risk level; Based on the risk level, a blocking strategy is selected, and a real-time blocking response is executed.

2. The container escape detection and blocking method according to claim 1, characterized in that, The continuous collection of multidimensional behavioral data during container runtime includes: Continuously collect behavioral summaries of container processes within a time window using eBPF probes, container runtime interfaces, kernel audit interfaces, or cloud platform event streams; The data collected includes system call names and order, container identifiers, namespace inode changes, capability changes, mount source and target paths, process PID / PPID, access to sensitive paths on the host machine, and access to network or file resources. For low-risk recurring events, only the count, time window, and calling subject are recorded, while the complete context is preserved for high-risk events.

3. The container escape detection and blocking method according to claim 1, characterized in that, The escape features extracted from the joint model output obtained based on joint modeling include: extracting risk indicators from multiple dimensions from system call sequence features, namespace state features, privileged operation features, mount behavior features, process relationship features, and resource access features, including high-risk system call combinations, abnormal namespace inode switching, CAP_SYS_ADMIN high-risk capability activation, host directory or Docker socket mounting, abnormal parent-child relationship between container processes and host processes, and access to sensitive files or network resources.

4. The container escape detection and blocking method according to claim 1, characterized in that, The determination of whether an escape has occurred includes: The escape probability P_t is compared with the dynamic sensing threshold threshold_t; if P_t is greater than or equal to threshold_t, it is determined that an escape has occurred; otherwise, it is determined that no escape has occurred. The dynamic perception threshold is updated based on the escape probability corresponding to the most recent N confirmed normal windows, and is expressed as threshold_t=clip(μ_t+k·s_t+r_t, threshold_min, threshold_max), where μ_t and s_t are the moving mean and standard deviation of the escape probability, respectively, k>0 is the sensitivity coefficient, r_t is the bounded context correction amount, and threshold_min and threshold_max are the lower and upper limits of the threshold, respectively, which are between 0 and 1. When there are fewer than N valid normal windows, a preset initial threshold is used; Windows that are identified as escaped, manually confirmed as abnormal, have an uncertain status, lack a core data collection source, or fail to be blocked will not participate in threshold updates.

5. The container escape detection and blocking method according to claim 1, characterized in that, The risk assessment and risk level calculation includes: performing a risk assessment based on a weighted sum of escape probability, impact degree, and propagation speed, and calculating the risk level. The escape probability, impact level, and propagation speed are all normalized to 0 to 1; the impact level is determined based on the activation of high-risk capabilities, entry into the host machine namespace, access to sockets during host machine sensitive directories or container runtime, and the target business level; the propagation speed is determined based on the number of associated containers, the number of associated host machines, and the number of newly added abnormal processes within a preset statistical period; all weighting coefficients are non-negative and the sum of the weighting coefficients is 1.

6. The container escape detection and blocking method according to claim 1, characterized in that, The blocking strategy selected based on the risk level includes: When a process is determined to be low-risk, restrict its external network connections and remove any high-risk capabilities it has been flagged for. When a process is determined to be medium-risk, freeze the process, block any abnormal mounts, and isolate the container it belongs to, in addition to the actions taken for low-risk processes. When a process is determined to be high-risk, stop the container it belongs to, block any associated processes, and isolate the relevant network. Before execution, save the permission status, network policy, mount status, and process status. After execution, verify the blocking result through the return value of the container runtime interface and status probe. If the blocking action fails, execute the next level of isolation action and output a manual handling alarm. Synchronously generate blocking evidence and rollback records. The blocking evidence includes trigger characteristics, risk score, threshold version, model version, hit rule, container identifier, process identifier, operation time, and execution return value. If the false alarm is confirmed by manual review and the runtime environment allows recovery, restore in reverse order according to the rollback record. If the recovery fails, maintain the isolation status and output a manual handling alarm.

7. A container escape detection and prevention system, characterized in that, The system includes: The container behavior acquisition module is configured to continuously collect multi-dimensional behavior data during container runtime, including system call sequences, namespace status, privileged operations, mount behavior, process relationships, and resource access. The modeling module is configured to jointly model the system call sequence and namespace state, and capture container escape behavior patterns by combining the privileged operations, mount behavior and process relationships, with the resource access as input for context correction. The escape feature extraction module is configured to extract escape features based on the joint model output of joint modeling. The escape features include system call sequence features, namespace state features, privileged operation features, mount behavior features, process relationship features, and resource access features. An escape probability calculation module is configured to calculate the escape probability based on the escape characteristics and determine whether an escape has occurred. The risk assessment module is configured to perform risk assessments and calculate risk levels. The real-time blocking module is configured to select a blocking strategy based on the risk level and execute a real-time blocking response.

8. An electronic device, characterized in that, The electronic device includes: At least one processor; and, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions executable by the at least one processor, which, when executed by the at least one processor, cause the at least one processor to perform the container escape detection and blocking method as described in any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that, when executed by at least one processor, cause the at least one processor to perform the container escape detection and blocking method as described in any one of claims 1 to 6.

10. A computer program product, characterized in that, The computer program product includes computer program instructions that, when executed by a processor, implement the container escape detection and blocking method as described in any one of claims 1 to 6.

Images