Process execution method, device and electronic device

Abstract

A process execution method, device and electronic device relate to the field of computer technology. When starting a target process for executing an executable file, the method obtains attribute information of the target process and the executable file, and the attribute information is used to characterize the owner of the execution permission of the target process and the access permission of the executable file, respectively. The owner includes a root user or a non-root user. When it is determined according to the attribute information that the execution permission of the process corresponds to the root user, and the non-root user has access to the file, an execution policy is determined, and the execution permission of the process is adjusted according to the policy, so that the process is prohibited from executing or executing the file with reduced permissions. In this way, when a high-privilege user executes a file that a low-privilege user can write, the process is no longer executed without judgment, but is refused to execute or executed after modifying the identity according to the file attributes, which ensures that the process executes the task while preventing the privileges of the high-privilege user from being abused by the low-privilege user, thereby improving the security of the system.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a process execution method, device, and electronic device. Background Art

[0002] In system operations, the root user, as the operating system administrator, holds the highest privileges. Other non-root users have lower privileges. Therefore, the operating system allows the root user to perform almost any operation on any file, while lower-privilege users can only perform operations on files for which they have permission. For example, the root user has permission to delete some important system files, but non-root users do not.

[0003] Furthermore, under the current operating system's user and file permission management mechanism, when a low-privileged user creates a program file, they can typically set the corresponding file attributes to grant high-privileged users execution permissions. This user and file permission management mechanism has some drawbacks. For example, if a low-privileged user creates a malicious script file and, by recording in its file attributes, grants the root user execution permissions, the root user can directly run the malicious script, thereby performing dangerous operations such as deleting important system files or elevating the permissions of low-privileged users. This can harm the operating system and even cause it to crash.

[0004] Therefore, in the operating system, the above-mentioned permission management mechanism for users and files hinders the security of the operating system. Summary of the Invention

[0005] The present application provides an execution method, apparatus, electronic device, computer storage medium, and computer program product, which can improve the security of an operating system.

[0006] In a first aspect, the present application provides a process execution method, the method comprising:

[0007] Start the target process, which is the process used to execute the executable file;

[0008] Obtaining attribute information of the target process and the executable file respectively, wherein the attribute information is used to represent the owner of the target process execution permission and the executable file access permission, and the owner includes a root user or a non-root user;

[0009] When it is determined, based on the attribute information, that the execution permission of the target process corresponds to the root user and the non-root user has access permissions to the executable file, an execution policy is determined;

[0010] According to the execution policy, the execution permissions of the target process are adjusted accordingly.

[0011] Among them, adjusting the execution permission of the target process in this embodiment can be to adjust the execution permission of the target process to deny execution to prohibit the target process from executing the executable file, or to adjust the execution permission of the target process to the permission of a low-privilege user to limit (i.e., reduce) the execution permission of the target process and execute the file with low execution permission.

[0012] In addition, when reducing the execution privilege of the target process, the identity information such as the user identity (uid) and basic group identity (gid) of the target process can be adjusted to the uid of the non-root user and the gid of the non-root group.

[0013] In this way, during the file execution process, the permission owner of the target process and executable file can be determined based on the attribute information of the target process and executable file. If the execution permission of the target process belongs to the root user (i.e., the process has high execution permission) and the access permission of the file belongs to a non-root user (i.e., a low-privileged user can write or execute the file), by determining the corresponding execution policy, the execution permission of the process is instructed to be adjusted. Therefore, when a high-privileged user executes a command (i.e., an executable file) that can be written by a low-privileged user, the permissions of the corresponding process are adaptively adjusted. Instead of executing the command that can be written by the low-privileged user without judgment, the execution is refused or the identity is modified based on the attributes of the executable file. The previous uid and gid can no longer be maintained for execution. This can ensure the functional execution of the process as much as possible while preventing the privileges of the high-privileged user from being abused by low-privileged users, thereby improving the security of the operating system.

[0014] In some possible implementations, the access permission includes writable permission.

[0015] When it is determined, based on the attribute information, that the execution permission of the target process corresponds to the root user and the non-root user has access permissions to the executable file, determining the execution policy further includes:

[0016] When it is determined that the execution permission of the target process corresponds to the root user, and when it is determined based on the attribute information of the executable file that the owner of the executable file is the root user and a non-root user has writable permission for the executable file, a first execution policy is determined;

[0017] The first execution policy is used to instruct that the execution permission of the target process be adjusted to deny execution, so as to prohibit the target process from executing the executable file.

[0018] In this way, when a process has the high execution privileges of the root user and other non-root users can write to the executable file, the first execution policy can be determined to instruct the target process whose uid is the root user to adjust the permissions and refuse to execute the file, thereby preventing other non-root users from using the write privileges to modify the file at will and then introduce dangerous commands, thereby protecting the security of the operating system.

[0019] In some possible implementations, when it is determined based on the attribute information that the execution permission of the target process corresponds to the root user and the non-root user has access permissions to the executable file, determining the execution policy specifically includes:

[0020] When it is determined that the execution permission of the target process corresponds to the root user, and when it is determined based on the attribute information of the executable file that the owner of the executable file is a non-root user, and the non-root user has the execution permission of the executable file, a second execution policy is determined;

[0021] The second execution policy is used to instruct that the execution permission of the target process be adjusted to correspond to a non-root user, so that the target process can execute the executable file with the adjusted execution permission.

[0022] In this way, when a process has the high execution privileges of the root user and the non-root user is the owner of the executable file (i.e., has write access and executable permissions to the file), the second execution policy can be used to switch the target process's identity to that of the non-root user, thereby allowing the target process to execute the executable file with the permissions of the non-root user. This ensures that if the file does not contain dangerous instructions (e.g., instructions requiring root user permissions), the file will be executed normally and the corresponding task will be completed. However, if the file contains dangerous instructions, the file will not be successfully executed because the corresponding process's execution permissions are those of the non-root user, thus ensuring the security of the operating system.

[0023] In some possible implementations, before determining the execution strategy, the method further includes:

[0024] Determine the type of the executable file, including binary executable format file type and script type;

[0025] When the executable file is of script type, determining the interpreter corresponding to the executable file;

[0026] According to the execution policy, the execution permissions of the target process are adjusted accordingly, including:

[0027] According to the corresponding execution policy, the execution permission of the target process is adjusted so that the target process executes the script type executable file and interpreter with the adjusted execution permission.

[0028] In this way, since the execution processes of binary executable format file types and script type executable files are different, binary executable format file types can directly participate in the determination of execution policies, but script type files require interpreter translation and execution. Therefore, after the file (i.e., the script) determines the execution policy, the target process is adjusted accordingly to execute the interpreter to ensure the integrity of the system execution logic.

[0029] In some possible implementations, after starting the target process, the method further includes:

[0030] Calling a preset switch, the preset switch is used to indicate whether to execute the steps in the process execution method;

[0031] When the preset switch indicates to execute the steps in the process execution method, the steps of respectively obtaining the attribute information of the target process and the executable file are continued.

[0032] In some possible implementations, the preset switch is a kernel-level switch or a file-level switch, wherein:

[0033] When the preset switch is a kernel-level switch, the preset switch corresponds to any executable file managed by the kernel;

[0034] When the preset switch is a file-level switch, the preset switch corresponds to the target executable file.

[0035] In this embodiment, a switch can be set to determine whether to enable the process execution method provided in the embodiment of the present application when the target process executes the file, that is, to determine whether to enable the adjustment of the process execution permissions, so that when this method is implemented as a kernel function, the compatibility of this function with the operating system can be guaranteed.

[0036] In a second aspect, an embodiment of the present application further provides a process execution device, the device comprising:

[0037] A processing unit, configured to start a target process, wherein the target process is configured to execute an executable file;

[0038] an acquisition unit, configured to respectively acquire attribute information of a target process and an executable file, wherein the attribute information is used to represent the owner of the target process execution permission and the executable file access permission, wherein the owner includes a root user or a non-root user;

[0039] The processing unit is further configured to determine, based on the attribute information, an execution policy when it is determined that the execution permission of the target process corresponds to a root user and a non-root user has access rights to the executable file;

[0040] The processing unit is further configured to adjust the execution permission of the target process accordingly according to the execution policy.

[0041] In some possible implementations, the access permission includes writable permission.

[0042] The processing unit is specifically used to:

[0043] Determining, based on the attribute information, that the execution permission of the target process corresponds to the root user, the owner of the executable file is the root user, and the non-root user has writable permission for the executable file, a first execution policy is determined;

[0044] The first execution policy is used to instruct that the execution permission of the target process be adjusted to deny execution, so as to prohibit the target process from executing the executable file.

[0045] In some possible implementations, the access permission includes execution permission.

[0046] The processing unit is specifically used to:

[0047] determining, based on the attribute information, a second execution policy when it is determined that the execution permission of the target process corresponds to the root user and the owner of the executable file is a non-root user and the non-root user has the execution permission of the executable file;

[0048] The second execution policy is used to instruct that the execution permission of the target process be adjusted to correspond to a non-root user, so that the target process can execute the executable file with the adjusted execution permission.

[0049] In some possible implementations, the processing unit is further configured to:

[0050] Calling a preset switch, which is used to indicate whether to enable the function of the process execution device;

[0051] When the preset switch instructs to execute the function of the process execution device, the task of respectively obtaining the attribute information of the target process and the executable file continues to be executed.

[0052] In a third aspect, the present application provides an electronic device comprising: at least one memory for storing programs; and at least one processor for executing the programs stored in the memory; wherein, when the program stored in the memory is executed, the processor is used to execute the method described in the first aspect or any possible implementation of the first aspect.

[0053] In a fourth aspect, the present application provides a computer-readable storage medium, which stores a computer program. When the computer program runs on a processor, the processor executes the method described in the first aspect or any possible implementation of the first aspect.

[0054] In a fifth aspect, the present application provides a computer program product, characterized in that when the computer program product runs on a processor, the processor executes the method described in the first aspect or any possible implementation of the first aspect.

[0055] In the sixth aspect, the present application provides a chip, characterized in that it includes at least one processor and an interface; at least one processor obtains program instructions or data through the interface; and at least one processor is used to execute program instructions to implement the method described in the first aspect or any possible implementation of the first aspect.

[0056] It can be understood that the beneficial effects of the second to sixth aspects mentioned above can be found in the relevant description of the first aspect mentioned above, and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0057] Figure 1A This is a schematic diagram of the system architecture of a computer device provided in an embodiment of the present application;

[0058] Figure 1B This is a schematic diagram of the hardware structure of a computer device provided in an embodiment of the present application;

[0059] Figure 2 This is a flowchart of a process execution method provided by an embodiment of the present application;

[0060] Figure 3 is a flowchart of a process execution method in some embodiments of the present application;

[0061] Figure 4 is a flowchart of a process execution method in other embodiments of the present application;

[0062] Figure 5 This is a schematic diagram of the structure of a process execution device provided in an embodiment of the present application;

[0063] Figure 6 This is a schematic diagram of the structure of a chip provided in an embodiment of the present application. DETAILED DESCRIPTION

[0064] The term "and / or" as used herein describes an association between related objects, indicating that three possible relationships exist. For example, "A and / or B" can represent: A exists alone, A and B exist simultaneously, or B exists alone. The symbol " / " as used herein indicates that the related objects are in an "or" relationship, for example, A / B means either A or B.

[0065] The terms "first" and "second" in this specification and claims are used to distinguish different objects rather than to describe a specific order of objects. For example, "first response message" and "second response message" are used to distinguish different response messages rather than to describe a specific order of response messages.

[0066] In the embodiments of this application, words such as "exemplary" or "for example" are used to indicate examples, illustrations, or descriptions. Any embodiment or design described as "exemplary" or "for example" in the embodiments of this application should not be interpreted as being preferred or advantageous over other embodiments or designs. Rather, the use of words such as "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner.

[0067] In the description of the embodiments of the present application, unless otherwise specified, "multiple" means two or more, for example, multiple processing units means two or more processing units, etc.; multiple elements means two or more elements, etc.

[0068] To facilitate understanding of the embodiments of the present application, some terms involved in the embodiments of the present application are introduced below.

[0069] Users and groups are the roles that the operating system uses to define the holders of permissions and rights. For example, in operating systems such as Linux and Unix, users and groups can be represented by uids and gids, respectively. A uid represents an individual user, while a gid can represent a group consisting of one or more users. Typically, a user belongs to only one primary group, but can also belong to multiple extended groups. Furthermore, different users can have different operating permissions and rights within the operating system. For example, the root user (root), as the administrator of the entire operating system, has the highest operating permissions and is also known as the superuser. The root user's primary group is the root group, and the root group typically contains only the root user. The root user has a fixed uid, typically "root" or "0" for both uid and gid. Non-root users have lower permissions than the root user, so the root user is referred to as the high-privilege user below, while other non-root users are referred to as low-privilege users.

[0070] A process is a dynamic concept. It is a computer program's execution of a data set and serves as the fundamental unit for resource allocation and scheduling. A process has the uid, gid, and gids attributes, which represent the process's user identity, basic group identity, and extended group identity, respectively. There is only one basic group identity, but multiple extended group identities are permitted.

[0071] An executable file is a static concept. It is a file that is a collection of pre-compiled instructions and data. An executable file includes a file header and binary execution code. Each process has a corresponding executable file, and the executable file script may include the process identifier.

[0072] The owner (user or owner) is a file attribute that represents the user who owns the file. The owner can be represented by "u" or its identity (ID), i.e., uid. Files can include, but are not limited to, the executable files mentioned above.

[0073] Group is a file attribute that indicates the group that owns the file. The group can be represented by "g" or its ID, gid.

[0074] Others (other), for a file, other users except the owner and group are collectively referred to as "other", which can be represented by "o".

[0075] The access mode attribute (mode) is a file attribute that records the file access permissions of three types of users: user, group, and other. The mode can be represented by a 9-bit vector. User file access permissions include read ("r"), write ("w"), and execute ("x").

[0076] The setuid mechanism sets the setuid attribute (represented by a single bit) on executable files. This ensures that when a user executes a command (i.e., executes the executable file), the corresponding process's user ID (UID) is no longer the user's, but the user ID of the executable file's owner, who has the permissions to perform the command. This is because, to protect operating system security, some data is protected from low-privilege users. However, in some application scenarios, low-privilege users do need to access this data. Therefore, the setuid mechanism was introduced in UNIX systems. A typical example is password modification. User passwords can be stored in the " / etc / shadow" file, owned by root and with an access mode of "0" (meaning only the root user can read and write). However, low-privilege users must access this file to modify their own passwords. Therefore, when a user changes their password, the command used to change the password is " / usr / bin / passwd". The " / etc / shadow" file of this command is owned by root and has the setuid attribute, making it executable by all users (including the user currently changing the password). During execution, the corresponding process's uid is the owner of the " / etc / shadow" file, root, and thus has access to the " / etc / shadow" file. In this way, low-privileged users can change passwords through the " / etc / shadow" file with the setuid attribute.

[0077] The setgid mechanism is similar to the setuid mechanism. The setuid mechanism sets the uid of a process based on the owner of the executable file, while the setgid mechanism sets the gid of a process based on the group of the executable file.

[0078] The kernel, or kernel layer, is the most basic part of the operating system. It is a part of the software that provides secure access to computer hardware for many applications. In the embodiment of the present application, the kernel can be a Linux kernel, but is not limited thereto.

[0079] System calls (or syscalls) are primarily used by operating systems to manage hardware resources and provide a favorable environment for application developers, ensuring greater compatibility. To achieve this, the kernel provides a series of kernel functions with predefined functions, presented to users through a set of entry points called system calls. System calls transmit requests from applications (running as executable files) to the kernel, which then invokes the corresponding kernel function to complete the required processing and returns the results to the application.

[0080] The execve() system call is used to run the executable file in the specified file path and load the executable file into the memory space of the current process.

[0081] The search_binary_handler() function is used to find the corresponding processing function according to the type of executable file (such as shell, a.out, ELF, etc.).

[0082] In UNIX systems, the owner of a file can modify the access mode attributes of the file. That is, the owner can always set various operation permissions for his or her own files, including write ("w") permission. Therefore, files writable by any user U can be divided into two categories: one is files with user U as the owner, and the other is files with access mode allowing user U to write as group or other user.

[0083] Furthermore, in UNIX systems, as long as the x bit (execute bit) is present in a file's access mode, the root user can execute the file regardless of the corresponding permissions granted to user, group, or other. For non-root users, whether the user type (e.g., user, group, or other) is supported by the file access mode determines whether the user has permission to operate the file.

[0084] Based on this, when a high-privilege user executes a file, the operating system typically does not determine whether the file is writable by other users. This makes it easy for low-privilege users to exploit the high-privilege user and execute commands set by the low-privilege user, resulting in some dangerous operations being performed by the high-privilege user. Among them, this dangerous operation may exist before the command is executed, or it may be introduced by the low-privilege user by modifying the executable file after the command is started. Dangerous operations include but are not limited to obvious destructive behaviors such as deleting important system files, as well as covert attack behaviors such as modifying file attributes and elevating user permissions, which facilitate low-privilege users to launch attacks. For example, low-privilege user user1 can create a malicious script (evil.sh) containing the following code:

[0085] #! / bin / bash

[0086] rm -fr /

[0087] The script access mode is "-rwxr-xr-x", which allows the root user to execute the script.

[0088] Thus, if the script is executed to delete a specified important system file F, when user user1 executes the script, the corresponding process uid is the uid of the current user user1, which will cause the script execution to fail because user user1 does not have sufficient access rights to file F. However, if the script is executed by the root user, the corresponding process uid is the uid of the root user. Since the root user has the highest operating privileges, the script will be successfully executed, and then the entire operating system will be paralyzed due to the deletion of file F.

[0089] Therefore, since high-privilege users can execute commands of low-privilege users, and the identity of the corresponding process is also a high-privilege user, and low-privilege users can arbitrarily modify the commands they own, including dangerous commands, this permission management mechanism is easily exploited by low-privilege users, thereby allowing high-privilege users to introduce dangerous operations, causing serious impact on the security of the operating system.

[0090] Furthermore, this problem is difficult to effectively address solely through the expertise of operations and maintenance personnel. Furthermore, due to the relative maturity of various operating system releases, it's also difficult to address it simply by prohibiting root from executing other users' executable files or by restricting root permissions to enforce access policies. For example, some technologies use access control lists (ACLs) to refine access policies, but ACLs still preserve root privileges and fail to address the aforementioned issue. Alternatively, operating systems use capabilities to segment root user privileges, thereby limiting root user permissions to a certain extent. However, this approach only works for executable and linkable format (ELF) files and is not universally applicable. Furthermore, mandatory access control mechanisms in operating systems, which are in tandem with access control in traditional Unix systems and don't address permission management, also fail to address the aforementioned issue. Furthermore, some technologies, such as execute disable (INTEL-XD) and execute disable (AMD-NX), use special flags on the central processing unit (CPU) to prevent the execution of instructions in the writable data segment. These technologies, however, are unrelated to permission management and thus similarly fail to address the aforementioned issue.

[0091] Therefore, in order to at least solve the problem that high-privilege users in the operating system can be easily exploited by low-privilege users to perform some dangerous operations, the embodiments of the present application provide a process execution method, device, electronic device, computer-readable storage medium, and computer program product. By identifying the process uid, gid, and the owner and group of the corresponding executable file during the process execution process, the corresponding execution policy is determined to adjust the execution permissions of the process. In this way, when a high-privilege user executes a command that can be written by a low-privilege user, the identity of the process can no longer maintain the previous uid and gid, but can be adaptively adjusted based on the attributes of the executable file, thereby not affecting the functional execution of the process, but also preventing the privileges of the high-privilege user from being abused by low-privilege users, thereby improving the security of the operating system.

[0092] A process execution method provided in an embodiment of the present application can be applied to a mobile device, a computer device, or a similar computing device for execution. Figure 1A FIG shows a schematic diagram of a system architecture of a computer device (or mobile device) 100 for executing the process execution method. Figure 1A As shown, the computer device 100 includes at least an operating system 110 and a hardware layer 120 .

[0093] Operating system 110 is divided into a user layer 111 and a kernel layer 112. User layer 111 is built based on user mode, while kernel layer 112 is built based on kernel mode. User layer 111 is the installation space for upper-layer applications (1111, 1112, ..., 111n). Kernel layer 112 controls the hardware resources of computer device 100 and provides an environment for the operation of upper-layer applications (1111, 1112, ..., 111n). Applications (1111, 1112, ..., 111n) running in user layer 111 can access computer resources in kernel layer 112 through system calls.

[0094] The hardware layer 120 includes resources such as a processor 121, memory 122, and a communication interface 123. The hardware layer 120 is used to provide hardware resources for the normal operation of the user layer 111 and the kernel layer 112. It will be appreciated that the hardware layer 120 of the computer device 110 may include more hardware, such as output devices (e.g., a display) and input devices (e.g., a keyboard), to provide more hardware functions.

[0095] For example, Figure 1B It is shown in the figure a schematic diagram of the hardware structure of a computer device. It can be understood that Figure 1B The hardware shown in FIG all belongs to the hardware layer 120. Figure 1BAs shown, the computer device 100 may include a processor 121, a memory 122, and a communication interface 123. The processor 121, the memory 122, and the communication interface 123 are connected via a bus 124 to communicate with each other.

[0096] The processor 121 may include various processing devices, such as a central processing unit (CPU), a system on chip (SOC), a processor integrated on an SOC, a separate processor chip or controller, etc. The processor 121 may also include a dedicated processing device, such as an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a digital signal processor (DSP), etc. The processor 121 may be a processor group consisting of multiple processors, and the multiple processors are coupled to each other via one or more buses.

[0097] The memory 122 may be coupled to the processor 121. Specifically, the memory 122 may be coupled to the processor 121 via one or more memory controllers. The memory 122 may be used to store computer program instructions, including the computer operating system 110 and various programs. The memory 122 may be a non-volatile memory that is not subject to power failure, such as an embedded multi-media card (EMMC), universal flash storage (UFS), or read-only memory (ROM), or other types of static storage devices that can store static information and instructions. It may also be a volatile memory that is not subject to power failure, such as random access memory (RAM) or other types of dynamic storage devices that can store information and instructions. It may also be an electrically erasable programmable read-only memory (EEPROM), a compact disc read-only memory (CD-ROM) or other optical disc storage, optical disc storage (including compact discs, laser discs, optical discs, digital versatile discs, Blu-ray discs, etc.), a magnetic disk storage medium or other magnetic storage device, or any other computer-readable storage medium that can be used to carry or store program code in the form of instructions or data structures and can be accessed by a computer, but is not limited thereto. The memory 122 may exist independently or be integrated with the processor 121.

[0098] The communication interface 123 is mainly used to implement communication between various modules, devices, units and / or equipment in the embodiments of the present application.

[0099] Exemplarily, the communication interface 123 may include an input interface 1231 and an output interface 1232. In this example, the computer device 100 may also include an input device 125 and an output device 126. The input device 125 and the output device 126 are connected to the bus 124 via the input interface 1231 and the output interface 1232, respectively, and are further connected to other devices, modules, units, or components of the computer device 100. Specifically, the input device 125 receives input information from the outside and transmits the input information to the processor 121 via the input interface 1231; the processor 121 may call programs or instructions stored in the memory 122, process the input information to generate output information, store the output information in the memory 122, and then transmit the output information to the output device 126 via the output interface 1232; the output device 126 outputs the output information to the outside of the computer device 100 for user use.

[0100] In this embodiment, bus 124 includes a bus of one or more communication protocols. Furthermore, bus 124 includes hardware, software, or both, coupling the components of computer device 100 to each other. By way of example and not limitation, bus 124 may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industrial Standard Architecture (EISA) bus, a Front Side Bus (FSB), a HyperTransport (HT) interconnect, an Industrial Standard Architecture (ISA) bus, an InfiniBand interconnect, a Low Pin Count (LPC) bus, a memory bus, a Micro Channel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCIE) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local (VLB) bus, or other suitable buses, or a combination of two or more of these. It should be understood that although the embodiments of the present application describe and illustrate specific buses, the present application contemplates any suitable bus or interconnect.

[0101] It should be understood that the structures illustrated in the embodiments of the present application do not constitute a specific limitation on the computer device 100. In other embodiments of the present application, the computer device 100 may include more or fewer components than shown, or may combine or separate certain components, or arrange the components differently. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0102] It is understood that in this solution, the computer device may be a server, mobile phone, tablet computer, digital camera, personal digital assistant (PDA), wearable device, smart TV, Huawei Smart Screen, etc. Exemplary embodiments of computer devices include, but are not limited to, electronic devices running iOS, Android, Windows, HarmonyOS, or other operating systems. The aforementioned computer devices may also be other electronic devices, such as laptop computers with touch-sensitive surfaces (e.g., touch panels). This solution does not specifically limit the type of computer device.

[0103] Next, based on the above description, a process execution method provided by an embodiment of the present application is introduced. It can be understood that this method is proposed based on the above description, and part or all of the content of this method can be referred to the above description.

[0104] See also Figure 2 , Figure 2 This is a flow chart of a process execution method provided by an embodiment of the present application. It can be understood that this method can be performed by Figure 1A The computer device shown or other devices, platforms, or equipment clusters with computing and processing capabilities are executed. Figure 2 As shown, the process execution method may include S21-S24:

[0105] S21, start starting a target process, where the target process is a process for executing an executable file.

[0106] In this embodiment, reference Figure 1A As shown, when any user U wants to execute an executable file (such as an application file) in the user layer 111, the corresponding target process is started from the operating system 110 (the target process can be started in the user layer 111 or in the kernel layer 112 before it is started) to execute the executable file in the target process, thereby completing the task indicated by the executable file.

[0107] The target process is a process that can be used to execute the executable file, and the target process is started by the user who wants to execute the executable file.

[0108] It's understandable that user access to computer resources is accomplished through processes. The operations performed by users are essentially those performed by processes that carry the user's identity information. Thus, based on the user's identity information carried by the process, the process has the corresponding execution permissions, allowing it to perform the corresponding legal operations.

[0109] For example, user U wants to execute an executable file and starts a target process that can be used to execute the file from the operating system 110. At this time, the identity information of the target process, such as the user identity or basic group identity, corresponds to user U. The target process has the operation authority of user U, and can thus execute the file and complete the operations allowed by the operation authority.

[0110] For example, the executable file may be a script or an executable and linkable format (ELF) file, but is not limited thereto. For example, the target executable file may be a shell script file or a file with a suffix of ".bat", ".sh", or ".py", but is not limited thereto.

[0111] It is understood that the operating system 110 in this embodiment can be a UNIX system or a Linux system. In some other examples, the operating system 110 can also be iOS, Android, Windows, Harmony OS, or other operating systems, and this embodiment does not limit it.

[0112] In a specific example, taking the operating system 110 as a UNIX system, refer to Figure 3 The process startup flow chart shown in the figure explains the specific process of starting the target process. Figure 3 As shown, in this example, when user U is to execute an executable file, the startup of target process can be completed by system mobilization. Specifically, by S31, target process carries out execve () system call in kernel, determines entry point, and obtains relevant parameter, and this parameter can comprise the file name, type, file path etc. of executable file. Like this, by carrying out execve () function, can read into the executable file of corresponding file path from this entry point, complete the startup of target process.Then, by S32, operating system 110 can call search_binary_handler () function, with according to the type (as shell, or ELF etc.) of this executable file, find corresponding processing function, thereby call the corresponding processing function found to load this executable file.For example, operating system can load the executable file of ELF type by load_elf_binary () function.

[0113] S22 , respectively obtaining attribute information of the target process and the executable file, wherein the attribute information is used to represent the owner of the target process execution permission and the executable file access permission, and the owner includes a root user or a non-root user.

[0114] In this embodiment, reference Figure 2 and Figure 3As shown, after starting a target process for executing an executable file, attribute information of the target process and attribute information of the executable file can be obtained respectively.

[0115] Exemplarily, the target process's attribute information may represent the owner of the target process's execution permission, where the user who launched the target process is the owner of the process's execution permission. Therefore, the target process's attribute information may include the target process's identity information, which may include the process's user identity (uid), basic group identity (gid), and / or extended group identities (gids). Furthermore, exemplary, the owner of the target process's execution permission may include a root user (root user) or a non-root user (non-root user), i.e., a high-privilege user or a low-privilege user.

[0116] For example, if the target process is started by the root user, the root user's uid and gid are the process's uid and gid respectively, and the process's execution permission owner is the root user. Similarly, if the target process is started by a non-root user, such as user1, its uid and gid are user1's uid and gid respectively, and the process's execution permission owner is user1.

[0117] Exemplarily, the attribute information of an executable file is used to characterize the owner of the file and its access rights. The attribute information of an executable file may include the file's identity information and access rights information, namely, the file's owner (user or owner), group (group), other (other), and / or access mode attributes (mode). The access mode attribute records the read, write, and execute permissions of the owner, group, and other users for the executable file.

[0118] For example, if an executable file is created by user root, the root user is the file's owner, and the access mode attribute records that the root user has read, write, and execute permissions for the file. Furthermore, if the root user also records "other" users, such as user "user1," with write permissions in the file's access mode attribute, the file's write permissions are granted to both user root and user "user1." This means that both user root and user "user1" can write and modify arbitrary code commands in the file.

[0119] S23 , determining an execution policy based on the attribute information when it is determined that the execution permission of the target process corresponds to the root user and the non-root user has access permission to the executable file.

[0120] In this embodiment, when the target process's attribute information determines that the owner of the target process's execution permission is the root user, and the executable file's attribute information determines that a non-root user has access rights to the executable file, a corresponding execution policy is determined. The execution policy is used to prohibit or reduce the target process's execution permission, where prohibiting means prohibiting the target process from running, and reducing means reducing the target process's execution permission, etc., but is not limited thereto.

[0121] Among them, illustratively, the execution permission of the target process corresponds to the root user, and the owner of the execution permission of the target process may be the root user or the root group (the basic group where the root user is located, but there is only the root user in the basic group), such as the uid and gid of the target process are both root.

[0122] For example, a non-root user has access permissions to an executable file, and the owner of the executable file access permissions may include a non-root user, for example, the owner or group of the executable file is a non-root user, or the non-root user has write permission to the file, etc. In this example, when the owner of the executable file access permissions includes a non-root user, the root user may also be included.

[0123] It should be pointed out that the root user, as a high-privilege user, can perform almost any operation on any file in the operating system. Therefore, the target process with execution authority belongs to the root user. Since it has the highest authority, even if the executable file contains dangerous instructions (i.e., instructions that are harmful to the operating system), the target process can execute the file in the operating system. Moreover, the executable file with dangerous instructions is usually a file created by a low-privilege user, or a file with writable authority for a low-privilege user. In this way, the low-privilege user can write the code for executing the dangerous instruction into the file based on his or her writable authority to the file, so that when the root user executes the file, the dangerous operation corresponding to the dangerous instruction is completed, such as deleting important system files, modifying file attributes, etc. Therefore, in order to avoid the above-mentioned situation in which a low-privilege user in the operating system uses the authority of a high-privilege user to perform dangerous operations, in the embodiment of the present application, when the execution authority of the target process belongs to the root user, the corresponding execution strategy can be determined according to the different situations of the executable file access rights to ensure that the target process cannot use the high authority of the root user to perform dangerous operations.

[0124] For example, different types of executable files have different execution processes. Therefore, in this embodiment, Figure 3As shown, before determining the execution policy in S23, the type of the executable file may be determined. The types may include binary executable format file types and script types. Thus, based on the different file types, the corresponding process is determined for the attributes of the executable file and the target process, and the corresponding execution policy is then determined. The following specifically describes the different situations in which corresponding execution policies are obtained for different file types.

[0125] For example, combined Figure 3 and Figure 4 As shown, for a file in a binary executable format, that is, an ELF file, when determining the execution strategy through S23, the following steps S231 to S234 may be specifically included:

[0126] S231: Based on the attribute information of the target process and the executable file, if it is determined that the target process's user ID is "root," the executable file is also owned by the root user, and other users (i.e., non-root users) are writable to the file, a first execution policy is determined. The first execution policy is configured to instruct the target process's execution permission to be set to deny execution, thereby prohibiting the target process from executing the executable file.

[0127] In this example, if the owner of the executable file is the root user, and the uid of the target process is also "root" (i.e., the uid of the root user), it indicates that the target process is started by the root user to execute the executable file that belongs to it. At this time, since the target process is started by the root user, the operating system will not block it no matter what command is executed. However, if the access mode attribute of the executable file also sets other users to be writable to the file, then other users can modify the file at will, and then other users may introduce dangerous commands through the file. Therefore, in this embodiment, when the owner of the executable file is the root user and other users are writable, the first execution policy is determined to instruct the target process with the uid of "root" to adjust permissions and refuse to execute the file, thereby protecting the security of the operating system.

[0128] For example, if executable file A is owned by user root, and user user1, as user "other," has writable access to file A, then when user root executes file A, the target process is started. S22 and S231 determine if the relevant attribute information meets the conditions set in S231 (i.e., the process uid is "root," file A is owned by user root, but user "other" has writable access to file A). Then, a first execution policy is determined, instructing the target process to adjust its permissions according to the first execution policy, i.e., to deny execution.

[0129] S232: If, based on the attribute information of the target process and the executable file, it is determined that the uid of the target process is "root" and the owner of the executable file is a non-root user, i.e., the owner of the executable file and its execution permissions are both non-root users, a second execution policy is determined. The second execution policy is used to instruct to adjust the execution permissions of the target process to correspond to the non-root user, so that the target process executes the executable file with the adjusted execution permissions.

[0130] Exemplarily, the execution permissions of the target process are adjusted to correspond to the non-root user. The setuid mechanism in the operating system kernel can be called to switch the uid of the target process to the uid of the non-root user, and the executable file can be executed with the low permissions of the non-root user.

[0131] In this example, if the executable file is owned by a non-root user, the non-root user has read, write, and execute permissions on the file. If the target process's uid is "root," this indicates that the file's access mode attribute specifies that the root user has execute permissions, and that the root user executed the file, which belongs to the non-root user.

[0132] In this example, considering that files created by low-privileged users or files writable by low-privileged users are not necessarily malicious files, in this example, in order to ensure that files with writable permissions for low-privileged users can be executed normally without endangering the security of the operating system, the second execution strategy is determined through the judgment of the above-mentioned situation 2, so that the target process switches the uid of the target process to the uid of the non-root user by calling the setuid mechanism. At this time, the non-root user has execution permission as the owner of the executable file, so that the target process can execute the executable file with the permission of the non-root user.

[0133] For example, consider executable file A, owned by user user1, and its instruction is to delete system file D (a system file that only the root user has execution permission for). Before the executable file is executed, the operating system cannot determine whether it introduces dangerous instructions. However, once successfully executed by the root user, who possesses the highest privilege, the dangerous consequences are irreversible. Therefore, in this example, when the root user executes file A, the target process is started. S22 and S232 determine if the relevant attribute information meets the conditions set in S232, and then the second execution policy is determined. In other words, if it is determined that the owner of executable file A (user user1) to be executed by the root user actually has read, write, and execute permissions, the target process's user ID (UID) is modified to the owner of executable file A (user user1), causing the target process to run with the execution permissions of user user1. This ensures that even if executable file A introduces dangerous commands, the target process will fail to execute because the non-root user does not have sufficient access permissions to system file D. That is, after modifying the uid of the target process, although the target process can run the executable file A with the executable permission of user user1, because user user1 does not have the execution permission for the system file D, the target process will fail to execute the instruction in file A that indicates to delete the system file D, thereby ensuring system security.

[0134] Of course, if the executable file A contains safe code and does not involve some dangerous operations, such as executable file A is used to delete file C that a non-root user has access rights to, then after the target process has its privileges reduced, it can still execute file A normally as a non-root user.

[0135] In this way, when the root user executes a file writable by a non-root user, if the non-root user also has execute permission on the file, the second execution policy can be used to instruct the target process to adjust its attributes and downgrade its permissions. In other words, the target process's permissions are restricted, reducing its permissions from the high-privilege of the root user to the low-privilege of the non-root user, allowing it to execute the file with the low permissions. This protects the security of the operating system while ensuring the normal operation of the process and the completion of the corresponding task.

[0136] S233: Based on the attribute information of the target process and the executable file, if it is determined that the gid of the target process is "root" (i.e., the gid of the root group, which is the basic group of the root user), the group of the executable file is also the root group, and other users (i.e., non-root users) can write to the file, then a first execution policy is determined.

[0137] In this example, similar to the conditions set in S231 above, if the group of the executable file is the root group and the gid of the target process is also "root", it indicates that the target process was started by the root user to execute a file belonging to the user. Similarly, to prevent other users from exploiting the writable permission on the executable file and introducing dangerous commands into the file, in this embodiment, when the group of the executable file is the root group and the other user is writable, the first execution policy is determined to instruct the target process with the gid of "root" to adjust its permissions and refuse to execute the file, thereby protecting the security of the operating system.

[0138] S234, based on the attribute information of the target process and the executable file, if it is determined that the gid of the target process is "root" and the group of the executable file is a non-root group, then determine the second execution policy to adjust the execution permissions of the target process to the corresponding non-root user group, so that the target process executes the executable file with the adjusted execution permissions.

[0139] Exemplarily, the execution permissions of the target process are adjusted to the corresponding non-root user by calling the setgid mechanism in the operating system kernel to switch the gid of the target process to the gid of the non-root group, and execute the executable file with the low permissions of the non-root user in the non-root group.

[0140] In this example, similar to the condition set in S232 above, if the group to which the executable file belongs is a non-root group, the non-root group has execute permission on the file. In this case, if the gid of the target process is "root", it indicates that the root group has execute permission in the access mode attribute of the file, and the root group executed the file that belongs to the non-root group.

[0141] In order to ensure the normal execution of the process as much as possible and at the same time ensure the security of the operating system, in this embodiment, the target process switches its identity information to the gid of the non-root group by calling the setgid mechanism, so that the process executes the corresponding executable file with the permissions of the user in the non-root group.

[0142] It is understood that in some examples, if the target process uid is "root" (or has the privilege CAP_SETUID for users to modify the user identity of the process), the operating system can simultaneously modify the process's uid, effective user ID (euid or fsuid), and saved set-user-id (suid) when calling the setuid mechanism.

[0143] When the root user executes a file with non-setuid / setgid attributes that is writable by other users, the setuid mechanism is executed, which sets the uid, euid, suid, etc. of the target process to the file owner, and the setgid mechanism is executed, which sets the gid, egid, sgid, etc. of the target process to the file group.

[0144] In this way, the target process will abandon the root user or root group permissions and run as the file owner or group. At the same time, setting the target process uid, suid (or gid, sgid) can prevent the process from restoring its original process identity by calling the setuid mechanism or setgid mechanism again.

[0145] The above steps S231 to S234 are four situations in which the execution strategy is determined when the executable file is of the ELF type. It is understandable that the steps S231 to S234 can be executed in any order.

[0146] In this embodiment, when the executable file is of ELF type, after determining the execution policy, the following step S24 may be executed to adjust the attribute information of the target process accordingly to prohibit the process from running or to run the process after reducing its permissions.

[0147] Next, the following describes the process of determining the execution strategy through S23 when the executable file is a script type.

[0148] In this embodiment, because the language used to describe instructions in the script cannot be directly executed by the process, it must be interpreted and translated by a corresponding script interpreter in order to execute the language in the script. That is, the actual object of the target program execution is the script interpreter. Therefore, in this embodiment, before determining the execution policy in S23, if the executable file is of the script type, the interpreter corresponding to the executable file is first determined. This interpreter is a tool in the operating system 110 and can be an ELF file. The script interpreter is owned by the root user, and other users do not have write permission on it, but they can have execute permission.

[0149] Therefore, in this embodiment, to maintain the integrity of the system's execution logic, when the executable file is a script file, the script and the interpreter can be treated as two separate files, each participating in the execution policy determination. Specifically, the execution policy determination is not only based on the script, but the script interpreter is also treated as an ELF file and subjected to the aforementioned determinations in S231 through S234. However, since the script interpreter does not fall into any of the categories set in S231 through S234, the execution policy determined based on the script is ultimately used to adjust the execution permissions of the target process, allowing the interpreter to execute.

[0150] Specifically, combined Figure 3 and Figure 4 As shown, in this embodiment, if the executable file is a script, the execution strategy determined in S23 may specifically include the following steps S235 to S239:

[0151] S235, open the script and use X to refer to its file descriptor fd, that is, use X to refer to the script.

[0152] S236, based on the attribute information of the target process and the script (i.e., the executable file), if it is determined that the uid of the target process is "root", the owner of the script is also the root user, and other users (i.e., non-root users) can write to the file, then a first execution policy is determined to indicate that the execution permission of the target process is adjusted to deny execution, thereby prohibiting the target process from executing the executable file.

[0153] In this way, similar to the aforementioned S231, when the relevant attributes of the target process and the script meet the conditions set in S236, the first execution strategy is determined, which can prevent other users from using the writable permission to the script to introduce dangerous commands, thereby protecting the security of the operating system.

[0154] S237: If, based on the attribute information of the target process and the script, it is determined that the uid of the target process is "root" and the owner of the script is a non-root user, i.e., the owner of the script and its execution permissions are both non-root users, a second execution policy is determined. The second execution policy is used to instruct to adjust the execution permissions of the target process to correspond to the non-root user, so that the target process executes the executable file with the adjusted permissions.

[0155] Exemplarily, the execution permissions of the target process are adjusted to the corresponding non-root user by calling the setuid mechanism in the operating system kernel to switch the uid of the target process to the uid of the non-root user, and execute the script with the low permissions of the non-root user, that is, execute the interpreter corresponding to the script.

[0156] In this way, similar to S232 above, when the root user executes a script that is writable by a non-root user, if the non-root user also has execution permission for the script, based on the determined second execution policy, an instruction is given to adjust the attributes of the target process to reduce its permissions. That is, the execution permission of the target process is reduced from the high permission of the root user to the low permission of the non-root user, and the script is executed with the low permission. In this way, while protecting the security of the operating system, the normal operation of the process is guaranteed to the greatest extent possible, and the corresponding task is completed.

[0157] S238: Based on the attribute information of the target process and the script, if it is determined that the gid of the target process is "root", the script belongs to the root group, and the other user (ie, non-root user) can write to the script, then determine the first execution policy.

[0158] In this example, similar to S233 above, if the script belongs to the root group and the gid of the target process is also "root", in order to prevent other users from introducing dangerous commands by exploiting the writable permission to the script, in this embodiment, based on the determined first execution strategy, the target process with gid of "root" is instructed to adjust permissions and refuse to execute the script, thereby protecting the security of the operating system.

[0159] S239, based on the attribute information of the target process and the script, if it is determined that the gid of the target process is "root" and the group of the script is a non-root group, a second execution policy is determined to adjust the execution permissions of the target process to the corresponding non-root group, so that the target process executes the script with the adjusted permissions.

[0160] Exemplarily, the execution permission of the target process is adjusted to the corresponding non-root group by calling the setgid mechanism in the operating system kernel to switch the gid of the target process to the gid of the non-root group, and execute the script with the low permission of the user in the non-root group.

[0161] Similar to the aforementioned S234, in this example, if the script belongs to a non-root group and the gid of the target process is "root", the target process switches its identity information to the gid of the non-root group by calling the setgid mechanism, so that the process executes the corresponding script with the permissions of the non-root group. This can ensure the normal execution of the process as much as possible while ensuring the security of the operating system.

[0162] After executing steps S235 to S239 based on the script, the script interpreter must be treated as an ELF file and then executed as steps S231 to S234 to ensure the integrity of the system's execution logic. However, since the script interpreter is writable only by the root user by default, it rarely falls under any of the scenarios set in steps S231 to S234. Therefore, the target process is ultimately executed using the execution policy determined in steps S235 to S239. Specifically:

[0163] When the script and the target process meet the conditions set in S236 or S238, a first execution policy is determined to instruct the target process to refuse execution. When the script and the target process meet the conditions set in S273 or S239, a second execution policy is determined to instruct the target process to be adjusted based on the corresponding setuid mechanism or setgid mechanism.

[0164] In addition, it is understandable that for the currently executed script, its interpreter is mostly an ELF file, so the operations S231 to S234 need to be performed on this interpreter. In some examples, the interpreter of the current script can also be a script. In this case, another interpreter is required to interpret the interpreter of the current script again, and so on, until an interpreter belonging to an ELF file is found. The operations S231 to S234 are performed on the interpreter of the ELF file to ensure the integrity of the system execution logic. However, the target process is ultimately executed according to the execution policy determined by the current script through steps S235 to S239.

[0165] For example, after determining the corresponding execution policy, when running the target process, the script interpreter parameter loaded is set to " / dev / fd / X". As described above, in S235, the character X is set to refer to the script. Thus, the script interpreter interprets the statements of the script. Next, the target process can be adjusted according to the execution policy determined in S234 to S239 through the following step S24.

[0166] S24: Adjust the execution permission of the target process accordingly according to the execution policy.

[0167] In this embodiment, according to the execution policy determined in S23, such as the first execution policy or the second execution policy, the execution privilege of the target process is adjusted accordingly, so that the target process is prohibited from executing the executable file or has its privileges reduced. Prohibiting execution means prohibiting the target process from executing the executable file, and reducing privileges means reducing the execution privileges of the target process to execute the file.

[0168] For example, when the first execution policy is determined in S23, the execution permission of the target process is adjusted to deny execution according to the policy. The target process then refuses to execute the executable file and exits after issuing an alarm.

[0169] Exemplarily, when the second execution policy is determined in S23, according to this policy, if the target process's uid is "root," the target process's uid is adjusted to the corresponding non-root user's uid based on the setuid mechanism, and the process continues to run with the non-root user's execution privileges. That is, the target process continues to execute the executable file with the non-root user's execution privileges. Specifically, if the executable file is an ELF file, the target process continues to execute the ELF file with the non-root user's execution privileges. If the executable file is a script, the target process continues to execute the corresponding interpreter with the non-root user's execution privileges to implement the task instructed by the script, thereby preventing race condition vulnerabilities (Time of Check to Time of Use, TOCTOU) attacks.

[0170] Exemplarily, when the second execution policy is determined in S23, according to this policy, if the target process's gid is "root," the target process's gid is adjusted to the corresponding non-root group's gid based on the setgid mechanism, and the process continues to run with the non-root group's execution permissions. That is, the target process continues to execute the executable file with the non-root group's execution permissions. Specifically, if the executable file is an ELF file, the target process continues to execute the ELF file with the non-root group's execution permissions. If the executable file is a script, the target process continues to execute the corresponding interpreter with the non-root group's execution permissions, completing the task instructed by the script. This can prevent race condition vulnerabilities (Time of Check to Time of Use, TOCTOU) attacks.

[0171] Thus, for those who meet the above Figure 3 After making these adjustments to target processes that meet conditions S231 through S239, the target process will ultimately refuse to run or run as a low-privilege user, preventing potentially dangerous operations from executing and thus preventing potential security risks to the system. Furthermore, for target processes that do not meet these conditions, these adjustments will not take effect and the target process will continue running without increasing system security risks.

[0172] Furthermore, when a high-privileged user executes a file writable by a low-privileged user, the process's identity is automatically downgraded to that of a low-privileged user to prevent malicious exploitation of the high-privileged user's identity. This adjustment does not affect the normal operation of the executed command, and dangerous operations in the command are either rendered inoperable or executable but no longer risky due to the changed process identity.

[0173] The method of the embodiment of the present application can be used as part of the software function in the kernel of the operating system 110, and is intended to automatically adjust the identity information of the process to protect the security of the system. No additional operations are required by the administrator, and a safe identity is automatically selected when the process starts, preventing the root user from executing "dangerous operations" set by low-privilege users, and also preventing ordinary users from using the root user's permissions to elevate their own permissions.

[0174] It can be understood that in this embodiment, if the uid or gid of the target process is a non-root user / group, it can be executed according to the existing execution logic in the current operating system, and this embodiment of the application will not be elaborated.

[0175] Furthermore, it is understood that in each of the above embodiments, the target process's uid is "root," which means that the target process's user identity is the root user's uid, and in each of the above embodiments, the target process's gid is "root," which means that the target process's basic group identity is the root user's gid. Therefore, if, in some examples, the operating system does not set the root user's uid and gid to "root," but instead sets them to other IDs, such as "0" or "1," then that ID can also be directly substituted into the above embodiments to execute the steps of the method of the present embodiment, thereby achieving the effects of the present embodiment.

[0176] In the embodiment of the present application, the corresponding execution policy is determined based on the relevant attribute information of the executable file and the target process, thereby adjusting the execution permissions of the process, thereby achieving the demotion of process execution, thereby restricting low-privilege users from utilizing the high permissions of high-privilege users. Therefore, unlike the traditional sudo instruction that allows administrators to allow ordinary users to execute some or all high-privilege management commands, the solution of the embodiment of the present application is more conducive to protecting the security of the operating system, and the solution of the embodiment of the present application will not be affected by environment variables such as LD_PRELOAD, LD_LIBRARY_PATH, PATH, and IFS.

[0177] In one possible implementation, the process execution method of the embodiment of the present application is implemented based on the kernel of the operating system 110 and is an extension of the execution logic of the execve() system call, that is, a process for adjusting the identity attributes (i.e., uid / gid) of the process according to different executable file types is added to the kernel. In order to maintain compatibility with the operating system 110, Figure 4 As shown, after executing the aforementioned S21, the preset switch variable can be called through S33 to switch the execution process of the operating system 110. Specifically, in this embodiment, after starting the target process in S21, the method can also include:

[0178] Calling a preset switch, where the preset switch is used to indicate whether to execute the steps in the process execution method;

[0179] When the preset switch instructs to execute the steps in the process execution method, the step S22 of respectively obtaining the attribute information of the target process and the executable file is continued to be executed.

[0180] In this embodiment, the preset switch is a preset switch variable keep_comp, and the switch variable has two states, namely, on and off, which are represented by the values ​​"true" and "false" respectively.

[0181] For example, two states of the switch variable may be defined in advance, for example, referring to Figure 4As shown, when the value of the switch variable is true, the identity management policy for the target process is enabled, that is, the operating system 110 can execute the aforementioned Figure 2 If the value of the switch variable is false, the identity management policy for the target process is turned off, that is, the operating system 110 does not execute the aforementioned Figure 2 Steps S22 to S24 are shown.

[0182] Alternatively, the identity management policy for the target process may be enabled when the value of the switch variable is false, and disabled when the value is true.

[0183] Furthermore, illustratively, the switch variable may be at the kernel level (ie, kernel parameter), so that the kernel-level switch variable can be used to uniformly turn on or off the kernel. Figure 2 The identity management policy for the target process shown in the figure then manages the target process accordingly during the execution of all files.

[0184] In another example, the switch variable can also be at the file level as a file attribute, that is, each executable file sets a corresponding switch variable. In this way, when running any executable file, the state of the switch variable of the executable file (in this case, the file is the target executable file) is used to determine whether to enable the identity management policy of the corresponding target process.

[0185] It is understandable that for executable files that have setuid / setgid attributes, since the identity of the corresponding process of the file has been switched to another user, there is no need to call the switch variable to start execution. Figure 2 The process of the method shown in the figure can be executed directly by executing the file.

[0186] Based on the method in the above embodiment, the embodiment of the present application provides a process execution device. Figure 5 , Figure 5 It is a structural diagram of a process execution device provided in an embodiment of the present application.

[0187] like Figure 5As shown, the process execution device 500 may include: a processing unit 501 and an acquisition unit 502. The processing unit 501 may be used to start a target process, and the target process is used to execute an executable file. The acquisition unit 502 may be used to respectively obtain attribute information of the target process and the executable file, and the attribute information is used to characterize the owner of the target process execution permission and the executable file access permission, and the owner includes a root user or a non-root user. In addition, the processing unit 501 may also be used to determine an execution policy based on the attribute information, when it is determined that the execution permission of the target process corresponds to the root user and the non-root user has access rights to the executable file, and adjust the execution permission of the target process accordingly based on the execution policy, so that the target process is prohibited from executing or has reduced permissions to execute the executable file.

[0188] In some embodiments, the access permission includes writable permission, and the processing unit 501 is specifically configured to:

[0189] Determining a first execution policy when it is determined, based on the attribute information, that the execution permission of the target process corresponds to the root user, the owner of the executable file is the root user, and the non-root user has writable permission for the executable file;

[0190] The first execution policy is used to instruct that the execution permission of the target process be adjusted to deny execution, so as to prohibit the target process from executing the executable file.

[0191] In some embodiments, the access permission includes execution permission, and the processing unit 501 is specifically configured to:

[0192] When it is determined based on the attribute information that the execution permission of the target process corresponds to the root user and the owner of the executable file is a non-root user, and the non-root user has the execution permission of the executable file, determining a second execution policy;

[0193] The second execution policy is used to instruct that the execution permission of the target process be adjusted to correspond to a non-root user, so that the target process can execute the executable file with the adjusted execution permission.

[0194] In some embodiments, the processing unit 501 is further configured to:

[0195] Calling a preset switch, which is used to indicate whether to enable the function of the process execution device;

[0196] When the preset switch indicates to start the function of the process execution device, the task of respectively obtaining the attribute information of the target process and the executable file continues to be executed.

[0197] The preset switch can be a kernel-level switch or a file-level switch. If the preset switch is a kernel-level switch, it corresponds to any executable file managed by the kernel. If the preset switch is a file-level switch, it corresponds to the current executable file (in this case, the target executable file).

[0198] It should be understood that the above-mentioned device is used to execute the method in the above-mentioned embodiment. The implementation principle and technical effect of the corresponding program unit in the device are similar to those described in the above-mentioned method. The working process of the device can refer to the corresponding process in the above-mentioned method and will not be repeated here.

[0199] Based on the methods in the above embodiments, embodiments of the present application provide an electronic device. The electronic device may include: at least one memory for storing programs; and at least one processor for executing the programs stored in the memory. When the programs stored in the memory are executed, the processor is configured to execute the methods in the above embodiments.

[0200] Based on the method in the above embodiment, an embodiment of the present application provides a computer-readable storage medium, which stores a computer program. When the computer program runs on a processor, the processor executes the method in the above embodiment.

[0201] Based on the method in the above embodiment, an embodiment of the present application provides a computer program product, characterized in that when the computer program product runs on a processor, the processor executes the method in the above embodiment.

[0202] Based on the method in the above embodiment, the present application embodiment also provides a chip. Figure 6 , Figure 6 This is a schematic diagram of the structure of a chip provided in an embodiment of the present application. Figure 6 As shown, the chip 600 includes one or more processors 601 and an interface 602. Optionally, the chip 600 may also include a bus 603.

[0203] Processor 601 may be an integrated circuit chip with signal processing capabilities. During implementation, each step of the above method may be performed by hardware integrated logic circuits within processor 601 or by software instructions. Processor 601 may be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic device, a discrete gate or transistor logic device, or a discrete hardware component. It may implement or execute the various methods and steps disclosed in the embodiments of this application. A general-purpose processor may be a microprocessor or any conventional processor.

[0204] The interface 602 may be used to send or receive data, instructions, or information. The processor 601 may process the data, instructions, or other information received by the interface 602 and may send processing completion information through the interface 602 .

[0205] Optionally, the chip 600 further includes a memory, which may include a read-only memory and a random access memory, and provides operation instructions and data to the processor. A portion of the memory may also include a non-volatile random access memory (NVRAM).

[0206] Optionally, the memory stores an executable software module or a data structure, and the processor can perform corresponding operations by calling an operation instruction stored in the memory (the operation instruction may be stored in an operating system).

[0207] Optionally, the interface 602 may be used to output the execution result of the processor 601 .

[0208] It should be noted that the functions corresponding to the processor 601 and the interface 602 can be implemented through hardware design, software design, or a combination of hardware and software, which is not limited here.

[0209] It should be understood that each step of the above method embodiment can be completed by a hardware-based logic circuit or a software-based instruction in a processor.

[0210] It is understood that the order of execution of the steps in the above embodiments does not necessarily imply a specific order of execution. The order of execution of each process should be determined by its function and inherent logic, and should not constitute any limitation on the implementation process of the embodiments of the present application. In addition, in some possible implementations, the steps in the above embodiments can be selectively executed according to actual circumstances, and can be executed partially or completely, which is not limited here.

[0211] It is understood that the processor in the embodiments of the present application may be a central processing unit (CPU), other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field programmable gate arrays (FPGA), other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. The general-purpose processor may be a microprocessor or any conventional processor.

[0212] The method steps in the embodiments of the present application can be implemented by hardware or by a processor executing software instructions. The software instructions can be composed of corresponding software modules, which can be stored in random access memory (RAM), flash memory, read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), registers, hard disks, mobile hard disks, CD-ROMs, or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor so that the processor can read information from the storage medium and write information to the storage medium. Of course, the storage medium can also be an integral part of the processor. The processor and the storage medium can be located in an ASIC.

[0213] In the above embodiments, all or part of the embodiments can be implemented using software, hardware, firmware, or any combination thereof. When implemented using software, all or part of the embodiments can be implemented in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of the present application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted via the computer-readable storage medium. The computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that can be accessed by a computer, or a data storage device such as a server or data center that integrates one or more available media. The available medium can be magnetic media (e.g., floppy disk, hard disk, tape), optical media (e.g., DVD), or semiconductor media (e.g., solid-state drive (SSD)).

[0214] It will be understood that the various numerical numbers involved in the embodiments of the present application are merely distinctions for the convenience of description and are not intended to limit the scope of the embodiments of the present application.

Claims

1. A process execution method, characterized in that: The method comprises: Starting a target process, wherein the target process is used to execute an executable file; Acquire attribute information of the target process and the executable file respectively, wherein the attribute information is used to characterize the owner of the target process execution permission and the executable file access permission respectively, and the owner includes a root user or a non-root user; Determining an execution policy when it is determined, based on the attribute information, that the execution permission of the target process corresponds to the root user and the non-root user has access rights to the executable file; According to the execution strategy, the execution permission of the target process is adjusted accordingly; Among them, the adjusting of the execution permission of the target process includes: if the owner of the executable file is the root user and the access permission includes writable permission, the execution permission of the target process is adjusted to deny execution to prohibit the target process from executing the executable file; if the owner of the executable file is the non-root user and the access permission includes execution permission, the execution permission of the target process is adjusted to correspond to the non-root user, so that the target process executes the executable file with the adjusted execution permission.

2. The method according to claim 1, characterized in that Before determining the execution strategy, the method further includes: Determine the type of the executable file, the type including a binary executable format file type and a script type; When the executable file is of the script type, determining an interpreter corresponding to the executable file; Then, adjusting the execution permission of the target process accordingly according to the execution policy specifically includes: According to the execution policy, the execution authority of the target process is adjusted so that the target process executes the script-type executable file and the interpreter with the adjusted execution authority.

3. The method according to claim 1 or 2, characterized in that: After starting the target process, the method further includes: Calling a preset switch, wherein the preset switch is used to indicate whether to execute the steps in the process execution method; When the preset switch indicates to execute the steps in the process execution method, the steps of respectively obtaining the attribute information of the target process and the executable file are continued to be executed.

4. The method according to claim 3, characterized in that The preset switch is a kernel-level switch or a file-level switch, wherein: When the preset switch is a kernel-level switch, the preset switch corresponds to any executable file managed by the kernel; When the preset switch is a file-level switch, the preset switch corresponds to a target executable file.

5. A process execution device, characterized in that: The device comprises: A processing unit, used to start a target process, wherein the target process is used to execute an executable file; an acquisition unit, used to respectively acquire attribute information of the target process and the executable file, wherein the attribute information is used to represent the owner of the target process execution permission and the executable file access permission, wherein the owner includes a root user or a non-root user; The processing unit is further configured to determine, based on the attribute information, an execution policy when it is determined that the execution permission of the target process corresponds to the root user and the non-root user has access rights to the executable file; The processing unit is further configured to adjust the execution permission of the target process accordingly according to the execution policy; Among them, the adjusting of the execution permission of the target process includes: if the owner of the executable file is the root user and the access permission includes writable permission, the execution permission of the target process is adjusted to deny execution to prohibit the target process from executing the executable file; if the owner of the executable file is the non-root user and the access permission includes execution permission, the execution permission of the target process is adjusted to correspond to the non-root user, so that the target process executes the executable file with the adjusted execution permission.

6. The device according to claim 5, characterized in that The processing unit is also used for: Calling a preset switch, wherein the preset switch is used to indicate whether to enable the function of the process execution device; When the preset switch indicates to turn on the function of the process execution device, the task of respectively obtaining the attribute information of the target process and the executable file continues to be executed.

7. An electronic device, characterized in that: include: at least one memory for storing a program; at least one processor, configured to execute the program stored in the memory; Wherein, when the program stored in the memory is executed, the processor is used to execute the method according to any one of claims 1-4.

Images