Container management system and method, and electronic device

Abstract

Embodiments of the present application relate to the field of operating systems, and provide a container management system and method, and an electronic device, capable of effectively preventing container escape attacks and improving the security and isolation of containers. The container management system is applied to a container runtime, the container runtime running in an operating system and being used to manage containers. The container management system comprises a first module. The first module is configured to take over a system call of an internal process of a container, the system call being used to request invocation of a function provided by a kernel of the operating system. The first module is further configured to deny a system call when the system call does not conform to a preset security policy.

Description

A container management system, method, and electronic device

[0001] This application claims priority to Chinese Patent Application No. 202411994126.5, filed with the China National Intellectual Property Administration on December 30, 2024, entitled "A Container Management System, Method and Electronic Device", and also claims priority to Chinese Patent Application No. 202411994126.5, filed with the China National Intellectual Property Administration on December 29, 2025, the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of operating systems, and more particularly to a container management system, method, and electronic device. Background Technology

[0003] Container technology is a lightweight virtualization technology that allows applications and all their dependencies to be packaged into an isolated runtime environment (called a container) for portability and operation across different environments. Container technology achieves resource and process isolation through operating system-level virtualization, such as namespaces and cgroups. Compared to traditional virtual machines, containers offer faster startup speeds, lower resource consumption, and greater portability.

[0004] However, with the widespread application of container technology, security issues such as container escape have become increasingly prominent. Container escape refers to the act of an attacker exploiting vulnerabilities in the operating system or container to gain access to the host machine or break through the isolation restrictions of the container, thereby launching an attack on the host machine or other containers.

[0005] It should be understood that container escape can lead to a series of problems such as data leaks, business interruptions, and system crashes, posing a serious security threat. Therefore, preventing container escape and improving the isolation and security of containers have become urgent issues to be addressed. Summary of the Invention

[0006] This application provides a container management system, method, and electronic device that can effectively prevent container escape attacks and improve the security and isolation of containers.

[0007] Firstly, a container management system is provided, comprising: a first module. The first module is used to intercept system calls made by internal processes of a container, whereby the system calls request to invoke functions provided by the operating system kernel. The first module is also used to reject system calls when they do not comply with security policies.

[0008] Based on this approach, filtering system calls through security policies effectively prevents malicious code from exploiting these calls, significantly improving container security. Furthermore, the pre-defined security policies are highly customizable, allowing for precise adjustments to the filtering granularity as needed, resulting in more targeted security protection. Additionally, the container runtime's control over system calls effectively prevents malicious processes within the container from escaping to the host machine or other containers, enhancing container isolation.

[0009] In conjunction with the container management system provided in the first aspect, in some possible implementations, this security policy is pre-configured.

[0010] In conjunction with the container management system provided in the first aspect, in some possible implementations, the operating system includes user space. The container management system also includes a second module. This second module is used to offload system calls to user space for execution when the system calls comply with security policies.

[0011] The second module is also used to return the results of system calls to the process. This approach avoids frequent switching between user mode and kernel mode, which helps reduce performance and resource overhead.

[0012] In conjunction with the container management system provided in the first aspect, in some possible implementations, the second module is also used to offload system calls to user space for execution via inter-process communication when the system calls comply with security policies.

[0013] Based on the container management system provided in the first aspect, in some possible implementations, the second module includes a client and a server. The client forwards system calls to the server via inter-process communication when the system call conforms to the security policy. The server implements the system call in user space. Based on this approach, system call processing logic can be implemented in user space, avoiding the sharing of the operating system kernel between containers and enhancing container isolation and security.

[0014] In conjunction with the container management system provided in the first aspect, in some possible implementations, when a system call conforms to the security policy and is an insecure system call, the second module is also used to replace the insecure system call with a secure system call, which is a directory file descriptor-based system call.

[0015] In conjunction with the container management system provided in the first aspect, in some possible implementations, the second module is also used to replace the system call `open` with the system call `openat` when the system call conforms to the security policy and is of the type `open`. The directory file descriptor of the `openat` system call indicates the container's file system mount directory. Based on this scheme, escaped access to other directories can be prevented.

[0016] In conjunction with the container management system provided in the first aspect, in some possible implementations, the second module is also used to replace the system call `open` with the system call `openat2` when the system call conforms to the security policy and is of the type `open`. The directory file descriptor of the system call `openat2` indicates the container's file system mount directory. Based on this scheme, escaped access to other directories can be prevented.

[0017] In conjunction with the container management system provided in the first aspect, in some possible implementations, the operating system runs on an x86-64 architecture processor. The container management system also includes a third module. This third module is used to scan for system call instructions in processes. System call instructions are used to instruct the execution of system calls.

[0018] In some possible implementations, the third module is also used to replace system call instructions with jump instructions. These jump instructions redirect system calls to the first module. Based on this approach, system call takeover can be implemented efficiently, avoiding the runtime overhead of context switching.

[0019] In conjunction with the container management system provided in the first aspect, in some possible implementations, the operating system runs on an AArch64 architecture processor. The container management system also includes a third module. This third module is used to scan for system call instructions in processes. System call instructions are used to instruct the execution of system calls.

[0020] In some possible implementations, the third module is also used to replace system call instructions with the first instruction. The first instruction redirects the system call to the first jump code, which in turn redirects the system call to the first module. Based on this scheme, it is possible to implement system calls that allow the container runtime to take over the internal processes of the container under the AArch64 architecture.

[0021] In some possible implementations, the first instruction mentioned above can be either the b instruction or the br instruction.

[0022] In some possible implementations, the third module is also used to replace system call instructions with the 'b' instruction. The 'b' instruction redirects the system call to the first jump code, which in turn redirects the system call to the first module. Based on this scheme, it is possible to implement system calls that allow the container runtime to take over the internal processes of the container within the AArch64 architecture.

[0023] In conjunction with the container management system provided in the first aspect, in some possible implementations, the first jump board code includes the following instructions: save the x30 register to the stack, use the bl instruction to jump to the first module, restore the value of the x30 register from the stack, and jump to the instruction following the system call instruction.

[0024] In conjunction with the container management system provided in the first aspect, some possible implementations of the container management system also include a fourth module. This fourth module is used to configure system call restrictions for the container's internal processes. System call restrictions are used to invalidate unreplaced system call instructions within the process. Based on this approach, the container management method can achieve self-protection, preventing the logic that takes over system calls from being altered or broken.

[0025] In conjunction with the container management system provided in the first aspect, some possible implementations of the container management system also include a fourth module. This fourth module is used to configure control flow protection for the internal processes of the container. Control flow protection is used to prevent control flow hijacking. Based on this scheme, low-level bypass prevention can be achieved, avoiding new system call instructions from invoking system functions during an attack.

[0026] In conjunction with the container management system provided in the first aspect, some possible implementations of the container management system also include a fourth module. This fourth module is used to protect the internal process data flow of the container, wherein the data flow protection is used to prevent unauthorized access or modification of the operating system's memory. Based on this scheme, low-level bypass prevention can be achieved, avoiding the invocation of system functions by newly emerging system call instructions during an attack.

[0027] In conjunction with the container management system provided in the first aspect, some possible implementations of the container management system also include a fourth module. This fourth module is used to configure control flow protection and data flow protection for the container's internal processes. Control flow protection prevents control flow hijacking, while data flow protection prevents unauthorized access to or modification of the operating system's memory. Based on this scheme, low-level bypass prevention can be achieved, avoiding new system call instructions from invoking system functions during an attack.

[0028] In conjunction with the container management system provided in the first aspect, in some possible implementations, data flow protection is also used to protect container data within the operating system kernel at the virtualization layer. Based on this scheme, it is possible to effectively prevent container data within the kernel from being tampered with.

[0029] In some possible implementations, the key data in the kernel is critical data containing container isolation information, such as namespaces, cgroups, etc., to achieve end-to-end escape protection for containers.

[0030] Secondly, a container management method is provided, which is applied to a container runtime that runs within an operating system and is used to manage containers. The method includes: intercepting system calls made by the container's internal processes. These system calls are used to request functions provided by the operating system kernel. System calls that do not comply with security policies are rejected.

[0031] In some possible implementations, the security policy can be pre-configured.

[0032] In conjunction with the container management methods provided in the second aspect, in some possible implementations, the operating system includes user space. The method also includes offloading the functionality invoked by the system call to user space for execution when the system call conforms to a security policy.

[0033] In some possible implementations, after the system call is offloaded to user space for execution, the method also includes returning the result of the system call to the container's internal process.

[0034] In conjunction with the container management methods provided in the second aspect, in some possible implementations, the operating system includes kernel mode. The method also includes switching the operating system to kernel mode to implement the system call when it conforms to a security policy.

[0035] In some possible implementations, after switching the operating system to kernel mode to implement the system call, the method also includes returning the result of the system call to the container's internal process. Based on this approach, since the code in kernel mode has the highest level of privileges, implementing system calls in kernel mode can utilize resources more efficiently, thus improving the efficiency of system call implementation.

[0036] In conjunction with the container management method provided in the second aspect, when the system call conforms to the security policy and is an insecure system call, the method further includes: replacing the insecure system call with a secure system call, wherein the secure system call is a system call based on a directory file descriptor.

[0037] In some embodiments, the unsafe system call is the open system call.

[0038] In conjunction with the container management methods provided in the second aspect, some possible implementations also include replacing the system call `open` with the system call `openat` when the system call conforms to the security policy and is `open`. The directory file descriptor of the `openat` system call indicates the container's file system mount directory.

[0039] In conjunction with the container management method provided in the second aspect, some possible implementations also include replacing the system call `open` with the system call `openat2` when the system call conforms to the security policy and is `open`. The directory file descriptor of the system call `openat2` indicates the container's file system mount directory.

[0040] In conjunction with the container management method provided in the second aspect, in some possible implementations, before taking over the system calls of the container's internal processes, the method further includes: scanning for system call instructions in the process. System call instructions are used to instruct the execution of system calls.

[0041] In some possible implementations, the method also includes replacing system call instructions with jump instructions. Jump instructions are used to redirect system calls to the container runtime.

[0042] In conjunction with the container management methods provided in the second aspect, in some possible implementations, the operating system runs on an AArch64 architecture processor. Before taking over system calls of the container's internal processes, the method also includes scanning for system call instructions within the process. These system call instructions are used to instruct the execution of system calls.

[0043] In some possible implementations, the method further includes replacing the system call instruction with a first instruction. The first instruction is used to redirect the system call to first jump code, which in turn redirects the system call to the container runtime.

[0044] The first instruction is a branch jump instruction in the AArch64 architecture, used to modify the value of the program counter to achieve execution flow jump.

[0045] In some possible implementations, the first instruction can be either the b instruction or the br instruction.

[0046] In some possible implementations, the method further includes replacing the system call instruction with a 'b' instruction. The 'b' instruction redirects the system call to a first jump code, which in turn redirects the system call to the container runtime.

[0047] In some possible implementations, the method also includes replacing the system call instruction with a br instruction. The br instruction is used to redirect the system call to a first jump code, which in turn redirects the system call to the container runtime.

[0048] In conjunction with the container management method provided in the second aspect, in some possible implementations, the first jump board code includes the following instructions: save the x30 register to the stack, use the bl instruction to jump to the first module, restore the value of the x30 register from the stack, and jump to the instruction following the system call instruction.

[0049] In conjunction with the container management method provided in the second aspect, in some possible implementations, the system call instructions in the process include system call instructions in binary files and system call instructions that have been loaded into memory.

[0050] In conjunction with the container management methods provided in the second aspect, some possible implementations also include configuring system call restrictions for the container's internal processes. System call restrictions are used to invalidate unreplaced system call instructions within the process. Based on this approach, the container management method can achieve self-protection, preventing the logic that takes over system calls from being altered or broken.

[0051] In conjunction with the container management methods provided in the second aspect, some possible implementations also include configuring control flow protection for the container's internal processes. This control flow protection prevents control flow hijacking. Based on this approach, low-level bypass prevention can be achieved, avoiding new system call instructions from invoking system functions during an attack.

[0052] In conjunction with the container management method provided in the second aspect, some possible implementations further include configuring data flow protection for the container's internal processes. This data flow protection prevents unauthorized access or modification of the operating system's memory. Based on this approach, low-level bypass prevention can be achieved, avoiding new system call instructions from invoking system functions during an attack.

[0053] In conjunction with the container management methods provided in the second aspect, some possible implementations also include configuring control flow protection and data flow protection for the container's internal processes. Control flow protection prevents control flow hijacking, while data flow protection prevents unauthorized access to or modification of the operating system's memory. Based on this approach, low-level bypass prevention can be achieved, avoiding new system call instructions from invoking system functions during attacks.

[0054] In conjunction with the container management methods provided in the second aspect, in some possible implementations, data flow protection is also used to protect the container's data within the operating system kernel at the virtualization layer.

[0055] In some possible implementations, the key data in the kernel is critical data containing container isolation information, such as namespaces, cgroups, etc., to achieve end-to-end escape protection for containers.

[0056] Thirdly, a container management device (or electronic device) is provided, including a processor and a memory. The processor is used to execute instructions stored in the memory, causing the electronic device to perform the method as described in any of the second aspects.

[0057] Fourthly, a container management device (or electronic device) is provided, characterized in that it includes a memory and one or more processors. The memory is used to store computer programs or instructions. The one or more processors are used to execute the computer programs or instructions in the memory, causing the container management device to perform the methods as described in any of the second aspects.

[0058] Fifthly, a container management device (or electronic device) is provided, comprising a plurality of interacting modules for implementing the method as described in any of the second aspects.

[0059] In a sixth aspect, a computer-readable storage medium is provided, comprising a computer program or instructions that, when executed, cause the method of any of the second aspects to be implemented.

[0060] In a seventh aspect, a computer program product is provided, comprising a computer program or instructions that, when executed, cause the method of any of the second aspects to be implemented.

[0061] Eighthly, a chip device is provided, including a processor and a memory. The processor is used to invoke a computer program or computer instructions stored in the memory to cause the processor to perform the methods described in any of the second aspects. Optionally, the processor is coupled to the memory via an interface.

[0062] It should be understood that the second to eighth aspects of this application are consistent with or correspond to the technical solutions of the first aspect of this application, and the beneficial effects achieved by each aspect and the corresponding feasible implementation are similar, and will not be repeated here. Attached Figure Description

[0063] Figure 1 is a schematic diagram of a container escape attack provided in an embodiment of this application;

[0064] Figure 2 is a schematic diagram of a container management system provided in an embodiment of this application;

[0065] Figure 3 is a schematic diagram of a replacement system call instruction provided in an embodiment of this application;

[0066] Figure 4 is a functional diagram of a third module provided in an embodiment of this application;

[0067] Figure 5 is a schematic diagram of another container management system provided in an embodiment of this application;

[0068] Figure 6 is a schematic diagram of the operation of a container management system provided in an embodiment of this application;

[0069] Figure 7 is a schematic diagram of a container escape attack provided in an embodiment of this application;

[0070] Figure 8 is a schematic diagram of the protection effect against container escape attacks provided in an embodiment of this application;

[0071] Figure 9 is a flowchart illustrating a container management method provided in an embodiment of this application;

[0072] Figure 10 is a schematic diagram of a container management device provided in an embodiment of this application. Detailed Implementation

[0073] To enable those skilled in the art to better understand the solutions in this application, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments.

[0074] In this document, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Here, A and B can be single or multiple. "At least one of the following" or similar expressions are used to represent any combination of the listed items. For example, at least one of A, B, and / or C can represent: A existing alone, B existing alone, C existing alone, A and B existing simultaneously, B and C existing simultaneously, A and C existing simultaneously, and A, B, and C existing simultaneously. Here, A, B, and C can be single or multiple.

[0075] The terms "first" and "second," etc., used in the specification and claims of this application are used to distinguish different objects, not to describe a specific order of objects. For example, "first target object" and "second target object," etc., are used to distinguish different target objects, not to describe a specific order of target objects.

[0076] In the embodiments of this application, the terms "exemplary" or "for example" are used to indicate that something is an example, illustration, or description. Any embodiment or design that is described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design. Specifically, the use of the terms "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0077] In the description of the embodiments of this application, unless otherwise stated, "a plurality of" means two or more.

[0078] To facilitate understanding, the background of this application is introduced below.

[0079] A container runtime is software that creates and runs containers on a host operating system. A container runtime provides an environment for isolating and managing applications, allowing applications to run in independent environments (i.e., containers) without interfering with each other. In mainstream container runtime architectures, the engine program that runs the container (such as Docker, Kubernetes, etc.) is responsible for extracting and integrating the internal file system of the container image, as well as providing the interface to the container control plane. These container engines invoke and communicate with the container runtime in accordance with the Open Container Initiative (OCI), and the container runtime is responsible for creating and running the containers.

[0080] Container runtimes can provide security isolation mechanisms for containers based on lightweight virtualization features provided by the operating system (such as control groups and namespaces). However, applications or processes inside containers often need to interact with the operating system kernel by initiating system calls, such as requesting functions provided by the operating system kernel. For example, a process inside a container can initiate a system call by executing a system call instruction (such as the syscall instruction in the Linux operating system). Executing a system call instruction causes the processor to generate a software interrupt, triggering the central processing unit (CPU) to switch from user mode to kernel mode (corresponding to the operating system switching from user mode to kernel mode). Before switching to kernel mode, the CPU saves the current user-mode context information (such as register states and program counters) so that it can be restored after the system call is completed. Then, the operating system kernel executes the system call and returns the result to the process inside the container.

[0081] It's important to note that when the operating system is in user mode, applications can only access memory regions and hardware devices permitted by the operating system. They cannot access the memory space of the operating system kernel or other applications, nor can they execute privileged instructions such as modifying memory mappings or switching processes. However, when the operating system is in kernel mode, applications can access all operating system resources and hardware devices, and can execute privileged instructions. In other words, the operating system only allows applications to call functions provided by the operating system kernel when it is in kernel mode.

[0082] However, from a security perspective, as long as the application within the container can directly interact with the host operating system kernel by initiating system calls, attackers can exploit vulnerabilities in the system call code path to attack the operating system kernel or escape the security isolation mechanisms provided by the container runtime. For example, the security isolation mechanisms provided by the container runtime may include creating independent namespaces, ensuring that containers can only see system resources within their current namespace, thereby preventing containers from accessing each other's resources. Another example is that security isolation mechanisms may include restricting the resources (such as CPU, memory, disk I / O, network, etc.) that each container can access through control groups. Attackers may exploit vulnerabilities in the system call code path to bypass these security isolation mechanisms and thus escape.

[0083] Furthermore, a host machine or cloud server may simultaneously host multiple containers running by a container runtime, and these containers share the same operating system kernel. When a malicious container successfully escapes the security isolation mechanism provided by the container runtime, it can attack other containers on the host machine or cloud server, thereby compromising the isolation between containers and causing serious security risks.

[0084] For example, please refer to Figure 1, which is a schematic diagram of a container escape attack provided in an embodiment of this application. As shown in Figure 1, the container runtime X runs and manages containers A and B. Container A and container B share the same operating system kernel K. Container A includes applications a1 and a2, and container B includes applications b1 and b2. When application a1 initiates a system call, an attacker may exploit a vulnerability in the system call code path to successfully escape the security isolation mechanism provided by the container runtime X for containers A and B. Then, the attacker can use container A to attack the operating system kernel K or container B (Figure 1 takes an attack on container B as an example), causing a series of serious problems such as data leakage, business interruption, and system crash.

[0085] To address the aforementioned issues, this application provides a container management system, method, and electronic device that effectively prevents container escape attacks and improves container security and isolation. Details are described below.

[0086] First, the container management system provided in the embodiments of this application will be introduced. It should be noted that the container management system provided in the embodiments of this application can be applied to a container runtime (or a secure container runtime). In other words, the container management system can be a system within a container runtime, and the modules within the container management system can also be modules within a container runtime, which will not be elaborated further.

[0087] Please refer to Figure 2, which is a schematic diagram of a container management system provided in an embodiment of this application. As shown in Figure 2, the container management system 200 includes a first module 201.

[0088] The first module 201 is used to take over system calls from the container's internal processes. These internal processes can be understood as running instances of applications within the container. When the container starts, it loads and runs the application from the container image; this running process includes the startup of one or more processes. In other words, the container provides the runtime environment for the application, and the process is the entity that actually executes the code within that runtime environment. In this embodiment, system calls initiated by processes can also be referred to as application-initiated system calls, which will not be elaborated further.

[0089] System calls are used to request and invoke functions provided by the operating system kernel. Specifically, system calls are a set of interfaces provided by the operating system to applications, allowing applications to invoke functions provided by the operating system kernel, such as file operations, process control, and network communication. For example, `open` is a system call providing file operations, used to open a file and return a file descriptor. `exec` is a system call providing process control, used to replace the execution image of the current process, replacing the contents of the current process with another executable file. `socket` is a system call providing network communication, used to create a socket for network communication.

[0090] In some possible implementations, the functionality provided by the operating system kernel can include the original functions of the operating system kernel, or it can include functions added to the kernel through technologies such as the extended Berkeley packet filter (eBPF). This is not limited here. eBPF is a Linux kernel technology that allows developers to execute secure, restricted code within the kernel to implement functions such as network filtering, system call tracing, and performance monitoring.

[0091] Module 201 avoids direct interaction between the container and the operating system kernel by taking over the system calls of the container's internal processes, which helps prevent container escape attacks and provides container security.

[0092] The first module 201 is also used to reject a system call when the aforementioned system call does not comply with the security policy.

[0093] In some possible implementations, the security policy can be pre-configured.

[0094] In the embodiments of this application, the security policy can be designed in various ways. For example, the security policy may include a whitelist, which includes identifiers (such as system call numbers) of one or more system calls. Thus, for a system call (referred to as system call S here for ease of distinction) to conform to the security policy, it may mean that the whitelist includes the identifier of system call S. For system call S to not conform to the security policy, it may mean that the whitelist does not include the identifier of system call S.

[0095] For example, a security policy can also include a blacklist, which contains identifiers for one or more system calls. Thus, system call S conforming to the security policy means that its identifier is not present in the blacklist. System call S not conforming to the security policy means that its identifier is present in the blacklist.

[0096] For example, security policies can also define normal or abnormal system calls based on factors such as system call frequency, system call order, and system call parameters. Thus, a system call S conforming to a security policy can mean that system call S is a normal system call or that system call S is not an abnormal system call. Conversely, a system call S not conforming to a security policy can mean that system call S is not a normal system call or that system call S is an abnormal system call.

[0097] For example, a security policy can also include different detection logics set for different system calls. If system call S requests a file operation function, it can check whether the file path of system call S is valid and whether the file permissions meet the requirements. Thus, system call S not conforming to the security policy could mean that system call S failed the detection logic, while conforming to the security policy could mean that system call S passed the detection logic.

[0098] It should be understood that the security policy can also be a combination of any of the implementation methods in the above examples. For example, the security policy can include both whitelists and blacklists, which is not limited here. In addition, the first module 201 can dynamically adjust the security policy according to the real-time operation of the operating system and historical data to adapt to constantly changing security threats, which is also not limited in this application.

[0099] As can be seen from the above description, the container management system provided in this application, by filtering system calls through security policies, can effectively prevent malicious code from using system calls to launch attacks, thereby significantly improving container security. Furthermore, the container runtime's takeover of system calls can effectively prevent malicious processes within the container from escaping to the host machine or other containers, which helps enhance container isolation. In addition, the pre-set security policies are highly customizable, allowing users to set the filtering granularity of the security policies as needed, resulting in more targeted security protection.

[0100] The container management system provided in this application outperforms virtual machine-based container runtimes in terms of startup performance, runtime CPU overhead, and runtime memory overhead. Furthermore, this container management system does not alter the original K8s / Containerd / Runc interface, ensuring compatibility with current container management platforms and exhibiting good compatibility. Additionally, this container management system does not modify container images or operating system kernel interfaces, offering the advantage of transparency to business operations.

[0101] In some possible implementations, the first module 201 can take over the system calls of the container's internal processes by implementing a lightweight kernel in user space. For details, please refer to the relevant technical documentation on gVisor; further details will not be elaborated here.

[0102] In some possible implementations, the container management system may include a third module 202. When the container management system runs on an x86-64 architecture processor, this third module 202 can be used to scan (e.g., using a disassembler) the system call instructions (such as syscall / sysenter instructions) in the process when the container's internal process starts, and replace (or rewrite) all system call instructions in the process with jump instructions (such as call rax instructions) that redirect to the first module 201. In this way, when the container's internal process attempts to initiate a system call, the control and data flow of the system call is taken over by the first module 201, with low resource and performance overhead. The system call instructions in the process may include system call instructions in binary files, system call instructions already loaded into memory, etc., and are not limited here.

[0103] For example, the container management system runs on a Linux operating system, and the internal processes of the container include assembly instructions as shown in Figure 3(a). In this assembly instruction, 0x38 is the system call number, "mov rax, 0x38" indicates that 0x38 is moved into the rax register, and syscall (i.e., the system call instruction) indicates that the system call indicated in the rax register is executed. The system call number is an identifier used to indicate the specific system call that the kernel is to execute. When the third module 202 scans the assembly instruction shown in Figure 3(a), it can replace the system call instruction (i.e., syscall) in the assembly instruction with a jump instruction (call rax in Figure 3(b)), resulting in the assembly instruction shown in Figure 3(b). In this case, the data in the rax register is treated as an address, and call rax indicates that the program code corresponding to the address in the rax register is executed. In this embodiment, the address in the rax register can be a jump code, which can jump to the system call dispatch function in the library operating system (LibOS), thereby enabling the first module 201 to take over the system calls of the container's internal processes after the syscall instruction is modified into a call rax instruction.

[0104] In some embodiments, the third module is further configured to replace the system call instruction with a first instruction, the first instruction being configured to redirect the system call to a first jump code, the first jump code being configured to redirect the system call to the first module.

[0105] The first instruction is a branch jump instruction in the AArch64 architecture, used to modify the value of the program counter to achieve execution flow jump.

[0106] In some embodiments, the first instruction may be a b instruction, that is, the third module is further configured to replace the system call instruction with a b instruction, the b instruction being configured to redirect the system call to the first jump code, the first jump code being configured to redirect the system call to the first module.

[0107] When the container management system runs on an AArch64 architecture processor, the third module 202 can implement the function shown in Figure 4. As shown in Figure 4, the third module 202 can be used to scan the system call instructions (such as svc instructions) in the process when the internal process of the container starts, and replace (or rewrite) all the system call instructions in the process with b instructions (marked in Figure 4 as system call instructions rewritten as b instructions). In the AArch64 architecture, the difference between b instructions and bl instructions is that b instructions do not overwrite the value of the x30 register, that is, they do not save the return address, but directly jump to the target address. In the embodiment of this application, the target jump address of the b instruction can be a stage 1 jump code (trampoline_stage1_xxx) (or the first jump code). The first jump code corresponds one-to-one with each replaced system call instruction. The first jump code consists of 4 instructions (i.e., the four lines of instructions in the trampoline_stage1_xxx box in Figure 4). The four instructions, from top to bottom, sequentially instruct to save the x30 register onto the stack, use the bl instruction to jump to the common jump board code (trampoline_stage2) (or the second jump board code, which in this example can be the first module 201), restore the value of the x30 register from the stack, and jump to the next instruction after the system call instruction corresponding to the first jump board code.

[0108] It should be understood that since the application has already been loaded and redirection has been completed when these jump code instructions are generated, the runtime address of each replaced system call instruction can be determined. Therefore, the address of the next instruction after this system call instruction can be hard-coded in the first-stage jump code to restore the original execution flow (or control flow). This allows jumping from the original system call to the corresponding first-stage jump code, and then freely jumping to the common jump code. The logic of the common jump code is similar to that of the jump code on x86-64, namely saving registers that need to be saved by the function caller, aligning the function stack, and calling a unified system call interception function, etc., which will not be elaborated here. It should be noted that the reason for distinguishing between the AArch64 architecture and the x86-64 architecture is that the AArch64 architecture uses a fixed-length instruction set, with each instruction being 4 bytes long. Therefore, the AArch64 architecture restricts the address of each executed instruction to be 4-byte aligned, thereby improving instruction decoding performance and defending against control flow hijacking attacks. Therefore, in the AArch64 architecture, the system call instructions cannot be rewritten as function call instructions with the system call number as the target address, as described above for the x86-64 architecture. This is because system call numbers that are not divisible by 4 cannot be used as valid function call addresses. Furthermore, converting the system call number to a multiple of 4 requires an extra instruction, which is clearly unacceptable.

[0109] Since each instruction on AArch64 is fixed-length, it's intuitive to think of replacing system call instructions with address-targeting `bl` instructions, directly jumping to the entry point of the system call interceptor function. However, the AArch64 architecture uses the x30 register to store the function's return address. When the `bl` instruction jumps, it writes the address of the current instruction into the x30 register. This allows the `ret` instruction to return to the function's call point. For non-leaf functions in the application's function call chain, the compiler automatically generates an instruction to save the x30 register at the beginning of the function and saves it to the stack. This allows the function to freely use `bl` instructions to call other functions, restoring the x30 register's value before returning. For leaf functions, the compiler assumes they won't call any other functions, and their x30 register's value won't be modified, so it doesn't generate an instruction to save the x30 register. If we replace system call instructions with `bl` instructions, for a leaf function, it's equivalent to becoming a non-leaf function, adding a new function call—something the compiler cannot know in advance. As a result, the return address of the leaf function will be lost during runtime due to the extra `bl` instruction. If the function call instruction is replaced with a bl instruction to directly jump to the system call interceptor function, the value of the x30 register of the original leaf function will be completely lost after the system call interceptor function returns. This will prevent the original function from returning to its original call point. Therefore, in this embodiment, the b instruction is used to replace the system call instruction.

[0110] In specific embodiments, the b instruction can be the b#imm instruction or the b.cond#imm instruction.

[0111] In some implementations, embodiments of this application use the br instruction to replace the system call instruction. The br instruction can be br... <xn>Core instructions, br x30 return variant instructions.

[0112] After taking over system calls from the container's internal processes, the first module 201 can determine whether the system call conforms to a pre-set security policy. If it does not conform to the security policy, the system call is rejected. For details, please refer to the description in the foregoing embodiments, which will not be repeated here.

[0113] In some possible implementations, when a system call conforms to a security policy, the first module 201 can trigger a switch from user mode to kernel mode to implement the system call in kernel mode.

[0114] In some other possible implementations, the container management system may include a second module 203. The second module 203 is used to offload system calls to user space for execution when the system calls comply with security policies.

[0115] In some other possible implementations, the container management system may include a second module 203. The second module 203 is used to offload the system call to user space for execution when the system call conforms to the security policy, and return the result of the system call to the process within the container.

[0116] In some possible implementations, the second module 203 is used to offload the system call to user mode for execution via inter-process communication when the system call conforms to the security policy.

[0117] For example, the second module 203 may include a client and a server (not shown in Figure 2). The client and server can communicate via a network protocol stack or inter-process communication (IPC). Furthermore, in the multiple containers included in the operating system, each container's runtime may include an independent client, and the container runtimes of each container can share the server. Thus, through communication between the server and each client, the system resource state can be synchronized, thereby achieving the abstraction and management of global system resources.

[0118] In some possible implementations, the server can simulate some or all system calls by implementing a lightweight kernel in user space, thereby offloading system calls to user space for execution. For details, please refer to the introduction of gVisor in related technologies; it will not be elaborated here. In other possible implementations, the server can also utilize a library operating system (LibOS) to implement some or all system calls. A library operating system is a special operating system that provides certain resource management functions originally belonging to the operating system kernel, such as file disk I / O and network communication, to applications in the form of libraries according to modular requirements. The library operating system can reasonably manage and control the computer resources involved in place of the operating system kernel and expose these resources directly to the application, allowing the application to run efficiently.

[0119] When a client receives a system call, it can determine whether the system call is included in a system call simulated by the server. If so, the client can forward the system call to the server via inter-process communication, and the server will implement the system call. If not, the client can trigger the operating system to switch to kernel mode, where the system call will be implemented.

[0120] In some possible implementations, when a system call conforms to a security policy and is an insecure system call, the second module 203 replaces the insecure system call with a secure system call, which is a directory file descriptor-based system call.

[0121] In some possible implementations, insecure system calls include unvalidated input, uncontrolled permissions, improper resource management, or interface abuse. Common input validation deficiencies include buffer-related calls such as gets() (reading input without checking the buffer size), strcpy() (string copying without length limits), open() (receiving user-controlled paths), and printf(user_input) (directly using user input as a format string), etc. Common improper permission control includes unauthorized execution (calling system() with root privileges to execute ordinary commands), uncontrolled permission inheritance, unauthorized sensitive operations (ioctl() operating on hardware devices), etc. Common improper resource management includes memory management vulnerabilities (not releasing memory after malloc()), file descriptor abuse (not closing file descriptors after open(), or repeatedly closing them), resource exhaustion attacks (fork() creating unlimited child processes), etc. These are not all listed here.

[0122] In some possible implementations, the second module 203 can also be used to replace the system call `open` with the system call `openat` when the system call conforms to the security policy and the system call is `open`. The directory file descriptor of the system call `openat` indicates the container's file system mount directory. This restricts the container to accessing only files under its own file system mount directory, thus preventing the container from escaping to access other directories.

[0123] In some possible implementations, the second module 203 can also be used to replace the system call `open` with the system call `openat 2` when the system call conforms to the security policy and is `open`. The directory file descriptor of the system call `openat 2` indicates the container's file system mount directory. This further restricts the container's access to related files, thereby preventing the container from escaping access to other directories. That is, in this embodiment, the insecure system call is `open`, and when the system call conforms to the security policy, the second module 203 replaces `open` with the secure system call `openat 2`.

[0124] The client and server in the second module are described below using a specific example. Please refer to Figure 5, which is a schematic diagram of another container management system provided in this application embodiment. As shown in Figure 5, multiple container management systems run in the operating system (Figure 5 uses container management system M and container management system N as examples). Container management system M includes a first module 401, a second module K (not shown in Figure 5), and a third module 403. The second module K includes a client 412 and a server 404. The second container runtime includes a first module 405, a second module J (not shown in Figure 5), and a third module 407. The second module J includes a client 416 and a server 404.

[0125] Both the first module 401 and the first module 405 are used to take over the system calls of the internal processes of each managed container, and reject the system call if it does not comply with the pre-set security policy. When the container management system runs on an x86-64 architecture processor, the third module 403 is used to scan the system call instructions in the process when the internal process of the container starts, and replace all system call instructions in the process with jump instructions that redirect to the first module 401 (labeled "Replace System Call Instructions" in Figure 5). When the container management system runs on an AArch64 architecture processor, the third module 403 is used to implement the function shown in Figure 4 (not shown in Figure 5), which will not be described in detail here. The function of the third module 407 is similar to that of the third module 403, and will not be described in detail here. The following description uses the container management system M as an example.

[0126] For ease of explanation, the following examples all use the example of the container management system running on an x86-64 architecture processor, and will not be repeated.

[0127] As shown in Figure 5, the container management system M manages container A. When a process inside container A attempts to make a system call, the control and data flows of the system call are redirected to the first module 401 because the system call instruction is replaced by the third module 403 with an instruction to jump to the first module 401. The first module 401 rejects the system call if it does not comply with the security policy. Assuming the system call complies with the security policy, the first module 401 forwards the system call to the client 412 of the second module K. The client 412 can parse the system call number and determine whether the system call is included in the system call simulated by the server 404. If so, the client 412 can send the system call data flow to the server 404 via IPC, and the server 404 will implement the system call and return the result to the container's internal process. If not, the operating system can be switched to kernel mode to implement the system call.

[0128] In traditional solutions, executing a system call requires switching from user mode to kernel mode, completing the system call, and then switching back to user mode. This frequent context switching incurs significant performance and resource overhead. This proposed solution, by offloading system calls to user mode, avoids this frequent switching between user and kernel modes, thus reducing performance and resource costs.

[0129] To further enhance security, in some possible implementations, the container management system 200 may also include a fourth module 204. The fourth module 204 is used to configure system call restrictions for the container's internal processes when they start. These system call restrictions disable unreplaced system call instructions within the container's internal processes. System call restrictions can be implemented based on the operating system's built-in system call filtering capabilities, such as secure computing mode (Seccomp) and syscall user dispatch. Seccomp is a Linux kernel security mechanism that restricts the system calls a process can use, thus providing a sandbox environment. Seccomp filters system calls by defining a whitelist or blacklist. In filtering mode, a process can call a predefined set of safe system calls, while other unauthorized system calls are blocked. Syscall user dispatch allows for dynamic handling and forwarding of system calls in user space. This technology intercepts system calls through user-space hook functions and allows user-space code to decide how to continue executing the system call when necessary.

[0130] For example, the fourth module 204 can also map unreplaced system call instructions to invalid addresses by configuring the system call table, thereby invalidating the unreplaced system call instructions.

[0131] It should be understood that configuring system call restrictions can prevent unauthorized system calls, thereby preventing container escape attacks and improving the security and stability of the system and containers.

[0132] In other possible implementations, when the container's internal processes start, the fourth module 204 can configure control flow protection for these processes. This control flow protection prevents control flow hijacking. For example, control flow protection can be implemented using technologies such as Intel Control-Flow Enforcement Technology (Intel CET) and Branch Target Identification (BTI). Taking BTI as an example, the fourth module 204 can enable BTI protection in the isolated shared library code area, ensuring that code segments can only enter through legitimate entry points (such as the first module in this solution), thereby effectively preventing attacks such as return-oriented programming (ROP).

[0133] In other possible implementations, the fourth module 204 can configure data flow protection for the container's internal processes. This data flow protection prevents unauthorized access to or modification of the operating system's memory. For example, data flow protection can be implemented using technologies such as Intel Memory Protection Keys (Intel MPK), ARM watchpoints, and ARM EL2 Stage 2 page table protection. This prevents user-mode system service-related logic (such as the first module 201, the second module 203, and the third module 202 in this solution) from being bypassed or damaged, effectively preventing attackers from unauthorized access to and modification of memory.

[0134] In some other possible implementations, when the container's internal process starts, the fourth module 204 can configure control flow protection and data flow protection for the container's internal process. Control flow protection is used to prevent control flow hijacking.

[0135] Data flow protection is used to prevent unauthorized access to or modification of the operating system's memory. For example, control flow protection can be implemented using technologies such as Intel Control-Flow Enforcement Technology (Intel CET) and Branch Target Identification (BTI). Taking BTI as an example, module 204 can enable BTI protection in the isolated shared library code area, ensuring that code segments can only enter through legitimate entry points (such as module 1 in this solution), thereby effectively preventing attacks such as return-oriented programming (ROP). As another example, data flow protection can be implemented using technologies such as Intel Memory Protection Keys (Intel MPK), ARM watchpoints, and ARM EL2 Stage 2 page table protection, thus preventing user-mode system service-related logic (such as module 201, module 203, and module 202 in this solution) from being bypassed or damaged, effectively preventing attackers from unauthorized access to and modification of memory.

[0136] In some possible implementations, data flow protection can also be used to protect critical container data within the kernel at the virtualization layer, including but not limited to container namespaces and control groups. This effectively prevents the tampering of critical container data within the kernel.

[0137] In some embodiments, the critical data is critical data containing container isolation information, such as namespaces, cgroups, etc., thereby achieving end-to-end escape protection for containers.

[0138] It should be noted that the aforementioned system call restrictions, data flow protection, control flow protection, and other functions can also be configured by other modules or through other means, and this application does not impose any restrictions on them.

[0139] In addition, the clients of the first module 201, the second module 203, and the third module 202 can all be in the form of shared library files (Shared Objects), and this application does not limit this.

[0140] The security of the container management system provided in the embodiments of this application will be described below.

[0141] The threat model is assumed to be as follows: attackers can exploit vulnerabilities in the operating system kernel and the internal processes of containers to invoke system services through system call instructions, and break through the isolation mechanism of the container itself to access the contents outside the container, the host or other containers, and even completely control the target host.

[0142] For threats involving exploiting operating system kernel vulnerabilities, attackers need to initiate system calls to access kernel-related functions, requiring multiple system calls to work together to complete the overall exploit. In the container management system provided by this solution, the first module takes over the system calls of the container's internal processes and rejects system calls that do not comply with security policies. The second module offloads system calls to user space for execution when they comply with security policies. The combined functionality of the first and second modules can definitely affect at least one link in the vulnerability exploitation attack chain (i.e., the system calls required to complete the container escape process). Furthermore, the control flow protection and data flow protection functions configured in the fourth module ensure that the functions of the first and second modules in the container management system cannot be bypassed or disrupted. System call restrictions configured in the fourth module achieve low-level bypass prevention, thereby preventing newly emerging system call instructions from invoking system functions during the attack.

[0143] As should be understood from the above description, the container management system provided in this application embodiment can realize that system calls of internal processes of containers will be processed inside the containers, thereby effectively avoiding the situation of sharing the operating system kernel between containers.

[0144] The container management system provided in this application embodiment is described below through a specific example.

[0145] Please refer to Figure 6, which is a schematic diagram of the operation of a container management system provided in an embodiment of this application. The container management system can be a container runtime or contained within a container runtime, or it can be an application or process that performs the same or similar functions as a container runtime. As shown in Figure 6, the container management system 500 includes a first module 501, a second module 502, and a third module 503. The second module 502 includes a client 512 and a server 505. The container management system 500 is used to manage containers 506.

[0146] As shown in Figure 6, when process P starts inside container 506, the third module 503 can inject the corresponding shared library file (e.g., libcrust.so) into the memory space of process P in advance. libcrust.so is used to scan all syscall instructions in process P's memory space except for libcrust.so, and replace each syscall instruction with a call rax instruction (the jump address is the address of the first module 501). Thus, when process P attempts to initiate a system call, the control flow and data flow of the system call are taken over by the first module 501. The first module 501 can reject the system call if it does not comply with the security policy. The first module 501 can also forward the system call to the client 512 of the second module 502 if it complies with the security policy. The client 512 forwards the system call to the server 505 for processing via IPC, and the server 505 returns the result after processing. More details about the functions of each module, client, and server can be found in the descriptions in the preceding embodiments, and will not be elaborated here.

[0147] The container management module may also include a fourth module (not shown in Figure 6). This fourth module can be used to configure system call restrictions, control flow protection, and data flow protection for the process P in the operating system kernel when the process P starts. For a description of system call restrictions, control flow protection, and data flow protection, please refer to the description in the foregoing embodiments; it will not be repeated here. For example, the fourth module can also configure the system call entry address (referred to as crust-gate in Figure 6) for the container management system. When the control flow protection function is enabled, crust-gate is the only entry point for the control flow of system calls for the first module 501, the second module 502, and the third module 503. Access permissions for the first module 501, the second module 502, and the third module 503 are enabled only when the control flow of the system call enters through crust-gate. When the control flow of the system call is located in a user program, access permissions for the first module 501, the second module 502, and the third module 503 are disabled. This ensures that the protection mechanism provided by the container management system cannot be bypassed, which is beneficial for improving security.

[0148] In some possible implementations, the container management system is applied to the container runtime (such as runc). runc is used to create, run, and manage containers according to the OCI standard; it does not run inside the container itself but runs on the host machine. When a container starts, runc is responsible for creating and starting the first process inside the container, typically the init process or a similar process used to initialize the container's runtime environment. After the container starts, runc no longer participates in the creation of internal processes within the container. Therefore, when a system call is made that creates a new process (such as fork or execve), this syscall can inject libcrust.so into the memory space of process P by calling another process (such as exec-stub). This ensures that all system calls of processes within the container can be handled by the first module 501 in the container management system, which improves security.

[0149] Please refer to Figure 7, which is a schematic diagram of a container escape attack provided in an embodiment of this application. As shown in Figure 7, before using the container management system provided in this embodiment, an attacker can execute an exploit program within a container to escape the container by exploiting vulnerabilities in the operating system kernel. The process of the container escape attack and the vulnerability exploitation chain involved in Figure 7 are as follows: First, the application inside the container performs normal business operations, opens the / dev / krwx driver through the open system call, and triggers the vulnerability through ioctl interaction. The attack program exploits the kernel vulnerability using the common open ( / dev / ptmx) method. The process involves calling the open system call multiple times and passing the parameter / dev / ptmx to achieve the effect of heap spraying. After successful heap spraying, the ioctl system call is called to leak the kernel address. The target close function pointer is overwritten by the privilege escalation function pointer, and finally the kernel control flow is hijacked by calling the close system call. Finally, the secret.txt file on the host operating system is opened through the open system call, realizing container escape (the bold part in Figure 7). It should be noted that the bold part in Figure 7 is only for ease of viewing. In actual applications, this part can also be displayed without bolding, and there is no limitation.

[0150] After applying the container management machine system provided in this application embodiment, the protection effect against container escape attacks is shown in Figure 8. It can be seen that when an attacker attempts to execute an exploit program within a container, they can configure the `open` system call to fail when the parameter is ` / dev / ptmx` (this can also be achieved by implementing the `open` system call in user space). Therefore, the exploit chain is interrupted at the `open( / dev / ptmx)` system call, preventing heap spraying and subsequent attack steps, resulting in attack failure (the bolded portion in Figure 8). It should be noted that the bolded portion in Figure 8 is only for ease of viewing; in actual applications, this portion can be displayed without bolding and is not limited to this aspect.

[0151] As can be seen, the container management system provided in this application embodiment can effectively prevent container escape attacks and has good security.

[0152] This application also provides a container management method, which can be applied to container runtime. Please refer to Figure 9, which is a flowchart illustrating a container management method provided in this application. As shown in Figure 9, the method includes the following steps.

[0153] S801 is a system call that takes over processes within a container.

[0154] S802. If the system call does not comply with the security policy, reject the system call.

[0155] In the aforementioned embodiments, the internal processes of the container are also referred to as the internal processes of the container, which are processes within the container and will not be elaborated upon here.

[0156] In some possible implementations, the security policy can be pre-configured.

[0157] It should be understood that this container management method filters system calls through security policies, effectively preventing malicious code from exploiting system calls for attacks, thereby significantly improving container security. Furthermore, the container runtime's takeover of system calls effectively prevents malicious processes within the container from escaping to the host machine or other containers, enhancing container isolation. In addition, the pre-defined security policies are highly customizable, allowing users to adjust the filtering granularity of security policies as needed, resulting in more targeted security protection.

[0158] In some possible implementations, the operating system includes user space. The method also includes offloading the functionality invoked by the system call to user space for execution when the system call satisfies a security policy.

[0159] In some possible implementations, after offloading the function invoked by the system call to user space for execution, the method further includes: returning the result of the system call to the process.

[0160] In some possible implementations, the operating system includes kernel mode. Another approach is to switch the operating system to kernel mode to implement the system call when the system call satisfies a security policy.

[0161] In some possible implementations, the operating system is switched to kernel mode to implement system calls. This method also includes returning the result of the system call to the container's internal process.

[0162] In some possible implementations, before taking over system calls from processes within the container, the method also includes scanning for system call instructions within the process. System call instructions are used to instruct the execution of system calls.

[0163] In some possible implementations, system call instructions within the internal process are scanned and replaced with jump instructions. Jump instructions are used to redirect system calls to the container runtime.

[0164] In some possible implementations, the system call instructions in the process include system call instructions in the binary file and system call instructions that have been loaded into memory.

[0165] Among some possible implementations, the approach also includes configuring system call restrictions for processes within the container. System call restrictions are used to invalidate unreplaced system call instructions within the process.

[0166] In some possible implementations, the method also includes configuring control flow protection and data flow protection for processes within the container. Control flow protection prevents control flow hijacking, while data flow protection prevents unauthorized access to or modification of the operating system's memory.

[0167] For more information on container management methods, please refer to the description of the container management system in the foregoing embodiments, which will not be repeated here.

[0168] This application also provides a container management device (or electronic device). As shown in FIG10, the electronic device 900 may include a processor 901 configured to execute any of the embodiments described above. Optionally, the electronic device 900 may further include a memory 902 coupled to the processor 901. The processor 901 may include a central processing unit (CPU), a network processor (NP), or a combination of a CPU and an NP. The processor 901 may also be an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The PLD may be a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof. The processor 901 may refer to a single processor or may include multiple processors. In this embodiment, memory 902 can be non-transitory memory, which can be volatile memory, such as random-access memory (RAM); memory can also be non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid-state drive (SSD); memory 902 can also include combinations of the above types of memory. It should be noted that the memory described herein includes, but is not limited to, these and other suitable types of memory. Memory 902 can refer to a single memory or may include multiple memories for storing program instructions. In one embodiment, memory 902 stores computer-readable instructions. In this embodiment, the operation performed by a module actually refers to the operation performed by processor 901 according to the module's instructions. Optionally, processor 901 may also store program code or instructions for executing the scheme of this embodiment, in which case processor 901 may not need to read the program code or instructions from memory 902.

[0169] This application also provides a container processing apparatus (or electronic device), including a processor and a memory. The processor is used to execute instructions stored in the memory, causing the electronic device to perform the method of any of the above embodiments.

[0170] This application also provides a computer-readable storage medium, which includes instructions that, when executed, cause the methods of any of the above embodiments to be implemented.

[0171] This application also provides a computer program product, which includes instructions that, when executed, cause the methods of any of the above embodiments to be implemented.

[0172] This application also provides a chip, including an interface circuit and a processor. The interface circuit and the processor are connected, and the processor is used to cause the chip to perform some or all of the operations in any of the methods in any of the foregoing embodiments.

[0173] This application also provides a chip system, including: a processor coupled to a memory, the memory being used to store programs or instructions, and when the program or instructions are executed by the processor, the chip system enables the chip system to perform some or all of the operations in any one of the methods in any of the foregoing embodiments.

[0174] Optionally, the chip system may contain one or more processors. These processors can be implemented in hardware or software. When implemented in hardware, the processor can be a logic circuit, an integrated circuit, etc. When implemented in software, the processor can be a general-purpose processor, implemented by reading software code stored in memory.

[0175] Optionally, the chip system may contain one or more memories. The memory may be integrated with the processor or disposed separately from it; this application embodiment does not limit this. For example, the memory may be a non-transient processor, such as a read-only memory (ROM), which may be integrated with the processor on the same chip or disposed separately on different chips. This application embodiment does not specifically limit the type of memory or the arrangement of the memory and processor.

[0176] This application also provides a system that includes one or more of the above-described devices, apparatuses, computer-readable storage media, computer program products, chips, or chip systems.

[0177] It should be understood that the division of parts in the embodiments of this application is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods. The functions in the embodiments of this application are integrated into a single processor, or the transceiver and processor may exist separately. The integrated device described above can be implemented in hardware, such as a chip, or in the form of a software functional unit.

[0178] The terms "comprising" and "having," and any variations thereof, in the specification, claims, and accompanying drawings of this application are intended to cover non-exclusive inclusion, meaning that a process, method, system, product, or apparatus that includes a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such process, method, product, or apparatus.

[0179] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0180] Those skilled in the art should realize that the above one or more examples are only used to illustrate the technical solutions of this application, and not to limit them; although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.< / xn>

Claims

1. A container management system, characterized in that, The container management system includes: a first module; The first module is used to take over the system calls of the internal processes of the container, and the system calls are used to request the invocation of functions provided by the kernel of the operating system; The first module is also configured to reject the system call if the system call does not comply with the security policy.

2. The container management system according to claim 1, characterized in that, The operating system includes a user space, and the container management system further includes a second module, which is used to unload the system call to the user space for execution when the system call conforms to the security policy.

3. The container management system according to claim 2, characterized in that, The second module is also used to return the result of the system call to the internal process of the container after the system call is unloaded to user space for execution.

4. The container management system according to claim 2 or 3, characterized in that, The second module is also used to offload the system call to user mode for execution via inter-process communication when the system call conforms to the security policy.

5. The container management system according to claim 4, characterized in that, The second module includes a client and a server; The client is used to forward the system call to the server via inter-process communication when the system call conforms to the security policy; The server is used to implement the system call in the user space.

6. The container management system according to any one of claims 2-5, characterized in that, When the system call conforms to the security policy and the system call is an insecure system call, the second module is further configured to replace the insecure system call with a secure system call, wherein the secure system call is a system call based on a directory file descriptor.

7. The container management system according to claim 6, characterized in that, The insecure system call is the system call open. The second module is used to replace the system call open with the system call openat. The directory file descriptor of the system call openat or system call openat2 indicates the file system mount directory of the container.

8. The container management system according to claim 6, characterized in that, The insecure system call is the system call open. The second module is used to replace the system call open with the system call openat2, where the directory file descriptor of the system call openat2 indicates the file system mount directory of the container.

9. The container management system according to any one of claims 1-8, characterized in that, The operating system runs on an x86-64 architecture processor; the container management system also includes a third module; The third module is used to scan system call instructions in the internal processes of the container, the system call instructions being used to instruct the execution of the system call.

10. The container management system according to claim 9, characterized in that, The third module is further configured to replace the system call instruction with a jump instruction, the jump instruction being used to redirect the system call to the first module.

11. The container management system according to any one of claims 1-8, characterized in that, The operating system runs on an AArch64 architecture processor; the container management system also includes a third module, which is used to scan system call instructions in the internal processes of the container, and the system call instructions are used to instruct the execution of the system call.

12. The container management system according to claim 11, characterized in that, The third module is further configured to replace the system call instruction with a first instruction, the first instruction being configured to redirect the system call to a first jump code, and the first jump code being configured to redirect the system call to the first module.

13. The container management system according to claim 12, characterized in that, The first instruction is either the b instruction or the br instruction.

14. The container management system according to claim 13, characterized in that, The b instruction includes the b#imm instruction and the b.cond#imm instruction, and the br instruction includes br <xn> Core instructions, br x30 return variant instructions.< / xn> 15. The container management system according to any one of claims 12-14, characterized in that, The first jump board code includes the following instructions: save the x30 register to the stack, use the bl instruction to jump to the first module, restore the value of the x30 register from the stack, and jump to the next instruction after the system call instruction.

16. The container management system according to any one of claims 6-15, characterized in that, The container management system further includes a fourth module; the fourth module is used to configure system call restrictions for the internal processes of the container; the system call restrictions are used to invalidate unreplaced system call instructions in the internal processes of the container.

17. The container management system according to any one of claims 1-15, characterized in that, The container management system further includes a fourth module; the fourth module is used to configure control flow protection and data flow protection for the internal processes of the container; wherein, the control flow protection is used to prevent control flow from being hijacked; and the data flow protection is used to prevent unauthorized access or modification of the operating system's memory.

18. The container management system according to any one of claims 1-15, characterized in that, The container management system further includes a fourth module; the fourth module is also used to configure data flow protection for the internal processes of the container, wherein the data flow protection is used to prevent the memory of the operating system from being accessed or modified without authorization.

19. The container management system according to any one of claims 1-15, characterized in that, The container management system further includes a fourth module; the fourth module is also used to configure control flow protection for the internal processes of the container, wherein the control flow protection is used to prevent control flow from being hijacked.

20. The container management system according to claim 17 or 18, characterized in that, The data flow protection is also used to protect the container's data within the operating system kernel at the virtualization layer.

21. A container management method, characterized in that, A container runtime applied in an operating system, the container runtime being used to manage containers, the method comprising: System calls that take over the internal processes of the container; these system calls are used to request functions provided by the kernel of the operating system; If the system call does not comply with the security policy, the system call is rejected.

22. The method according to claim 21, characterized in that, The operating system includes a user mode, and the method further includes: When the system call conforms to the security policy, the function invoked by the system call is offloaded to the user space for execution.

23. The method according to claim 22, characterized in that, After the system call is unloaded to user space for execution, the method further includes: returning the result of the system call to the internal process of the container.

24. The method according to claim 21, characterized in that, The operating system includes a kernel mode, and the method further includes: When the system call conforms to the security policy, the operating system is switched to the kernel mode to implement the system call.

25. The method according to claim 24, characterized in that, After the operating system switches to kernel mode to implement the system call, the method further includes: returning the result of the system call to the internal process of the container.

26. The method according to claim 22 or 23, characterized in that, When the system call conforms to the security policy and the system call is an insecure system call, the method further includes: replacing the insecure system call with a secure system call, wherein the secure system call is a system call based on a directory file descriptor.

27. The method according to claim 26, characterized in that, The insecure system call is the system call open. The second module is used to replace the system call open with the system call openat or the system call openat2. The directory file descriptor of the system call openat or the system call openat2 indicates the file system mount directory of the container.

28. The method according to any one of claims 21-27, characterized in that, The operating system runs on an x86-64 architecture processor; prior to the system call that takes over the internal processes of the container, the method further includes: Scan the system call instructions in the internal processes of the container; the system call instructions are used to instruct the execution of the system call.

29. The method according to claim 28, characterized in that, The method further includes: replacing the system call instruction with a jump instruction; the jump instruction is used to redirect the system call to the container runtime.

30. The method according to any one of claims 21-27, characterized in that, The operating system runs on an AArch64 architecture processor; prior to the system calls that take over the internal processes of the container, the method further includes: Scan the system call instructions in the internal processes of the container; the system call instructions are used to instruct the execution of the system call.

31. The method according to claim 30, characterized in that, The method further includes: replacing the system call instruction with a first instruction; the first instruction is used to redirect the system call to a first jump code, and the first jump code is used to redirect the system call to the container runtime.

32. The method according to claim 31, characterized in that, First instruction; the first instruction is either the b instruction or the br instruction.

33. The method according to claim 31 or 32, characterized in that, The first jump board code includes the following instructions: save the x30 register to the stack, use the bl instruction to jump to the first module, restore the value of the x30 register from the stack, and jump to the next instruction after the system call instruction.

34. The method according to any one of claims 28-33, characterized in that, The system call instructions in the internal process include system call instructions in binary files and system call instructions that have been loaded into memory.

35. The method according to any one of claims 28-33, characterized in that, The method further includes: Configure system call restrictions for the container's internal processes; the system call restrictions are used to invalidate unreplaced system call instructions in the container's internal processes.

36. The method according to any one of claims 21-35, characterized in that, The method further includes: Configure control flow protection and data flow protection for the internal processes of the container; wherein, the control flow protection is used to prevent control flow from being hijacked; and the data flow protection is used to prevent unauthorized access or modification of the operating system's memory.

37. The method according to any one of claims 21-35, characterized in that, The method further includes configuring data flow protection for the internal processes of the container, wherein the data flow protection is used to prevent unauthorized access or modification of the operating system's memory.

38. The method according to any one of claims 21-35, characterized in that, The method further includes configuring control flow protection for the internal processes of the container, wherein the control flow protection is used to prevent control flow hijacking.

39. The method according to claim 36 or 37, characterized in that, The data flow protection is also used to protect the container's data within the operating system kernel at the virtualization layer.

40. An electronic device, characterized in that, It includes a processor and a memory; the processor is configured to execute instructions stored in the memory, causing the electronic device to perform the method as described in any one of claims 21-39.

Images