Method and apparatus for permission management of container runtime

Abstract

The one or more embodiments of the application provide a method and device for permission management of a container runtime, the method comprising: determining, by the container runtime, whether to trigger execution of a plug-in code during execution of a target process; wherein the plug-in code is a code segment inserted for a code corresponding to an interactive process, and the interactive process is a process with which the container runtime interacts with a container instance; if the execution of the plug-in code is triggered, the container runtime sends a notification signal to a plug-in for permission management of a process; the plug-in performs process tracking on the target process in response to the received notification signal, and performs permission management on the target process based on a preset security policy; after completing the permission management on the target process, the container runtime continues to execute the target process after the permission management.

Description

Technical Field

[0001] One or more embodiments of this application relate to the field of container technology, and in particular to a method and apparatus for managing permissions during container runtime. Background Technology

[0002] Container technology is a lightweight virtualization technology that allows applications and their dependencies to be packaged together to form a portable, self-contained runtime environment. By sharing the host machine's operating system kernel resources, containers offer advantages such as fast startup, lightweight design, and portability.

[0003] A container runtime is system software responsible for managing and executing the lifecycle of containers. It is a core component of the container technology stack, responsible for transforming packaged container images into running container instances, managing operations such as container creation, startup, stopping, and destruction, and typically providing underlying support functions such as networking, storage, and resource limiting.

[0004] A container instance is a specific container service unit running on a cloud service platform. It represents a running container, including the container image, configuration parameters, and resources allocated to it (such as CPU, memory, storage, and network).

[0005] Container runtimes provide various functions for interacting with container instances. While these functions enhance the flexibility and operability of container applications, most container escape security incidents are directly related to these functions, creating weak points in security protection. Specifically, attackers within a container can exploit the communication and data exchange mechanisms between the container and the host machine to bypass established security boundaries. Through well-designed attack strategies, attackers can not only illegally intrude into the host machine's file system and obtain sensitive information, but also execute malicious code at the host level to carry out deeper attack operations. The success of such attacks is largely due to the high privilege level, usually root privileges, that container runtime uses when interacting with container instances. Therefore, these attacks are highly destructive, potentially leading to data leaks, service interruptions, or even complete system paralysis. Given this, how to maintain the convenience and efficiency of container technology while effectively managing permissions for the container runtime and strengthening its security isolation capabilities has become a pressing issue. Summary of the Invention

[0006] One or more embodiments of this application provide the following technical solutions:

[0007] This application provides a method for managing permissions during container runtime, the method comprising:

[0008] During the execution of the target process, the container runtime determines whether to trigger the execution of instrumentation code; wherein, the instrumentation code is a code snippet inserted for the code corresponding to the interactive process, and the interactive process is the process in which the container runtime interacts with the container instance;

[0009] If the execution of the instrumentation code is triggered, the container runtime sends a notification signal to the plugin used for process permission management;

[0010] In response to the received notification signal, the plugin performs process tracking on the target process and manages permissions for the target process based on a preset security policy.

[0011] After completing the permission management of the target process, the container runtime continues to execute the target process after the permission management is completed.

[0012] This application also provides a permission management device for a container runtime, the device including a container runtime and a plugin for managing permissions for processes;

[0013] in:

[0014] During the execution of the target process, the container runtime determines whether to trigger the execution of instrumentation code; wherein, the instrumentation code is a code snippet inserted for the code corresponding to the interaction process, and the interaction process is the process in which the container runtime interacts with the container instance;

[0015] If the instrumentation code is executed, the container runtime sends a notification signal to the plugin;

[0016] In response to the received notification signal, the plugin performs process tracking on the target process and manages permissions for the target process based on a preset security policy.

[0017] After completing the permission management of the target process, the container runtime continues to execute the target process after the permission management is completed.

[0018] This application also provides an electronic device, including:

[0019] processor;

[0020] Memory used to store processor-executable instructions;

[0021] The processor executes the executable instructions to implement the steps of the method as described in any of the preceding descriptions.

[0022] This application also provides a computer-readable storage medium having computer instructions stored thereon, which, when executed by a processor, implement the steps of the method as described in any of the preceding claims.

[0023] In the above technical solution, during the execution of the target process, the container runtime can determine whether to trigger the execution of instrumentation code corresponding to the interactive process. The interactive process is the process in which the container runtime interacts with the container instance. If so, the container runtime can send a notification signal to the plugin used for process permission management. The plugin can respond to the received notification signal, perform process tracking on the target process, and perform permission management on the target process based on a preset security policy. After completing the permission management of the target process, the container runtime can continue to execute the target process after permission management.

[0024] By employing the above method, through the collaboration between the container runtime and the plugin used for process permission management, permission management can be performed on the processes that interact with the container instance. The permissions of these processes can be adjusted in real time and dynamically to prevent these processes from being interfered with or completely controlled, thus avoiding information leakage and abuse of privileges. Attached Figure Description

[0025] The accompanying drawings used in the description of the exemplary embodiments will now be explained, wherein:

[0026] Figure 1 This is a flowchart illustrating a permission management method for container runtime according to an exemplary embodiment of this application.

[0027] Figure 2 This is a schematic diagram illustrating a permission management process during container runtime, as shown in an exemplary embodiment of this application.

[0028] Figure 3 This is a schematic diagram of the structure of a device shown in an exemplary embodiment of this application.

[0029] Figure 4 This is a block diagram illustrating a permission management device for container runtime according to an exemplary embodiment of this application. Detailed Implementation

[0030] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with one or more embodiments of this application. Rather, they are merely examples consistent with some aspects of one or more embodiments of this application.

[0031] It should be noted that the steps of the corresponding methods are not necessarily performed in the order shown and described in this application in other embodiments. In some other embodiments, the methods may include more or fewer steps than those described in this application. Furthermore, a single step described in this application may be broken down into multiple steps in other embodiments; and multiple steps described in this application may be combined into a single step in other embodiments.

[0032] In container technology, a container runtime is the system software responsible for managing and executing the lifecycle of containers. It is a core component of the container technology stack, responsible for transforming packaged container images into running container instances, managing operations such as container creation, startup, stopping, and destruction, and typically providing underlying support functions such as networking, storage, and resource limiting. A container instance is a specific container service unit running on a cloud service platform. It represents a running container, including the container image, configuration parameters, and resources allocated to it (such as CPU, memory, storage, and network).

[0033] The container runtime handles background tasks such as creating the execution environment, starting the container, managing the container lifecycle, and stopping or destroying the container. The container instance, on the other hand, is the foreground presentation, corresponding to a specific running container application; it is an execution instance of the container image under specific configurations and resource limitations.

[0034] Specifically, a container runtime is low-level software that provides mechanisms for creating, running, managing, and destroying containers. It works closely with the operating system kernel, utilizing technologies such as namespaces and control groups (cgroups) to achieve resource isolation, limiting, and measurement, ensuring that containers can run in a secure and resource-constrained environment. Common container runtimes include runc, containerd, and CRI-O.

[0035] In other words, the entire lifecycle management of a container instance, from creation, startup, and monitoring of its running status to stopping and destroying it, is performed by the container runtime. It provides a series of APIs and command-line tools that enable easy interaction with container instances and control over their running status. The container runtime utilizes technologies such as namespaces and control groups to create an independent runtime environment for each container instance. This not only means that each container instance has its own file system view, network configuration, process ID space, etc., but also allows for precise control over resource usage (such as CPU share and memory limits), preventing one container instance from excessively consuming resources and affecting other container instances or the stability of the host machine. Furthermore, the container runtime is also responsible for managing container images, including downloading images from remote repositories to the local machine, decompressing image layers, and creating executable root file systems, which are fundamental to starting container instances.

[0036] A container instance is a concrete entity created and managed by the container runtime. It is based on a container image and contains the application and its dependencies. Each container instance represents an independent, portable runtime environment with its own file system, network configuration, process space, etc. Users can customize the behavior of container instances by defining configurations such as container images, environment variables, port mappings, and volume mounts.

[0037] The process of interaction between the container runtime and the container instance can include: providing parameters such as image name, environment variables, and resource limits through the container runtime's API, and requesting the creation of a container instance; after receiving the request, the container runtime obtains the container image and configures the container's execution environment according to the request parameters; then, the container runtime creates namespaces and control groups on the operating system to isolate and limit container resources, and starts the container instance; during the operation of the container instance, the container runtime continuously monitors the status of the container instance and reports status changes, such as performance metrics and health check results, to the management system through the API; when the container instance is no longer needed, the container runtime responds to stop or delete commands, cleans up resources, and ends the lifecycle of the container instance.

[0038] As a core component for managing and executing containers, the container runtime provides various functions for interacting with container instances to ensure effective management and control of their runtime status. These functions include: allowing users to start new container instances or stop running ones as needed; allowing users to execute commands within running container instances, which is very useful for debugging, data querying, or script execution; providing the ability to view container instance output logs, crucial for monitoring application runtime status and troubleshooting; monitoring container instance resources such as CPU, memory, and disk I / O, and setting resource usage limits to ensure container instances do not excessively consume host resources; and supporting container network configuration, including assigning IP addresses, setting port mappings, and creating network isolation. Container runtime allows for controlled communication between containers or between containers and the outside world; it can mount storage volumes to container instances for persistent or shared data, as well as for sharing data volumes between container instances; it can set up health check mechanisms to periodically check whether container instances are running normally and decide whether to restart them based on the check results; it needs to be able to pull, store, and clean up container images to ensure that container instances have the correct image base when they start; it allows copying files between container instances and the host machine for easy data exchange or backup; it provides an interactive shell to access container instances, as if directly logging into the container, facilitating manual operation and troubleshooting; and so on.

[0039] A process is the basic unit of resource allocation and scheduling in an operating system. A process can be viewed as an instance of a program that is currently executing. It includes the program code itself, its current activity state (such as which line of code it is executing), and the resources allocated to it. When a program needs to execute, the operating system creates a process, allocates memory, CPU time slices, and other necessary resources to the program, and maintains its execution state. Each process has its own independent memory space, open files, and other resources required for execution.

[0040] Similarly, in container runtimes, processes are the basic unit of resource management and execution. Container runtimes interact with container instances through operating system-level processes. Some of the main processes that interact with container instances include: the process that starts the container instance; the container runtime daemon, responsible for creating, running, and stopping container instances; processes that allow users to execute new commands within a running container without interrupting existing processes; processes that allow users to directly connect to the container's standard input, output, and error streams for real-time interaction; processes that copy files between the container instance and the host machine; processes that view the list of processes within the container instance; processes that display container instance resource usage statistics; and so on.

[0041] Since container runtimes are responsible for creating, running, and managing container instances, ensuring their efficient and secure access to various resources of the underlying system, and given that container instances need to interact closely with the host operating system to utilize operating system kernel resources (such as CPU, memory, I / O, etc.), container runtimes are typically granted root privileges to facilitate the configuration of necessary system services and resources without hindrance.

[0042] Correspondingly, processes that interact with container instances during the container runtime are granted equivalent root privileges to perform management tasks or transfer data. However, this design choice also introduces significant security vulnerabilities such as container escape. Container escape refers to attackers exploiting vulnerabilities or configuration flaws in container technology to allow processes or code originally confined within the container to breach the container's isolation boundaries and gain access to the host machine or other containers. Specifically, malicious code may lurk within container instances. This malicious code can interfere with or completely control the processes that interact with the container runtime through various attack strategies such as code injection and privilege escalation. Once successful, attackers can use the high privileges of these processes to leak or tamper with sensitive information on the host machine, or even execute malicious code within the host machine's own execution environment or runtime state, seriously threatening the security and stability of the entire system.

[0043] Although container runtimes incorporate numerous security checks during development to prevent such malicious activities, the complexity and dynamic nature of the interaction between the container runtime and container instances mean these checks cannot cover all process behaviors during the interaction, leading to the aforementioned security issues. Furthermore, container runtimes may utilize numerous third-party libraries during development to extend functionality or improve compatibility, and these libraries typically lack relevant security checks, further contributing to the aforementioned security problems.

[0044] This application provides a technical solution for implementing permission management for container runtimes. In this solution, during the execution of a target process, the container runtime can determine whether to trigger the execution of instrumentation code corresponding to the interactive process, which is the process through which the container runtime interacts with the container instance. If so, the container runtime can send a notification signal to a plugin for managing process permissions. In response to the received notification signal, the plugin can perform process tracking on the target process and manage permissions for the target process based on a preset security policy. After completing the permission management for the target process, the container runtime can continue to execute the target process with the permissions managed.

[0045] By employing the above method, through the collaboration between the container runtime and the plugin used for process permission management, permission management can be performed on the processes that interact with the container instance. The permissions of these processes can be adjusted in real time and dynamically to prevent these processes from being interfered with or completely controlled, thus avoiding information leakage and abuse of privileges.

[0046] The technical solution provided in this application can be applied to servers. The server can be a server containing a single independent physical host, or a server cluster consisting of multiple independent physical hosts; alternatively, the server can be a virtual server, cloud server, etc., hosted by a host cluster.

[0047] It should be noted that the above server is equipped with a container runtime and a plugin for managing process permissions.

[0048] In this application, in order to implement permission management for container runtime, enhance the security isolation capability of container runtime, and prevent container escape security events, it is first necessary to capture the processes that are currently running container runtime interacting with container instances, and then perform permission management on these processes.

[0049] The following describes the process of capturing the interaction between the container runtime and the container instance during execution.

[0050] In some embodiments, the processes by which the container runtime interacts with the container instance may include: processes executed by the container runtime for accessing the internal file system of the container instance; and / or processes executed by the container runtime for accessing network resources of the container instance. Accordingly, key behaviors that occur during the execution of the processes by which the container runtime interacts with the container instance may include: opening files inside the container instance; and / or connecting to network resources of the container instance.

[0051] In some embodiments, instrumentation can be used to capture the processes by which the running container runtime interacts with the container instance.

[0052] Instrumentation is a software engineering technique involving inserting additional code snippets ("stubs") into program code to collect runtime information, monitor program behavior, or modify program execution flow. Instrumentation is divided into static instrumentation and dynamic instrumentation. Static instrumentation occurs during the program compilation phase; it directly modifies the source code or bytecode, inserting the stub code into the target program at compile time. Once compilation is complete, the stub code becomes permanently part of the program. Dynamic instrumentation occurs at runtime, without modifying the original program code. It inserts stub code after the program is loaded into memory by modifying the program's memory image, using a special runtime environment or virtual machine technology.

[0053] If instrumentation code is executed during the process of interacting with the container instance during the container runtime (also known as triggering the execution of instrumentation code), the execution flow can be changed based on the characteristics of instrumentation, and permission management can be performed on the process of interacting with the container instance during the container runtime. This achieves the capture of the process of interacting with the container instance during the execution of the container runtime.

[0054] In practical applications, security vulnerabilities often arise from critical behaviors exhibited during the execution of processes interacting with the container runtime and container instance. Therefore, by detecting whether these processes exhibit critical behaviors during execution, specific running processes interacting with the container runtime and container instance can be identified. In other words, instrumentation can be used to detect whether critical behaviors occur during the execution of these processes, thereby identifying those processes exhibiting such critical behaviors.

[0055] In some embodiments, for a process that interacts with a container instance during container runtime, the code corresponding to the interaction process may include: a source code segment in the source code of the container runtime that corresponds to the interaction process; and / or a source code segment in the source code of a third-party library used by the container runtime that corresponds to the interaction process.

[0056] In some embodiments, static instrumentation results in relatively low runtime overhead because the stub code is determined at compile time. Therefore, taking static instrumentation as an example, this paper describes whether critical behaviors occur during the execution of a process that detects the interaction between the container runtime and the container instance.

[0057] Specifically, static analysis can be performed on the source code snippets in the container runtime's source code and / or the source code of third-party libraries used by the container runtime, focusing on the behaviors indicated by the processes interacting with the container instance. By analyzing the parameter lists of functions in these source code snippets, key behaviors of the processes interacting with the container instance during execution can be identified. For example, the parameter `container_path / files` in the function `open("container_path / files")` indicates files inside the container instance, and this function indicates opening files inside the container instance, which is a key behavior. Similarly, the parameter `container_network_address` in the function `connect(container_network_address)` indicates network resources of the container instance, and this function indicates connecting to network resources of the container instance, which is also a key behavior. In this case, static instrumentation code can be inserted at the location corresponding to the key behavior. This ensures that if the instrumentation code is triggered during the execution of the processes interacting with the container instance, it can be determined that the key behavior has occurred during the execution of these processes.

[0058] In some embodiments, during the instrumentation process, various call graph generation methods can be used, including Rapid Type Analysis (RTA) and pointer analysis, to generate a directed graph that reflects the call relationships between functions in the source code. This directed graph can then be used to help identify key behaviors of processes that interact with the container instance during execution, thus completing the instrumentation.

[0059] The following describes permission management for processes that interact with the container instance during the execution of the container runtime.

[0060] Please refer to Figure 1 , Figure 1 This is a flowchart illustrating a permission management method for container runtime according to an exemplary embodiment of this application.

[0061] The above-mentioned container runtime permission management method may include the following steps:

[0062] Step 102: During the execution of the target process, the container runtime determines whether to trigger the execution of instrumentation code; wherein, the instrumentation code is a code fragment inserted for the code corresponding to the interactive process, and the interactive process is the process in which the container runtime interacts with the container instance.

[0063] In this embodiment, as described above, instrumentation can be used to determine when critical behaviors occur during the execution of processes that interact with the container instance during the container runtime. That is, during the execution of a process (which may be called the target process) by the container runtime, it can be determined whether the execution of instrumented code is triggered; wherein, the instrumented code is a code fragment inserted for the code corresponding to the interactive process, which can refer to the process that interacts with the container instance by the container runtime.

[0064] Step 104: If the execution of the instrumentation code is triggered, the container runtime sends a notification signal to the plugin used for process permission management.

[0065] In this embodiment, if the execution of the aforementioned instrumentation code is triggered, it can be determined that a critical action has occurred during the execution of the process interacting with the container instance during the container runtime. In this case, the container runtime can send a notification signal to the plugin used for process permission management.

[0066] It should be noted that a plugin is a program written according to a certain API specification, and therefore has its corresponding process. The aforementioned notification signals can refer to mechanisms used to notify a process that certain events or conditions have occurred. These mechanisms can be signals themselves or other forms of inter-process communication (IPC) mechanisms.

[0067] Step 106: In response to the received notification signal, the plugin performs process tracking on the target process and performs permission management on the target process based on a preset security policy.

[0068] In this embodiment, the plugin can respond to the received notification signal and perform process tracking on the target process. After process tracking begins, the plugin can manage permissions for the target process based on a preset security policy.

[0069] In some embodiments, the notification signal may include the execution context of the target process. When performing process tracing on the target process, the plugin may attach itself to the target process (specifically, attach the plugin's process to the target process's context) based on the system calls used for process tracing and the execution context of the target process, in order to perform process tracing on the target process.

[0070] System calls are a mechanism provided by the operating system for applications to interact with the operating system kernel. They allow user-space programs to request privileged operations or access protected resources from the kernel. Simply put, applications use system calls to perform tasks that only the kernel can execute, such as file I / O operations, process control, memory management, and network communication.

[0071] System calls are not ordinary callable functions. Although they may be used in a manner similar to function calls, system calls actually involve a transition from user mode to kernel mode. This means that when a system call occurs, the processor changes its operating mode, granting the executable code higher privileges so that it can directly access hardware resources and execute privileged instructions.

[0072] In other words, the above plugins can work in user mode and have good adaptability to the extension of kernel-mode data structures and functions.

[0073] In some embodiments, the system call used for process tracing may be the ptrace (short for ProcessTrace) system call.

[0074] The primary function of the ptrace system call is to allow one process (often called the debugging process) to monitor and control the execution of another process (the process being debugged). The ptrace system call allows the debugging process to attach itself to the process being debugged. Once the debugging process successfully attaches to the process being debugged using the ptrace system call, it can monitor and control the execution of the process being debugged.

[0075] In some embodiments, when the above-mentioned plugin performs permission management on the target process based on a preset security policy, it may specifically perform permission management on the target process based on system calls used for process control and the security policy.

[0076] In some embodiments, the system call used for process control described above may be the prctl (ProcessControl) system call.

[0077] The prctl system call is used to control the behavior of a process. This call allows user-mode programs to modify or query certain attributes and behaviors of their process, thereby enhancing the flexibility and security of process management.

[0078] As for the aforementioned plugin, since it uses the ptrace system call and is attached to the target process, it can use the prctl system call to modify or query certain attributes and behaviors of the target process.

[0079] In some embodiments, the security policy described above includes one or more of the following policies: performing process cleanup on the target process when the parent process of the target process terminates; prohibiting the target process from generating a kernel dump file when it terminates abnormally; prohibiting the target process and its child processes from obtaining additional privileges; and enabling a secure computing mode for the target process.

[0080] Specifically, the PR_SET_PDEATHSIG option in the prctl system call allows a process to set a signal that will be sent to it when its parent process terminates. This is very useful for ensuring that child processes do not become zombie processes after their parent process terminates unexpectedly. For example, if SIGTERM is set as the death signal, when the parent process terminates, the child process will receive the SIGTERM signal and can then perform cleanup work or terminate itself accordingly.

[0081] The PR_SET_DUMPABLE option in the prctl system call controls whether a core dump is generated when a process terminates abnormally. A core dump is a snapshot of a process's memory image, which is very useful when a program terminates abnormally because it can help developers diagnose the cause of the crash. If set to dumpable, a core dump can be generated even if the process has elevated privileges (such as those set via set-user-ID or set-group-ID).

[0082] When the PR_SET_NO_NEW_PRIVS flag in the prctl system call is set to 1, the process and all its child processes will be unable to gain additional privileges through subsequent operations (such as the execve system call, setting or changing its capabilities set via set-user-ID or set-group-ID, etc.). This is a security enhancement that prevents malicious code from escalating privileges by executing other programs within the process. This is particularly important for sandboxed environments or services that require strict access control.

[0083] The PR_SET_SECCOMP option in the prctl system call allows a process to enable or configure Secure Computing Mode (seccomp), a security mechanism provided by the Linux kernel that restricts the system calls a process can execute. This is extremely useful for improving service security, especially for applications that do not require the full set of system calls. By restricting system calls, the attack surface can be reduced, protecting against potential security threats.

[0084] In practical applications, security policies can be customized according to specific operating environments and business needs to adapt to changing application scenarios, combat increasingly complex attack patterns, and ensure the continuous security and stability of the system.

[0085] Step 108: After completing the permission management of the target process, the container runtime continues to execute the target process after permission management.

[0086] In this embodiment, after the permission management of the target process is completed, the container runtime can continue to execute the target process after the permission management is completed.

[0087] In some embodiments, as described above, the plugin can attach itself to the target process based on system calls used for process tracing and the execution context of the target process (specifically, attaching the plugin's process to the context of another process) to perform process tracing on the target process. Accordingly, after completing permission management for the target process, the plugin can detach from the target process (specifically, detach from the target process's context and return to its own context), and the container runtime can continue to execute the target process after permission management.

[0088] In some embodiments, the instrumentation code described above can be used to implement breakpoints. If the execution of this instrumentation code is triggered, the container runtime can pause the execution of the target process and send a notification signal to the plugin. Correspondingly, after completing permission management for the target process, the container runtime can resume execution of the target process after permission management. This avoids security issues arising during permission management of the target process.

[0089] Please refer to Figure 2 , Figure 2 This is a schematic diagram illustrating a permission management process during container runtime, as shown in an exemplary embodiment of this application.

[0090] like Figure 2As shown, instrumentation can first be performed on the code corresponding to the interaction process, which is the process through which the container runtime interacts with the container instance. Subsequently, the container runtime can interact with the container instance through this interaction process, and the instrumented code is triggered during the execution of this interaction process. When the instrumented code is triggered, the interaction process in the container runtime can send a notification signal to the plugin used for process permission management. The plugin can respond to the received notification signal, perform process tracking on the interaction process, and manage permissions for the interaction process based on a preset security policy. After completing permission management for the interaction process, the container runtime can continue to execute the permission-managed interaction process, meaning the container runtime can continue to interact with the container instance through the permission-managed interaction process.

[0091] In the above technical solution, during the execution of the target process, the container runtime can determine whether to trigger the execution of instrumentation code corresponding to the interactive process. The interactive process is the process in which the container runtime interacts with the container instance. If so, the container runtime can send a notification signal to the plugin used for process permission management. The plugin can respond to the received notification signal, perform process tracking on the target process, and perform permission management on the target process based on a preset security policy. After completing the permission management of the target process, the container runtime can continue to execute the target process after permission management.

[0092] By employing the above method, through the collaboration between the container runtime and the plugin used for process permission management, permission management can be performed on the processes that interact with the container instance. The permissions of these processes can be adjusted in real time and dynamically to prevent these processes from being interfered with or completely controlled, thus avoiding information leakage and abuse of privileges.

[0093] Corresponding to the embodiments of the methods described above, this application also provides embodiments of the apparatus.

[0094] Please refer to Figure 3 , Figure 3 This is a schematic diagram illustrating the structure of a device according to an exemplary embodiment of this application. At the hardware level, the device includes a processor 302, an internal bus 304, a network interface 306, memory 308, and non-volatile memory 310, and may also include other necessary hardware. One or more embodiments of this application can be implemented in software, for example, the processor 302 reads the corresponding computer program from the non-volatile memory 310 into memory 308 and then runs it. Of course, besides software implementation, one or more embodiments of this application do not exclude other implementation methods, such as logic devices or a combination of hardware and software, etc. That is to say, the execution entity of the following processing flow is not limited to individual logic modules, but can also be hardware or logic devices.

[0095] Please refer to Figure 4 , Figure 4 This is a block diagram illustrating a permission management device for container runtime according to an exemplary embodiment of this application.

[0096] The aforementioned container runtime permission management device can be applied to Figure 3 The device shown is used to implement the technical solution of this application. The device includes a container runtime 402 and a plugin 404 for managing process permissions;

[0097] in:

[0098] During the execution of the target process, the container runtime determines whether to trigger the execution of instrumentation code; wherein, the instrumentation code is a code snippet inserted for the code corresponding to the interaction process, and the interaction process is the process in which the container runtime interacts with the container instance;

[0099] If the instrumentation code is executed, the container runtime sends a notification signal to the plugin;

[0100] In response to the received notification signal, the plugin performs process tracking on the target process and manages permissions for the target process based on a preset security policy.

[0101] After completing the permission management of the target process, the container runtime continues to execute the target process after the permission management is completed.

[0102] In some embodiments, the notification signal includes the execution context of the target process;

[0103] The process tracing of the target process includes:

[0104] Based on the system calls used for process tracing and the execution context of the target process, the plugin is attached to the target process to perform process tracing on the target process;

[0105] After completing the permission management of the target process, the container runtime continues to execute the target process after the permission management is completed, including:

[0106] After completing the permission management of the target process, the plugin detaches from the target process, and the container continues to execute the target process after permission management.

[0107] In some embodiments, the system call used for process tracing is the ptrace system call.

[0108] In some embodiments, the permission management of the target process based on a preset security policy includes:

[0109] Based on system calls used for process control and preset security policies, permission management is performed on the target process.

[0110] In some embodiments, the system call for process control is the prctl system call.

[0111] In some embodiments, the security policy includes one or more of the policies shown below:

[0112] When the parent process of the target process terminates, the target process is cleaned up.

[0113] Prevent the target process from generating a core dump file upon abnormal termination;

[0114] The target process and its child processes are prohibited from obtaining additional privileges;

[0115] Enable secure computing mode for the target process.

[0116] In some embodiments, the instrumentation code is used to implement instrumentation breakpoints;

[0117] If the instrumentation code is triggered, the container runtime sends a notification signal to the plugin used for process permission management, including:

[0118] If the instrumentation code is executed, the container runtime suspends the execution of the target process and sends a notification signal to the plugin used for process permission management.

[0119] In some embodiments, the processes by which the container runtime interacts with the container instance include: processes executed by the container runtime for accessing the internal file system of the container instance, and / or processes executed by the container runtime for accessing the network resources of the container instance.

[0120] In some embodiments, the code corresponding to the process that interacts with the container instance during the container runtime includes: source code segments in the source code of the container runtime and / or the source code of third-party libraries used in the container runtime that correspond to the process that interacts with the container instance during the container runtime; the instrumentation code is static instrumentation code.

[0121] For the device embodiments, they basically correspond to the method embodiments; therefore, relevant details can be found in the descriptions of the method embodiments. The device embodiments described above are merely illustrative. The modules described as separate components may or may not be physically separate, and the components shown as modules may or may not be physical modules; that is, they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of the technical solution of this application according to actual needs.

[0122] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or physical entities, or by products with certain functions. A typical implementation device is a computer, which can take the form of a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email sending and receiving device, game console, tablet computer, wearable device, or any combination of these devices.

[0123] In a typical configuration, a computer includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0124] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0125] Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can store information using any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, disk storage, quantum memory, graphene-based storage media or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0126] It should be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0127] The foregoing has described specific embodiments of this application. Other embodiments are within the scope of this application. In some cases, the actions or steps described in this application may be performed in a different order than those shown in the embodiments and still achieve the desired results. Furthermore, the processes depicted in the accompanying drawings do not necessarily require a specific or sequential order to achieve the desired results. In some implementations, multitasking and parallel processing are also possible or may be advantageous.

[0128] The terminology used in one or more embodiments of this application is for the purpose of describing particular embodiments only and is not intended to limit the scope of one or more embodiments of this application. The singular forms “a,” “the,” and “the” are also intended to include the plural forms unless the context clearly indicates otherwise. The term “and / or” refers to and includes any or all possible combinations of one or more associated listed items.

[0129] The terms "an embodiment," "some embodiments," "example," "specific example," or "one implementation," as used in one or more embodiments of this application, refer to specific features or characteristics described in connection with that embodiment, which are included in at least one embodiment of this application. Illustrative descriptions of these terms do not necessarily refer to the same embodiment. Furthermore, the described specific features or characteristics may be combined in a suitable manner in one or more embodiments of this application. In addition, different embodiments and specific features or characteristics from different embodiments may be combined without contradiction.

[0130] It should be understood that although the terms first, second, third, etc., may be used to describe various information in one or more embodiments of this application, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of one or more embodiments of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to a determination."

[0131] The above description is merely a preferred embodiment of one or more embodiments of this application and is not intended to limit the scope of one or more embodiments of this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of one or more embodiments of this application should be included within the protection scope of one or more embodiments of this application.

[0132] The user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

Claims

1. A method for managing permissions during container runtime, the method comprising: During the execution of the target process, the container runtime determines whether to trigger the execution of instrumentation code; wherein, the instrumentation code is a code snippet inserted for the code corresponding to the interactive process, and the interactive process is the process in which the container runtime interacts with the container instance; If the execution of the instrumentation code is triggered, the container runtime sends a notification signal to the plugin used for process permission management; In response to the received notification signal, the plugin performs process tracking on the target process and manages permissions for the target process based on a preset security policy. After completing the permission management of the target process, the container runtime continues to execute the target process after the permission management is completed.

2. The method according to claim 1, wherein the notification signal includes the execution context of the target process; The process tracing of the target process includes: Based on the system calls used for process tracing and the execution context of the target process, the plugin is attached to the target process to perform process tracing on the target process; After completing the permission management of the target process, the container runtime continues to execute the target process after the permission management is completed, including: After completing the permission management of the target process, the plugin detaches from the target process, and the container continues to execute the target process after permission management.

3. The method according to claim 2, wherein the system call used for process tracing is the ptrace system call.

4. The method according to claim 1, wherein the permission management of the target process based on a preset security policy includes: Based on system calls used for process control and preset security policies, permission management is performed on the target process.

5. The method according to claim 4, wherein the system call for process control is the prctl system call.

6. The method of claim 5, wherein the security policy comprises one or more of the following: When the parent process of the target process terminates, the target process is cleaned up. Prevent the target process from generating a core dump file upon abnormal termination; The target process and its child processes are prohibited from obtaining additional privileges; Enable secure computing mode for the target process.

7. The method according to claim 1, wherein the instrumentation code is used to implement instrumentation breakpoints; If the instrumentation code is triggered, the container runtime sends a notification signal to the plugin used for process permission management, including: If the instrumentation code is executed, the container runtime suspends the execution of the target process and sends a notification signal to the plugin used for process permission management.

8. The method according to claim 1, wherein the interaction process comprises: The process executed by the container runtime for accessing the internal file system of the container instance, and / or the process executed by the container runtime for accessing the network resources of the container instance.

9. The method according to claim 1, wherein the code corresponding to the interaction process comprises: The source code segment in the source code of the container runtime and / or the source code of the third-party libraries used in the container runtime that corresponds to the process by which the container runtime interacts with the container instance; The instrumentation code is static instrumentation code.

10. A permission management device for a container runtime, the device comprising a container runtime and a plugin for managing permissions for processes; in: During the execution of the target process, the container runtime determines whether to trigger the execution of instrumentation code; wherein, the instrumentation code is a code snippet inserted for the code corresponding to the interaction process, and the interaction process is the process in which the container runtime interacts with the container instance; If the instrumentation code is executed, the container runtime sends a notification signal to the plugin; In response to the received notification signal, the plugin performs process tracking on the target process and manages permissions for the target process based on a preset security policy. After completing the permission management of the target process, the container runtime continues to execute the target process after the permission management is completed.

11. An electronic device, comprising: processor; Memory used to store processor-executable instructions; The processor implements the method as described in any one of claims 1 to 9 by executing the executable instructions.

12. A computer-readable storage medium having stored thereon computer instructions that, when executed by a processor, implement the method as described in any one of claims 1 to 9.

Images