A container isolation and hardening method and system based on confined eBPF technology

Abstract

This invention belongs to the field of computer security technology and relates to a container isolation and hardening method and system based on restricted eBPF technology. The method mainly includes: constructing an eBPF program capable of hardening container security isolation; attaching the eBPF program to kernel hook points; triggering the eBPF program and executing corresponding security protection logic when the kernel executes a critical point on a specific path; constructing a two-level eBPF function permission restriction model based on eBPF program granularity and eBPF helper function granularity; and using this two-level eBPF function permission restriction model to restrict the eBPF functions of the container, enabling the secure use of eBPF technology in container isolation and hardening scenarios. This invention improves the security of container environment isolation while ensuring that eBPF technology itself is not maliciously exploited, making eBPF technology more adaptable to container environments and enhancing its flexibility and security at the container level.

Description

Technical Field

[0001] This invention relates to the field of computer security technology, particularly cloud-native and container security. Specifically, it provides an isolation and hardening method and system based on restricted eBPF technology for container environments, which improves the security of container environment isolation while ensuring that eBPF technology itself cannot be maliciously exploited. Background Technology

[0002] Today's cloud computing ecosystem is evolving towards cloud-native architecture. While cloud computing answers the question of "where to deploy and run applications," cloud-native addresses the question of "how to deploy and run applications better in the cloud." This indicates that cloud computing development is shifting towards optimizing application deployment and operation. Cloud-native is a rapid application iteration technology based on containerization, microservices, and container orchestration, offering excellent elasticity and fault tolerance. Containerization holds a central position in the cloud-native technology stack. A container is a unit that packages program code, related data, and dependencies together, with each container unit capable of independently running workloads and providing functionality. Unlike virtual machines, multiple containers on a system share the same kernel and leverage existing kernel isolation mechanisms to achieve lightweight isolation at the operating system level. Because they share the same kernel, containers enable efficient and highly elastic software deployment and development, playing a crucial role in achieving agile deployment, portability, and scalability of applications in cloud-native environments. However, with the widespread adoption of container technology, security issues exposed by containers are increasing, and users are paying increasing attention to container security, especially isolation security. Compared to virtual machines, the performance advantages of containerization's lightweight isolation scheme come at the cost of reduced isolation strength. This exposes it to security threats stemming from the weak isolation of containers, such as container escape and resource isolation failure. These security threats are particularly serious, potentially compromising not only the security of individual containers but also the secure operation of the entire cloud environment. Therefore, how to more effectively harden the isolation of container runtime is a pressing issue requiring further research.

[0003] Lightweight container isolation is implemented based on Linux's existing isolation technologies, such as: 1) using namespace technology to achieve view-level isolation of users, file systems, and networks within containers; 2) using cgroups technology to limit the container's usage of various computing resources such as CPU and memory; 3) using Seccomp technology to restrict executable system calls within containers; and 4) using Capabilities technology to further refine root privileges within containers and impose fine-grained functional restrictions. The Linux technologies used for container isolation include... Figure 1As shown.

[0004] Currently, some researchers are using the aforementioned Linux isolation techniques to harden container isolation security. However, these methods have certain limitations. Linux's native isolation mechanism is not specifically designed for container scenarios, and modifying it to adapt to container environments can lead to semantic gaps. Furthermore, the mixing of various security mechanisms reduces the flexibility and increases the complexity of isolation hardening methods. Other researchers have addressed these issues and attempted to directly modify the kernel code for container isolation security hardening. However, modifying the kernel code introduces external patch sets, which can easily compromise system stability. In practical applications, some enterprises and users are often reluctant to make significant kernel modifications due to compatibility and stability considerations, thus limiting the applicability of this kernel code modification-based approach.

[0005] In recent years, with the rise of Extended Berkeley Packet Filter (eBPF) technology, using eBPF to harden the security of cloud-native environments has become popular. eBPF is a kernel code hooking technology that can securely and efficiently extend kernel functionality without modifying the kernel source code. The following is the process of using eBPF: After writing eBPF program code in a high-level programming language such as C, users compile it into eBPF bytecode using a compiler such as LLVM. Then, a mounting tool mounts the eBPF bytecode to various specific kernel hook points. When the kernel executes to the specified path, the mounted eBPF program will be executed. Users can use eBPF technology to securely, flexibly, and efficiently customize kernel functionality while keeping the kernel source code unchanged. Since multiple containers running on the same system share the same kernel, using eBPF technology for unified security hardening of containers at the kernel level is well-suited to cloud-native scenarios. Many researchers have also explored methods for applying eBPF technology to container security, and their research shows that eBPF technology has broad application prospects in enhancing container security.

[0006] However, while eBPF technology is highly effective in hardening container security, its powerful features also introduce additional attack surfaces to cloud-native environments. Research indicates that without security restrictions on eBPF usage in cloud-native environments, attackers could exploit eBPF tools to compromise container security and even disrupt the overall security of the cloud environment. Therefore, ensuring that eBPF technology itself is not maliciously exploited by attackers while simultaneously hardening containers is a critical issue that warrants serious attention.

[0007] Based on the above background, it can be seen that the current container isolation and hardening technologies mainly suffer from the following problems, and corresponding development trends can be summarized: 1) High performance overhead. Although existing container isolation and hardening methods can effectively improve container security, the performance overhead they add to the system is often quite large. Therefore, the industry needs to explore a container isolation and hardening mechanism that combines high security and high performance. 2) Lack of flexible and stable isolation methods at the kernel level. Because there is a semantic gap between Linux's native isolation mechanism and container scenarios, container hardening methods based on Linux's native isolation mechanism often lead to insufficient flexibility and stability. The industry needs to explore a flexible and stable container isolation security hardening method that can be implemented at the kernel level. 3) Lack of functional restrictions for eBPF technology. Since the existing eBPF technology's functional permission model cannot guarantee that it can only be used securely in a cloud-native environment, the industry hopes to further refine and restrict the functionality of eBPF technology, so as to prevent malicious exploitation while using eBPF technology to harden container isolation. Summary of the Invention

[0008] The container isolation and hardening method based on restricted eBPF technology proposed in this invention aims to simultaneously meet the following requirements and provide corresponding functions: 1) It can perform precise access control and isolation of various access behaviors of containers at the granularity of kernel function parameters; 2) It can obtain the namespace to which a process or file belongs in kernel-related data structures, thereby distinguishing the container scope to which a process or file belongs; 3) It can flexibly restrict the system calls executed by container processes; 4) It can implement fine-grained restrictions on the functional permission model of eBPF technology while keeping the kernel source code unchanged.

[0009] The container isolation and hardening method based on restricted eBPF technology proposed in this invention can meet all the above requirements. This method designs several eBPF programs based on eBPF technology and uses the LSM framework to mount them to the corresponding kernel hook points, thereby realizing fine-grained access control measures for container environments. At the same time, it designs and implements a two-level eBPF function permission restriction model and method based on the granularity of eBPF programs and the granularity of eBPF auxiliary functions, ensuring that eBPF technology can only be used securely in container isolation and hardening scenarios.

[0010] The technical solution adopted in this invention is as follows:

[0011] A container isolation hardening method based on restricted eBPF technology includes the following steps:

[0012] Build an eBPF program that can harden container security isolation, attach the eBPF program to the kernel hook point, and trigger the eBPF program and execute the corresponding security protection logic when the kernel executes to a critical point on a specific path.

[0013] A two-level eBPF function permission restriction model is constructed based on the granularity of eBPF program and the granularity of eBPF helper functions. The eBPF functions of the container are restricted by the two-level eBPF function permission restriction model, so that eBPF technology can be used safely in container isolation and hardening scenarios.

[0014] Furthermore, the above method also includes setting up a daemon process in user space, the daemon process comprising the following three core components:

[0015] Container Monitoring and Management Suite: Responsible for real-time monitoring of all containers in the cloud-native environment, tracking the entire lifecycle of containers from creation to destruction, capturing container-related information when the container state changes, and completing the secure registration and deregistration process of containers;

[0016] Policy execution engine: It is responsible for receiving security policy files issued to containers by container users and system administrators, parsing the security policy files, converting the parsed security policies into corresponding eBPF mapping entries and adding them to the container's corresponding eBPF mapping, thus realizing the complete process of loading security policies into the kernel.

[0017] eBPF Object Manager: Responsible for managing all eBPF objects, including eBPF applications and eBPF mappings, and also responsible for the unified management of eBPF-related operations.

[0018] Furthermore, the security policy document includes basic triples and additional information for implementing fine-grained protection;

[0019] The basic triple includes: 1) the absolute path of the active party initiating the access behavior on the file system, i.e., the subject absolute path; 2) the absolute path of the passive party receiving the access behavior on the file system, i.e., the object absolute path; 3) the specific action of the access behavior.

[0020] Additional information for implementing fine-grained protection includes: 1) specifying whether access control is applied to directories or recursively applied to directories; 2) whether read-only access restrictions are applied; 3) specifying the default behavior of container security protection as allow or deny by default; 4) specifying the threshold for the time interval of container symbolic link operations; 5) specifying the namespace range that the container can communicate with; and 6) specifying the eBPF procedures, eBPF helper functions, and available eBPF mappings that the container can use.

[0021] Furthermore, the eBPF program includes: a fine-grained access control checker based on the subject and object of container access behavior, a namespace consistency checker for container access behavior, and an eBPF mitigation program for symbolic link race condition vulnerabilities; the eBPF mapping includes: a mapping that stores access control policies for each container, a mapping that stores eBPF programs and eBPF helper functions available to the container, a mapping that stores the range of communicable namespaces for each container, and a mapping that stores the symbolic link refresh time interval threshold for each container.

[0022] Furthermore, the fine-grained access control check procedure based on the subject and object of container access behavior includes:

[0023] When a container process triggers a specified access behavior, the complete subject path, complete object path, and specific access behavior are extracted from the LSM hook point and the context information provided by the eBPF program to form a security policy triple.

[0024] Based on the security policy triplet, security policy matching is performed in the following order: 1) Complete subject path + complete object path; 2) Complete subject path + hierarchical components of each object path; 3) Complete object path; 4) Hierarchical components of each object path.

[0025] If a corresponding security policy is matched, access control will be applied to this access attempt, and a decision will be made on whether to allow the access attempt to occur.

[0026] Furthermore, the namespace consistency check procedure for the container access behavior includes:

[0027] When extracting security policy triples from context information, namespace information corresponding to the subject and object is extracted from kernel data structures;

[0028] Based on the namespace information corresponding to the subject and object, check in the eBPF mapping of the communicable namespace range of each container whether the current cross-namespace behavior is allowed. Only container access behavior that meets the namespace communication consistency requirements is allowed.

[0029] Furthermore, the eBPF mitigation procedure for the symbolic link race condition vulnerability includes:

[0030] Specify a time interval threshold t for each container and store it in the eBPF mapping corresponding to the container;

[0031] When a container performs symbol link-related operations, it records the current kernel timestamp and calculates the difference between it and the timestamp of the container's last symbol link operation. If the difference is less than the specified time interval threshold t, it indicates that the container has a symbol link refresh behavior and rejects the current symbol link operation.

[0032] Furthermore, the two-level eBPF function permission restriction model is used to restrict the eBPF function of the container by verifying whether the process executing the bpf system call is a daemon process through a specific eBPF program, and attaching the eBPF program through LSM hook points, thereby achieving comprehensive control over eBPF-related behaviors, and adopting two protection modes against eBPF abuse behaviors: strict mode and lenient mode.

[0033] The strict mode includes:

[0034] All eBPF programs are written by security administrators and undergo rigorous security verification to form a list of verified eBPF programs. Then, the security administrators allocate a range of available eBPF programs to the container based on its needs. The container process sends the name of the eBPF program it requests to use to the daemon process. After receiving the request, the daemon process searches within the container's range of available eBPF programs. If the program exists, it means that the container can use the corresponding eBPF program.

[0035] The easing mode includes:

[0036] The daemon maintains an independent bitmap structure for each container, indicating the range of offensive eBPF helper functions that the container can use. Setting the corresponding bit to "1" indicates that the container is allowed to use eBPF programs containing the corresponding offensive helper functions, while setting it to "0" indicates that it is not allowed. The daemon also maintains a list describing the eBPF mappings that each container can use, which ensures that the container's eBPF programs cannot access certain critical security eBPF mapping resources.

[0037] When a container needs to use its own eBPF program, it transmits the code text of the eBPF program that it wants to mount to the kernel to the daemon process. After receiving the code text, the daemon process performs preprocessing: 1) Adds a field at the beginning of the code text to identify the namespace of the container to which the eBPF program belongs; 2) Inserts a piece of logic at the beginning of each eBPF program segment in the code text to verify whether the process that triggered the eBPF program is consistent with the namespace of the corresponding container, ensuring that only eBPF programs that pass this verification will continue to execute the original logic.

[0038] The daemon compiles the pre-processed container eBPF program into the corresponding eBPF bytecode, and then performs a security analysis on the eBPF bytecode. If the container's eBPF program uses helper functions or mappings that are outside its permitted scope, the daemon refuses to mount the eBPF program.

[0039] A container isolation and hardening system based on restricted eBPF technology includes a daemon process in user space, a kernel hook point, and an eBPF object in kernel space. The eBPF object includes an eBPF program capable of hardening container security isolation. The eBPF program is attached to the corresponding kernel hook point. When the kernel execution reaches a critical point on a specific path, the eBPF program is triggered and the corresponding security protection logic is executed. The daemon process uses a two-level eBPF function permission restriction model based on eBPF program granularity and eBPF helper function granularity to restrict the eBPF functions of the container, enabling the safe use of eBPF technology in container isolation and hardening scenarios.

[0040] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0041] (I) This invention utilizes eBPF technology to design a fine-grained and flexible eBPF program for container isolation and hardening, which improves the isolation security of container runtime from multiple perspectives, such as access control based on subject / object path matching, namespace consistency checks of container access behavior, and symbolic link condition race mitigation.

[0042] (II) This invention utilizes eBPF technology to inject a security hardening mechanism into the kernel, achieving low-performance overhead, flexible and stable kernel-level security isolation without changing the kernel code. It balances performance and security, solving the problems of high performance overhead and lack of flexible and stable kernel-level security isolation in current container hardening methods.

[0043] (III) This invention introduces an eBPF function restriction model, which restricts and defends against specific functions and scenarios in which eBPF technology may be maliciously exploited, ensuring that eBPF technology can be used safely in a container environment with a shared kernel.

[0044] In summary, this invention proposes a set of eBPF programs that can strengthen container security isolation. These eBPF programs are then attached to corresponding kernel hooks within the LSM framework, allowing them to be triggered and execute corresponding security protection logic when the kernel reaches critical points on specific paths, thereby improving container isolation at a fine-grained level. Furthermore, this invention specifically addresses the issue of eBPF technology's inability to be used securely in container environments. It restricts the eBPF functionality usable in containers at both the eBPF program and eBPF helper functions level, making eBPF technology more adaptable to container environments and thus improving its flexibility and security at the container level. Attached Figure Description

[0045] Figure 1 It is a Linux kernel isolation technology used by containers.

[0046] Figure 2 It is the overall framework of a container isolation and hardening method based on restricted eBPF technology.

[0047] Figure 3 It is an eBPF program: policy matching based on subject-object paths.

[0048] Figure 4 It is an eBPF program: Namespace Consistency Verification.

[0049] Figure 5 This is an eBPF application: Symbolic link race condition mitigation.

[0050] Figure 6 It is a functional constraint model for eBPF: strict mode.

[0051] Figure 7 It is a functional constraint model for eBPF: relaxed mode.

[0052] Figure 8 This refers to the increased basic system performance overhead under different security protection configurations.

[0053] Figure 9 This refers to the increased performance overhead of system calls under different security protection configurations. Detailed Implementation

[0054] To better understand the design concept and principle of this invention, the specific implementation method of this invention will be described below in conjunction with the accompanying drawings and examples.

[0055] The overall architecture of this invention is as follows Figure 2 As shown, it includes the following parts:

[0056] (I) Daemon Process. The daemon process runs in user space and mainly consists of the following three core components, each providing different primary functions:

[0057] 1) Container Monitoring and Management Suite: This suite is mainly responsible for real-time monitoring of all containers in the cloud-native environment. It maintains a set of data structures and binds them to container objects, tracks the entire lifecycle of containers from creation to destruction, captures relevant container information when the container state changes, and completes the secure registration and deregistration process of containers. Only containers that have been securely registered will be included in the security mechanism implemented by this invention for management.

[0058] The aforementioned set of data structures refers to an independent management data structure maintained for each container in the system within the container monitoring and management suite. This structure includes the following fields: 1. Container ID; 2. Container Name; 3. Container Image; 4. Container Status; 5. Container Process PID; 6. Container PID Namespace ID; 7. Container Mount Namespace ID; 8. Security Registration Flag; 9. CAP_SYS_BPF Flag. The container monitoring and management suite captures dynamic container behavior in the system by listening to container-related events and actions, and synchronously updates the corresponding information to the relevant data structure. Based on this data structure, it performs container security management and operations. For example, when a container is created, the suite synchronously creates a corresponding data structure instance and initializes its basic information (such as container ID, container name, etc.), and then performs security registration; when a container's status changes, it updates the corresponding status information (such as the container status field); when a container exits or is destroyed, it performs a security deregistration operation and synchronously deletes the corresponding data structure, etc.

[0059] Security registration is a process of bringing a container into the security management scope of the container isolation and hardening method proposed in this paper. The specific process is as follows: a) Obtain information such as container ID, PID namespace ID, and Mount namespace ID from the data structure, and use these two namespace IDs to construct the container's NSKey structure. b) Create the corresponding security policy eBPF mapping sec_policies for the container. c) Write the "NSKey→sec_policies mapping" entry into the system's overall container security policy eBPF mapping. d) Send a signal to the container monitoring and management suite, and update the container's status to "registered". e) The security deregistration process is the reverse of the above process, completing the container's security deregistration by revoking the relevant resources in reverse order.

[0060] 2) Policy Execution Engine: This component is responsible for receiving security policy files issued to containers by container users and system administrators. It then performs policy parsing based on YAML format on the security policy files. After parsing, the security policies are converted into corresponding eBPF mapping entries and added to the container's corresponding eBPF mapping, thus realizing the complete process of loading the security policies into the kernel.

[0061] 3) eBPF Object Manager: This component manages all eBPF objects related to this invention within the system, including the eBPF programs used and eBPF mappings. It also manages all eBPF-related operations within the system, including receiving eBPF programs and eBPF C code text requested by containers with CAP_SYS_BPF permissions, performing proxy compilation of the container's eBPF C code to form the corresponding eBPF program, and pre-checking the mounting of eBPF programs in the kernel to implement eBPF functional limitations.

[0062] (ii) Kernel Hooks. This invention is based on the LSM (Linux Security Module) framework and mounts eBPF programs to corresponding kernel hooks according to different eBPF functions. The LSM hooks used can provide context information when the container executes relevant system calls, such as function parameters and calling processes, and pass this information to the eBPF program for further processing.

[0063] (III) eBPF Objects. The eBPF objects involved in this invention are mainly divided into two categories:

[0064] 1) eBPF programs that are mounted to each LSM hook point and provide different security protection and inspection mechanisms, including fine-grained access control inspection programs based on the subject and object of container access behavior, namespace consistency inspection programs for container access behavior, and eBPF mitigation programs for symbolic link race condition vulnerabilities, etc.

[0065] 2) Various eBPF mappings that work with various eBPF security programs and container eBPF programs, including mappings for storing access control policies for each container, mappings for storing eBPF programs and eBPF helper functions available to containers, mappings for storing the namespace ranges that each container can communicate with, and mappings for storing the refresh interval thresholds of symbolic links for each container, etc.

[0066] The following describes the application process of the security policy of this invention. First, the user constructs a security policy file according to a specified paradigm. The content of the security policy file must include at least the following:

[0067] 1) The absolute path of the active party initiating the access behavior on the file system, i.e., the absolute path of the subject;

[0068] 2) The absolute path of the passive party receiving the access request on the file system, i.e., the absolute path of the object;

[0069] 3) Specific actions of access behavior, such as reading, writing, or performing access.

[0070] These three attributes together form the basic triplet of an access control policy. Security policy files may also contain additional information for implementing fine-grained protection:

[0071] 1) Specify whether this access control applies to directories or whether it applies recursively to directories;

[0072] 2) Whether to implement read-only access restrictions;

[0073] 3) Specify the default behavior for container security protection as either allow or deny by default;

[0074] 4) Specify the threshold for the time interval of symbolic link operations for this container;

[0075] 5) Specify the namespace range that the container can communicate with;

[0076] 6) Specify the eBPF procedures, eBPF helper functions, and available eBPF mappings that the container can use.

[0077] After the user constructs the security policy file, they push it to the policy execution engine. Upon receiving the user's security policy file, the policy execution engine parses it to generate corresponding eBPF mapping entries. It then queries the container monitoring and management suite for the corresponding container's unique identifier, and uses this unique identifier to locate the container's security policy eBPF mapping (which stores the mappings of access control policies for each container). Finally, it places the generated eBPF mapping entries into that eBPF mapping. When a container process triggers a specified eBPF procedure, it will match the corresponding security policy entry (i.e., the eBPF mapping entry) from the container's corresponding security policy eBPF mapping and execute the appropriate access control behavior.

[0078] The set of eBPF procedures proposed in this invention, which can strengthen the safety isolation of containers, mainly consists of the following three parts:

[0079] (a) eBPF program: Policy matching based on subject-object paths (fine-grained access control checker based on container access behavior subject-object)

[0080] This type of eBPF program, when a container process triggers a specified access behavior, extracts the complete subject path, complete object path, and specific access behavior from the LSM hook point and the context information provided by the eBPF program, forming a security policy triple. It then performs security policy matching in the following order: 1) Complete subject path + complete object path; 2) Complete subject path + each object path hierarchical component; 3) Complete object path; 4) Each object path hierarchical component. If a matching security policy is found, access control will be applied to this access behavior, and the program will determine whether to allow the access behavior based on the verification result, thus implementing access control. The workflow is as follows: Figure 3 As shown.

[0081] In this context, the subject path is the absolute path of the subject, and the object path is the absolute path of the object. Taking " / usr / bin / cat / etc / passwd" as an example, the complete subject path is " / usr / bin / cat", and the subject path hierarchy components are " / usr / bin / " and " / usr / ". The complete object path is " / etc / passwd", and the object path hierarchy component is " / etc / ".

[0082] The process of determining whether to allow an access action based on the verification result involves several steps. Verification includes assessing the access action's mode (read, write, execute), scope (whether recursive path verification or folder-based verification), access control outcome (whether to allow or audit), and access control principles (default denial or default allow). Verification results can be categorized as follows: allow access without security auditing, allow access but perform security auditing (issue a system warning), or deny access. One of these three options is chosen.

[0083] This type of eBPF program achieves fine-grained access control over container-related critical resources at the function parameter level through the aforementioned security policy triplet, thereby improving container isolation. Furthermore, because eBPF programs possess the ability to retrieve and parse relevant kernel data structures, they can simultaneously identify whether a process belongs to a container or the host machine, enabling unified management of related access behaviors under different environments. This achieves seamless security protection for container environments while maintaining compatibility with the host system environment.

[0084] (ii) eBPF program: Namespace consistency verification (a namespace consistency checker for container access behavior)

[0085] This type of eBPF application adds cross-namespace access restrictions between containers and between containers and the host machine to the eBPF application based on the subject-object path-based policy matching mechanism. The workflow is as follows: Figure 4As shown, when extracting the security policy triple from the context information, this type of eBPF program simultaneously extracts the namespace information corresponding to the subject and object from the kernel data structure. It then checks whether the cross-namespace behavior is allowed within the communicable namespace range specified by the user in the security policy. Specifically, it searches for entries in the corresponding communicable namespace eBPF mapping (which stores the mapping of the communicable namespace ranges for each container). This method allows only container access behaviors that meet the namespace communication consistency requirements to occur, thereby improving container isolation at the namespace level.

[0086] (III) eBPF Procedure: Symbolic Link Race Condition Vulnerability Mitigation (eBPF mitigation procedure for symbolic link race condition vulnerability)

[0087] In addition to namespace consistency verification protection, a targeted protection against symbolic link race conditions is also needed. This is because attacks exploiting symbolic link race conditions, such as CVE-2018-15664, do not actually involve cross-namespace access, thus requiring additional targeted protection. The corresponding eBPF program working process of this invention is as follows: Figure 5 As shown, since containers do not normally need to frequently refresh symbolic links during runtime, a time interval threshold 't' can be specified for each container and stored in the corresponding eBPF mapping (a mapping that stores the symbolic link refresh time interval thresholds for each container). When a container performs symbolic link-related operations, this eBPF program will be triggered. This eBPF program records the current kernel timestamp and calculates the difference between it and the timestamp of the container's last symbolic link operation. If the result is less than the specified time interval threshold 't', it indicates that the container is attempting to refresh symbolic links, and the current symbolic link operation is rejected, thus effectively preventing race condition attacks based on symbolic link refreshes.

[0088] The aforementioned security measures for container isolation utilize eBPF technology; therefore, further functional restrictions on eBPF itself are necessary to prevent its malicious exploitation. The eBPF functional permission restriction model proposed in this invention will be explained in detail below.

[0089] First, it is necessary to strictly control BPF system calls across the system. This approach helps to narrow the attack surface for malicious exploitation of eBPF. Specifically, this invention verifies whether the process executing the BPF system call is a daemon process through a specific eBPF program, and attaches the eBPF program through a BPF LSM hook point, thereby achieving comprehensive control over eBPF-related behaviors. After completing the unified control of BPF system calls, this invention further proposes two protection modes against eBPF abuse: a strict mode and a lenient mode, to meet the eBPF security management needs in different scenarios.

[0090] (I) Strict Mode

[0091] The strict mode designed in this invention refers to the following: all eBPF programs on the system are written by the security administrator and have undergone rigorous security verification, thus forming a list of verified eBPF programs. The security administrator then allocates a range of available eBPF programs to containers based on their needs. When a container process sends the name of the requested eBPF program to the daemon process via a specific Unix socket mounted within the container, the daemon process, upon receiving the request, searches within the range of eBPF programs that the container can use. If the program exists, it means that the container can use the corresponding eBPF program.

[0092] The security of strict mode lies in the fact that all eBPF programs that containers can mount have been approved by security administrators, thus ensuring that malicious eBPF programs will not run on the system. Verified eBPF programs can support specific parameters. For example, for an eBPF program used to monitor system calls, the specific system call name can be used as a parameter. When a container requests to use this eBPF program, it also includes the specific system call name and sends it to the daemon process. The daemon process then injects the parameter into the corresponding data location of the eBPF program, thereby enabling the same program to run differently in different scenarios.

[0093] The working process of the above strict mode is as follows: Figure 6 As shown.

[0094] (II) Relaxed Mode

[0095] In contrast to strict mode, where containers can only use specific eBPF programs, lenient mode grants containers the ability to write and run their own eBPF programs. In lenient mode, the daemon maintains an independent bitmap structure for each container, indicating the range of potentially malicious eBPF helper functions that container can use. A "1" on a corresponding bit indicates that the container is allowed to use an eBPF program containing that malicious helper function, while a "0" indicates that it is not allowed. In addition, the daemon maintains a list describing the eBPF mappings that each container can use, ensuring that container eBPF programs cannot access certain critical security eBPF mapping resources.

[0096] When a container needs to use its own eBPF program, it must also transmit the C code text of the eBPF program that it wants to mount to the kernel to the daemon process via a specific Unix socket mounted inside the container. Upon receiving this C code text, the daemon process will perform the following preprocessing: 1) Add a field at the beginning of the code text to identify the container's namespace; 2) Then, at the beginning of each section of the eBPF program described in the code text, insert logic to verify whether the process triggering the eBPF program matches the corresponding container's namespace, ensuring that only eBPF programs that pass this verification will continue executing their original logic. This preprocessing only involves simple new variable initialization and variable equality checks, and will not have any unacceptable impact on the original eBPF program in terms of logic or performance.

[0097] After completing the above preprocessing, the daemon process will proxies the compilation of the modified C code for the container, while the security of the code itself is guaranteed by the eBPF verifier. Since all eBPF-related operation permissions have been centrally controlled on the system, the compilation process of the container's eBPF program should also be uniformly performed by the daemon process to ensure the consistency and integrity of the security design.

[0098] The daemon process compiles the pre-processed container eBPF program to form the corresponding eBPF bytecode. The crucial next step is to perform security analysis on this eBPF bytecode. Specifically, this involves analyzing and extracting the eBPF helper functions and eBPF mappings used in the eBPF program, with a focus on whether malicious helper functions are used. The extracted information is then compared with the container's list of available malicious helper functions and eBPF mappings. If the container's eBPF program uses helper functions or mappings beyond its permitted scope, the daemon process will refuse to mount the eBPF program, thus ensuring that even containers in permissive mode cannot use relevant eBPF critical resources without permission. It's worth noting that extracting relevant information from the eBPF program at the bytecode level is more reasonable because eBPF bytecode is a binary file formed after compiler optimization and verifier verification. It is immutable and analyzable; arbitrarily modifying the eBPF bytecode will cause the eBPF program to fail to mount to the kernel or malfunction.

[0099] The workflow of the eBPF functional constraint model under the above-mentioned relaxed mode is as follows: Figure 7 As shown.

[0100] The following section will conduct an experimental evaluation of the container isolation and hardening technology proposed in this paper (hereinafter referred to as eBPFArmor). Comparative experiments will be conducted from three dimensions: security capabilities, performance overhead, and ease of use. Furthermore, a comparative analysis will be performed with AppArmor, Seccomp, and the PATROL protection method proposed by Z. Li et al. AppArmor and Seccomp are currently mainstream container security frameworks; while PATROL is a container security protection method based on modifying kernel code, and it has good effectiveness in protecting against isolation defects based on vulnerabilities in container-related components.

[0101] For the experimental evaluation of security capabilities, this paper will conduct protection experiments on container isolation flaws based on insecure configurations (Table 1), container isolation flaws based on vulnerabilities in related components (Table 2), and eBPF abuse methods. Specifically, the protection experiments for container isolation flaws will employ the eBPFArmor, AppArmor, Seccomp, and PATROL methods proposed in this paper, and the security coverage and protection capabilities of each protection scheme will be quantitatively evaluated. Regarding eBPF abuse protection, since there are currently no mainstream dedicated protection technologies for malicious eBPF, the experiments will primarily be based on the eBPF functional limitation model proposed in this paper to conduct protection experiments against publicly available eBPF malicious capability POCs such as bad-bpf and ebpfkit.

[0102] Table 1. Container isolation deficiencies based on insecure configurations

[0103]

[0104] Table 2. Container isolation defects based on vulnerabilities in related components

[0105]

[0106] For performance overhead evaluation, this paper uses the sysbench benchmark tool to evaluate the basic system performance overhead in terms of CPU, memory, and file I / O, and the stress-ng stress testing tool to evaluate the performance overhead in system call scenarios such as process creation. The descriptions of each evaluation item are shown in Table 3. The first three items are evaluated using sysbench, and the subsequent items are evaluated using stress-ng. To comprehensively compare the performance impact of the proposed protection technology with AppArmor, several different security protection configurations were designed, and experiments were conducted on the above evaluation items under different protection configurations. A summary of the various security protection configurations is shown in Table 4. The performance overhead without any security protection measures is used as the baseline, and the performance overhead of other security protection configurations is calculated as a relative percentage increment based on the baseline configuration. Each performance experiment was executed 5 times, and the average value was taken as the final evaluation result.

[0107] The usability assessment mainly focuses on the protection approach, granularity, configuration difficulty of protection strategies, and scalability of the container isolation security protection scheme. It qualitatively compares and analyzes the container isolation technology based on the eBPF functional limitation model proposed in this paper with AppArmor, Seccomp, PATROL, and bpfkit-monitor.

[0108] Table 3. Performance Overhead Experimental Evaluation Items

[0109]

[0110] Table 4. Safety protection configuration used in the performance overhead experiment

[0111] name illustrate Baseline No security measures are applied, including AppArmor and Seccomp. AppArmor Base Enable AppArmor but do not apply any security policies AppArmor All A security policy that enables AppArmor and protects against the threats listed in Section 3.1. eBPFArmor Base Enable the security protection technologies proposed in this article but do not apply any security strategies. eBPFArmor All Enable the security protection technologies proposed in this paper and apply the security strategies for protecting against the threats listed in Section 3.1.

[0112] Experimental Results and Analysis:

[0113] 1) Safety Capability Experiment

[0114] The experimental results of the security capability experiment are shown in Table 5. "√" indicates that the protection method can protect against the corresponding security vulnerability scenario, "×" indicates that the protection method cannot protect against the corresponding security vulnerability scenario, and "-" indicates that the protection method is not applicable to the corresponding security vulnerability scenario. The explanations are as follows: For the protection of the C-A1 (unauthorized access to Docker remote API) scenario, it is only necessary to enable Docker remote API authentication to carry out protection, and no additional security protection is required; For the protection of the C-P1 (privileged container) scenario, specific protection is required for specific container isolation attacks, and the security configuration cannot be uniformly represented; PATROL is a security protection method based on modifying kernel code and is not applicable to container isolation vulnerability protection based on insecure configuration.

[0115] In terms of results, the technology proposed in this paper is the most comprehensive in terms of security capability coverage, providing effective protection against all listed container isolation threats. AppArmor, which also uses the LSM framework to implement file path-based security protection, is the second best option. For container component security, PATROL can achieve isolation hardening at the kernel file system level, resisting most vulnerabilities related to container component isolation defects. Finally, Seccomp, which can only restrict the enabling or disabling of system calls, has a relatively coarse granularity of security protection capabilities, thus limiting its security protection support capabilities for most container isolation threat scenarios. Even among these technologies, which can all successfully provide protection, the granularity and principles of protection differ in certain scenarios. For example, in the C-C1 threat scenario, the technology proposed in this paper can restrict only specific processes from executing the ptrace system call on a specified process, while AppArmor can only restrict the ptrace system call to be invoked by a specific process and cannot control the target process being invoked. Seccomp is even simpler and more direct, simply prohibiting containers from executing the ptrace system call. Similarly, in protecting against the CVE-2019-14271 vulnerability, the technology proposed in this paper and PATROL work from the underlying mechanism, implementing security protection based on restricting cross-namespace access between subjects and objects, while AppArmor requires additional security policies for surface patching. Furthermore, in the symbolic link refresh threat scenario based on the TOCTTOU attack, the technology proposed in this paper can dynamically monitor the call frequency of system calls programmatically and impose restrictions, while AppArmor and Seccomp do not have the ability to provide fine-grained protection based on call frequency, and PATROL blocks the erroneous resolution of symbolic links by marking the dentry structure.

[0116] Table 5. Results of Safety Capability Tests

[0117] Threat Number eBPFArmor AppArmor Seccomp PATROL C-A1 - - - - C-A2 √ √ × - C-F1 √ √ × - C-F2 √ √ × - C-C1 √(Fine-grained) √(Medium particle size) √(Coarse-grained) - C-C2 √(Fine-grained) √(Medium particle size) √(Coarse-grained) - C-C3 √(Fine-grained) √(Medium particle size) √(Coarse-grained) - C-C4 √ √ × - C-P1 - - - - CVE-2018-15664 √ × × √ CVE-2019-5736 √ √ × √ CVE-2019-14271 √(No configuration) √ (Configuration required) × √(No configuration) CVE-2019-16884 √ √ × - CVE-2021-30465 √ × × √ CVE-2022-0492 √ √ × √ CVE-2024-21626 √ √ × -

[0118] Table 6 shows the experimental results regarding security protection against eBPF abuse. The results demonstrate that the proposed two-level functional restriction model for eBPF effectively defends against eBPF abuse threats in both strict and lenient modes. Specifically, strict mode restricts the execution of unauthorized eBPF programs by allowing only security-approved eBPF programs to be mounted to the kernel by the daemon process; while lenient mode, based on eBPF bytecode security analysis, restricts eBPF programs from executing potentially malicious helper functions and accessing unauthorized eBPF mappings.

[0119] Table 6. Experimental Results of Security Capabilities Against eBPF Abuse

[0120] model Various Proof-of-Concepts in bad-bpf ebpfkit Strict mode √ √ Relaxed mode √ √

[0121] The security capability experiments described above demonstrate that the container isolation technology based on the eBPF functional limitation model not only covers the broadest range of container isolation threat scenarios in terms of protection scope, but also achieves multi-layered, fine-grained container security hardening from the underlying principles by combining multiple dimensions such as file paths and access behaviors, namespaces, system call parameters, and programmable security policies, highlighting the security protection effectiveness of the technology proposed in this paper. Furthermore, considering the security of using eBPF technology itself, a two-level functional limitation model for eBPF was established, providing fine-grained security protection for eBPF-related operations performed by individual containers that require CAP_SYS_BPFcapability.

[0122] 2) Performance overhead experiment

[0123] The performance overhead experiment results based on Tables 3 and 4 are as follows: Figure 8 as well as Figure 9 As shown, where Figure 8 The results of experiments demonstrating the basic system performance overhead in three areas—CPU, memory access, and file I / O—using the sysbench benchmark test are presented. Figure 9 The results of performance overhead experiments for various system calls performed using the stress-ng stress testing tool are presented.

[0124] from Figure 8 As can be seen, the container isolation security protection technology proposed in this paper, when compared with the baseline experimental results without any security protection measures, shows that the increased basic system performance overhead is lower than that of the current mainstream container security protection framework AppArmor in both cases where no security strategy is applied and when a security strategy that can protect against the threats listed in Section 3.1 is applied. This indicates that the container isolation security protection technology proposed in this paper has a greater advantage in overall performance than AppArmor.

[0125] Figure 9 The figure illustrates the performance overhead of different security protection configurations under various high-frequency system call execution scenarios. Analysis of the figure shows that the container isolation security protection technology proposed in this paper incurs less performance overhead than AppArmor in most system call scenarios. Notably, the proposed technology incurs approximately 14% less performance overhead on fork system calls than AppArmor. This is preliminarily speculated to be because AppArmor's security policy has an inheritance mechanism; the security policy of a process is automatically inherited to its child processes, which then create and maintain their own security policies. Therefore, AppArmor incurs significant additional overhead in scenarios with frequent child process creation. In contrast, the security policy of the proposed technology is based on a single container, and there is no additional special handling when creating child processes. Furthermore, in the experimental results of the chmod system call, the performance overhead of the technique proposed in this paper is about 23% higher than that of AppArmor. The analysis shows that this is because when applying security policies, the policy execution engine creates several corresponding file integrity protection policies, including a policy to check whether the chmod call will damage the integrity of the protected file. Therefore, there will be a high performance overhead in scenarios where the chmod system call is frequently called. However, in normal container usage scenarios, the chmod system call is a low-frequency operation, so the actual performance overhead is acceptable.

[0126] Regarding the additional performance overhead of the two-level eBPF functional limitation model proposed in this paper on the execution of eBPF programs, since it does not involve runtime modifications, there will be no additional runtime overhead. It will only increase the inter-process transmission latency of the eBPF program's C code and the overhead of security analysis and hash verification of the eBPF bytecode. These overheads depend on the size of the eBPF program and therefore cannot be quantitatively analyzed.

[0127] 3) Usability Analysis

[0128] For ease of discussion, the container isolation technology based on the eBPF functional limitation model proposed in this paper will be referred to as "eBPFArmor" below.

[0129] (1) Protection layer. In terms of protection strategies against some container isolation threats, eBPFArmor, AppArmor, and Seccomp can all achieve surface protection by restricting access to specific files or execution of system calls. However, in terms of protection against some CVE vulnerabilities, AppArmor can only provide security hardening based on surface access control rules, while eBPFArmor and PATROL can rely on kernel-level security mechanisms to prevent vulnerability exploitation principles from a low-level perspective, and have the ability to deal with 0-day attacks to a certain extent.

[0130] (2) Protection granularity. eBPFArmor uses eBPF technology, which can implement access control based on function parameters and callers, thus providing more granular security protection. PATROL, based on patching the kernel structure, combined with built-in access control rules, achieves effective protection at the dentry granularity. In contrast, AppArmor only supports access control based on a single file, a single process, and its access behavior. Seccomp can only perform "on / off" restrictions on system calls, which is relatively coarse-grained.

[0131] (3) Difficulty in policy configuration. eBPFArmor uses a security policy configuration file based on YAML format and implements security policy application in user space through a declarative API, which has good readability and ease of use; AppArmor has a mature security policy configuration mechanism, but the complexity and maintenance difficulty of the policy are high when multiple protection rules are applied at the same time; while Seccomp only restricts specific system calls, and the configuration method is the simplest.

[0132] (4) Scalability. eBPFArmor has high programmability and flexibility, and supports customized extensions by adding new eBPF programs. For example, it can limit the behavior of container processes based on the frequency of system calls. In contrast, AppArmor and Seccomp can only rely on predefined methods to perform container isolation protection, while PATROL limits scalability from the perspective of kernel hard coding, and the kernel needs to be recompiled every time it is changed.

[0133] The summary of the above usability dimensions is shown in Table 7. It can be seen that the technology proposed in this paper has advantages in terms of protection granularity and scalability.

[0134] Table 7. Usability Analysis of Various Container Isolation and Safety Protection Technologies

[0135] Usability dimension eBPFArmor AppArmor Seccomp PATROL Protection layer Surface + Underlying layer surface layer surface layer bottom layer Protective particle size thin middle thick thin Strategy configuration difficulty medium complex Simple Not involved Scalability high Low Low Low

[0136] To evaluate the usability of the eBPF functional restriction model, this paper selects bpfkit-monitor as a comparison object. While bpfkit-monitor is primarily used for static analysis and runtime monitoring of eBPF objects, it can only monitor eBPF-related activities and cannot provide fine-grained security protection against malicious eBPF behavior. In contrast, the eBPF functional restriction model proposed in this paper not only provides unified management of BPF system calls but also supports access control at two different granularities: eBPF programs and helper functions. This achieves more refined security management and can more effectively prevent security risks associated with malicious eBPF programs.

[0137] Another embodiment of the present invention provides a container isolation and hardening system based on restricted eBPF technology, which includes a daemon process located in user space and kernel hooks and eBPF objects located in kernel space. The eBPF object includes an eBPF program capable of hardening container security isolation. The eBPF program is attached to the corresponding kernel hook, and when the kernel execution reaches a critical point on a specific path, the eBPF program is triggered and the corresponding security protection logic is executed. The daemon process uses a two-level eBPF function permission restriction model based on eBPF program granularity and eBPF helper function granularity to restrict the eBPF functionality of the container, enabling the secure use of eBPF technology in container isolation and hardening scenarios. The specific working process of this system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0138] This invention can be implemented as software functional units and stored in a computer-readable storage medium. It includes several instructions to cause a computer device to execute some or all of the steps of the method described in this invention. For example, one embodiment of this invention provides a computer device (computer, server, smartphone, etc.) including a memory and a processor. The memory stores a computer program configured to be executed by the processor. The computer program includes instructions for performing the steps of the method of this invention. Another embodiment of this invention provides a computer-readable storage medium (such as ROM / RAM, disk, optical disk, etc.) storing a computer program. When executed by a computer, the computer program implements the steps of the method of this invention.

[0139] The specific embodiments of the present invention disclosed above are intended to help understand the content of the present invention and to implement it accordingly. Those skilled in the art will understand that various substitutions, changes, and modifications are possible without departing from the spirit and scope of the present invention. The present invention should not be limited to the content disclosed in the embodiments of this specification; the scope of protection of the present invention is defined by the claims.

Claims

1. A container isolation and hardening method based on confined eBPF technology, characterized in that, Includes the following steps: Build an eBPF program that can harden container security isolation, attach the eBPF program to the kernel hook point, and trigger the eBPF program and execute the corresponding security protection logic when the kernel executes to a critical point on a specific path. A two-level eBPF function permission restriction model based on eBPF program granularity and eBPF helper function granularity is constructed. The eBPF function permission restriction model is used to restrict the eBPF function of the container, so that eBPF technology can be used safely in container isolation and hardening scenarios. The method also includes setting up a daemon process in user space, the daemon process comprising the following three core components: Container Monitoring and Management Suite: Responsible for real-time monitoring of all containers in the cloud-native environment, tracking the entire lifecycle of containers from creation to destruction, capturing container-related information when the container state changes, and completing the secure registration and deregistration process of containers; Policy execution engine: It is responsible for receiving security policy files issued to containers by container users and system administrators, parsing the security policy files, converting the parsed security policies into corresponding eBPF mapping entries and adding them to the container's corresponding eBPF mapping, thus realizing the complete process of loading security policies into the kernel. eBPF Object Manager: Responsible for managing all eBPF objects, including eBPF applications and eBPF mappings, and also responsible for the unified management of eBPF-related operations; The two-level eBPF function permission restriction model restricts the eBPF function of the container by verifying whether the process executing the bpf system call is a daemon process through a specific eBPF program, and attaching the eBPF program through LSM hook points, thereby achieving comprehensive control over eBPF-related behaviors and adopting two protection modes against eBPF abuse: strict mode and lenient mode. The strict mode includes: All eBPF programs are written by security administrators and undergo rigorous security verification to form a list of verified eBPF programs. Then, the security administrators allocate a range of available eBPF programs to the container based on its needs. The container process sends the name of the eBPF program it requests to use to the daemon process. After receiving the request, the daemon process searches within the container's range of available eBPF programs. If the program exists, it means that the container can use the corresponding eBPF program. The easing mode includes: The daemon maintains an independent bitmap structure for each container, indicating the range of offensive eBPF helper functions that the container can use. Setting a "1" to a corresponding bit indicates that the container is allowed to use an eBPF program containing the corresponding offensive helper function, while setting a "0" indicates that it is not allowed. The daemon also maintains a list describing the eBPF mappings that each container can use, which ensures that the container's eBPF program cannot access certain critical security eBPF mapping resources. When a container needs to use its own eBPF program, it transmits the code text of the eBPF program that it wants to mount to the kernel to the daemon process. After receiving the code text, the daemon process performs preprocessing: 1) Adds a field at the beginning of the code text to identify the namespace of the container to which the eBPF program belongs; 2) Inserts a piece of logic at the beginning of each eBPF program in the code text to verify whether the process that triggered the eBPF program is consistent with the namespace of the corresponding container, ensuring that only eBPF programs that pass this verification will continue to execute the original logic. The daemon compiles the pre-processed container eBPF program into the corresponding eBPF bytecode, and then performs a security analysis on the eBPF bytecode. If the container's eBPF program uses helper functions or mappings that are outside its permitted scope, the daemon refuses to mount the eBPF program.

2. The method according to claim 1, characterized in that, The security policy document includes basic triples and additional information for implementing fine-grained protection; The basic triple includes: 1) the absolute path of the active party initiating the access behavior on the file system, i.e., the subject absolute path; 2) the absolute path of the passive party receiving the access behavior on the file system, i.e., the object absolute path; 3) the specific action of the access behavior. Additional information for implementing fine-grained protection includes: 1) specifying whether access control applies to directories or recursively to directories; 2) whether to restrict read-only access; 3) specifying the default behavior of container security protection as allow or deny by default; 4) specifying the threshold for the time interval of container symbolic link operations; 5) specifying the namespace range that the container can communicate with; and 6) specifying the eBPF procedures, eBPF helper functions, and available eBPF mappings that the container can use.

3. The method according to claim 1, characterized in that, The eBPF program includes: a fine-grained access control checker based on the subject and object of container access behavior, a namespace consistency checker for container access behavior, and an eBPF mitigation program for symbolic link race condition vulnerabilities; the eBPF mapping includes: a mapping that stores access control policies for each container, a mapping that stores eBPF programs and eBPF helper functions available to the container, a mapping that stores the range of namespaces that each container can communicate with, and a mapping that stores the symbolic link refresh interval threshold for each container.

4. The method according to claim 3, characterized in that, The fine-grained access control check procedure based on the subject and object of container access behavior includes: When a container process triggers a specified access behavior, the complete subject path, complete object path, and specific access behavior are extracted from the LSM hook point and the context information provided by the eBPF program to form a security policy triple. Based on the security policy triplet, security policy matching is performed in the following order: 1) Complete subject path + complete object path; 2) Complete subject path + hierarchical components of each object path; 3) Complete object path; 4) Hierarchical components of each object path. If a corresponding security policy is matched, access control will be applied to this access attempt, and a decision will be made on whether to allow the access attempt to occur.

5. The method according to claim 3, characterized in that, The namespace consistency check procedure for container access behavior includes: When extracting security policy triples from context information, namespace information corresponding to the subject and object is extracted from kernel data structures; Based on the namespace information corresponding to the subject and object, check in the eBPF mapping of the communicable namespace range of each container whether the current cross-namespace behavior is allowed. Only container access behavior that meets the namespace communication consistency requirements is allowed.

6. The method according to claim 4, characterized in that, The eBPF mitigation procedure for the symbolic link race condition vulnerability includes: Specify a time interval threshold t for each container and store it in the eBPF mapping corresponding to the container; When a container performs symbol link-related operations, it records the current kernel timestamp and calculates the difference between it and the timestamp of the container's last symbol link operation. If the difference is less than the specified time interval threshold t, it indicates that the container has a symbol link refresh behavior and rejects the current symbol link operation.

7. A container isolation and hardening system based on confined eBPF technology using the method described in any one of claims 1 to 6, characterized in that, This includes a daemon process located in user space, kernel hooks located in kernel space, and eBPF objects. The eBPF objects include eBPF programs that can harden container security isolation. The eBPF programs are attached to corresponding kernel hooks, and when the kernel executes to a critical point on a specific path, the eBPF programs are triggered and the corresponding security protection logic is executed. The daemon process uses a two-level eBPF function permission restriction model based on eBPF program granularity and eBPF helper function granularity to restrict the eBPF functions of the container, so that eBPF technology can be used securely in container isolation hardening scenarios.

8. A computer device, characterized in that, It includes a memory and a processor, the memory storing a computer program configured to be executed by the processor, the computer program including instructions for performing the method of any one of claims 1 to 6.

Images