Safety detection method, device and equipment during container operation and storage medium

Abstract

The invention relates to the technical field of cloud security, provides a security detection method and device during container operation, equipment and a storage medium, and is used for improving the security detection efficiency during container operation. According to the method, for a target function called by an operation behavior during running of an application program in a container, a calling event of the target function is filtered through a target kernel program before security detection, so that the number of kernel space functions sent to a user space for processing and the number of calling events of the user space function are reduced; system resources required by safety detection during container operation are reduced, and the detection efficiency is improved. Moreover, the alarm information is sent for the calling event with the risk, so that high-risk operation during container running can be prevented, and the safety during container running is guaranteed. Due to the fact that the target functions of the same injection type share one set of universal kernel program, it is avoided that an injection program is written for each target function in a targeted mode, the development workload is reduced, and meanwhile the maintainability of the target kernel program is improved.

Description

Technical Field

[0001] The present application relates to the field of cloud security technology and provides a container runtime security detection method, apparatus, device and storage medium. Background Art

[0002] Containers are an emerging lightweight operating system virtualization technology that enables efficient use of cloud servers and the distribution and deployment of applications on the cloud. They have become essential to cloud computing. With the widespread adoption of containers, container security has become even more critical.

[0003] Container security protection is primarily divided into two phases: pre-runtime security and runtime security. Pre-runtime security ensures the security of the container's initial state through baseline checks and static image scanning, while runtime security focuses on behavioral detection and alerting during application operation.

[0004] Currently, container runtime security detection methods primarily involve kernel module loading and Berkeley Packet Filter (BPF) program injection. Both methods dynamically inject programs into kernel space to monitor calls to sensitive functions. When a sensitive function is called, the program is sent to user space for security detection. By injecting programs into kernel space, these two methods avoid context switching between user and kernel space. Dynamic program injection also makes monitoring container operations more flexible, offering significant performance advantages.

[0005] Because kernel module loading can introduce unknown security risks and impact cloud platform stability, BPF program injection has become a mainstream method for container runtime security testing. However, certain sensitive functions are frequently called, resulting in a high number of sensitive functions being sent to user space, increasing system resource overhead for security testing and affecting detection efficiency. Summary of the Invention

[0006] Embodiments of the present application provide a container runtime security detection method, apparatus, device, and storage medium to reduce the system resources required for container runtime security detection and improve detection efficiency.

[0007] In one aspect, an embodiment of the present application provides a container runtime security detection method, the method comprising:

[0008] Obtaining a system function called by an operation behavior generated when the application in the container is running; wherein the system function includes one of a kernel space function and a user space function;

[0009] If the system function is a preset target function, filtering the call event of the target function based on the target kernel program associated with the target function; wherein the target kernel program is pre-generated based on the injection type of the target function;

[0010] When the filtering result is to retain the target function, performing a security check on the call event;

[0011] If it is detected that the call event has a risk, an alarm message corresponding to the call event is sent.

[0012] On the other hand, an embodiment of the present application provides a container runtime security detection device, including:

[0013] An acquisition module, configured to acquire a system function called by an operation behavior generated when an application in the container is running; wherein the system function includes one of a kernel space function and a user space function;

[0014] a filtering module configured to, if the system function is a preset target function, filter the call event of the target function based on a target kernel program associated with the target function; wherein the target kernel program is pre-generated based on the injection type of the target function;

[0015] A security detection module, configured to perform a security detection on the call event when the filtering result is to retain the target function;

[0016] The alarm module is used to send alarm information corresponding to the call event if it is detected that the call event has a risk.

[0017] Optionally, the device further includes a program generation module, configured to:

[0018] Obtaining and parsing a pre-generated filtering rule set to obtain at least one target function, an injection type of each target function, and at least one attribute information;

[0019] For each objective function, perform the following operations:

[0020] generating the filter parameter set based on at least one attribute information of the target function, and storing the filter parameter set in a target database; wherein the structure of the target database supports data sharing and communication between kernel programs and between kernel space and user space of an operating system;

[0021] After the validity of the target function is verified, a target kernel program is generated based on the injection type and function name of the target function;

[0022] Injecting the target kernel program into the kernel space of the operating system.

[0023] Optionally, the program generation module is specifically used to:

[0024] Get the kernel version of your own operating system;

[0025] When the kernel version exceeds the preset version, querying the preset function table;

[0026] When it is found that the target function is located in the preset function table, determining that the target function is valid;

[0027] Based on the injection type of the valid target function, loading the general kernel program corresponding to the injection type;

[0028] When the universal kernel program is loaded successfully, a target kernel program is generated in combination with the function name of the target function.

[0029] Optionally, the filtering module is specifically used to:

[0030] Based on the function name of the system function, determining whether the system function is a preset target function;

[0031] If so, loading the target kernel program associated with the target function to obtain a filter parameter set corresponding to the target function;

[0032] Based on the filter parameter set, the call event of the target function is filtered.

[0033] Optionally, the filtering module is specifically used to:

[0034] Determining whether the filter parameter set is empty;

[0035] If yes, retain the target function and store the call event of the target function in a common message queue for security detection;

[0036] Otherwise, when the filter parameter set contains at least one context information to be analyzed, obtain the reference context information corresponding to each of the at least one context information to be analyzed; when the at least one context information to be analyzed and the corresponding reference context information set are all successfully matched, retain the target function and store the call event of the target function in the common message queue for security detection.

[0037] Optionally, the filtering module is further configured to:

[0038] When the filter parameter set does not include the context information to be analyzed, if other attribute information in the filter parameter set meets the preset filter conditions, the target function is retained and the call event of the target function is stored in the common message queue for security detection.

[0039] Optionally, the filtering module is further configured to:

[0040] When at least one reference context information fails to be obtained, the target kernel program is terminated to stop security detection on the call event of the target function.

[0041] Optionally, the filtering module is specifically used to:

[0042] Storing the target function call event in a ring buffer in the kernel space;

[0043] When the call event of the target function is read from the buffer to the user space, adding process information and cluster information to the call event of the target function;

[0044] Packaging the target function call event after the information is added to obtain a data packet to be detected;

[0045] The data packet to be detected is stored in the common message queue for security detection.

[0046] Optionally, the security detection module is specifically used to:

[0047] Reading and parsing a data packet to be detected from the shared message queue one at a time to obtain a call event of a target function; wherein the data packet to be detected is generated based on the call event of the target function retained after filtering;

[0048] Matching the target function with sensitive functions in a pre-stored sensitive function set called by various sensitive operation behaviors respectively;

[0049] Based on the matching result, a security detection result of the call event of the target function is obtained.

[0050] Optionally, the alarm module is specifically configured to perform at least one of the following operations:

[0051] Send the warning information of the call event to the target mailbox to inform the risk;

[0052] The call event is stored in an alarm database so that the front-end device can display the call event on a page.

[0053] An electronic device provided in an embodiment of the present application includes a processor and a memory, wherein the memory stores a computer program. When the computer program is executed by the processor, the processor performs the steps of any one of the above-mentioned container runtime security detection methods.

[0054] An embodiment of the present application provides a computer-readable storage medium, which includes a computer program. When the computer program is executed on an electronic device, the computer program is used to cause the electronic device to perform the steps of any one of the above-mentioned container runtime security detection methods.

[0055] An embodiment of the present application provides a computer program product, which includes a computer program stored in a computer-readable storage medium. When a processor of an electronic device reads the computer program from the computer-readable storage medium, the processor executes the computer program, causing the electronic device to perform the steps of any of the above-mentioned container runtime security detection methods.

[0056] The container runtime security detection method, apparatus, device, and storage medium provided by the embodiments of the present application have the following beneficial effects:

[0057] A system function is called for the operating behavior of the application runtime in the container, where the system function can be a kernel space function or a user space function. When the called system function is a preset target function, the target function call event is filtered based on the target kernel program associated with the target function. In this way, the number of events of calling kernel space functions and user space functions sent to the user space for processing can be reduced, thereby reducing the system resources required for container runtime security detection and improving detection efficiency. When a risk is detected in the call event of the filtered target function, an alarm message is sent to prevent malicious operating behavior at the container runtime, thereby improving the security of the container runtime.

[0058] On the other hand, the target kernel program of each target function is pre-generated based on the injection type of the target function. Since target functions of the same injection type share a set of common kernel programs, there is no need to write a program injected into the kernel specifically for each target function, which reduces the development workload and has strong maintainability, thereby further improving the detection efficiency.

[0059] Other features and advantages of the present application will be described in the following description, and in part will become apparent from the description, or will be understood by practicing the present application. The purposes and other advantages of the present application can be realized and obtained by the structures particularly pointed out in the written description, claims, and drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0060] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0061] Figure 1A schematic diagram of an application scenario provided in an embodiment of the present application;

[0062] Figure 2 A container runtime security detection system provided in an embodiment of the present application;

[0063] Figure 3 An overall architecture diagram of a container runtime security detection provided by an embodiment of the present application;

[0064] Figure 4 A flowchart of a target kernel program generation method provided in an embodiment of the present application;

[0065] Figure 5 A schematic diagram of the target kernel program generation process provided in an embodiment of the present application;

[0066] Figure 6 A flowchart of a target kernel program generation method provided in an embodiment of the present application;

[0067] Figure 7 A flowchart of a container runtime security detection method provided in an embodiment of the present application;

[0068] Figure 8 A flow chart of a method for filtering an objective function provided in an embodiment of the present application;

[0069] Figure 9 A schematic diagram of a process for sequentially matching multiple contexts to be analyzed provided in an embodiment of the present application;

[0070] Figure 10 A schematic diagram of the three-terminal interaction process provided in an embodiment of the present application;

[0071] Figure 11 A structural diagram of a container runtime security detection device provided in an embodiment of the present application;

[0072] Figure 12 This is a schematic diagram of the hardware structure of an electronic device according to an embodiment of the present application. DETAILED DESCRIPTION

[0073] To make the purpose, technical solutions, and advantages of the embodiments of this application more clear, the technical solutions of this application will be clearly and completely described below in conjunction with the drawings in the embodiments of this application. Obviously, the described embodiments are part of the embodiments of the technical solutions of this application, but not all of them. Based on the embodiments described in this application document, all other embodiments obtained by ordinary technicians in this field without making creative efforts shall fall within the scope of protection of the technical solutions of this application.

[0074] The following is an introduction to some concepts involved in the embodiments of this application.

[0075] Cloud Native is a software development and deployment approach and philosophy designed to leverage the advantages of cloud computing to improve application scalability, elasticity, and maintainability. Cloud Native applications typically employ microservices architecture, containerized deployment, and automated management to adapt to dynamic cloud environments and evolving business needs.

[0076] Cloud computing is a computing model that distributes computing tasks across a resource pool consisting of a large number of computers, enabling various application systems to access computing power, storage space, and information services as needed. The network that provides these resources is called the "cloud." To users, these resources appear infinitely scalable and can be accessed at any time, used on demand, expanded at any time, and paid for on a per-use basis.

[0077] As a provider of cloud computing infrastructure, a cloud computing resource pool (referred to as a cloud platform, often referred to as IaaS (Infrastructure as a Service)) is established. Various virtual resources are deployed within the resource pool for external customers to choose from. This resource pool primarily includes computing devices (virtualized machines, including operating systems), storage devices, and network equipment.

[0078] Based on logical functional divisions, the PaaS (Platform as a Service) layer can be deployed on top of the IaaS layer, and the SaaS (Software as a Service) layer can be deployed on top of the PaaS layer. SaaS can also be deployed directly on top of IaaS. PaaS is a platform for software execution, such as databases and web containers. SaaS is a variety of business software, such as web portals and text messaging apps. Generally speaking, SaaS and PaaS are layers above IaaS.

[0079] Runtime security provides proactive protection by preventing malicious operations through security checks during container runtime. It is the last security barrier in the entire container lifecycle. Its core concept is to monitor and limit malicious behavior in the container and reduce the capabilities and permissions of the container process.

[0080] User space refers to a piece of memory space allocated by the operating system to each process, which is used to store process code, data, stack and other information.

[0081] User space programs are programs that run in user space and are composed of a series of user space functions. User space programs can usually only access their own memory space, cannot directly access the hardware resources of the operating system, and cannot perform certain restricted system operations. User space programs interact with kernel space through system calls to request kernel space to provide them with services, such as file operations, network communication, and memory management.

[0082] The kernel space is the core part of the operating system. It has full system control authority and the ability to directly access hardware resources. It is responsible for managing system resources, scheduling processes, handling interrupts and system calls, etc.

[0083] The extended Berkeley Packet Filter (eBPF) program is a kernel-space program that allows developers to run specific functions without modifying kernel code. The concept of eBPF is derived from BPF, which is a network filter that can capture and filter network packets. Currently, BPF usually refers to eBPF, so eBPF in the embodiments of this application can be referred to as BPF.

[0084] Kernel-space probes (Kprobes) are a dynamic monitoring mechanism in the Linux kernel that allows probes to be inserted anywhere within kernel-space functions and execute custom processing logic during container runtime. Kprobes can be used to monitor kernel-space function calls, function parameters, and return values, enabling real-time monitoring of kernel-space operations.

[0085] Userspace probes (Uprobes) are a dynamic monitoring mechanism in the Linux kernel that allows probes to be inserted anywhere within userspace functions and execute custom processing logic during container runtime. Uprobes can be used to monitor userspace function calls, function parameters, and return values, enabling real-time monitoring of userspace operations.

[0086] A tracepoint is a static probing mechanism in the Linux kernel that allows predefined detection points to be inserted into kernel-space functions. Unlike Kprobes and Uprobes, tracepoints are explicitly defined by kernel developers in the kernel source code. Compared to dynamic probing mechanisms, tracepoints offer greater portability and stability.

[0087] A database, in short, can be thought of as a digital filing cabinet—a place where electronic files are stored, supporting operations such as adding, querying, updating, and deleting data within those files. A "database" is a collection of data that is stored together, shared, minimally redundant, and independent of applications.

[0088] The following is a brief introduction to the design concept of the embodiments of this application.

[0089] When attackers infiltrate and invade containers, they often use them to carry out subsequent attacks. This process involves various sensitive operations, such as mounting sensitive directories, accessing sensitive files, and changing file permissions. These operations are implemented through function call events in the operating system. The core of container runtime security is to monitor high-risk operations within the container. This is achieved by monitoring sensitive function call events within the container during runtime.

[0090] Currently, container runtime security testing methods are primarily categorized into kernel module loading and BPF program injection. Kernel module loading offers strong scalability and powerful functionality, allowing arbitrary code execution in kernel space. However, it can introduce unknown security risks, easily causing kernel crashes, and hindering the security and stability of the operating system. Furthermore, there are cross-platform compatibility issues. Cloud platforms, on the other hand, have high stability requirements, and products used in cloud infrastructure should ensure their own stability as much as possible. Compared to kernel module loading, BPF program injection is typically more portable and flexible. Before being injected into the kernel, a validator verifies the BPF program. Furthermore, BPF programs run in a secure kernel sandbox, subject to strict resource restrictions and access controls. This prevents malicious code execution and kernel crashes, ensuring the security and stability of BPF programs, and ultimately the operating system. Therefore, BPF program injection has become the mainstream method for container runtime security testing.

[0091] Typically, during container runtime security testing, most of the time, BPF programs are used to monitor the call events of sensitive functions. These events are then sent to the user space for processing, and then security testing is performed using rule-based detection engines, such as Falco and Tracee.

[0092] However, certain sensitive functions can be called very frequently. Sending a large number of these events to user space for processing consumes significant system resources. Furthermore, current container runtime security detection methods typically require writing specific BPF programs for all called system functions (both kernel and user space), which results in a significant development workload and prohibitively high maintenance costs.

[0093] In view of this, the embodiments of the present application provide a container runtime security detection method, apparatus, device and storage medium for reducing the system resources and development workload occupied by maintaining container runtime security detection. Specifically, when the system function called by the operation behavior generated by the operation of the application in the container is a preset target function, the call event of the target function is filtered based on the target kernel program associated with the target function. In this way, the number of events of calling kernel space functions and user space functions sent to the user space for processing can be reduced, thereby reducing the system resources required for container runtime security detection and improving detection efficiency. When there is a risk in the call event of the filtered target function, an alarm message is sent to prevent malicious operation behavior at the container runtime, thereby ensuring the security of the container runtime.

[0094] On the other hand, the target kernel program of each target function is pre-generated based on the injection type of the target function. Since target functions of the same injection type share a set of common kernel programs, there is no need to write a program injected into the kernel specifically for each target function, which reduces the development workload and has strong maintainability, thereby further improving the detection efficiency.

[0095] The preferred embodiments of the present application are described below in conjunction with the drawings in the specification. It should be understood that the preferred embodiments described herein are only used to illustrate and explain the present application and are not used to limit the present application. In addition, the embodiments and features in the embodiments of the present application can be combined with each other if there is no conflict.

[0096] like Figure 1 , which is a schematic diagram of a scenario in which an embodiment of the present application is implemented, including two terminal devices 110 and a server 120 .

[0097] In the embodiment of the present application, the terminal device 110 includes but is not limited to mobile phones, tablet computers, laptop computers, desktop computers, e-book readers, intelligent voice interaction devices, smart home appliances, vehicle-mounted terminals, aircraft and other devices; various applications are installed on the terminal device 110 and can receive various operation behaviors, and the server 120 is the server corresponding to the various applications. The application runs in the container of the server 120. The server 120 detects the system functions called by the operation behaviors generated by the application runtime to achieve real-time detection of malicious operation behaviors, thereby ensuring the runtime security of the container. Among them, the server 120 can be an independent physical server, or a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms.

[0098] In an embodiment of the present application, multiple virtual machines are built on the server 120, and the multiple virtual machines each serve as a host node to form a server cluster. Each host node contains one or more containers, and each container contains all the resources required for the operation of the application, such as program code, runtime environment, system tools and function libraries, etc.

[0099] It should be noted that the container runtime security detection method in each embodiment of the present application can be executed by each host node on the server 120, and the host node calls the system function based on the operation behavior generated when the application program in the container is running, so as to realize the monitoring of sensitive operation behavior. When the called system function is a preset target function, the call event of the target function is security detected based on the filter parameter set obtained by the target kernel program associated with the target function. By filtering the target function call events of sensitive operation behaviors, the number of function call events for security detection is effectively reduced, and the system resources required for monitoring sensitive operation behaviors through BPF program injection in cloud native scenarios are reduced. At the same time, since each target function is associated with a target kernel program generated based on the injection type, there is no need to write a program for injection into the kernel for each target function, which reduces the development workload and has strong maintainability.

[0100] In an optional implementation, the terminal device 110 and the server 120 may communicate via a communication network.

[0101] In an optional implementation, the communication network may be a wired network or a wireless network.

[0102] It should be noted that Figure 1The examples shown are just for illustration. In fact, the number of terminal devices and servers is not limited and is not specifically limited in the embodiments of this application.

[0103] The container runtime security detection method provided in the embodiment of the present application can be applied to the cluster environment of the cloud platform in various scenarios such as cloud technology, artificial intelligence, smart transportation, and assisted driving. The method can be deployed in each host node of the server cluster in the form of an agent to provide reliable protection for the runtime security of the container on the server cluster.

[0104] Taking the smart transportation scenario as an example, city roads are often equipped with cameras to capture traffic violations. The videos, images, and other sensitive files captured by these cameras are uploaded in real time to the traffic management bureau's cloud platform database. An attacker could exploit the exposed interfaces of the smart transportation platform to infiltrate a container on a host node in the cloud platform cluster, using that container as a point of entry to execute an attack. When carrying out malicious activities, attackers often perform various sensitive operations within the container, such as searching for sensitive files and escaping the container. In this case, the agent deployed on the host node can monitor all sensitive file operations within the container and perform security checks on the system functions called by these operations. This allows for timely detection of malicious intrusions into the smart transportation platform and ensures the runtime security of the container.

[0105] The following describes the container runtime security detection method provided by the exemplary embodiment of the present application in combination with the application scenarios described above and with reference to the accompanying drawings. It should be noted that the above application scenarios are only shown to facilitate understanding of the spirit and principles of the present application, and the implementation methods of the present application are not limited in this respect.

[0106] The embodiment of the present application optimizes the monitoring performance of sensitive operation behaviors in the container runtime security detection in the cloud native scenario, which can reduce the system resources and development workload required for container runtime security detection. The structure of the container runtime security detection system corresponding to this optimization solution is as follows: Figure 2 As shown, it includes a function call event collection module, a function call event detection module and a function call event alarm module.

[0107] Each host node in the collection module contains an agent. Each agent is a program code that monitors the runtime security of the container. It is deployed on each host node in the form of a daemonse and is responsible for collecting system function call events generated by the operation behaviors of applications in all containers on the cluster. After filtering the call events of the target function, it pushes the filtered call events of the target function to the back-end device through the communication network to detect sensitive operation behaviors.

[0108] A rule detection engine is deployed in the detection module, which is responsible for performing security detection on the call events of the target functions pushed by all host nodes based on the pre-stored sensitive function set of sensitive operation behaviors (including the detection rules of sensitive functions called by sensitive operation behaviors).

[0109] The alert module generates an event alert when it detects a risky call event for a target function. For example, it displays the sensitive operations corresponding to the target function call event on the page in real time and notifies operations personnel via email to address the risk.

[0110] based on Figure 2 The functions implemented by each module in the embodiment of the present application are shown in the overall architecture diagram of the container runtime security detection. Figure 3 As shown, where:

[0111] In the function call event collection module, the operating system of each host node is divided into kernel space and user space. The kernel space contains kernel space functions and kernel space programs (such as BFP programs) corresponding to user space functions, and the user space contains user space programs. In the kernel space, for the collected call events of specific kernel space functions, the target kernel program generated by the injection type Kprobe and trancepoint of the kernel space function is used to obtain the filter parameter set corresponding to the kernel space function, and the call event of the kernel space function is filtered based on the filter parameter set. When it is determined that the kernel space function is retained, the call event of the kernel space function is stored in the ring buffer area. In the user space, for the collected call events of user space functions triggered by specific user space programs, the target kernel program generated by the injection type Uprobe of the user space function is used to obtain the filter parameter set corresponding to the user space function, and the user space function is filtered based on the filter parameter set. When it is determined that the user space function is retained, the call event of the user space function is stored in the ring buffer area. Furthermore, the function call events in the ring buffer of the kernel space will be continuously read into the user space to add process information and cluster information to indicate the process and cluster from which the function call events originated. Finally, the call events of the kernel space function and user space function with added information will be packaged and sent to the shared message queue of each host node in the back-end device.

[0112] In the function call event detection module, the filtered kernel space function and user space function call events are read from the shared message queue, and the original target function is stored in a database (such as ElsticSearch database, ClickHouse database, etc.) to facilitate the screening of sensitive function call events during later intrusion backtracing. At the same time, the read target function call event is pre-processed and input into the rule detection engine for security detection. The rule detection engine stores a sensitive function set of sensitive operation behaviors that appear in various containers. When the target function matches a sensitive function in the sensitive function set, it is determined that the target function call event is at risk, and the target function call event is stored.

[0113] In the function call event alarm module, alarms are issued for call events of risky target functions. The alarm methods are divided into real-time email alarm notifications and persistent page alarm displays. In this way, operators can achieve observable real-time perception of intrusion risks during container runtime and take corresponding risk measures based on the alarm information, thereby ensuring the security of container runtime.

[0114] The embodiments of the present application are aimed at the runtime security of containers in cloud-native scenarios. They adopt eBPF technology to monitor the system functions called by containers when running applications, and adopt a system architecture of function call event collection, function call event detection and function call event alarm to achieve real-time protection of the runtime security of containers in the cluster and improve the security of the entire life cycle of the container. Moreover, in the function call event collection module, the target kernel program based on the kernel space filters the call events of the target function sent to the user space, thereby discarding the call events of the safe target function and retaining the call events of the sensitive target function, limiting the number of function call events that need to be detected at the kernel level, thereby reducing the system resource overhead as a whole.

[0115] It should be noted that Figure 3 The functions implemented by each module can be integrated and executed on one device or distributed on different devices.

[0116] For example, when a device serves as the execution subject, the functions of the collection module, the detection module, and the alarm module can be implemented by each host node on the server cluster.

[0117] For another example, when multiple devices serve as execution entities, the functions of the collection module can be implemented by each host node on the server cluster, the functions of the detection module can be implemented by the back-end device, and the functions of the alarm module can be implemented by the front-end device.

[0118] In response to the problem of heavy workload in developing BPF programs injected into kernel space, an embodiment of the present application provides a general kernel program generation method, which generates corresponding target kernel programs according to the injection types of different target functions. Among them, the injection types are divided into three categories: Kprobe, Uprobe, and tracepoint, which can cover kernel space functions and user space functions in the operating system. For these three types of injection, general kernel programs are written respectively, each general kernel program corresponds to an injection type, and each general kernel program contains logic code for filtering function call events.

[0119] See also Figure 4 , is an implementation flow chart of a target kernel program generation method provided in an embodiment of the present application. Taking each host node in a server cluster as an execution subject as an example, the specific implementation process of this method is as follows:

[0120] S401: The host node obtains and parses a pre-generated filtering rule set to obtain at least one target function, and an injection type and at least one attribute information of each target function.

[0121] Since the operating system is divided into kernel space and user space, the operating system's system functions include kernel space functions and user space functions. At least one of the kernel space functions and user space functions called by sensitive operations is identified as a target function to be monitored. Based on the target function information, a filtering rule set is pre-generated. Each filtering rule in the filtering rule set contains: the function name of a target function, the injection type, and at least one attribute information.

[0122] For example, when it is necessary to monitor the call of the kernel space function ksys_dup3, the function name of the target function is specified as "ksys_dup3" in the filtering rule, the injection type is "Kprobe", and the attribute information is: the file descriptor is a socket, and the returned address structure type is AF_INET or AF_INET6.

[0123] During the target kernel program generation process, after obtaining the filtering rule set, the host node can obtain at least one target function that needs to be monitored and the injection type and at least one attribute information of each target function through parsing.

[0124] S402: For each target function, the host node generates a filter parameter set based on at least one attribute information of the target function, and stores the filter parameter set in a target database.

[0125] The data structure of the target database supports data sharing and communication between kernel programs and between the kernel space and user space of the operating system.

[0126] Optionally, the target database can be BPF Maps. BPF Maps are a special kernel data structure stored in memory that can store various types of data, such as counters, arrays, hash tables, etc.

[0127] In one example, in addition to file descriptor information and the returned address structure type, the attribute information of the target function may also include at least one of the function return value and context information, wherein the context information includes at least one of the process identifier (PID), cluster namespace, permission control mechanism (capability) and function input value (input).

[0128] S403: After the validity of the target function is verified, the host node generates a target kernel program based on the injection type and function name of the target function.

[0129] When maintaining container runtime security, only kernel-space and user-space functions need to be monitored; other functions (such as library functions) do not need to be monitored. Therefore, after parsing the target function, the validity of the target function can be verified to ensure that it is the function that needs to be monitored. Once the validity verification passes, the corresponding target kernel program is generated based on the target function's injection type and function name. The target kernel program is the target eBPF program injected into kernel space.

[0130] Take the target eBPF program as an example, Figure 5 As shown in the figure, the target kernel program generation process is as follows. Assuming that the injection types of the system function are Kprobe, Uprobe and trancepoint, each injection type corresponds to a common BPF program, and the function name of the target function is unique. Therefore, a unique target eBPF program can be generated using a common BPF program of the same injection type and the function name of the target function.

[0131] In one example, the specific implementation process of S403 is as follows: Figure 6 As shown, it mainly includes the following steps:

[0132] S4031: Obtain the kernel version of the operating system.

[0133] The kernel version can be obtained by the version number. Typically, a version number consists of three groups of digits: the first group indicates the major version, the second group indicates the minor version, and the third group indicates the modification count. An even number in the second group indicates a stable version, while an even number indicates a development version.

[0134] For example, 2.6.0 indicates the stable 2.6 kernel series.

[0135] S4032: Determine whether the kernel version exceeds the preset version. If so, execute S4033, otherwise end.

[0136] Considering that the BPF program injection technology for container runtime security has certain requirements for the kernel version, and lower-version kernels do not support BPF program injection technology, after obtaining your own kernel version, you can compare the kernel version with the preset version.

[0137] Optionally, the kernel version used in the embodiment of the present application is 5.4.0.

[0138] It should be noted that the embodiment of the present application does not impose any restrictive requirements on the kernel version and can be set according to actual needs.

[0139] S4033: Query the preset function table to determine whether the current target function is in the preset function table. If so, execute S4034, otherwise end.

[0140] The preset function table includes sensitive kernel space functions and user space functions. By querying the preset function table, it can be determined whether the current target function is a sensitive function that needs to be monitored.

[0141] S4034: Determine whether the objective function is valid.

[0142] When the target function is in the preset function table, it indicates that the target function is valid and a corresponding target kernel program needs to be generated for it; when the target function is not in the preset function table, it indicates that the target function is invalid and no monitoring is required, so there is no need to generate a corresponding target kernel program.

[0143] S4035: Based on the injection type of the valid target function, load the general kernel program of the injection type.

[0144] Among them, the filtering function of the target function is implemented in the general kernel program corresponding to each injection type, which can effectively reduce the number of function call events for security detection and reduce system resource overhead.

[0145] S4036: Determine whether the universal kernel program is loaded successfully. If so, execute S4037; otherwise, return to S402 to process the next target function.

[0146] S4037: Generate a target kernel program based on the general kernel program and the function name of the target function.

[0147] For example, when the injection type of the target function ksys_dup3 is Kprobe, select the general BPF program corresponding to Kprobe and replace the function name in the general BPF program with ksys_dup3 to obtain the target eBPF program.

[0148] S404: The host node injects the target kernel program into the kernel space of the operating system.

[0149] After generating a target kernel program for the target function, the target kernel program is injected into the kernel space of the operating system for filtering processing before security detection.

[0150] In an embodiment of the present application, three general BPF programs that implement filtering functions are generated based on the classification of injection types. In this way, after parsing the target function that needs to be monitored, a general BPF program can be selected according to the injection type of the target function. Combined with the function name of the target function, the corresponding target eBPF program is automatically generated, thereby avoiding the need to write a specific BPF program for each target function, improving the maintainability of the system, and effectively reducing the amount of engineering work required to write the BPF program for the system function.

[0151] Based on the target kernel programs injected into the kernel space, a function processing process can be implemented to ensure the security of the container runtime.

[0152] See also Figure 7 , is an implementation flow chart of a container runtime security detection method provided by an embodiment of the present application. The specific implementation process of the method is as follows:

[0153] S701: Obtaining system functions called by operation behaviors generated when an application program in a container is running.

[0154] Taking the host node in a server cluster as an example, the host node can be deployed with one or more containers based on the business functions it implements. As a lightweight independent operating environment, the container contains all the resources required for the application to run, such as code, runtime environment, system tools and function libraries. Therefore, each application can run independently in a container.

[0155] While an application is running, attackers can infiltrate the container by modifying the program code and carrying out attacks. To ensure runtime security, the host node can obtain system functions called by application operations based on background logs. These system functions can be either kernel-space functions or user-space functions.

[0156] In an operating system, operating behaviors are implemented by calling system functions. Therefore, real-time monitoring of operating behaviors can be achieved by real-time monitoring of called system functions.

[0157] S702: Determine whether the system function is a preset target function. If so, execute S703; otherwise, end.

[0158] For container runtime security, not every called system function needs to be filtered. Only some specific target functions need to be filtered through the target kernel program in the kernel space.

[0159] For example, all system functions called under the system call entry sys_execve when a process is created need to be monitored and no filtering is required. System functions for file reading and writing (such as open and openat) are called frequently in the operating system and are relatively common kernel space functions. However, in actual applications, we only need to focus on operations on sensitive files, such as " / etc / passwd" and "notify_on_release". Sensitive files can be obtained through parameters in kernel space functions such as open and openat. Therefore, system functions for file reading and writing such as open and openat can be used as target functions, and kernel space functions such as open and openat called by operations involving sensitive files such as " / etc / passwd" and "notify_on_release" can be filtered out as target functions. Kernel space functions such as open and openat called by other operations not related to sensitive files can be eliminated.

[0160] In one example, the function names of these specific target functions can be counted and saved in advance. In this way, after obtaining the called system function, by matching its function name with the preset function name, it can be determined whether it is the target function that needs to be filtered.

[0161] S703: Filtering the target function's call event based on the target kernel program associated with the target function.

[0162] In the aforementioned embodiment, a target kernel program has been automatically generated for the target function, and a filter parameter set containing at least one attribute of the target function has also been stored in the BPF Maps. Therefore, when the target function is called, it triggers the startup of the target kernel program in kernel space. After the target kernel program starts, it can obtain the filter parameter set corresponding to the target function from the BPF Maps, and then filter the target function call event based on the obtained filter parameter set.

[0163] The attribute information of the target function included in the filter parameter set includes, but is not limited to, file descriptor information, returned address structure type, function return value, context information, etc. Optionally, the context information includes at least one of PID, namespace, capability, and input.

[0164] Since the target kernel function contains filtering logic code, it is possible to determine whether to retain the target function to implement the filtering function based on the filtering parameter set of the target function, thereby reducing the number of function call events for security detection and reducing system resource overhead.

[0165] In one example, the filtering process of the target function call event is as follows: Figure 8 As shown, it mainly includes the following steps:

[0166] S703_1: Determine whether the filter parameter set is empty. If so, execute S703_7; otherwise, execute S703_2.

[0167] In kernel space, the target kernel program determines whether to retain the target function for filtering based on the target function's filter parameter set. Therefore, filtering requires determining whether the filter parameter set is empty. If the filter parameter set is empty, it indicates that filtering is not required for the target function. Therefore, the target function can be retained directly; otherwise, the filtering logic is executed.

[0168] S703_2: Determine whether the filter parameter set contains at least one context information to be analyzed. If so, execute S703_3; otherwise, execute S703_8.

[0169] When the filter parameter set is not empty, it indicates that the call event of the target function needs to be filtered, and whether the filter parameter set contains at least one context information to be analyzed can be further determined.

[0170] The context information to be analyzed includes at least one of a PID to be analyzed, a namespace to be analyzed, a capability to be analyzed, and an input to be analyzed.

[0171] S703_3: Obtain reference context information corresponding to at least one piece of context information to be analyzed.

[0172] When the filter parameter set includes at least one context to be analyzed, the reference context information corresponding to each context to be analyzed can be obtained and matched to achieve filtering of the objective function. The reference context information includes at least one of a reference PID, a reference namespace, a reference capability, and a reference input.

[0173] S703_4: Determine whether at least one reference context information is successfully obtained. If so, execute S703_5; otherwise, execute S703_9.

[0174] When at least one reference context information corresponding to the target function is pre-stored in the target database, the acquisition can be successful; when at least one reference context information corresponding to the target function is not pre-stored in the target database, the acquisition fails and filtering cannot be performed.

[0175] S703_5: For each piece of context information to be analyzed, match it with the corresponding reference context information set.

[0176] For each piece of context information to be analyzed, when its corresponding reference context information is successfully acquired, the context information to be analyzed is matched with the corresponding reference context information.

[0177] Taking the context information to be analyzed as an example, which includes the PID to be analyzed, the namespace to be analyzed, the capability to be analyzed, and the input to be analyzed, the matching process is as follows: Figure 9 As shown, first obtain the reference PID from BPF Maps, and match the PID to be analyzed with the reference PID; if the match is successful, obtain the reference namespace from BPF Maps, and match the namespace to be analyzed with the reference namespace; if the match is successful, further obtain the reference capability from BPF Maps, and match the capability to be analyzed with the reference capability; if the match is successful, finally obtain the reference input from BPF Maps, and match the input to be analyzed with the reference input.

[0178] It should be noted that the embodiment of the present application does not impose any restrictions on the order of matching the at least one context information to be analyzed, and can be adjusted according to actual conditions. For example, the namespace to be analyzed can be matched with the reference namespace first, and then the PID to be analyzed can be matched with the reference PID.

[0179] S703_6: Determine whether all matches of at least one context information to be analyzed are successful. If so, execute S703_7; otherwise, execute S703_9.

[0180] When at least one of the context information to be analyzed is successfully matched, it indicates that a security check needs to be performed on the call event of the target function, so the target function is retained.

[0181] S703_7: Retain the target function and store the target function's call event in a common message queue for security detection.

[0182] When the target function is retained, the call event of the target function may be stored.

[0183] In one example, the stored procedure for the target function call event includes:

[0184] 1. Store the target function’s call event in a ring buffer in kernel space.

[0185] Among them, the call events in the ring buffer will be continuously read into the user space.

[0186] Optionally, before storing the call event in the ring buffer, pre-processing operations such as formatting may be performed on the call event.

[0187] 2. When the call event of the target function is read from the buffer to the user space, process information and cluster information are added to the call event of the target function.

[0188] The kernel and user spaces of the operating systems of each host node in the server cluster can interact. This allows target function call events filtered by the kernel space to be stored in a ring buffer and then read by the user space. In user space, process and cluster information are added to indicate the source of the function call event.

[0189] 3. Package the call events of the target function after the information is added to obtain the data packet to be detected.

[0190] 4. Store the data packets to be tested in the shared message queue for security testing.

[0191] By sending the data packets to be tested to the shared message queue of each host node, the call event of the target function can be security checked. In specific implementation, each data packet to be tested is read from the shared message queue and parsed to obtain a call event of the target function. The target function is then matched with sensitive functions in a pre-stored set of sensitive functions called by various sensitive operation behaviors to obtain a matching result. If the matching result is a match, the security check result of the target function call event is determined to be risky. If the matching result is a mismatch, the security check result of the target function call event is determined to be safe.

[0192] S703_8: Determine whether other attribute information in the filtering parameter set meets the preset filtering condition. If so, execute S703_7; otherwise, execute S703_9.

[0193] When the filter parameter set does not contain the context information to be analyzed, it may also contain other attribute information such as file descriptor information, function return value, returned address structure type, etc. Therefore, filtering can be performed based on other attribute information. When other attribute information meets the preset filtering conditions, the target function can be retained; otherwise, the target function can be discarded.

[0194] S703_9: End the target kernel program to stop security detection of target function call events.

[0195] When the reference context information corresponding to at least one context information to be analyzed in the filtering parameter set fails to be obtained, or when at least one context information to be analyzed has unsuccessfully matched context information to be analyzed, or when other attribute information in the filtering parameter set does not meet the preset filtering conditions, the target kernel program associated with the target function is terminated. In this way, the calling event of the target function will not be sent to the user space, thereby stopping the security detection of the calling event of the target function.

[0196] The following describes the function filtering process, using the target function ksys_dup3 as an example. The ksys_dup3 function is a frequently called kernel-space function within the operating system, used to duplicate a file descriptor within a process. However, in rebound shell scenarios, attackers often implement this behavior by redirecting socket input and output. This behavior triggers the call of the ksys_dup3 function, and this behavior has distinct characteristics: the file descriptor corresponding to the first parameter of the ksys_dup3 function is a network socket, and the return value is 0, 1, or 2. Therefore, the pre-set filtering conditions for the ksys_dup3 function are: the file descriptor of the first parameter of the ksys_dup3 function is a socket of type AF_INET or AF_INET6, and the return value is 0, 1, or 2. When a call event of the ksys_dup3 function occurs, the target kernel program corresponding to the ksys_dup3 function is triggered to start, and the filter parameter set of the ksys_dup3 function is loaded. When the filter parameter set does not contain the context information to be analyzed, the matching process is skipped and the file descriptor information, the function return value and the returned address structure type are directly determined to determine whether they meet the preset filter conditions. If the file descriptor of the first parameter of the ksys_dup3 function is a socket, and the returned address structure type is AF_INET or AF_INET6 type, and the return value is 0 or 1 or 2, it is determined that the preset filter conditions are met, so the ksys_dup3 function is retained and the call event of the ksys_dup3 function is stored in the ring buffer. Otherwise, the ksys_dup3 function is discarded.

[0197] In an embodiment of the present application, a target kernel program is injected into kernel space, and the target function call events are filtered in advance in kernel space using attributes such as the process and namespace to which the target function call events belong. This allows useless function call events to be promptly discarded at the kernel level upon capture, reducing the number of function call events sent to user space for processing. This reduces system resource overhead, improves the efficiency of container runtime security detection, and allows more system resources to be used for other applications, improving system execution performance. Furthermore, different filtering rules can be customized in the target kernel program for different scenarios, providing greater flexibility.

[0198] S704: When the filtering result is to retain the target function, a security check is performed on the calling event.

[0199] In one example, sensitive functions called by various sensitive operations can be pre-collected to generate and store a sensitive function set. This way, for packets to be detected corresponding to target function call events stored in a shared message queue, the rule detection engine performs security checks on target function call events based on the pre-stored sensitive function set.

[0200] In one example, before the back-end device performs security checks on the target function's call events, it can also perform pre-processing operations on the target function's call events read from the shared message queue, such as modifying the length of a field in the target function or performing some mapping on a field.

[0201] It should be noted that the preprocessing operation is not a necessary step and can be performed selectively according to needs.

[0202] S705: Determine whether the detection result contains risks. If so, execute S706; otherwise, end.

[0203] In one example, when the target function matches the sensitive function, it is determined that the call event of the target function has a risk; otherwise, the call event of the target function has no risk.

[0204] S706: Sending alarm information corresponding to the calling event.

[0205] When a risk is detected in a target function call, an alert is sent, allowing operators to promptly address the risk, preventing malicious container runtime operations and improving container runtime security. Optionally, the alert includes the permissions, files, program vulnerabilities, operator, and call time associated with the called target function.

[0206] It should be noted that the embodiment of the present application does not impose any restrictive requirements on the prompting method of the alarm information. For example, the call event can be stored in the alarm database for the front-end device to display the call event on the page, and the alarm information of the call event of the target function can also be sent to the target mailbox in real time to inform the operator of the risk.

[0207] It should be noted that the embodiments of the present application do not impose any restrictive requirements on the execution entity of container runtime security. For example, it can be executed directly by each host node, or it can be executed jointly by each host node and back-end device, such as the host node executing S701~S703 and the back-end device executing S704~S706.

[0208] The following uses the call of the ksys_dup3 function in the smart transportation scenario as an example to describe the interaction process between the server cluster, back-end devices, and front-end devices. Figure 10 As shown, first, each host node in the service period cluster generates a target eBPF program based on the injection type Kprobe of the ksys_dup3 function. The target eBPF program contains the filtering logic code of the ksys_dup3 function. Therefore, after being injected into the kernel space, when the ksys_dup3 function is called, the filtering parameter set of the ksys_dup3 function can be loaded based on the target eBPF program for filtering. When it is determined to retain the ksys_dup3 function, the call event of the ksys_dup3 function is sent to the user space for processing and then sent to the back-end device for security detection. After the backend device reads the ksys_dup3 function call event, it matches the ksys_dup3 function with a pre-stored set of sensitive functions for sensitive operations for security detection. It determines that the ksys_dup3 function call is a redirection of the driver's phone call image file captured by the camera. This suggests that a driver violating traffic laws may have tampered with the phone call image file to avoid traffic penalties. Therefore, an alert is required for the ksys_dup3 function call event. Therefore, the contents of the ksys_dup3 function are sent to the frontend device as an alert. Upon receiving the alert, the frontend device displays the ksys_dup3 function alert content on a webpage and sends an email notification, enabling operations and maintenance personnel to promptly address the file tampering risk and ensure container runtime security.

[0209] In the embodiment of the present application, for kernel space functions and user space functions called by sensitive operation behaviors, a target eBPF program is automatically generated based on the injection type and injected into the kernel space. Since functions of the same injection type share a common set of BPF programs, it is avoided to write injection programs for each function in a targeted manner, effectively reducing the development workload; and the target eBPF program can filter the call events of the target function based on a filter parameter set containing at least one attribute information of the target function, thereby filtering out the target functions called by some safe operation behaviors in the kernel space, avoiding sending a large number of function call events to the user space for processing, thereby reducing system resource overhead, improving security detection efficiency, and facilitating operation and maintenance personnel to promptly resolve container runtime risks. Compared with the current mainstream container runtime security falco, tracee and other technologies, the embodiment of the present application is more lightweight, ensuring high-performance real-time detection of container runtime security in cloud native scenarios.

[0210] Based on the same inventive concept, an embodiment of the present application also provides a container runtime security detection device, which can implement any of the above-mentioned container runtime security detection methods and achieve the same technical effect.

[0211] See also Figure 11 The detection device includes an acquisition module 1101, a filtering module 1102, a detection module 1103 and an alarm module 1104, wherein

[0212] An acquisition module 1101 is configured to acquire a system function called by an operation behavior generated when an application in the container is running; wherein the system function includes one of a kernel space function and a user space function;

[0213] The filtering module 1102 is configured to filter the call event of the target function based on the target kernel program associated with the target function if the system function is a preset target function; wherein the target kernel program is pre-generated based on the injection type of the target function;

[0214] The detection module 1103 is used to perform a security detection on the call event when the filtering result is to retain the target function;

[0215] The alarm module 1104 is configured to send an alarm message corresponding to the call event if a risk is detected in the call event.

[0216] Optionally, the detection device further includes a program generation module 1105, which is used to:

[0217] Obtaining and parsing a pre-generated filtering rule set to obtain at least one target function, an injection type of each target function, and at least one attribute information;

[0218] For each objective function, perform the following operations:

[0219] generating a filter parameter set based on at least one attribute information of the target function, and storing the filter parameter set in a target database; wherein the structure of the target database supports data sharing and communication between kernel programs and between kernel space and user space of the operating system;

[0220] After the validity of the target function is verified, the target kernel program is generated based on the injection type and function name of the target function;

[0221] Inject the target kernel program into the kernel space of the operating system.

[0222] Optionally, the program generation module 1105 is specifically configured to:

[0223] Get the kernel version of your own operating system;

[0224] When the kernel version exceeds the preset version, query the preset function table;

[0225] When it is found that the target function is in the preset function table, determining that the target function is valid;

[0226] Based on the injection type of the valid target function, load the general kernel program corresponding to the injection type;

[0227] When the universal kernel program is loaded successfully, the target kernel program is generated in combination with the function name of the target function.

[0228] Optionally, the filtering module 1102 is specifically configured to:

[0229] Based on the function name of the system function, determining whether the system function is a preset target function;

[0230] If so, load the target kernel program associated with the target function to obtain the filter parameter set corresponding to the target function;

[0231] Based on the filter parameter set, the target function call events are filtered.

[0232] Optionally, the filtering module 1102 is specifically configured to:

[0233] Determine whether the filter parameter set is empty;

[0234] If yes, the target function is retained and the target function call event is stored in the common message queue for security detection;

[0235] Otherwise, when the filter parameter set contains at least one context information to be analyzed, obtain the reference context information corresponding to at least one context information to be analyzed; when at least one context information to be analyzed is successfully matched with the corresponding reference context information set, retain the target function and store the call event of the target function in the common message queue for security detection.

[0236] Optionally, the filtering module 1102 is further configured to:

[0237] When the filter parameter set does not contain the context information to be analyzed, if other attribute information in the filter parameter set meets the preset filter conditions, the target function is retained and the call event of the target function is stored in the common message queue for security detection.

[0238] Optionally, the filtering module 1102 is further configured to:

[0239] When at least one reference context information fails to be obtained, the target eBPF program is terminated to stop security detection of the target function call event.

[0240] Optionally, the filtering module 1102 is specifically configured to:

[0241] Store the target function's call events in the kernel space's ring buffer;

[0242] When the target function's call event is read from the buffer to the user space, process information and cluster information are added to the target function's call event;

[0243] Pack the target function call event after the information is added to obtain the data packet to be detected;

[0244] The data packets to be detected are stored in a common message queue for security detection.

[0245] Optionally, the security detection module 1103 is specifically configured to:

[0246] Reading and parsing a data packet to be detected from the shared message queue one at a time to obtain a call event of a target function; wherein the data packet to be detected is generated based on the call event of the target function retained after filtering;

[0247] Match the target function with the sensitive functions in the pre-stored sensitive function set called by various sensitive operation behaviors;

[0248] Based on the matching results, the security detection results of the target function call event are obtained.

[0249] Optionally, the alarm module 1104 is specifically configured to perform at least one of the following:

[0250] Send the alarm information of the call event to the target mailbox to inform the risk;

[0251] The call event is stored in the alarm database so that the front-end device can display the call event on the page.

[0252] In the embodiment of the present application, the container runtime security detection device calls the system function for the operation behavior of the application program runtime in the container, wherein the system function can be a kernel space function or a user space function. When the called system function is a preset target function, the target function call event is filtered based on the target kernel program associated with the target function. In this way, the number of events of calling kernel space functions and user space functions sent to the user space for processing can be reduced, thereby reducing the system resources required for container runtime security detection and improving detection efficiency. When there is a risk in the call event of the filtered target function, an alarm message is sent to prevent malicious operation behavior at the container runtime, thereby improving the security of the container runtime.

[0253] On the other hand, the target kernel program of each target function is pre-generated based on the injection type of the target function. Since target functions of the same injection type share a set of common kernel programs, there is no need to write a program injected into the kernel specifically for each target function, which reduces the development workload and has strong maintainability, thereby further improving the detection efficiency.

[0254] For the convenience of description, the above parts are divided into modules (or units) according to their functions and described separately. Of course, when implementing this application, the functions of each module (or unit) can be implemented in the same or multiple software or hardware.

[0255] After introducing any container runtime security detection method and device according to the exemplary embodiments of the present application, an electronic device according to another exemplary embodiment of the present application is introduced next.

[0256] Those skilled in the art will appreciate that various aspects of the present application can be implemented as systems, methods, or program products. Therefore, various aspects of the present application can be specifically implemented in the following forms: a complete hardware implementation, a complete software implementation (including firmware, microcode, etc.), or an implementation that combines hardware and software aspects, which may be collectively referred to herein as a "circuit," "module," or "system."

[0257] Based on the same inventive concept as the above method embodiment, an electronic device is also provided in the embodiment of the present application. In one embodiment, the electronic device can be each host node in a server cluster. In this embodiment, the structure of the electronic device can be as follows: Figure 12 As shown, it includes a memory 1201 , a communication module 1203 and one or more processors 1202 .

[0258] Memory 1201 is used to store computer programs executed by processor 1202. Memory 1201 may primarily include a program storage area and a data storage area. The program storage area may store an operating system and programs required for running instant messaging functions, while the data storage area may store various instant messaging messages and operating instruction sets.

[0259] Memory 1201 may be a volatile memory, such as random-access memory (RAM); a non-volatile memory, such as read-only memory, flash memory, a hard disk drive (HDD), or a solid-state drive (SSD); or any other medium capable of carrying or storing a desired computer program in the form of instructions or data structures and accessible by a computer, but is not limited thereto. Memory 1201 may be a combination of the aforementioned memories.

[0260] The processor 1202 may include one or more central processing units (CPUs) or digital processing units, etc. The processor 1202 is configured to implement any of the above container runtime security detection methods when calling a computer program stored in the memory 1201 .

[0261] The communication module 1203 is used to communicate with back-end devices and other servers.

[0262] The specific connection medium between the memory 1201, the communication module 1203 and the processor 1202 is not limited in the embodiment of the present application. Figure 12 In the embodiment, the memory 1201 and the processor 1202 are connected via a bus 1204. The bus 1204 is connected to the processor 1202 via a bus 1204. Figure 12 The connections between the other components are shown in bold lines, which are only for illustration and are not intended to be limiting. The bus 1204 can be divided into an address bus, a data bus, a control bus, etc. For ease of description, Figure 12 The diagram shows a single thick line, but this does not indicate that there is only one bus or one type of bus.

[0263] The memory 1201 stores a computer storage medium, which stores computer executable instructions. The computer executable instructions are used to implement any container runtime security detection method in the embodiments of the present application. The processor 1202 is used to execute any of the above container runtime security detection methods, such as Figure 7 shown.

[0264] In some possible implementations, various aspects of any container runtime security detection method provided in this application may also be implemented in the form of a program product, which includes a computer program. When the program product is run on an electronic device, the computer program is used to enable the electronic device to perform the steps of any container runtime security detection method according to various exemplary embodiments of the present application described above in this specification. For example, the electronic device may perform the following steps: Figure 7 Follow the steps shown in .

[0265] The program product may employ any combination of one or more readable media. The readable medium may be a readable signal medium or a readable storage medium. The readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device, or component, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: an electrical connection with one or more wires, a portable disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof.

[0266] The program product of the embodiment of the present application may be a portable compact disc read-only memory (CD-ROM) and include a computer program, and can be run on an electronic device. However, the program product of the present application is not limited thereto. In this document, a readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with a command execution system, apparatus, or device.

[0267] A readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, which carries a readable computer program. Such a propagated data signal may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable signal medium may also be any readable medium other than a readable storage medium that can transmit, propagate, or transfer a program for use by or in conjunction with a command execution system, apparatus, or device.

[0268] The computer program embodied on the readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

[0269] The computer program for performing the operations of the present application can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java, C++, etc., and conventional procedural programming languages ​​such as "C" or similar programming languages. The computer program can be executed entirely on the user electronic device, partially on the user electronic device, as a separate software package, partially on the user electronic device and partially on a remote electronic device, or entirely on a remote electronic device or server. In cases involving remote electronic devices, the remote electronic device can be connected to the user electronic device through any type of network, including a local area network (LAN) or a wide area network (WAN), or can be connected to an external electronic device (for example, using an Internet service provider to connect through the Internet).

[0270] It should be noted that although several units or subunits of the device are mentioned in the detailed description above, this division is merely exemplary and not mandatory. In fact, depending on the embodiment of the application, the features and functions of two or more units described above can be embodied in a single unit. Conversely, the features and functions of a single unit described above can be further divided and embodied by multiple units.

[0271] Furthermore, although the operations of the method of the present application are described in a particular order in the accompanying drawings, this does not require or imply that the operations must be performed in this particular order, or that all illustrated operations must be performed to achieve the desired results. Additionally or alternatively, some steps may be omitted, multiple steps may be combined into one step, and / or one step may be decomposed into multiple steps.

[0272] Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems, or computer program products. Therefore, the present application may adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Furthermore, the present application may adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) that contain a computer-usable computer program.

[0273] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program commands. These computer program commands can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the commands executed by the processor of the computer or other programmable data processing device generate commands for implementing the processes in the flowchart and / or block diagram. Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0274] These computer program instructions may also be stored in a computer readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer readable memory produce an article of manufacture comprising a command device, which implements the process Figure 1 a process or multiple processes and / or boxes Figure 1 The function specified in one or more boxes.

[0275] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0276] Although the preferred embodiments of the present application have been described, those skilled in the art may make additional changes and modifications to these embodiments once they have learned the basic creative concept. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments and all changes and modifications that fall within the scope of the present application.

[0277] Obviously, those skilled in the art may make various changes and modifications to this application without departing from the spirit and scope of this application. Thus, if these modifications and variations of this application fall within the scope of the claims of this application and their equivalents, this application is intended to include these modifications and variations.

Claims

1. A container runtime security detection method, characterized in that: The method comprises: Obtaining a system function called by an operation behavior generated when the application in the container is running; wherein the system function includes one of a kernel space function and a user space function; If the system function is a preset target function, filtering the call event of the target function based on the target kernel program associated with the target function; wherein the target kernel program is pre-generated based on the injection type of the target function; When the filtering result is to retain the target function, performing a security check on the call event; If it is detected that the call event has a risk, an alarm message corresponding to the call event is sent.

2. The method according to claim 1, wherein The generation process of the target kernel program associated with each target function includes: Obtaining and parsing a pre-generated filtering rule set to obtain at least one target function, an injection type of each target function, and at least one attribute information; For each objective function, perform the following operations: generating the filter parameter set based on at least one attribute information of the target function, and storing the filter parameter set in a target database; wherein the structure of the target database supports data sharing and communication between kernel programs and between kernel space and user space of an operating system; After the validity of the target function is verified, a target kernel program is generated based on the injection type and function name of the target function; Injecting the target kernel program into the kernel space of the operating system.

3. The method according to claim 2, wherein: After the validity verification of the target function is passed, generating a target kernel program based on the injection type and function name of the target function includes: Get the kernel version of your own operating system; When the kernel version exceeds the preset version, querying the preset function table; When it is found that the target function is located in the preset function table, determining that the target function is valid; Based on the injection type of the valid target function, loading the general kernel program corresponding to the injection type; When the universal kernel program is loaded successfully, a target kernel program is generated in combination with the function name of the target function.

4. The method according to claim 1, wherein If the system function is a preset target function, filtering the call event of the target function based on the target kernel program associated with the target function includes: Based on the function name of the system function, determining whether the system function is a preset target function; If so, loading the target kernel program associated with the target function to obtain a filter parameter set corresponding to the target function; Based on the filter parameter set, the call event of the target function is filtered.

5. The method according to claim 4, wherein The filtering process on the target function call event based on the filter parameter set includes: Determining whether the filter parameter set is empty; If yes, retain the target function and store the call event of the target function in a common message queue for security detection; If not, when the filter parameter set contains at least one context information to be analyzed, obtain the reference context information corresponding to each of the at least one context information to be analyzed; when the at least one context information to be analyzed and the corresponding reference context information set are all successfully matched, retain the target function and store the call event of the target function in the common message queue for security detection.

6. The method according to claim 5, wherein When the filter parameter set does not include the context information to be analyzed, the method further includes: If other attribute information in the filtering parameter set meets the preset filtering conditions, the target function is retained, and the call event of the target function is stored in the common message queue for security detection.

7. The method according to claim 5, wherein When at least one reference context information fails to be acquired, the method further includes: The target kernel program is terminated to stop security detection of the call event of the target function.

8. The method according to claim 5 or 6, wherein: The step of storing the target function call event in a common message queue for security detection includes: Storing the target function call event in a ring buffer in the kernel space; When the call event of the target function is read from the buffer to the user space, adding process information and cluster information to the call event of the target function; Packaging the target function call event after the information is added to obtain a data packet to be detected; The data packet to be detected is stored in the common message queue for security detection.

9. The method according to any one of claims 1 to 7, wherein When the filtering result is to retain the target function, performing a security check on the call event includes: Reading and parsing a data packet to be detected from the shared message queue one at a time to obtain a call event of a target function; wherein the data packet to be detected is generated based on the call event of the target function retained after filtering; Matching the target function with sensitive functions in a pre-stored sensitive function set called by various sensitive operation behaviors respectively; Based on the matching result, a security detection result of the call event of the target function is obtained.

10. The method according to any one of claims 1 to 7, wherein The method of sending the alarm information corresponding to the call event includes at least one of the following: Send the warning information of the call event to the target mailbox to inform the risk; The call event is stored in an alarm database so that the front-end device can display the call event on a page.

11. A container runtime security detection device, characterized in that: include: An acquisition module, configured to acquire a system function called by an operation behavior generated when an application in the container is running; wherein the system function includes one of a kernel space function and a user space function; a filtering module configured to, if the system function is a preset target function, filter the call event of the target function based on a target kernel program associated with the target function; wherein the target kernel program is pre-generated based on the injection type of the target function; A security detection module, configured to perform a security detection on the call event when the filtering result is to retain the target function; The alarm module is used to send alarm information corresponding to the call event if it is detected that the call event has a risk.

12. An electronic device, characterized in that: The method comprises a processor and a memory, wherein the memory stores a computer program, and when the computer program is executed by the processor, the processor is enabled to perform the steps of any one of the methods of claims 1 to 10.

13. A computer-readable storage medium, characterized in that The method comprises a computer program. When the computer program is run on an electronic device, the computer program is used to enable the electronic device to execute the steps of any one of the methods according to claims 1 to 10.

14. A computer program product, characterized in that The method comprises a computer program stored in a computer-readable storage medium; when a processor of an electronic device reads the computer program from the computer-readable storage medium, the processor executes the computer program, so that the electronic device performs the steps of any one of the methods described in claims 1 to 10.

Images