CN118153040A - Method and device for protecting key process of credit-invasive operating system - Google Patents
Method and device for protecting key process of credit-invasive operating system Download PDFInfo
- Publication number
- CN118153040A CN118153040A CN202410564895.5A CN202410564895A CN118153040A CN 118153040 A CN118153040 A CN 118153040A CN 202410564895 A CN202410564895 A CN 202410564895A CN 118153040 A CN118153040 A CN 118153040A
- Authority
- CN
- China
- Prior art keywords
- signal
- function
- ptrace
- key
- signal processing
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 336
- 230000008569 process Effects 0.000 title claims abstract description 320
- 238000012545 processing Methods 0.000 claims abstract description 84
- 230000004048 modification Effects 0.000 claims description 17
- 238000012986 modification Methods 0.000 claims description 17
- 230000006870 function Effects 0.000 description 77
- 238000007726 management method Methods 0.000 description 7
- 230000003068 static effect Effects 0.000 description 6
- 239000011800 void material Substances 0.000 description 4
- 238000010586 diagram Methods 0.000 description 2
- 230000000694 effects Effects 0.000 description 2
- 238000012544 monitoring process Methods 0.000 description 2
- 201000009032 substance abuse Diseases 0.000 description 2
- 230000009286 beneficial effect Effects 0.000 description 1
- 239000000306 component Substances 0.000 description 1
- 239000008358 core component Substances 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 238000002955 isolation Methods 0.000 description 1
- 230000009191 jumping Effects 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 230000002265 prevention Effects 0.000 description 1
- 230000008439 repair process Effects 0.000 description 1
- 230000009131 signaling function Effects 0.000 description 1
- 230000001960 triggered effect Effects 0.000 description 1
Landscapes
- Storage Device Security (AREA)
Abstract
The invention discloses a method and a device for protecting key processes of a credit-invasive operating system, and relates to the technical field of operating systems. In order to better protect key processes of an operating system, the method comprises the following two parts: modifying signal processing logic in a signal processing function do_signal, when a kill command is executed to kill a current process, protecting the current process from being killed when the current process is a specified key process; and (II) adding a hook function of ptrace_ traceme, and when a malicious user tries to modify the current process through the gdb program, protecting the current process from being modified when the current process is a designated key process. The invention can protect the key process from being killed and modified after the system is invaded, and maintain the normal operation of the key process.
Description
Technical Field
The invention relates to the technical field of operating systems, in particular to a method and a device for protecting key processes of a credit-invasive operating system.
Background
In the field of trust, security hole repair of an operating system is very important, because the security hole may be utilized by malicious attackers to damage a system and data, and repairing the security hole of the trust operating system is important for ensuring the security of the system, protecting user data and privacy, improving the stability and reliability of the system and complying with legal compliance.
The key processes of an operating system are generally referred to as: an initialization process, a scheduling process, a memory management process, a file system management process, a network service process, a log record process, a security monitoring process, a user interface process, a device driving process, a resource isolation process, a multi-task processing process, a system service process, a performance monitoring process, an error reporting and recovering process, and a user authentication and authority management process.
The key process of protecting the operating system is one of the important measures to ensure the safe and stable operation of the computer system. The key processes of the operating system are usually the core components of the system and are responsible for the key functions of managing system resources, scheduling tasks, maintaining security and the like. The following are some important reasons for protecting key processes of an operating system:
1. system stability: the key processes are responsible for the core functions of the operating system, such as memory management, process scheduling, file system maintenance, and the like. If these processes are affected by malware or unauthorized access, they may cause the system to crash or be unstable. Protecting critical processes helps to ensure proper operation and reliability of the system.
2. Safety: key processes of an operating system typically include components directly related to system security, such as rights management, authentication, and security auditing. An attacker may attempt to exploit vulnerabilities or malicious code to destroy these processes, to gain unauthorized access or to perform malicious activity. By protecting critical processes, the risk of the system being attacked maliciously can be reduced.
3. And (3) resource management: the key process is responsible for managing system resources including memory, CPU, storage, etc. If these processes are corrupted, they may cause resource leakage, over-utilization, or resource conflict, thereby affecting system performance. By protecting critical processes, efficient management and allocation of resources can be ensured.
4. Abuse prevention: protecting critical processes helps prevent users or programs from misusing system rights. If critical processes are corrupted or tampered with, unauthorized access or dangerous operations may be performed. By implementing the protection mechanism, the abuse risk can be reduced, and the overall security of the system can be improved.
5. Service continuity: some critical processes may be directly related to the business continuity of the system. For example, if a process is responsible for critical data storage or processing, its availability and integrity are critical to business operations. By protecting these processes, it is ensured that the system can maintain normal business operation in the face of various threats.
In general, the key process of protecting an operating system is a necessary measure to maintain the system's safe, stable and normal operation, helping to prevent various threats and improving the overall performance of the system.
Disclosure of Invention
Aiming at the needs and the shortcomings of the prior art development, the invention provides a method and a device for protecting key processes of a credit-created operating system, which are used for protecting the key processes from being killed, modified and destroyed after the system is invaded and maintaining the normal operation of the key processes.
In a first aspect, the present invention provides a method for protecting a critical process of a signal creation operating system, which solves the above technical problems by adopting the following technical scheme:
a method for protecting key processes of a credit-invasive operating system comprises the following two parts:
Modifying signal processing logic in a signal processing function do_signal, when a kill command is executed to kill a current process, protecting the current process from being killed when the current process is a specified key process;
And (II) adding a hook function of ptrace_ traceme, and when a malicious user tries to modify the current process through the gdb program, protecting the current process from being modified when the current process is a designated key process.
Optionally, the specific operation of performing (a) to protect the process from killing is as follows:
(1) Adding a unique identifier of a key process to be protected to a key process list A;
(2) Modifying the signal processing logic in the signal processing function do_signal: if the unique identifier of the current process appears in the key process list A and the signal is SIGKILL or SIGTERM, the SIGKILL signal or SIGTERM signal of the current process is ignored, otherwise, the current process is killed by calling a handle_signal function according to the original logic;
(3) When executing the kill command to kill the process a, the signal processing function do_signal in the kernel mode is called, and the signal processing function do_signal kills the process a or protects the process a from being killed according to the signal processing logic.
Further alternatively, after the signal processing function do_signal calls the handle_signal function according to its signal processing logic, when the process a runs in kernel state, the handle_signal function does not act immediately, and the process a is killed until the user state is to be returned.
Optionally, the specific operation of executing (two) to protect the process from modification is as follows:
(1) Adding a unique identifier of the key process to be protected to a key process list B;
(2) With the LSM framework, a hook function of ptrace_ traceme is added, and its processing logic is: when a malicious user tries to modify the current process through the gdb program, judging whether the current process is in a key process list B, if so, refusing to modify the current process, and if not, allowing to modify the current process;
(3) When a malicious user tries to modify the process b through the gdb program, a hook function of ptrace_ traceme is called, and the process b is modified or is protected from being modified according to a judging result.
Further alternatively, ptrace_ traceme is a request option for a ptrace () system call;
When a child process invokes ptrace_ traceme, ptrace_ traceme informs the operating system that the child process wishes to be tracked by its parent process, in which mode any signal received by the child process and other than SIGKILL causes it to stop executing and informs the parent process via the wait () function.
In a second aspect, the present invention provides a device for protecting a key process of a credit-invasive operating system, which solves the technical problems as follows:
An apparatus for protecting critical processes of an operating system of a credit, comprising:
the modification module is used for modifying signal processing logic in the signal processing function do_signal, and protecting the current process from being killed when the current process is a designated key process when the kill command is executed to kill the current process;
and the adding module is used for adding a hook function of the ptrace_ traceme, and protecting the malicious user from being modified when the current process is a designated key process when the malicious user tries to modify the current process through the gdb program.
Optionally, the modification module specifically includes:
the configuration submodule is used for configuring a key process list A and adding a unique identifier of a key process to be protected into the key process list A;
The logic modification submodule is configured to modify signal processing logic in the signal processing function do_signal, and specifically is: if the unique identifier of the current process appears in the key process list A and the signal is SIGKILL or SIGTERM, the SIGKILL signal or SIGTERM signal of the current process is ignored, otherwise, the current process is killed by calling a handle_signal function according to the original logic;
and the function calling submodule I is used for calling a signal processing function do_signal in a kernel mode when the kill process a of the kill command is executed, and the signal processing function do_signal kills the process a or protects the process a from being killed according to the signal processing logic.
Further optionally, after the concerned signal processing function do_signal calls the handle_signal function according to its signal processing logic, when process a runs in kernel state, the handle_signal function does not act immediately, and process a is killed until the user state is to be returned.
Optionally, the related add-on module specifically includes:
The configuration submodule is used for configuring a key process list B and adding a unique identifier of a key process to be protected into the key process list B;
the logic adding sub-module is used for adding a hook function of ptrace_ traceme by using the LSM framework, and the processing logic is as follows: when a malicious user tries to modify the current process through the gdb program, judging whether the current process is in a key process list, if so, refusing to modify the current process, and if not, allowing to modify the current process;
And a function calling sub-module II, which is used for calling the hook function of the ptrace_ traceme when the malicious user tries to modify the process b through the gdb program so as to modify the process b or protect the process b from being modified according to the judging result.
Further alternatively, the related ptrace_ traceme is a request option for a ptrace () system call;
When a child process invokes ptrace_ traceme, ptrace_ traceme informs the operating system that the child process wishes to be tracked by its parent process, in which mode any signal received by the child process and other than SIGKILL causes it to stop executing and informs the parent process via the wait () function.
Compared with the prior art, the method and the device for protecting the key process of the credit-invasive operating system have the beneficial effects that:
the invention realizes the purpose of protecting the key process from being killed by modifying the signal processing logic of the signal processing function do_signal in the kernel and ignoring the termination signal sent to the key process, and realizes the purpose of protecting the key process from being modified by realizing the ptrace_ traceme hook function in one LSM framework and maintains the normal operation of the key process.
Drawings
FIG. 1 is a block diagram of the interior of a modification module according to a second embodiment of the present invention;
Fig. 2 is a block diagram of the interior of an add-on module according to a second embodiment of the invention.
Detailed Description
In order to make the technical scheme, the technical problems to be solved and the technical effects of the invention more clear, the technical scheme of the invention is clearly and completely described below by combining specific embodiments.
The english words related to the following examples will now be explained:
1. The do_signal function is one of core functions for processing signals in the Linux kernel and is responsible for transmitting received signals to a target process. The main responsibilities of the do_signal function are as follows: ① Checking signal authority: before the signal is sent, the system will go through a series of checks by the send sig info () function. The bad signal () function is first called to confirm whether the sending process has permission to send the signal to the target process. Next, the system will call the ignored_signal () function to check if the target process has ignored the signal. ② Transmitting a signal: if the signal is not ignored, the system continues to execute the discover_signal () function to actually send the signal to the target process. The do_signal function plays a core role in this process, which updates the state of the target process, ensuring that the signal is properly passed and processed. ③ User state signal processing: when a signal needs to be processed by a signal processing function in the user state (e.g., by a custom processing function set by sigaction (), do_signal will schedule this signal processing function to be performed in the user state. This typically involves pushing the address of the signal processing function into the user stack and jumping to the user state to execute the function when the interrupt returns. ④ Interrupt processing: during the processing of a system call or a clock interrupt, if a new signal is detected to be processed, do_signal is called to process the signals. Before the interrupt handler exits, it examines the signal bitmap and calls do_signal to process the corresponding signal as needed.
2. SIGKILL and SIGTERM are two different signals used to send a termination signal to a process in a Unix-like operating system. Wherein: the SIGKILL signal number 9, which can force any process to terminate, regardless of the state the process is currently in, is used to terminate the process without giving the process any opportunity to clean or save work, possibly resulting in data loss or file system inconsistencies, due to the enforcement of SIGKILL; SIGTERM signal, which is the end of program signal, is numbered 15, SIGTERM can be captured and processed by the process. Overall SIGTERM allows the process the opportunity to clean up and gracefully exit, while SIGKILL is a forced termination process, giving no opportunity for any reaction by the process. In practice, it is common to first attempt to terminate a process using the SIGTERM signal, and if the process does not respond, then consider using the SIGKILL signal.
3. And the handle_signal function is used for processing signals sent by the operating system.
4. Ptrace _ traceme is a Linux system call used to set the current process to be trackable. When other processes attempt to trace the process using the ptrace system call, a signal (default SIGTRAP) is triggered to notify the tracker. To implement a hook function to handle ptrace_ traceme, the following steps can be generally used: ① Contains the necessary header files; ② Defining a signal processing function to be invoked upon receipt of SIGTRAP signals; ③ Performing the required operations in the signal processing function; ④ Correlating SIGTRAP signals with a signal processing function using a signal function; ⑤ The ptrace _ traceme function is called.
5. Gdb is a powerful debugging tool for debugging programs on Linux and Unix systems. It allows developers to check the internal state of a program, such as variable values, memory layout, etc., at runtime.
Embodiment one: the embodiment provides a method for protecting key processes of a credit-invasive operating system, which comprises the following two parts:
And (one) modifying signal processing logic in the signal processing function do_signal, and when the kill command is executed to kill the current process, protecting the current process from being killed when the current process is a designated key process.
The specific operation for realizing the steps is as follows:
(1.1) adding a unique identification of the critical process to be protected to the critical process list a;
(1.2) modifying the signal processing logic in the signal processing function do_signal: if the unique identifier of the current process appears in the key process list A and the signal is SIGKILL or SIGTERM, the SIGKILL signal or SIGTERM signal of the current process is ignored, otherwise, the current process is killed by calling a handle_signal function according to the original logic;
(1.3) when executing the kill command to kill the process a, calling a signal processing function do_signal in a kernel mode, wherein the signal processing function do_signal kills the process a or protects the process a from killing according to the signal processing logic.
It should be added that after the signal processing function do_signal calls the handle_signal function according to its signal processing logic, when the process a runs in the kernel state, the handle_signal function does not act immediately, and the process a is killed until the user state is to be returned.
The code portion to be modified involved in the signal processing function do_signal is:
A file: arm/kernel/signal. C
static int do_signal(struct pt_regs *regs, int syscall) {
......
If (get_signal (& ksig)) { # obtains the current signal
......
Handle_signal (& ksig, regs); logic can be added near where #: according to the judgment of the current process name of the current, if the current process is a key process, signal processing is not executed
}
......
}
And (II) adding a hook function of ptrace_ traceme, and when a malicious user tries to modify the current process through the gdb program, protecting the current process from being modified when the current process is a designated key process.
The specific operation for realizing the steps is as follows:
(2.1) adding a unique identification of the critical process to be protected to the critical process list B;
(2.2) adding a hook function of ptrace_ traceme using LSM framework, its processing logic is: when a malicious user tries to modify the current process through the gdb program, judging whether the current process is in a key process list B, if so, refusing to modify the current process, and if not, allowing to modify the current process;
(2.3) when the malicious user tries to modify the process b through the gdb program, the hook function of ptrace_ traceme is called, and the process b is modified or is protected from being modified according to the judgment result.
It should be added that the ptrace () system call is a tool of a debugging process provided by Linux, and is very powerful, and provides a very many debugging modes to let us debug a process, and the following is a definition of the ptrace () system call:
long ptrace(enum __ptrace_request request, pid_t pid, void *addr, void *data)；
the role of the various parameters of ptrace () is explained below:
request: instructions specifying debugging are of many types, such as: ptrace_ TRACEME, PTRACE _ PEEKUSER, PTRACE _cont, ptrace_ GETREGS, and so on.
Pid: the process ID being debugged.
Addr: a certain address space of a process may be read or written to by this parameter for a certain address of the process.
Data: other uses exist, depending on the particular instructions.
Ptrace_ traceme is a request option for a ptrace () system call;
When a child process invokes ptrace_ traceme, ptrace_ traceme informs the operating system that the child process wishes to be tracked by its parent process, in which mode any signal received by the child process and other than SIGKILL causes it to stop executing and informs the parent process via the wait () function.
The processing logic added in this step involves the following code:
static struct security_hook_list test_hooks[] __lsm_ro_after_init = {
LSM_HOOK_INIT(ptrace_traceme, test_ptrace_traceme),
};
static int test_ptrace_traceme(struct task_struct *parent)
{
The logic is added here: if it is a modification to a critical process, it is ignored
}
Embodiment two: with reference to fig. 1 and 2, this embodiment proposes a device for protecting key processes of a signal creation operating system, which includes:
the modification module is used for modifying signal processing logic in the signal processing function do_signal, and protecting the current process from being killed when the current process is a designated key process when the kill command is executed to kill the current process;
and the adding module is used for adding a hook function of the ptrace_ traceme, and protecting the malicious user from being modified when the current process is a designated key process when the malicious user tries to modify the current process through the gdb program.
In this embodiment, the modification module specifically includes:
the configuration submodule is used for configuring a key process list A and adding a unique identifier of a key process to be protected into the key process list A;
The logic modification submodule is configured to modify signal processing logic in the signal processing function do_signal, and specifically is: if the unique identifier of the current process appears in the key process list A and the signal is SIGKILL or SIGTERM, the SIGKILL signal or SIGTERM signal of the current process is ignored, otherwise, the current process is killed by calling a handle_signal function according to the original logic;
and the function calling submodule I is used for calling a signal processing function do_signal in a kernel mode when the kill process a of the kill command is executed, and the signal processing function do_signal kills the process a or protects the process a from being killed according to the signal processing logic.
It should be added that after the signal processing function do_signal calls the handle_signal function according to its signal processing logic, when the process a runs in the kernel state, the handle_signal function does not act immediately, and the process a is killed until the user state is to be returned.
The logic modification submodule modifies the code part to be modified, which is involved in the signal processing function do_signal, as follows:
A file: arm/kernel/signal. C
static int do_signal(struct pt_regs *regs, int syscall) {
......
If (get_signal (& ksig)) { # obtains the current signal
......
Handle_signal (& ksig, regs); logic can be added near where #: according to the judgment of the current process name of the current, if the current process is a key process, signal processing is not executed
}
......
}
In this embodiment, the related add-on module specifically includes:
The configuration submodule is used for configuring a key process list B and adding a unique identifier of a key process to be protected into the key process list B;
the logic adding sub-module is used for adding a hook function of ptrace_ traceme by using the LSM framework, and the processing logic is as follows: when a malicious user tries to modify the current process through the gdb program, judging whether the current process is in a key process list, if so, refusing to modify the current process, and if not, allowing to modify the current process;
And a function calling sub-module II, which is used for calling the hook function of the ptrace_ traceme when the malicious user tries to modify the process b through the gdb program so as to modify the process b or protect the process b from being modified according to the judging result.
It should be added that the ptrace () system call is a tool of a debugging process provided by Linux, and is very powerful, and provides a very many debugging modes to let us debug a process, and the following is a definition of the ptrace () system call:
long ptrace(enum __ptrace_request request, pid_t pid, void *addr, void *data)；
the role of the various parameters of ptrace () is explained below:
request: instructions specifying debugging are of many types, such as: ptrace_ TRACEME, PTRACE _ PEEKUSER, PTRACE _cont, ptrace_ GETREGS, and so on.
Pid: the process ID being debugged.
Addr: a certain address space of a process may be read or written to by this parameter for a certain address of the process.
Data: other uses exist, depending on the particular instructions.
Ptrace_ traceme is a request option for a ptrace () system call;
When a child process invokes ptrace_ traceme, ptrace_ traceme informs the operating system that the child process wishes to be tracked by its parent process, in which mode any signal received by the child process and other than SIGKILL causes it to stop executing and informs the parent process via the wait () function.
The processing logic added by the logic adding submodule in the step relates to the following codes:
static struct security_hook_list test_hooks[] __lsm_ro_after_init = {
LSM_HOOK_INIT(ptrace_traceme, test_ptrace_traceme),
};
static int test_ptrace_traceme(struct task_struct *parent)
{
The logic is added here: if it is a modification to a critical process, it is ignored
}
In summary, the method and the device for protecting the key process of the credit-created operating system can protect the key process from being killed and modified and destroyed after the system is invaded, and maintain the normal operation of the key process.
The foregoing has outlined rather broadly the principles and embodiments of the present invention in order that the detailed description of the invention may be better understood. Based on the above-mentioned embodiments of the present invention, any improvements and modifications made by those skilled in the art without departing from the principles of the present invention should fall within the scope of the present invention.
Claims (10)
1. A method for protecting key processes of a credit-invasive operating system is characterized by comprising the following two parts:
Step one, modifying signal processing logic in a signal processing function do_signal, and when a kill command is executed to kill a current process, protecting the current process from being killed when the current process is a designated key process;
And step two, adding a hook function of ptrace_ traceme, and protecting the malicious user from being modified when the current process is a designated key process when the malicious user tries to modify the current process through the gdb program.
2. The method of claim 1, wherein the step one is performed to protect against killing the critical process, as follows:
step 1, adding a unique identifier of a key process to be protected to a key process list A;
Step 2, modifying the signal processing logic in the signal processing function do_signal: if the unique identifier of the current process appears in the key process list A and the signal is SIGKILL or SIGTERM, the SIGKILL signal or SIGTERM signal of the current process is ignored, otherwise, the current process is killed by calling a handle_signal function according to the original logic;
And 3, when the kill command process a is executed, calling a signal processing function do_signal in a kernel mode, wherein the signal processing function do_signal kills the process a or protects the process a from being killed according to the signal processing logic.
3. A method of protecting critical processes of a signal-generating operating system according to claim 2, characterized in that after the signal processing function do_signal calls the handle_signal function according to its signal processing logic, the handle_signal function does not act immediately when process a is running in kernel mode, and process a is not killed until it is about to return to user mode.
4. The method of claim 1, wherein the step two is performed, and the specific operation of protecting the process from modification is as follows:
step 1, adding a unique identifier of a key process to be protected to a key process list B;
Step 2, adding a hook function of ptrace_ traceme by using the LSM framework, and processing logic of the hook function is as follows: when a malicious user tries to modify the current process through the gdb program, judging whether the current process is in a key process list B, if so, refusing to modify the current process, and if not, allowing to modify the current process;
and 3, when a malicious user tries to modify the process b through the gdb program, calling a hook function of the ptrace_ traceme, and modifying the process b or protecting the process b from modification according to a judging result.
5. The method of claim 4, wherein ptrace_ traceme is a request option for a ptrace () system call;
When a child process invokes ptrace_ traceme, ptrace_ traceme informs the operating system that the child process wishes to be tracked by its parent process, in which mode any signal received by the child process and other than SIGKILL causes it to stop executing and informs the parent process via the wait () function.
6. An apparatus for protecting critical processes of a trusted operating system, comprising:
the modification module is used for modifying signal processing logic in the signal processing function do_signal, and protecting the current process from being killed when the current process is a designated key process when the kill command is executed to kill the current process;
and the adding module is used for adding a hook function of the ptrace_ traceme, and protecting the malicious user from being modified when the current process is a designated key process when the malicious user tries to modify the current process through the gdb program.
7. The apparatus for protecting critical processes of a trusted operating system of claim 6, wherein said modification module specifically comprises:
the configuration submodule is used for configuring a key process list A and adding a unique identifier of a key process to be protected into the key process list A;
The logic modification submodule is configured to modify signal processing logic in the signal processing function do_signal, and specifically is: if the unique identifier of the current process appears in the key process list A and the signal is SIGKILL or SIGTERM, the SIGKILL signal or SIGTERM signal of the current process is ignored, otherwise, the current process is killed by calling a handle_signal function according to the original logic;
and the function calling submodule I is used for calling a signal processing function do_signal in a kernel mode when the kill process a of the kill command is executed, and the signal processing function do_signal kills the process a or protects the process a from being killed according to the signal processing logic.
8. The apparatus of claim 7, wherein after the signal processing function do_signal calls the handle_signal function according to its signal processing logic, when the process a is running in kernel mode, the handle_signal function does not act immediately, and the process a is killed until the user mode is to be returned.
9. The apparatus for protecting critical processes of a credit-invasive operating system according to claim 6, wherein the add-on module specifically comprises:
The configuration submodule is used for configuring a key process list B and adding a unique identifier of a key process to be protected into the key process list B;
the logic adding sub-module is used for adding a hook function of ptrace_ traceme by using the LSM framework, and the processing logic is as follows: when a malicious user tries to modify the current process through the gdb program, judging whether the current process is in a key process list, if so, refusing to modify the current process, and if not, allowing to modify the current process;
And a function calling sub-module II, which is used for calling the hook function of the ptrace_ traceme when the malicious user tries to modify the process b through the gdb program so as to modify the process b or protect the process b from being modified according to the judging result.
10. An apparatus for protecting a critical process of an information-oriented operating system as described in claim 9, wherein said ptrace_ traceme is a request option for a ptrace () system call;
When a child process invokes ptrace_ traceme, ptrace_ traceme informs the operating system that the child process wishes to be tracked by its parent process, in which mode any signal received by the child process and other than SIGKILL causes it to stop executing and informs the parent process via the wait () function.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202410564895.5A CN118153040A (en) | 2024-05-09 | 2024-05-09 | Method and device for protecting key process of credit-invasive operating system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202410564895.5A CN118153040A (en) | 2024-05-09 | 2024-05-09 | Method and device for protecting key process of credit-invasive operating system |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN118153040A true CN118153040A (en) | 2024-06-07 |
Family
ID=91293330
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202410564895.5A Pending CN118153040A (en) | 2024-05-09 | 2024-05-09 | Method and device for protecting key process of credit-invasive operating system |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN118153040A (en) |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR20020040482A (en) * | 2000-11-24 | 2002-05-30 | 구자홍 | System and Method of Protecting Process |
| CN106682493A (en) * | 2015-11-06 | 2017-05-17 | 珠海市君天电子科技有限公司 | Method and device for preventing process from being maliciously ended and electronic equipment |
| CN116226861A (en) * | 2022-12-29 | 2023-06-06 | 天翼云科技有限公司 | Linux system process self-protection method and system |
-
2024
- 2024-05-09 CN CN202410564895.5A patent/CN118153040A/en active Pending
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR20020040482A (en) * | 2000-11-24 | 2002-05-30 | 구자홍 | System and Method of Protecting Process |
| CN106682493A (en) * | 2015-11-06 | 2017-05-17 | 珠海市君天电子科技有限公司 | Method and device for preventing process from being maliciously ended and electronic equipment |
| CN116226861A (en) * | 2022-12-29 | 2023-06-06 | 天翼云科技有限公司 | Linux system process self-protection method and system |
Non-Patent Citations (3)
| Title |
|---|
| 李 萍: "Android应用防篡改机制的研究", 《天津中德职业技术学院学报》, 15 October 2015 (2015-10-15), pages 67 - 70 * |
| 李霞, 郭井龙, 吕荣耀: "Linux中的几种安全防护技术", 信息工程大学学报, no. 01, 30 March 2004 (2004-03-30), pages 63 - 66 * |
| 王兴泉: "移动电子商务时代的信息安全与信息保护", 《兰州学刊》, 31 December 2014 (2014-12-31), pages 175 - 180 * |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7530103B2 (en) | Projection of trustworthiness from a trusted environment to an untrusted environment | |
| US7607041B2 (en) | Methods and apparatus providing recovery from computer and network security attacks | |
| US8595170B2 (en) | Stateful reference monitor | |
| US7665139B1 (en) | Method and apparatus to detect and prevent malicious changes to tokens | |
| JP5054768B2 (en) | Method and apparatus for intrusion detection | |
| US7293251B2 (en) | Initiating and debugging a process in a high assurance execution environment | |
| EP1628222A2 (en) | Software operation monitoring apparatus and software operation monitoring method | |
| CN113569244B (en) | Memory malicious code detection method based on processor tracking | |
| WO2015066454A1 (en) | Virtual machine introspection facilities | |
| CN105408911A (en) | Hardware and software execution profiling | |
| Biggs et al. | The jury is in: Monolithic os design is flawed: Microkernel-based designs improve security | |
| CN109446799B (en) | Memory data protection method, security component, computer equipment and storage medium | |
| CN113051034A (en) | Container access control method and system based on kprobes | |
| US20240143739A1 (en) | Intelligent obfuscation of mobile applications | |
| KR19990036567A (en) | Method and system to prevent unauthorized access to computer program | |
| Filho et al. | Evasion and countermeasures techniques to detect dynamic binary instrumentation frameworks | |
| Biggs et al. | The jury is in: Monolithic OS design is flawed | |
| CN118153040A (en) | Method and device for protecting key process of credit-invasive operating system | |
| CN116956272A (en) | Authority calling monitoring method and device and electronic equipment | |
| EP1944676A1 (en) | Stateful reference monitor | |
| CN112214757B (en) | Terminal registry security protection method and system based on windows driving technology | |
| WO2023029835A1 (en) | Method for protecting kernel thread, and terminal and computer readable storage medium | |
| CN112395599B (en) | Attack detection method and device for system kernel data, storage medium and computer equipment | |
| Zhang et al. | A Dynamic Trust Chain Measurement Method Based on Mixed Granularity of Call Sequence | |
| CN115935341A (en) | Vulnerability defense method, system, server and storage medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination |