Method, device, storage medium and electronic equipment for user layer process protection

Abstract

The application relates to a method and device for realizing process protection by a user layer, a storage medium and an electronic device, wherein the method comprises the following steps: determining whether a first application process exists a first operation through a first user layer system interface, the first operation being ending a second application process; if the first operation exists, when the second application process is a protected process and the first operation is an illegal operation of ending the second application process, returning a rejection operation information through the first user layer system interface; if the first operation does not exist, determining whether the first application process performs a second operation on a target file through a second user layer system interface; if the first application process performs the second operation on the target file, obtaining an absolute path name of the second operation, and when the absolute path name is consistent with a path name of the protected process and the first application process is not the protected process, returning the rejection operation information through the second user layer system interface. The application has the effect of improving compatibility during process protection.

Description

Technical Field

[0001] This application relates to the field of process protection technology, specifically to a method, apparatus, storage medium, and electronic device for implementing process protection at the user level. Background Technology

[0002] Endpoint security products strengthen the security of endpoint operating systems and are favored by many users due to their powerful protection capabilities. While these products provide robust protection mechanisms for the operating system, the application processes themselves face numerous threats. Therefore, how to effectively protect these processes has become a pressing issue.

[0003] In related technologies, process protection has two aspects: preventing termination and preventing deletion, tampering, and renaming. Both are unified and indispensable; however, from a functional design and implementation perspective, their functions are independent and require different technologies to implement—one is process protection, and the other is file protection. Existing process protection is usually based on technologies related to the system's underlying drivers, implemented by hooking the underlying system interfaces. For the Linux platform, once the underlying kernel version is updated, the system's underlying drivers need to be redeveloped and adapted, resulting in poor compatibility. Summary of the Invention

[0004] To improve compatibility during process protection, this application provides a method, apparatus, storage medium, and electronic device for implementing process protection at the user level.

[0005] The first aspect of this application provides a method for implementing process protection at the user level, specifically including: The system determines whether the first application process has a first operation by hooking the first user layer system interface. The first application process is an application process that threatens the stable operation of the protected process. The first operation is to terminate the second application process. The first user layer system interface is an interface for transmitting process termination signals between application processes. If so, when the second application process is the protected process and the first operation is an illegal termination of the second application process, a denial operation message is returned through the first user-level system interface; If it does not exist, the second user layer system interface is used to determine whether the first application process performs a second operation on the target file. The target file is a file containing the application process. The second operation is one of the following: renaming, deleting, or tampering. If a second operation is performed on the target file, the absolute path name of the second operation is obtained. If the absolute path name is consistent with the path name of the protected process and the first application process is not the protected process, the operation rejection information is returned through the second user-level system interface.

[0006] By employing the above technical solution, and using a hook to monitor the first user-level system interface, if it is determined that the first application process is terminating other application processes, i.e., the second application process, and further, if the second application process illegally terminated by the first application process is a protected process, and the stable operation of the protected process is threatened, then a rejection message is returned through this first user-level system interface to refuse to execute the first operation; if there is no first operation, then the hook monitors the second user-level system interface. If it is determined that the first application is performing a second operation on the target file, and the absolute path of the second operation is the same as the path of the protected process, and the first application process is not a protected process, it indicates that the first application process is performing an illegal second operation on the file where the protected process is located, then a rejection message is returned to refuse to execute the second operation. Thus, the purpose of process protection is achieved by hooking the user-level system interface, without relying on the underlying kernel version of the system, and compatibility is improved.

[0007] Optionally, determining whether the first application process has performed a first operation by hooking the first user-layer system interface specifically includes: Hook the system kill interface of the Linux operating system; If a process termination signal is received from the first application process, it is determined that the first application process has performed a first operation. If no process termination signal is received from the first application process, it is determined that the first application process does not perform the first operation.

[0008] By adopting the above technical solution, when hooking the system kill interface of the Linux operating system, if a process termination signal is obtained from the first application process, it indicates that the first application process is terminating other application processes; otherwise, it indicates that the first application process is not terminating other application processes, thus enabling more accurate monitoring of the first application process's actions to terminate other processes.

[0009] Optionally, if the second application process is the protected process and the first operation is an illegal termination of the second application process, then a rejection operation message is returned through the first user-level system interface, specifically including: If it exists, the process identifier of the second application process and the SIG value of the process termination signal issued by the first application process are obtained by hooking the system kill interface of the Linux operating system. Determine whether the process termination signal is an unmaskable signal based on the SIG value; If so, the first operation is determined to be an illegal termination of the second application process, and the name of the terminated process is determined according to the process identifier. If the name of the terminated process is the same as the name of the protected process, the second application process is determined to be the protected process. When the second application process is the protected process and the first operation is an illegal termination of the second application process, the EPERM value is returned through the system kill interface.

[0010] By employing the above technical solution, if the SIG value of the process termination signal indicates that it is an unmaskable signal, it means that the termination of the second application process by the first application process is an illegal termination. Furthermore, if the process name of the terminated second application process is the same as the name of the protected process, it can be determined that the first application process is illegally terminating the protected process, requiring process protection. Finally, the system kill interface returns an EPERM value, refusing to execute the first operation, thus achieving the effect of preventing the protected process from being killed.

[0011] Optionally, before determining whether the process termination signal is an unmaskable signal based on the SIG value, the method further includes: Call the sigprocmask interface to block the system default signals sent to the protected process.

[0012] By adopting the above technical solution, based on the sigprocmask interface, all system default signals sent to the protected process can be blocked, thereby effectively preventing the protected process from receiving system default signals and performing the default processing mode, i.e., the protected process is stopped, which helps to achieve the effect of preventing the process from being killed.

[0013] Optionally, if a second operation is performed on the target file, the absolute path name of the second operation is obtained. If the absolute path name matches the path name of the protected process and the first application process is not the protected process, operation rejection information is returned through the second user-level system interface, specifically including: If the target file is deleted, the absolute path name corresponding to the deletion operation is obtained by hooking the unlink call interface, unlinkat call interface and remove call interface of the Linux operating system. If the absolute path name to be deleted is the same as the path name of the protected process, and the first application process is not the protected process, then the EPERM value is returned through the unlink call interface, the unlinkat call interface, and the remove call interface.

[0014] By adopting the above technical solution, if the second operation is a deletion operation, the absolute path name corresponding to the deletion operation is compared with the path name of the protected process. If they match, and the first application process is not the protected process itself, it means that the first application process is attempting to illegally delete the file where the protected process is located, and execution should be refused. Then, the EPERM value is returned, thereby effectively protecting the process from deletion.

[0015] Optionally, if a second operation is performed on the target file, the absolute path name of the second operation is obtained. If the absolute path name matches the path name of the protected process and the first application process is not the protected process, operation rejection information is returned through the second user-level system interface, specifically including: If the target file is to be renamed, the source path and destination path corresponding to the renaming operation are obtained by hooking the rename call interface and renameat call interface of the Linux operating system. If there is a path name in the source path and the destination path that matches the path name of the protected process, and the first application process is not the protected process, then the EPERM value is returned through the rename call and the renameat call interface.

[0016] By adopting the above technical solution, if the second operation is a renaming operation, the source path and destination path corresponding to the renaming operation will be compared with the path name of the protected process. If there is a path that matches the path name of the protected process, and the first application process is not a protected process, it means that the first application process is trying to illegally rename the file where the protected process is located, and execution should be refused. Then, the EPERM value is returned, thus effectively protecting the process from renaming.

[0017] Optionally, if a second operation is performed on the target file, the absolute path name of the second operation is obtained. If the absolute path name matches the path name of the protected process and the first application process is not the protected process, operation rejection information is returned through the second user-level system interface, specifically including: If the target file is tampered with, the absolute path name corresponding to the tampering operation is obtained by hooking the truncate call interface and truncate64 call interface of the Linux operating system. If the modified absolute path name is consistent with the path name of the protected process, and the first application process is not the protected process, then the EPERM value is returned through the truncate call interface and the truncate64 call interface.

[0018] By adopting the above technical solution, if the second operation is a tampering operation, and if the absolute path name corresponding to the tampering operation is consistent with the path name of the protected process, and the first application process is not the protected process itself, it means that the first application process is attempting to illegally tamper with the file where the protected process is located, and execution should be refused. In this case, the EPERM value is returned, thereby providing better protection against tampering of the process.

[0019] A second aspect of this application provides a user-level apparatus for implementing process protection, specifically comprising: The first monitoring module is used to determine whether the first application process has a first operation by hooking the first user layer system interface. The first application process is an application process that threatens the stable operation of the protected process. The first operation is to terminate the second application process. The first user layer system interface is an interface for transmitting process termination signals between application processes. The anti-kill protection module is used to return operation rejection information through the first user layer system interface if the second application process is the protected process and the first operation is an illegal termination of the second application process. The second monitoring module is used to determine whether the first application process has performed a second operation on the target file by hooking the second user-level system interface if the target file does not exist. The target file is a file containing the application process. The second operation is one of renaming, deleting, and tampering. The second user-level system interface is a system call that implements the second operation. The file protection module is used to obtain the absolute path name of the second operation if a second operation is performed on the target file, and to return operation rejection information through the second user-level system interface when the absolute path name is consistent with the path name of the protected process and the first application process is not the protected process.

[0020] By adopting the above technical solution, the first monitoring module determines whether the first application process has performed a first operation by hooking the first user-level system interface. When the first operation exists, the anti-kill protection module determines that the second application process is a protected process and that the first operation is an illegal termination. It then returns an operation rejection message through the first user-level system interface to perform anti-kill protection. Next, when the first operation does not exist, the second monitoring module determines whether the first application process has performed a second operation on the target file by hooking the second user-level system interface. Finally, when the second operation exists, if the absolute path name is the same as the path name of the protected process and the first application process is not the protected process itself, the file protection module returns an operation rejection message through the second user-level system interface. Therefore, process protection does not need to be implemented based on the underlying system interface, resulting in good compatibility.

[0021] In summary, this application includes at least one of the following beneficial technical effects: If it is determined that the first application process is terminating other application processes, i.e., the second application process, and further, if the second application process terminated illegally by the first application process is a protected process, and the stable operation of the protected process is threatened, then a rejection message is returned through this first user-level system interface to refuse to execute the first operation; if the first operation does not exist, then the second user-level system interface is monitored by hooking. If it is determined that the first application is performing a second operation on the target file, and the absolute path of the second operation is the same as the path of the protected process, and the first application process is not a protected process, it means that the first application process is performing an illegal second operation on the file where the protected process is located. Then, a rejection message is returned to refuse to execute the second operation. Thus, the purpose of process protection is achieved by hooking the user-level system interface, without relying on the underlying kernel version of the system, and compatibility is improved. Attached Figure Description

[0022] Figure 1 This is a flowchart illustrating a method for implementing process protection at the user layer, as provided in an embodiment of this application. Figure 2 This is a flowchart illustrating another method for implementing process protection at the user layer, provided in an embodiment of this application. Figure 3 This is a schematic diagram of the structure of a user-level device for implementing process protection, provided in an embodiment of this application. Figure 4 This is a schematic diagram of another user-level device for implementing process protection provided in this application embodiment.

[0023] Explanation of reference numerals in the attached diagram: 11. First monitoring module; 12. Anti-kill protection module; 13. Second monitoring module; 14. File protection module; 15. Signal shielding module. Detailed Implementation

[0024] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments.

[0025] In the description of the embodiments in this application, words such as "illustrative," "for example," or "for example" are used to indicate examples, illustrations, or explanations. Any embodiment or design described as "illustrative," "for example," or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or designs. Rather, the use of words such as "illustrative," "for example," or "for example" is intended to present the relevant concepts in a specific manner.

[0026] In the description of the embodiments of this application, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, B existing alone, or A and B existing simultaneously. Furthermore, unless otherwise stated, the term "multiple" means two or more. For example, multiple systems refer to two or more systems, and multiple screen terminals refer to two or more screen terminals. In addition, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the indicated technical features. Thus, a feature defined with "first" or "second" may explicitly or implicitly include one or more of that feature. The terms "comprising," "including," "having," and their variations all mean "including but not limited to," unless otherwise specifically emphasized.

[0027] The application scenario of the user-level process protection method provided in this application is as follows: In Linux platforms, when it is necessary to protect a specific process, it is usually based on the system's low-level driver technology. By hooking the low-level system interface, the application's data structure is obtained to ultimately achieve the goal of process protection, preventing the protected process from being terminated, deleted, tampered with, or renamed. Since the low-level system interface is usually provided by the operating system and accessed by the low-level driver, and the low-level driver is highly dependent on the Linux operating system's low-level kernel version, when the low-level kernel version is updated, the technical personnel need to redevelop the low-level driver to adapt to the updated low-level kernel version. As a result, when using this method to protect processes, it is greatly affected by the low-level kernel version update and has poor compatibility.

[0028] In this application scenario, the user-level process protection method provided in this application is no longer based on low-level driver technology and hooking the low-level system interface. Instead, it hooks the user-level system interface, so that process protection no longer depends on the low-level kernel version of the Linux operating system, which improves compatibility issues to a certain extent.

[0029] See Figure 1 This application discloses a flowchart illustrating a method for implementing process protection at the user level. This method can be implemented using a computer program or run on a user-level process protection device based on the von Neumann architecture. The computer program can be integrated into an application or run as a standalone utility application, specifically including: S101: Determine whether the first application process has a first operation by HOOKing the first user layer system interface. The first operation is to terminate the second application process.

[0030] In one feasible implementation, the system kill interface of the Linux operating system is hooked. If a process termination signal is received from the first application process, it is determined that the first application process has performed a first operation. If no process termination signal is received from the first application process, it is determined that the first application process does not have a first operation.

[0031] Specifically, a hook is a message processing mechanism that can be used to intercept and customize message processing procedures in a system. Custom functions can be linked into the system message processing flow to monitor, modify, or block messages. In this embodiment, it is primarily used to monitor application processes under the Linux operating system.

[0032] The user-level system interface refers to the interface between user programs and the operating system kernel, providing a way for applications to interact with the operating system. The first application process refers to an application process that may illegally terminate, delete, tamper with, or rename the protected process, threatening the stable operation of the protected process. The first user-level system interface is the interface for transmitting process termination signals between application processes. In this embodiment, the first application process is a resource manager, console terminal, or third-party application. The protected process is mainly a security protection application that ensures the security of the Linux operating system. Additionally, the first user-level system interface is the system kill interface. In other embodiments, the first user-level system interface can be the sigqueue interface.

[0033] Hooking the Linux operating system's system kill interface is a technique used to send signals to processes. It allows user-space applications to terminate a target process via system calls or by triggering corresponding operations within the operating system. If the hook reveals that the first application process is sending a termination signal to the second application process, it indicates that the first application process has performed a first operation. If the hook does not reveal a termination signal, it indicates that the first application process has not performed a first operation.

[0034] S102: If the second application process is a protected process and the first operation is an illegal termination of the second application process, then a rejection operation message is returned through the first user-level system interface.

[0035] In another feasible implementation, if it exists, the process identifier of the second application process and the SIG value of the process termination signal issued by the first application process are obtained by hooking the system kill interface of the Linux operating system. Determine whether the process termination signal is an unmaskable signal based on the SIG value; If so, the first operation is determined to be an illegal termination of the second application process, and the name of the terminated process is determined according to the process identifier. If the name of the terminated process is the same as the name of the protected process, the second application process is determined to be a protected process. When the second application process is a protected process and the first operation is an illegal termination of the second application process, the EPERM value is returned through the system kill interface.

[0036] Specifically, if a first operation exists, it indicates that the first application process is terminating the second application process. Further investigation is needed to determine if the first operation was an illegal termination, i.e., whether the first application process illegally terminated the second application process. Details are as follows: By hooking the Linux operating system's system kill interface, not only can the process termination signal be obtained, but also the process ID (PID) of the terminated second application process and the SIG value of the process termination signal can be obtained. The PID is a numerical value used by the operating system to identify processes; each process has a unique process ID. The SIG value is the identifier for the process termination signal, used to represent different signal types.

[0037] Next, based on the SIG value of the process termination signal, it is determined whether this process termination signal is a non-maskable signal. Common non-maskable signals are SIGKILL, SIGTERM, and SIGSTOP signals. The SIG value of the SIGKILL signal is 9, the SIG value of the SIGTERM signal is 15, and the SIG value of the SIGSTOP signal is 19. Therefore, if the SIG value of the process termination signal is any one of 9, 15, or 19, then it can be determined that this process termination signal is a non-maskable signal.

[0038] Before determining whether the process termination signal is an unmaskable signal based on the SIG value, the sigprocmask interface is called to mask the system default signal sent to the protected process. The sigprocmask interface is an important system call in the Linux operating system. It is mainly used to change the signal mask of the protected process, thereby achieving the purpose of masking the system default signal and thus avoiding the default process termination.

[0039] After determining that the process termination signal is an unmaskable signal, the next step is to determine whether the illegally terminated second application process is a protected process. The details are as follows: the process name corresponding to the second application process is obtained through the process identifier of the second application process. Since each application process automatically executes the constructor specified by the constructor attribute when it is loaded, the process identifier and process name of the current application process are obtained and saved in the process information cache. Therefore, the process name corresponding to the process identifier of the second application process can be matched from the process information cache.

[0040] If the name of the terminated process matches the name of the protected process, it indicates that the second application process is a protected process. This confirms that the current first application process is illegally terminating the protected process. Finally, the system kill interface returns a denial-of-operation information. In this embodiment, the denial-of-operation information is an EPERM value, which typically indicates that the system or program refuses to execute a request or operation. This prevents the illegal termination of the protected process, achieving the effect of preventing the protected process from being killed. In this embodiment, the EPERM value can be 0.

[0041] It should be noted that by calling the sigprocmask interface to block the system default signals and by hooking the system kill interface to monitor and restrict the signals that cannot be blocked, the protected process cannot receive either the system default signals or the signals that cannot be blocked. As a result, the protected process cannot be terminated by other application processes, thus achieving a better anti-kill effect.

[0042] S103: If it does not exist, determine whether the first application process performs a second operation on the target file by HOOKing the second user-level system interface.

[0043] Specifically, the target file is a file or directory containing application processes. These processes may be unprotected or protected. The second operation is one of three: renaming, deleting, or modifying. The second user-level system interface is a system call that implements this second operation. Since protected processes also reside in files or directories, process protection primarily relies on protecting the file containing the protected process to prevent deletion, modification, or renaming.

[0044] If the first operation does not exist, it means that the current first application process has not terminated the protected process through the kill mechanism. Therefore, it is necessary to further determine whether the first application process has performed any of the following operations on the target file containing the protected process: deletion, modification, or renaming. In this embodiment, the second user-level system interface is hooked, specifically the `rename` and `renameat` calls of the Linux operating system (second user-level system interface). If any function in the `rename` or `renameat` function is called, it indicates that a renaming operation is currently being performed on the target file, confirming that the first application process is performing the second operation on the target file. Alternatively, the `unlink`, `unlinkat`, and `remove` calls of the Linux operating system are hooked. If any function in the `unlink`, `unlinkat`, or `remove` function is called, it indicates that a deletion operation is currently being performed on the target file, confirming that the first application process is performing the second operation on the target file. In other embodiments, tools such as `inotify` and `fsnotify` can be used to monitor changes to the target file, including deletion, modification, and renaming, thereby ultimately determining whether the first application process is performing the second operation on the target file.

[0045] S104: If a second operation is performed on the target file, the absolute path name of the second operation is obtained. If the absolute path name is consistent with the path name of the protected process and the first application process is not a protected process, the operation rejection information is returned through the second user-level system interface.

[0046] Specifically, if it is determined that the first application process performs a second operation on the target file, namely, deleting, modifying, or renaming the file, then the absolute path name of the second operation can be obtained by calling the `readlink` function. The absolute path name starts from the root directory and fully represents the file path. In this embodiment, the absolute path starts at the root directory, enters subdirectories level by level, and finally reaches the application process in the target file. Next, the path name of the protected process is obtained using the `pwd` command. In other embodiments, the path name of the protected process can also be obtained by calling the `realpath` function. The path name of the protected process refers to the file or folder path where the protected process resides; for example, the protected process may be stored in the ` / system` or ` / protected` directory.

[0047] Finally, the absolute path name is compared with the path name of the protected process. If they match, it means that the first application process is currently performing a second operation on the file containing the protected process. If the first application process is the protected process itself, the second operation will not affect the stable operation of the protected process, and no operation prohibition is needed in this case. Therefore, when the first application process is not the protected process, the protected process is threatened with being tampered with, deleted, or renamed, requiring protection actions. Finally, a denial information is returned through the second user-level system interface, rejecting the second operation and generating a corresponding warning log, which is sent to the user's terminal. This prevents the protected process from being deleted, modified, or renamed, thereby improving compatibility during process protection and making process protection independent of the underlying kernel version.

[0048] See Figure 2 This application discloses a flowchart illustrating another method for implementing process protection at the user level. This method can be implemented using a computer program or run on a user-level process protection device based on the von Neumann architecture. The computer program can be integrated into an application or run as a standalone utility application, specifically including: S201: Determine whether the first application process has a first operation by HOOKing the first user layer system interface. The first operation is to terminate the second application process.

[0049] S202: If the second application process is a protected process and the first operation is an illegal termination of the second application process, then a denial operation message is returned through the first user-level system interface.

[0050] S203: If it does not exist, then determine whether the first application process performs a second operation on the target file by HOOKing the second user-level system interface.

[0051] For details, please refer to steps S101-S103, which will not be repeated here.

[0052] S204: If a deletion operation is performed on the target file, the absolute path name corresponding to the deletion operation is obtained by hooking the unlink call interface, unlinkat call interface and remove call interface of the Linux operating system.

[0053] S205: If the absolute path name to be deleted is the same as the path name of the protected process, and the first application process is not a protected process, then return the EPERM value through the unlink call interface, the unlinkat call interface, and the remove call interface.

[0054] Specifically, the `unlink`, `remove`, and `unlinkat` calls are all system calls used in the Linux operating system for deleting files. If the first application process's second operation on the target file is deletion, then the Linux operating system's `unlink`, `unlinkat`, and `remove` calls will all be hooked and monitored. Once the target file is deleted, it will definitely be detected by the hook, thus ultimately obtaining the absolute path name of the deletion operation performed by the first application process.

[0055] If the absolute path name to be deleted matches the path name of the protected process, it indicates that the first application process is attempting to delete the file or directory where the protected process resides. Since the first application process is not the protected process itself, this needs to be blocked. Furthermore, the deletion operation is rejected by returning an EPERM value through the `unlink`, `unlinkat`, and `remove` API calls, thus preventing the protected process from being deleted. In other embodiments, an EPERM value may also be returned through some of the `unlink`, `unlinkat`, and `remove` API calls.

[0056] S206: If a renaming operation is performed on the target file, the source path and destination path corresponding to the renaming operation are obtained by hooking the rename call interface and renameat call interface of the Linux operating system.

[0057] S207: If there is a path name in the source path and destination path that matches the protected process, and the first application process is not a protected process, then the EPERM value is returned through the rename call and the renameat call interface.

[0058] Specifically, the `rename` and `renameat` calls are system calls used in the Linux operating system for renaming files. If the first application process performs a second operation on the target file—name renaming—the `rename` and `renameat` calls will be hooked and monitored. Once a renaming operation is performed on the target file, it will definitely be detected by the hook, thus ultimately obtaining the source and destination paths of the first application process's renaming operation. The source path refers to the complete path from one file or directory to another in the computer system. The destination path indicates where the source file or directory is copied or moved.

[0059] If either the source or destination path matches the pathname of the protected process, it indicates that the first application process is attempting to rename the file or directory containing the protected process. Since the first application process is not the protected process itself, this should be blocked. Furthermore, by using the `rename` and `renameat` APIs to return an EPERM value, the renaming operation is rejected, thus preventing the protected process from being renamed. In other embodiments, either the `rename` or `renameat` API may return an EPERM value.

[0060] In other embodiments, if the target file is tampered with, the absolute path name corresponding to the tampering operation is obtained by hooking the truncate call interface and truncate64 call interface of the Linux operating system. If the tampered absolute path name is the same as the path name of the protected process, and the first application process is not a protected process, then the EPERM value is returned through the truncate call interface and the truncate64 call interface.

[0061] Specifically, both the `truncate` and `truncate64` calls are system calls used in the Linux operating system for truncating files. Since tampering operations include editing files, truncating files, and modifying file permissions and ownership, if the first application process performs a second operation on the target file that constitutes tampering, then both the `truncate` and `truncate64` calls will be hooked and monitored. Once a truncation operation is performed on the target file, it will definitely be detected by the hook, ultimately revealing the absolute path name of the tampered file corresponding to the second operation.

[0062] If the modified absolute path name matches the path name of the protected process, it indicates that the first application process is attempting to truncate the file or directory containing the protected process to a specified size. Furthermore, since the first application process is not the protected process itself, this needs to be blocked. Specifically, by returning an EPERM value through the `truncate` and `truncate64` API calls, the second operation is rejected, thus preventing the protected process from being tampered with. In one feasible implementation, either the `truncate` or `truncate64` API call can return an EPERM value.

[0063] In another embodiment, if the first application process performs a second operation on the target file that is a tampering operation, it can hook the Linux operating system's chmod, lchmod, and fchmodat call interfaces. These interfaces are system calls that modify file permissions. The system ultimately obtains the absolute path name of the target file whose permissions are being modified. If the absolute path name matches the path name of the protected process, it indicates that the first application process is attempting to modify the permissions of the file containing the protected process. Furthermore, since the first application process is not the protected process itself, this is considered a tampering operation on the protected process and needs to be prohibited. Further, the chmod, lchmod, and fchmodat call interfaces return an EPERM value, rejecting this second operation and thus preventing the protected process from being tampered with.

[0064] In another embodiment, if the first application process performs a second operation on the target file that is a tampering operation, then by hooking the chown, lchown, and fchownat call interfaces of the Linux operating system, where the chown, lchown, and fchownat call interfaces are all system calls for modifying the ownership permissions of a file, the absolute path name of the target file whose ownership permissions are to be modified is finally obtained. If the absolute path name of the modified file is the same as the path name of the protected process, it means that the first application process is attempting to modify the ownership permissions of the file containing the protected process, and the first application process is not the protected process itself. Therefore, it is considered a tampering operation on the protected process and needs to be prohibited. Furthermore, the chown, lchown, and fchownat call interfaces return an EPERM value to reject this second operation, thereby preventing the protected process from being tampered with.

[0065] In other embodiments, if the second operation performed by the first application process on the target file is a modification operation, then the access mode of the first application process opening the target file is obtained by calling the fopen function. If the access mode is any of read-write, write-only, append, or create, then further, the absolute path name of the target file is obtained by hooking the call interfaces of the Linux operating system such as create, create64, open, open64, openat, openat64, fopen, fopen64, and freopen. If the absolute path name is consistent with the path name of the protected process, it means that the first application process is trying to open the file where the protected process is located, and the first application process is not the protected process itself. In this case, it is regarded as an editing operation on the protected process and needs to be prohibited.

[0066] The implementation principle of the user-level process protection method in this application embodiment is as follows: If it is determined that the first application process is terminating other application processes, i.e., the second application process, and further, if the second application process terminated illegally by the first application process is a protected process, and the stable operation of the protected process is threatened, then the first user-level system interface returns an EPERM value to refuse to execute the first operation; if the first operation does not exist, then the second user-level system interface is monitored by hook. If it is determined that the first application is performing a second operation on the target file, and the absolute path of the second operation is the same as the path of the protected process, and the first application process is not a protected process, it indicates that the first application process is performing an illegal second operation on the file where the protected process is located, then an EPERM value is returned to refuse to execute the second operation. Thus, the purpose of process protection is achieved by hooking the user-level system interface, without relying on the underlying kernel version of the system, and compatibility is improved.

[0067] The following are embodiments of the apparatus described in this application, which can be used to execute the embodiments of the method described in this application. For details not disclosed in the apparatus embodiments of this application, please refer to the embodiments of the method described in this application.

[0068] Please see Figure 3 This is a schematic diagram of the structure of a user-level process protection device provided in an embodiment of this application. This device for user-level process protection can be implemented entirely or partially through software, hardware, or a combination of both. The device 1 includes a first monitoring module 11, an anti-kill protection module 12, a second monitoring module 13, and a file protection module 14.

[0069] The first monitoring module 11 is used to determine whether the first application process has a first operation by HOOKing the first user layer system interface. The first application process is an application process that threatens the stable operation of the protected process. The first operation is to terminate the second application process. The first user layer system interface is an interface for transmitting process termination signals between application processes. The anti-kill protection module 12 is used to return a denial operation information through the first user layer system interface if the second application process is the protected process and the first operation is an illegal termination of the second application process. The second monitoring module 13 is used to determine whether the first application process performs a second operation on the target file by hooking the second user layer system interface if the target file does not exist. The target file is a file containing the application process. The second operation is one of renaming, deleting, and tampering. The second user layer system interface is a system call that implements the second operation. The file protection module 14 is used to obtain the absolute path name of the second operation if a second operation is performed on the target file, and to return operation rejection information through the second user layer system interface when the absolute path name is consistent with the path name of the protected process and the first application process is not the protected process.

[0070] Optionally, the first monitoring module 11 is specifically used for: Hook the system kill interface of the Linux operating system; If a process termination signal is received from the first application process, it is determined that the first application process has performed a first operation. If no process termination signal is received from the first application process, it is determined that the first application process does not perform the first operation.

[0071] Optional, anti-kill protection module 12, specifically used for: If it exists, the process identifier of the second application process and the SIG value of the process termination signal issued by the first application process are obtained by hooking the system kill interface of the Linux operating system. Determine whether the process termination signal is an unmaskable signal based on the SIG value; If so, the first operation is determined to be an illegal termination of the second application process, and the name of the terminated process is determined according to the process identifier. If the name of the terminated process is the same as the name of the protected process, the second application process is determined to be the protected process. When the second application process is the protected process and the first operation is an illegal termination of the second application process, the EPERM value is returned through the system kill interface.

[0072] Optional, such as Figure 4 As shown, device 1 also includes a signal shielding module 15, specifically used for: Call the sigprocmask interface to block the system default signals sent to the protected process.

[0073] Optional, file protection module 14, specifically used for: If the target file is deleted, the absolute path name corresponding to the deletion operation is obtained by hooking the unlink call interface, unlinkat call interface and remove call interface of the Linux operating system. If the absolute path name to be deleted is the same as the path name of the protected process, and the first application process is not the protected process, then the EPERM value is returned through the unlink call interface, the unlinkat call interface, and the remove call interface.

[0074] Optionally, file protection module 14 is also used for: If the target file is to be renamed, the source path and destination path corresponding to the renaming operation are obtained by hooking the rename call interface and renameat call interface of the Linux operating system. If there is a path name in the source path and the destination path that matches the path name of the protected process, and the first application process is not the protected process, then the EPERM value is returned through the rename call and the renameat call interface.

[0075] Optionally, file protection module 14 is also used for: If the target file is tampered with, the absolute path name corresponding to the tampering operation is obtained by hooking the truncate call interface and truncate64 call interface of the Linux operating system. If the modified absolute path name is consistent with the path name of the protected process, and the first application process is not the protected process, then the EPERM value is returned through the truncate call interface and the truncate64 call interface.

[0076] It should be noted that the above embodiments of the device for implementing process protection at the user layer are only illustrated by the division of the above functional modules when executing the method for implementing process protection at the user layer. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the device for implementing process protection at the user layer and the method embodiment for implementing process protection at the user layer provided in the above embodiments belong to the same concept, and the implementation process is detailed in the method embodiment, which will not be repeated here.

[0077] This application also discloses a computer-readable storage medium storing a computer program, wherein when the computer program is executed by a processor, a user-level process protection method according to the above embodiments is employed.

[0078] The computer program can be stored in a computer-readable medium. The computer program includes computer program code, which can be in the form of source code, object code, executable file, or certain middleware. The computer-readable medium includes any entity or device capable of carrying computer program code, recording media, USB flash drive, portable hard drive, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the computer-readable medium includes, but is not limited to, the above-mentioned components.

[0079] The method for implementing process protection at the user level according to the above embodiments is stored in the computer-readable storage medium and loaded and executed on the processor to facilitate the storage and application of the above method.

[0080] This application also discloses an electronic device in which a computer program is stored in a computer-readable storage medium. When the computer program is loaded and executed by a processor, the above-described method for implementing process protection at the user level is employed.

[0081] The electronic device can be a desktop computer, a laptop computer, or a cloud server, and the electronic device includes, but is not limited to, a processor and a memory. For example, the electronic device may also include input / output devices, network access devices, and buses.

[0082] The processor can be a central processing unit (CPU). Of course, depending on the actual use, it can also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), off-the-shelf programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor, etc., and this application does not limit it.

[0083] The memory can be an internal storage unit of an electronic device, such as a hard disk or RAM, or an external storage device, such as a plug-in hard disk, smart memory card (SMC), secure digital card (SD), or flash memory card (FC) equipped on the electronic device. Furthermore, the memory can be a combination of an internal storage unit and an external storage device. The memory is used to store computer programs and other programs and data required by the electronic device. The memory can also be used to temporarily store data that has been output or will be output. This application does not limit this.

[0084] In this electronic device, a method for implementing process protection at the user level according to the above embodiment is stored in the memory of the electronic device and loaded and executed on the processor of the electronic device for convenient use.

[0085] The foregoing description is merely an exemplary embodiment of this disclosure and should not be construed as limiting the scope of this disclosure. Any equivalent changes and modifications made in accordance with the teachings of this disclosure shall still fall within the scope of this disclosure. Other embodiments of this disclosure will be readily apparent to those skilled in the art upon consideration of the specification and practice of the disclosure herein. This application is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not described herein. The specification and embodiments are to be considered exemplary only, and the scope and spirit of this disclosure are defined by the claims.

Claims

1. A method for implementing process protection at the user level, characterized in that, The method includes: The system determines whether the first application process has a first operation by hooking the first user layer system interface. The first application process is an application process that threatens the stable operation of the protected process. The first operation is to terminate the second application process. The first user layer system interface is an interface for transmitting process termination signals between application processes. If present, when the second application process is the protected process and the first operation is an illegal termination of the second application process, a denial operation information is returned through the first user-level system interface, including: if present, obtaining the process identifier of the second application process and the SIG value of the process termination signal issued by the first application process through the system kill interface of the HOOKLinux operating system; determining whether the process termination signal is an unmaskable signal based on the SIG value; if so, determining that the first operation is an illegal termination of the second application process, and determining the name of the terminated process based on the process identifier; if the name of the terminated process is consistent with the name of the protected process, determining that the second application process is the protected process; when the second application process is the protected process and the first operation is an illegal termination of the second application process, returning an EPERM value through the system kill interface; If it does not exist, the second user-level system interface is used to determine whether the first application process performs a second operation on the target file. The target file is a file containing the application process. The second operation is one of renaming, deleting, or tampering. The second user-level system interface is a system call that implements the second operation. If a second operation is performed on the target file, the absolute path name of the second operation is obtained. If the absolute path name is consistent with the path name of the protected process and the first application process is not the protected process, the operation rejection information is returned through the second user-level system interface.

2. The method for implementing process protection at the user layer according to claim 1, characterized in that, The step of determining whether the first application process has performed a first operation by hooking the first user-level system interface specifically includes: Hook the system kill interface of the Linux operating system; If a process termination signal is received from the first application process, it is determined that the first application process has performed a first operation. If no process termination signal is received from the first application process, it is determined that the first application process does not perform the first operation.

3. The method for implementing process protection at the user layer according to claim 1, characterized in that, Before determining whether the process termination signal is an unmaskable signal based on the SIG value, the method further includes: Call the sigprocmask interface to block the system default signals sent to the protected process.

4. The method for implementing process protection at the user layer according to claim 1, characterized in that, If a second operation is performed on the target file, the absolute path name of the second operation is obtained. If the absolute path name matches the path name of the protected process and the first application process is not the protected process, operation rejection information is returned through the second user-level system interface, specifically including: If the target file is deleted, the absolute path name corresponding to the deletion operation is obtained by hooking the unlink call interface, unlinkat call interface and remove call interface of the Linux operating system. If the absolute path name to be deleted is the same as the path name of the protected process, and the first application process is not the protected process, then the EPERM value is returned through the unlink call interface, the unlinkat call interface, and the remove call interface.

5. The method for implementing process protection at the user layer according to claim 1, characterized in that, If a second operation is performed on the target file, the absolute path name of the second operation is obtained. If the absolute path name matches the path name of the protected process and the first application process is not the protected process, operation rejection information is returned through the second user-level system interface, specifically including: If the target file is to be renamed, the source path and destination path corresponding to the renaming operation are obtained by hooking the rename call interface and renameat call interface of the Linux operating system. If there is a path name in the source path and the destination path that matches the path name of the protected process, and the first application process is not the protected process, then the EPERM value is returned through the rename call interface and the renameat call interface.

6. The method for implementing process protection at the user layer according to claim 1, characterized in that, If a second operation is performed on the target file, the absolute path name of the second operation is obtained. If the absolute path name matches the path name of the protected process and the first application process is not the protected process, operation rejection information is returned through the second user-level system interface, specifically including: If the target file is tampered with, the absolute path name corresponding to the tampering operation is obtained by hooking the truncate call interface and truncate64 call interface of the Linux operating system. If the modified absolute path name is consistent with the path name of the protected process, and the first application process is not the protected process, then the EPERM value is returned through the truncate call interface and the truncate64 call interface.

7. An apparatus for implementing process protection at the user layer, used to implement the method for implementing process protection at the user layer as described in any one of claims 1 to 6, characterized in that, include: The first monitoring module (11) is used to determine whether the first application process has a first operation by HOOKing the first user layer system interface. The first application process is an application process that threatens the stable operation of the protected process. The first operation is to terminate the second application process. The first user layer system interface is an interface for transmitting process termination signals between application processes. The anti-kill protection module (12) is used to return a denial operation information through the first user layer system interface if the second application process is the protected process and the first operation is an illegal termination of the second application process. The second monitoring module (13) is used to determine whether the first application process performs a second operation on the target file by HOOKing the second user layer system interface if the target file does not exist. The target file is a file containing the application process. The second operation is one of renaming, deleting, and tampering. The second user layer system interface is a system call to implement the second operation. The file protection module (14) is used to obtain the absolute path name of the second operation if the target file is subjected to a second operation, and to return operation rejection information through the second user layer system interface when the absolute path name is consistent with the path name of the protected process and the first application process is not the protected process.

8. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is loaded and executed by the processor, the user-level process protection method described in any one of claims 1 to 6 is employed.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and capable of running on the processor, characterized in that, When the processor loads and executes a computer program, it employs the user-level process protection method described in any one of claims 1 to 6.

Images