Process permission management method and device, electronic equipment and readable storage medium

Abstract

Embodiments of the present application provide a process permission management method and device, electronic equipment and readable storage medium, and relate to the technical field of containers. The specific implementation scheme is: in the process of creating a container child process in a first container, determining the security label of a target container process as the security label of the container child process, the target container process being used to start the first container, and security-enhanced Linux being disabled in the first container; and performing permission management on the container child process based on the security label of the container child process. Based on the present scheme, permission management can be performed with a single process as the granularity, and fine-grained permission management of processes can be achieved.

Description

Technical Field

[0001] This application relates to the field of container technology, and more specifically, to a process permission management method, apparatus, electronic device, and readable storage medium. Background Technology

[0002] A container is a sandbox technology primarily designed to run applications in isolation from the outside world, allowing the sandbox to be easily migrated to other host machines. Containers simplify the process of building, deploying, and running applications.

[0003] Security-Enhanced Linux (SELinux) is a security subsystem of Linux designed to enhance the security of the traditional Linux operating system. SELinux uses mandatory access control (MAC) mechanisms to restrict access to system resources by processes, users, and applications, thereby reducing the risk of system attacks.

[0004] Currently, SELinux has poor granularity in managing process permissions. How to effectively achieve granular permission management for processes has become an important technical issue. Summary of the Invention

[0005] This application provides a process permission management method, apparatus, electronic device, and readable storage medium, aiming to at least solve one of the aforementioned technical deficiencies. The technical solution adopted in this application is as follows:

[0006] In a first aspect, embodiments of this application provide a process permission management method, the method comprising:

[0007] During the creation of a container child process within the first container, the security label of the target container process is determined as the security label of the container child process. The target container process is used to start the first container, and security-enhanced Linux is disabled within the first container.

[0008] Access control for container subprocesses is managed based on their security tags.

[0009] Secondly, embodiments of this application provide a process permission management device, the device comprising:

[0010] The security label determination module is used to determine the security label of the target container process as the security label of the container subprocess during the creation of the container subprocess in the first container. The target container process is used to start the first container, and the security-enhanced Linux is disabled in the first container.

[0011] The permission management module is used to manage permissions for container subprocesses based on their security tags.

[0012] Thirdly, embodiments of this application provide a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the above-described process permission management method.

[0013] Fourthly, embodiments of this application provide an electronic device, which includes:

[0014] One or more processors; and

[0015] A memory associated with one or more processors, the memory being used to store program instructions that, when read and executed by one or more processors, perform the steps of the process permission management method described above.

[0016] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the steps of the above-described process permission management method.

[0017] The beneficial effects of the technical solutions provided in this application are:

[0018] The solution provided in this application disables Security Enhanced Linux in a first container started by the target container process, and during the creation of container child processes within the first container, determines the security label of the target container process as the security label of the container child processes, thereby managing the permissions of the container child processes based on their security labels. Based on this solution, permission management can be performed at the granularity of individual processes, achieving fine-grained permission management for processes. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments of this application will be briefly introduced below.

[0020] Figure 1 This is a system architecture diagram applicable to the embodiments of this application;

[0021] Figure 2 A flowchart illustrating the process permission management method provided in this application embodiment;

[0022] Figure 3 This is a schematic diagram of the structure of the container environment provided in the embodiments of this application;

[0023] Figure 4 This is a flowchart illustrating a specific implementation of the container permission management method in this application.

[0024] Figure 5 This is a schematic diagram of the structure of the second container provided in the embodiments of this application.

[0025] Figure 6 This is a schematic diagram of the structure of the first container provided in the embodiments of this application.

[0026] Figure 7 This is a schematic diagram of the process permission management device provided in the embodiments of this application;

[0027] Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0028] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of this application are within the scope of protection of this application.

[0029] The terminology used in the embodiments of this application is for the purpose of describing particular embodiments only and is not intended to be limiting of this application. The singular forms “a,” “the,” and “the” used in the embodiments of this application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise.

[0030] It should be understood that the term "and / or" used in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " in this article generally indicates that the preceding and following related objects have an "or" relationship.

[0031] Depending on the context, the word "if" as used here can be interpreted as "when," "when," "in response to determination," or "in response to detection." Similarly, depending on the context, the phrase "if determination" or "if detection (of the stated condition or event)" can be interpreted as "when determination," "in response to determination," "when detection (of the stated condition or event)," or "in response to detection (of the stated condition or event)."

[0032] First, let me introduce and explain several terms used in this application:

[0033] Security-Enhanced Linux (SELinux) is a security subsystem of Linux designed to enhance the security of the traditional Linux operating system. SELinux uses mandatory access control (MAC) mechanisms to restrict access to system resources by processes, users, and applications, thereby reducing the risk of system attacks.

[0034] Systemd is a system and service manager in Linux systems. It is responsible for initializing the system, managing system services, maintaining system state, controlling system resources, and providing a range of other functions to simplify system administration. Systemd can be used to create all other processes.

[0035] A container is a sandbox technology primarily designed to run applications in isolation from the outside world, while also facilitating the migration of this sandbox to other host machines. Essentially, a container is a special process that provides a lightweight virtualization environment, allowing applications to run in an isolated environment without interfering with each other.

[0036] Podman is an open-source container runtime project that can be used on most Linux platforms.

[0037] Basic environment: refers to the basic environment of an embedded system, on which container environments and SELinux environments are deployed.

[0038] In Linux, the parent process and child process have a parent-child relationship, meaning that the child process is created by the parent process.

[0039] Shell: It is the software layer between the user and the operating system. It is responsible for handling the interaction between user commands and the operating system kernel. When the user enters a command and executes it, the shell interprets the command and passes it to the kernel, and then returns the kernel output to the user.

[0040] Currently, SELinux manages process permissions by classifying processes into security categories and isolating different processes by these categories, ensuring that processes within the same security category are granted the same operational permissions. This approach lacks the granularity to manage permissions down to the individual process level, resulting in poor precision and failing to meet the principle of least privilege. Therefore, how to achieve fine-grained permission management at the individual process level has become a significant technical challenge.

[0041] Furthermore, containers, as a sandbox technology, primarily aim to isolate the container from its internal environment, providing a certain level of security. SELinux, however, uses security tags for permission management, covering all files in the system. This conflicts with the security features provided by containers themselves. Therefore, the compatibility issues between containers and SELinux cannot be ignored.

[0042] In related technologies, to address compatibility issues between containers and SELinux, container management tools offer options for configuring security labels, such as configuring security labels in Podman's security options (security-opt). However, this approach may fail to configure security labels in certain scenarios and may also present compatibility issues with older versions of SELinux.

[0043] The above-mentioned container and SELinux compatibility solutions fail to deeply integrate containers and SELinux, resulting in a poor solution to the compatibility issues between containers and SELinux.

[0044] In view of this, this application provides a new approach. To facilitate understanding of this application, the system architecture on which this application is based will first be described. Figure 1 An exemplary system architecture that can be applied to embodiments of this application is shown, such as Figure 1 As shown, the system architecture may include: user terminals, network, and server.

[0045] A network is a medium used to provide a communication link between a server and a user terminal. Networks can include various connection types, such as wired or wireless communication links, or fiber optic cables, etc.

[0046] Understandably, the process permission management device provided in this application embodiment can be set on a host machine with a container environment, and the host machine can be set on the server side or the user terminal. When the process permission management device is on the server side, the user can initiate operation commands through the user terminal, and the user terminal sends the operation commands to the server side through the network.

[0047] like Figure 1 The server shown can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, and big data and artificial intelligence platforms. The user terminal can be a smart terminal such as a smartphone, tablet, laptop, desktop computer, or smart TV.

[0048] Figure 2This illustration shows a flowchart of a process permission management method provided in an embodiment of this application. The method can be implemented by... Figure 1 The process permission management device in the system shown is executed. For example... Figure 2 As shown, this method mainly includes:

[0049] Step S210: During the process of creating a container subprocess in the first container, the security label of the target container process is determined as the security label of the container subprocess. The target container process is used to start the first container, and SELinux is disabled in the first container.

[0050] Step S220: Perform permission management on container subprocesses based on their security tags.

[0051] The target container process is the process created in the base environment to create and start the first container.

[0052] As an example, a target container process can be created in response to a container creation command. After the target container process is created, it can create and start the first container.

[0053] Security labels, also known as SELinux security identifiers (SIDs), are a tagging mechanism used for access control in SELinux. By assigning a unique security label to each process, file, or other resource, security control can be achieved.

[0054] After the first container starts, when creating container child processes within the first container, a security label needs to be determined for each container child process. The target container process is the parent process of the container child processes within the first container. By determining the security label of the target container process as the security label of the container child processes, the container child processes within the first container can inherit the security label of the target container process, thereby enabling them to inherit the permissions of the target container process.

[0055] In this embodiment, SELinux is disabled within the first container, creating an SELinux-free environment. Since systemd is not deployed within the first container, SELinux is not started by systemd, thus achieving SELinux disabling.

[0056] In related technologies, the SELinux mechanism automatically assigns a security label to the created process during process creation. However, in this embodiment, when creating a container child process within the first container, since SELinux is disabled, the security label of the container child process is not determined based on the SELinux mechanism. Instead, the container child process inherits the security label of the target container process and has the same permissions as the target container process. The label of the target container process can be defined according to the permission requirements of the services running within the first container, thus ensuring that the security label of the container child process within the first container also meets the corresponding permission requirements.

[0057] In this embodiment, the first container can serve as a service container, and the sub-processes within the first container can serve as service processes, providing corresponding container services. The first container can provide a layer of container isolation for these service processes.

[0058] In this embodiment of the application, by effectively managing the permissions of the container subprocesses within the first container, the granularity of permission management is refined to a single process, thus satisfying the permission minimization rule.

[0059] The method provided in this application disables SELinux in a first container started by the target container process and, during the creation of a container child process within the first container, determines the security label of the target container process as the security label of the container child process, thereby managing the permissions of the container child process based on the security label. Based on this solution, permission management can be performed at the granularity of a single process, achieving fine-grained permission management for processes.

[0060] In this embodiment, the permission management of the container child processes within the first container is independent of SELinux, effectively mitigating compatibility issues between containers and SELinux. It also eliminates the need to rely on configuration options for security labels provided by container management tools, such as Podman's security-opt. This solution achieves deep integration between containers and SELinux, enabling more effective permission management for container processes.

[0061] In one optional embodiment of this application, before creating the first container, the method further includes:

[0062] During the creation of the target container process, the security label of the target container process is determined based on the container-related information of the first container.

[0063] In this embodiment of the application, the security label of the target container process determines the security label of the container subprocess within the first container. Therefore, the security label of the container subprocess within the first container can be defined by defining the security label of the target container process.

[0064] To achieve accurate matching of security labels, security labels can be determined for the target container process based on the container-related information of the first container, so that the determined security labels can match the permission requirements of the container child processes within the first container.

[0065] In one optional embodiment of this application, determining the security label of the target container process based on container-related information of the first container includes:

[0066] Based on the preset matching relationship between container-related information and object tags, the container-related information of the first container is matched to obtain the matching result;

[0067] Determine the object label to be converted based on the matching results;

[0068] Perform domain transformation on the label of the object to be transformed to obtain the security label of the target container process.

[0069] In this embodiment of the application, a preset matching relationship between container-related information and object tags can be configured to perform container-related information matching with object tags.

[0070] Preset matching relationships can be configured according to actual needs. By configuring preset matching relationships, permission configuration for the target container process can be achieved.

[0071] After matching the container-related information of the first container, the matching results can be obtained, and the object label to be converted can be determined based on the matching results.

[0072] In SELinux, the label of an object to be translated needs to undergo domain translation to obtain the security label of the target container process. Domain translation refers to the process of translating from one domain to another within the SELinux policy. In SELinux, domain translation can be performed by modifying the SELinux policy or by using security context translation functions in the application.

[0073] In one optional embodiment of this application, the matching result indicates the existence of a target object label that matches the container-related information of the first container. Determining the object label to be converted based on the matching result includes:

[0074] Retrieve the default object tag corresponding to the creation command of the target container process;

[0075] Change the default object label corresponding to the creation command to the target object label;

[0076] Execute the creation command to identify the target object label as the object label to be transformed.

[0077] In this embodiment of the application, when the container-related information of the first container is successfully matched, it indicates that there is a target object tag that matches the container-related information of the first container.

[0078] The command for creating a target container process can be taken as an example using the Podman command. By default, the Podman command has a default object label, which can be understood as the file label of the Podman command. By default, when executing the Podman command to create a process, the default object label is used as the object label to be converted for the target container process, and then the default object label is domain-casted to the security label of the created container process.

[0079] In this embodiment, the default object label corresponding to the Podman command can be modified to configure the object label to be transformed. Specifically, the default object label corresponding to the Podman command can be modified to the target object label, that is, the file label of the Podman command is modified to the target object label. When the Podman command is executed to create the target container process, the target object label is used as the object label to be transformed for the target container process, and then domain transformation is performed to obtain the security label of the target container process.

[0080] By modifying the default object label corresponding to the Podman command, the target object label that matches the container information of the first container can be used as the object label to be converted, and the security label of the target container process can be obtained through domain conversion, thus realizing the effective configuration of the security label of the target container process.

[0081] In one optional embodiment of this application, after performing domain conversion on the object label to be converted to obtain the security label of the target container process, the above method further includes:

[0082] Change the target object label corresponding to the creation command to the default object label.

[0083] In this embodiment, when the target object label is successfully matched based on the container-related information of the first container, a matching security label can be assigned to the target container process by modifying the default object label corresponding to the Podman command. After the default object label corresponding to the Podman command is modified, it needs to be modified again so that the Podman command can again correspond to the default object label, that is, the file label of the Podman command is restored to the default object label, so that Podman can support subsequent use.

[0084] In this embodiment of the application, the modification of the default object label corresponding to the Podman command can be accomplished using the chcon command.

[0085] In one optional embodiment of this application, if the matching result is that there is no target security label matching the container-related information of the first container, the object label to be converted is determined based on the matching result, including:

[0086] Retrieve the default object tag corresponding to the creation command of the target container process;

[0087] Execute the creation command to specify the default object label as the object label to be converted.

[0088] In this embodiment, when the container-related information of the first container fails to match, it means that there is no target object label that matches the container-related information of the first container. At this time, it can be considered that no security label has been configured for the target container process. In this case, the default label corresponding to the creation command can be left unchanged, and the default object label can be used as the label to be converted. The default object label is then converted to obtain the security label of the target container process. Thus, the configuration of the security label of the target container process can be achieved when the container-related information of the first container fails to match.

[0089] In one optional embodiment of this application, the first container runs on a base environment where SELinux is enabled. SELinux includes a container security policy module, which is used to configure object labels.

[0090] In this embodiment of the application, Systemd running on the basic environment will enable SELinux. In this example, the SELinux container can add a container security policy module in the policy module to provide basic container support.

[0091] As an example, the container security policy module can use a set of default tags related to containers, which should include at least: security tags for processes (i.e., object tags), security tags for binary files used for domain translation, security tags for temporary files, and security tags for configuration files.

[0092] The container security policy module also allows configuration of basic container-related permissions, such as domain translation and allowing subjects to access objects within this module.

[0093] The container security policy module can also be configured with external permissions, such as allowing other system modules to access files related to the container security policy module, allowing access to other modules with low security requirements, but not allowing access to other modules with high security requirements, etc.

[0094] In an optional embodiment of this application, after the target container process is created, the above method further includes:

[0095] In response to the detection of the first container's start command, the target container process is invoked to start the first container.

[0096] In this embodiment of the application, after the target container process is created, the first container can be started based on the image of the first container.

[0097] In one optional embodiment of this application, the above method further includes:

[0098] The second container is started by a daemon process. The second container runs SELinux. The container child processes in the second container include shell processes. The container child processes in the first container include service processes of a specified type, but the service processes of the specified type do not include shell processes.

[0099] In this embodiment of the application, SELinux can be run in the second container to implement permission management within the second container.

[0100] The second container can be configured to mimic the basic environment. Systemd can be deployed in the second container, and systemd will automatically start SELinux.

[0101] When the second container starts, a default label is assigned to it. This default label has the permission to start other processes and allows users to enter the second container to perform user shell operations.

[0102] It is understandable that running a shell process within a second container to support user shell operations is a typical application of a second container. The second container can also support running other processes with different permissions, which are not limited in this application.

[0103] Certain file directories in the base environment, such as configuration files and policy module files, can be mapped to the second container as needed, thereby ensuring that the second container is consistent with the base environment.

[0104] The second container can run multiple independent container subprocesses. These subprocesses can be started by the user or automatically started as needed. The SELinux service is automatically started using Systemd deployed within the second container, and security labels are initialized within the container. After initialization, the second container resembles the basic environment; each container subprocess has a subject label, and each accessed file has an object label. Container subprocesses with different labels can also be started through domain translation. Processes within the second container can perform permission management based on SELinux, satisfying MAC protection and adhering to the principle of least privilege.

[0105] In this embodiment, the second container can be used for user shell operations, ensuring that all shell operations of the logged-in user are isolated within the larger container, and the logged-in user's label is consistent with the base environment. After logging in, the user will default to the second container and inherit the login shell label from the base environment. Permission management within the second container will also comply with SELinux.

[0106] The solution provided in this application embodiment can provide two types of containers within a container environment: a first container and a second container. The second container disguises itself as being identical to the underlying environment outside the container. After a user logs in, they default to entering the second container, which is then recognized as the underlying environment for user operations, thus isolating user operations from the underlying environment. The first container is only used to start specified types of service processes to provide corresponding container services. These specified types of service processes do not include shell processes; that is, the container services provided within the first container do not include user shell operations. By deploying SELinux security protection on the container environment, and simultaneously aligning with the characteristics of the first and second containers, the label binding between containers and SELinux is decoupled from the container tool side, forming a "container-Systemd-SELinux" relationship, deeply integrating containers and SELinux, and achieving dual security protection for containers and SELinux.

[0107] The execution logic involved in the container permission management method in this application embodiment can be packaged into a toolkit in the form of a script. This toolkit is added to the Podman container environment and can be named container-tool. At the same time, a container policy module is added to SELinux in the base environment to support the matching of security labels for container processes.

[0108] In one optional embodiment of this application, the container-related information includes at least one of the following:

[0109] The image identifier of the first container corresponds to the container image;

[0110] The label information of the first container.

[0111] The first container is started based on the corresponding container image. The image identifier of the container image can be used to identify the first container. Therefore, the image identifier and the object label can be used to establish a preset matching relationship.

[0112] The label indication information can be custom information as described in this case. It is used to specify the object label that matches the first container and can establish a preset matching relationship between the label indication information and the object label.

[0113] As an example, Figure 3This is a schematic diagram of the container environment provided in the embodiments of this application.

[0114] like Figure 3 As shown, the container environment in this case uses Podman. Podman commands can be encapsulated and named "container-tool," while SELinux support can be added.

[0115] The container tool may include a series of scripts for implementing the container permission management method of this application, as well as Podman commands. Specifically, the container tool may include commands for the second container to start the second container with a default label, map SELinux inside and outside the second container, and ensure consistency between the second container and the base environment. The container tool may also include commands for the first container to implement the step of determining the security label of the target container process, including: determining whether a target object label matches the image identifier of the first container; if a matching target object label exists, performing a domain translation on the target object label to obtain the security label of the target container process; if no matching target object label exists, performing a domain translation on the default object label to obtain the security label of the target container process.

[0116] The second container deploys Systemd, which automatically starts SELinux. It then starts a label refresh service within the container, which refreshes the security labels of processes within the second container based on SELinux.

[0117] like Figure 3 As shown, processes A, B, and C are all container child processes within the second container. These processes are assigned security labels based on the SELinux service. Specifically, process A's security label is u:r:a_t:s0, process B's is u:r:b_t:s0, and process C's is u:r:c_t:s0.

[0118] The first container does not deploy Systemd, and therefore SELinux will not be started. For example... Figure 3 As shown, the container child process running within the first container X has a security label of u:r:X_t:s0.

[0119] The solutions provided in this application deeply integrate containers with SELinux, employing different permission management schemes for specific use cases. For example, in user operation scenarios, users log in and enter a second container, with permission management based on SELinux. For individual service processes, a first container can be used. The container child processes within the first container serve as separate service processes, inheriting the security labels from the target service process, thereby achieving permission management.

[0120] The solution provided in this application can decouple the support for security-opt on the container tool side. As long as the container technically supports SELinux, it can achieve the same effect as before the decoupling on the tool side, and it is easier to expand the number of containers. At the same time, it can provide a permission minimization solution in complex container environments.

[0121] As an example, Figure 4 This is a flowchart illustrating a specific implementation of the container permission management method in this application.

[0122] like Figure 4 As shown, the first containers started by the target container process are container-xxx, container-xxx1, and container-xxx2, respectively. The container image repository stores the images of the containers. Specifically, the image for container-xxx can be obtained from the path Localhost / container-xxx, the image for container-xxx1 can be obtained from the path Localhost / container-xxx1, and the image for container-xxx2 can be obtained from the path Localhost / container-xxx2.

[0123] The SELinux policy module includes a container policy module, specifically comprising two modules: xxx1 and xxx2. Module xxx1 corresponds to the module label xxx1_t, which, after domain translation, yields the process label xxx. Similarly, module xxx2 corresponds to the module label xxx2_t, which, after domain translation, yields the process label xxx2. In this example, the module label is the aforementioned object label, and the process label is the security label of the target container process.

[0124] Container tools can match container image names with container policy modules and determine the security label of the target container process based on the matching results. For example... Figure 4As shown, if the container image name xxx cannot be matched with a module in the container policy module, the default module tag `container_runtime_t` can be domain-casted to obtain the process tag `Container`. If the container policy module contains a module `xxx1`, and the container image name matches `xxx1`, the corresponding module tag `xxx1_t` can be domain-casted to obtain the process tag `xxx1`. Similarly, if the container policy module contains a module `xxx2`, and the container image name matches `xxx2`, the default module tag `xxx2_t` can be domain-casted to obtain the process tag `xxx2`. This is understandable.

[0125] As an example, Figure 5 This is a schematic diagram of the structure of the second container provided in the embodiments of this application.

[0126] like Figure 5 As shown, SELinux is automatically started in the second container by deploying systemd.

[0127] The second container contains process A, which runs service A and has the security label u:r:a_t:s0. The second container also contains process B, which runs service B and has the security label u:r:b_t:s0.

[0128] After logging in, users can enter the second container, where all user shell operations are isolated. Processes such as process C are used to execute user shell operations.

[0129] As an example, Figure 6 This is a schematic diagram of the structure of the first container provided in the embodiments of this application.

[0130] The first container does not deploy Systemd, and therefore SELinux will not be started. For example... Figure 6 As shown, the X service can be run within the first container through a container process (i.e., a container child process), and the security label of this container process is u:r:X_t:s0.

[0131] In practical use, multiple first containers can be started, and each first container can be responsible for running different services independently.

[0132] Based on and Figure 2 The method shown follows the same principle. Figure 7 This illustration shows a schematic diagram of the structure of a process permission management device provided in an embodiment of this application, such as... Figure 7 As shown, the process permission management device 70 may include:

[0133] The security label determination module 710 is used to determine the security label of the target container process as the security label of the container subprocess during the creation of the container subprocess in the first container. The target container process is used to start the first container, and SELinux is disabled in the first container.

[0134] The permission management module 720 is used to manage permissions for container subprocesses based on their security tags.

[0135] Optionally, the security label determination module described above is also used for:

[0136] Before the first container is created, during the creation process of the target container process, the security label of the target container process is determined based on the container-related information of the first container.

[0137] Optionally, when determining the security label of the target container process based on the container-related information of the first container, the security label determination module is specifically used for:

[0138] Based on the preset matching relationship between container-related information and object tags, the container-related information of the first container is matched to obtain the matching result;

[0139] Determine the object label to be converted based on the matching results;

[0140] Perform domain transformation on the label of the object to be transformed to obtain the security label of the target container process.

[0141] Optionally,

[0142] The matching result indicates the existence of target object tags that match the container-related information of the first container. Based on the matching result, the object tags to be converted are determined, including:

[0143] Retrieve the default object tag corresponding to the creation command of the target container process;

[0144] Change the default object label corresponding to the creation command to the target object label;

[0145] Execute the creation command to identify the target object label as the object label to be transformed.

[0146] Optionally, the above-mentioned device further includes:

[0147] The command restoration module performs domain transformation on the object label to be transformed, obtaining the security label of the target container process.

[0148] Retrieve the default object tag corresponding to the creation command of the target container process;

[0149] Execute the creation command to specify the default object label as the object label to be converted.

[0150] Optionally, if the matching result indicates that no target security label matches the container-related information of the first container, the security label determination module determines the object label to be converted based on the matching result, specifically for:

[0151] Retrieve the default object tag corresponding to the creation command of the target container process;

[0152] Execute the creation command to specify the default object label as the object label to be converted.

[0153] Optionally, the first container runs on a base environment with SELinux enabled. SELinux includes a container security policy module, which is used to configure object labels.

[0154] Optionally, the device further includes:

[0155] The first container startup module is used to call the target container process to start the first container after the target container process is created, in response to the detection of the first container startup command.

[0156] Optionally, the device further includes:

[0157] The second container startup module is used to start a second container via a daemon process. The second container runs SELinux. The container child processes in the second container include shell processes. The container child processes in the first container include service processes of a specified type, but the specified service processes do not include shell processes.

[0158] Optionally, container-related information includes at least one of the following:

[0159] The image identifier of the first container corresponds to the container image;

[0160] The label information of the first container.

[0161] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the device embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments. The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0162] It should be noted that 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 portals are provided for users to choose to authorize or refuse.

[0163] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of any of the methods in the foregoing method embodiments.

[0164] The computer-readable storage medium provided in this application, compared with the prior art, disables SELinux in a first container started by the target container process and determines the security label of the target container process as the security label of the container subprocess during the creation of container subprocesses within the first container. This allows for permission management of the container subprocess based on its security label. Based on this solution, permission management can be performed at the granularity of a single process, achieving fine-grained permission management for processes.

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

[0166] One or more processors; and

[0167] A memory associated with one or more of the aforementioned processors, the memory being used to store program instructions that, when read and executed by one or more of the aforementioned processors, perform the steps of the method in any of the foregoing method embodiments.

[0168] The electronic device provided in this application, compared with the prior art, disables SELinux in a first container started by the target container process and determines the security label of the target container process as the security label of the container subprocess during the creation of container subprocesses within the first container. This allows for permission management of the container subprocess based on its security label. Based on this solution, permission management can be performed at the granularity of a single process, achieving fine-grained permission management for processes.

[0169] As an example, Figure 8 A schematic diagram of the structure of an electronic device to which this application embodiment applies is shown, such as... Figure 8As shown, the electronic device 2000 includes a processor 2001 and a memory 2003. The processor 2001 and the memory 2003 are connected, for example, via a bus 2002. Optionally, the electronic device 2000 may also include a transceiver 2004. It should be noted that in practical applications, the transceiver 2004 is not limited to one type, and the structure of the electronic device 2000 does not constitute a limitation on the embodiments of this application.

[0170] In this embodiment, the processor 2001 is used to implement the method shown in the above method embodiment. The transceiver 2004 may include a receiver and a transmitter. In this embodiment, the transceiver 2004 is used to enable the electronic device of this embodiment to communicate with other devices during execution.

[0171] Processor 2001 may be a CPU (Central Processing Unit), a general-purpose processor, a DSP (Digital Signal Processor), an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It can implement or execute the various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. Processor 2001 may also be a combination that implements computing functions, such as including one or more microprocessor combinations, a combination of a DSP and a microprocessor, etc.

[0172] Bus 2002 may include a pathway for transmitting information between the aforementioned components. Bus 2002 may be a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus, etc. Bus 2002 can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 8 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0173] The memory 2003 may be ROM (Read Only Memory) or other types of static storage devices capable of storing static information and instructions, RAM (Random Access Memory) or other types of dynamic storage devices capable of storing information and instructions, or EEPROM (Electrically Erasable Programmable Read Only Memory), CD-ROM (Compact Disc Read Only Memory) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital universal optical discs, Blu-ray discs, etc.), magnetic disk storage media or other magnetic storage devices, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but not limited thereto.

[0174] Optionally, the memory 2003 is used to store application code that executes the scheme of this application, and its execution is controlled by the processor 2001. The processor 2001 is used to execute the application code stored in the memory 2003 to implement the steps of the method in any of the foregoing method embodiments.

[0175] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of any of the methods in the foregoing method embodiments.

[0176] The computer program product provided in this application, compared with the prior art, disables SELinux in the first container started by the target container process and determines the security label of the target container process as the security label of the container subprocess during the creation of container subprocesses within the first container. This allows for permission management of the container subprocess based on its security label. Based on this solution, permission management can be performed at the granularity of a single process, achieving fine-grained permission management for processes.

[0177] It should be understood that although the steps in the flowcharts of the accompanying figures are shown sequentially as indicated by the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the accompanying figures may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times, and their execution order is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0178] The above are only some embodiments of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A process authority management method characterized by comprising: include: A target container process is created in a base environment with Security Enhanced Linux enabled, and a first container is started and run in the base environment through the target container process, wherein Security Enhanced Linux is disabled in the first container; During the process of creating a container subprocess within the first container, the security label of the target container process is determined as the security label of the container subprocess. Access control is performed on the container subprocess based on its security tag.

2. The method of claim 1, wherein, Before creating the first container, the method further includes: During the creation of the target container process, the security label of the target container process is determined based on the container-related information of the first container.

3. The method of claim 2, wherein, Determining the security label of the target container process based on the container-related information of the first container includes: Based on the preset matching relationship between container-related information and object tags, the container-related information of the first container is matched to obtain the matching result; Based on the matching results, determine the object label to be converted; The object label to be converted is subjected to domain conversion to obtain the security label of the target container process.

4. The method of claim 3, wherein, The matching result indicates the existence of a target object tag that matches the container-related information of the first container. The step of determining the object tag to be converted based on the matching result includes: Obtain the default object tag corresponding to the creation command of the target container process; Modify the default object label corresponding to the creation command to the target object label; Execute the creation command to determine the target object label as the object label to be converted.

5. The method of claim 4, wherein, After performing domain transformation on the object label to be converted to obtain the security label of the target container process, the method further includes: Modify the target object label corresponding to the creation command to the default object label.

6. The method of claim 3, wherein, The matching result indicates that there is no target security label that matches the container-related information of the first container. The step of determining the object label to be converted based on the matching result includes: Obtain the default object tag corresponding to the creation command of the target container process; Execute the creation command to designate the default object label as the object label to be converted.

7. The method according to any one of claims 3-6, characterized in that, The security-enhanced Linux includes a container security policy module, which is used to configure the object labels.

8. The method according to any one of claims 1-6, characterized in that, After the target container process is created, the method further includes: In response to the detection of the start command for the first container, the target container process is invoked to start the first container.

9. The method according to any one of claims 1-6, characterized in that, Also includes: A second container is started by a daemon process. The second container runs a security-enhanced Linux. The container child processes in the second container include shell processes. The container child processes of the first container include service processes of a specified type, but the specified service processes do not include the shell processes.

10. The method of any one of claims 2-6, wherein, The container-related information includes at least one of the following: The first container corresponds to the image identifier of the container image; The label information of the first container.

11. A process authority management apparatus characterized by comprising: include: The security label determination module is used to create a target container process in a base environment with Security Enhanced Linux enabled, and to start and run a first container in the base environment through the target container process, wherein Security Enhanced Linux is disabled in the first container; during the creation of a container subprocess in the first container, the security label of the target container process is determined as the security label of the container subprocess. The permission management module is used to manage permissions for the container subprocess based on the security label of the container subprocess.

12. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the steps of the method according to any one of claims 1-10.

13. An electronic device, comprising: include: One or more processors; as well as A memory associated with the one or more processors, the memory being used to store program instructions that, when read and executed by the one or more processors, perform the steps of the method according to any one of claims 1-10.

14. A computer program product comprising a computer program, characterized in that, When executed by a processor, the computer program performs the steps of the method according to any one of claims 1 to 10.

Images