Software security protection method and device for system kernel layer, equipment and storage medium

Abstract

The invention discloses a software security protection method and device for a system kernel layer, equipment and a storage medium, and relates to the technical field of computer security. The method comprises the steps of obtaining kernel mode event data in a system starting stage; matching the kernel mode event data with a preset behavior baseline to obtain an abnormal event; performing risk assessment according to the abnormal event to obtain a risk level; and performing hierarchical protection on a process corresponding to the abnormal event according to the risk level.

Description

Technical Field

[0001] This application relates to the technical field of computer security, and in particular to a software security protection method, apparatus, device, and storage medium for the system kernel layer. Background Technology

[0002] With the rapid development of the mobile internet, the security of Android, as a mainstream mobile operating system, is of paramount importance. Android's security architecture largely relies on security mechanisms provided by its underlying Linux kernel, such as the sandbox mechanism of the SELinux mandatory access control framework. However, with the continuous evolution of attack techniques, the system kernel layer is becoming a weak link in security protection and a key entry point for attackers. Current solutions reveal several shortcomings when facing new types of attacks: First, traditional security monitoring methods have limitations. User-space auditing tools struggle to capture malicious behavior at the kernel level in real time and comprehensively; while intrusive modifications to the kernel source code to implant monitoring points pose risks of poor compatibility, maintenance difficulties, and system instability. This makes it difficult to detect and prevent kernel-level attacks targeting Linux kernel vulnerabilities in a timely manner. Second, existing core security strategies mostly adopt preset global static policies. This "one-size-fits-all" approach lacks adaptability and precision when facing the dynamic behavior of core system processes. Finally, existing protection mechanisms typically employ a black-and-white binary decision-making model, lacking the ability to assess and handle security incidents.

[0003] Therefore, improving the security protection capabilities of the system kernel layer is an urgent problem that needs to be solved. Summary of the Invention

[0004] The main purpose of this application is to provide a method, apparatus, device and storage medium for software security protection at the system kernel layer, aiming to solve the technical problem of how to improve the security protection capability of the system kernel layer.

[0005] To achieve the above objectives, this application proposes a software security protection method at the system kernel layer, the method comprising: During the system startup phase, kernel-mode event data is acquired; The kernel-mode event data is matched with a preset behavior baseline to obtain abnormal events; Risk assessment is conducted based on abnormal events to determine the risk level; The processes corresponding to abnormal events are protected in layers according to their risk levels.

[0006] In one embodiment, the step of acquiring kernel-mode event data during the system startup phase includes: During the system startup phase, the extended Berkeley packet filter is loaded into kernel mode, and the hook point is invoked to mount the extended Berkeley packet filter. Kernel-mode event data is collected through an extended Berkeley package filter. This kernel-mode event data includes at least system call parameters, calling process identifiers, and permission change records.

[0007] Furthermore, to achieve the above objectives, this application also proposes a software security protection device for the system kernel layer, the device comprising: The data monitoring module is used to acquire kernel-mode event data during the system startup phase; The anomaly monitoring module is used to match kernel-mode event data with a preset behavior baseline to obtain anomaly events; The risk assessment module is used to assess risks based on abnormal events and obtain risk levels. The layered protection module is used to provide layered protection for processes corresponding to abnormal events based on their risk levels.

[0008] In addition, to achieve the above objectives, this application also proposes a system kernel layer software security protection device, the device including: a memory, a processor, and a computer program stored on the memory and executable on the processor, the computer program being configured to implement the steps of the system kernel layer software security protection method described above.

[0009] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the software security protection method of the system kernel layer as described above.

[0010] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the software security protection method for the system kernel layer as described above. Attached Figure Description

[0011] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0012] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0013] Figure 1This is a flowchart illustrating the first embodiment of the software security protection method for the system kernel layer of this application. Figure 2 This is a flowchart illustrating the second embodiment of the software security protection method for the system kernel layer in this application. Figure 3 This is a flowchart illustrating the third embodiment of the software security protection method for the system kernel layer in this application. Figure 4 This is a schematic diagram of the overall process framework of the software security protection method for the kernel layer of the system in this application; Figure 5 This is a schematic diagram of the module structure of the software security protection device at the system kernel layer in an embodiment of this application; Figure 6 This is a schematic diagram of the device structure of the hardware operating environment involved in the software security protection method of the system kernel layer in this application embodiment.

[0014] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0015] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0016] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0017] The main solution of this application embodiment is: during the system startup phase, kernel-mode event data is acquired; the kernel-mode event data is matched with a preset behavior baseline to obtain abnormal events; risk assessment is performed based on the abnormal events to obtain risk levels; and layered protection is applied to the processes corresponding to the abnormal events based on the risk levels.

[0018] With the rapid development of the mobile internet, the security of Android, as a mainstream mobile operating system, is of paramount importance. Android's security architecture largely relies on security mechanisms provided by its underlying Linux kernel, such as the sandbox mechanism of the SELinux access control framework. However, with the continuous evolution of attack techniques, the system kernel layer is becoming a weak link in security protection and a key entry point for attackers. Current solutions reveal several shortcomings when facing new types of attacks: First, traditional security monitoring methods have limitations. User-space auditing tools struggle to capture malicious behavior at the kernel level in real time and comprehensively; while intrusive modifications to the kernel source code to implant monitoring points pose risks of poor compatibility, maintenance difficulties, and system instability. This makes it difficult to detect and prevent kernel-level attacks targeting Linux kernel vulnerabilities in a timely manner. Second, existing core security strategies mostly adopt preset global static policies. This "one-size-fits-all" approach lacks adaptability and precision when facing the dynamic behavior of core system processes. Finally, existing protection mechanisms typically employ a black-and-white binary decision-making model, lacking the ability to assess and handle security incidents. Therefore, improving the security protection capabilities of the system kernel layer is a pressing issue that needs to be addressed.

[0019] This application effectively captures kernel-level attacks that are difficult for traditional tools to detect by implementing non-intrusive real-time monitoring and establishing dynamic behavior baselines at the kernel level. It achieves a balance between precise protection and system functionality, and improves the accuracy and adaptability of security protection at the system kernel level through risk-layered protection.

[0020] It should be noted that the executing entity in this embodiment can be a software security protection system at the system kernel layer, or a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an electronic device capable of implementing the aforementioned software security protection functions at the system kernel layer. This embodiment does not specifically limit it in this way. The following uses a software security protection system at the system kernel layer as an example to describe this embodiment and the following embodiments.

[0021] Based on this, embodiments of this application provide a software security protection method for the system kernel layer, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the software security protection method for the kernel layer of the system in this application.

[0022] In this embodiment, the software security protection method at the system kernel layer includes steps S10 to S40: Step S10: During the system startup phase, acquire kernel-mode event data.

[0023] It should be noted that the method used in this application to obtain kernel-mode event data differs from the methods typically used for post-event auditing with user-mode tools or intrusive monitoring that requires modification of the kernel source code. Kernel-mode event data refers to event information such as system calls, process behaviors, and permission changes generated during kernel operation. It is understandable that by directly monitoring at the kernel level, the latency and blind spots of traditional user-mode tools (such as strace) can be avoided, and kernel-level attack behaviors (such as unauthorized kernel module loading) can be captured.

[0024] In one feasible implementation, step S10 specifically includes: Step S101: During the system startup phase, the extended Berkeley packet filter is loaded into kernel mode, and the hook point is invoked to mount the extended Berkeley packet filter.

[0025] It should be noted that during the initial startup phase (such as the Android system initialization phase), the system automatically loads the eBPF (Extended Berkeley Package) program into kernel mode and attaches the eBPF program through system call hook points. This step enables non-intrusive kernel monitoring, allowing real-time capture of critical process behavior without modifying the kernel source code.

[0026] Step S102: Collect kernel-mode event data through the extended Berkeley package filter program, wherein the kernel-mode event data includes at least system call parameters, calling process identifiers, and permission change records.

[0027] It should be noted that the system directly captures event data in kernel space via the eBPF (Extended Berkeley Package) program, including system call parameters (such as syscall parameters), the identifier of the calling process (the calling process's PID), and permission change records. Kernel-space event data is then efficiently transmitted to user-space security analysis services (such as secured) via a ring buffer, ensuring low latency and high throughput.

[0028] Additionally, it should be noted that the ring buffer is a circular buffer mechanism used for efficient data exchange between kernel mode and user mode, avoiding data loss and performance bottlenecks.

[0029] In one possible implementation, before step S20, the method further includes: Step A10: Initialize the baseline database. The baseline database stores the legal behavior rules of the core processes, which include the initialization process, the incubation process, and the service manager process.

[0030] It should be noted that the system initializes a baseline database (such as stored in / data / security / baseline.db) during startup. This database predefines the legal behavior rules for core processes such as the initiator process, the Zygote process, and the service manager process. These rules include the whitelist of child processes of the initiator process, the baseline of the system call sequence of the Zygote process, and the permission scope of the service manager.

[0031] Additionally, it should be noted that the initialization process (init) is the root process of the Android system, responsible for starting system services; the incubation process (Zygote) is the parent process of application processes, used to quickly incubate application instances; and the service manager process (servicemanager) is responsible for the management of system services and access control.

[0032] Step A20: Load the legal behavior rules into the core process to obtain the preset behavior baseline, which includes: the whitelist of child processes defined for the initialization process, the legal system call sequence baseline established for the incubation process, and the permission scope limited for the service manager process.

[0033] It's important to note that in this step, the system instantiates the rule templates in the database into executable behavioral baselines for each specific process. For example, it loads a unique whitelist of child processes (allowing only predefined processes like ueventd and logd) for the currently running init process; it loads a typical legal system call sequence baseline for the Zygote process, such as clone→mmap→execve; and it loads the permission scope for the servicemanager process (retaining only necessary permissions like CAP_IPC_OWNER). Furthermore, when the system is upgraded or a new service is added, the system automatically scans and updates the baseline rules to ensure continuous policy adaptation.

[0034] Understandably, the purpose of this step is to enable fine-grained, personalized process behavior management, avoiding the one-size-fits-all problem of traditional global static strategies and improving adaptability.

[0035] Step S20: Match the kernel-mode event data with the preset behavior baseline to obtain the abnormal event.

[0036] It should be noted that the preset behavior baseline is a set of rules built upon the historical legitimate behavior of core processes, including process creation, system call sequences, and permission ranges. This step is understood to identify kernel events that deviate from normal behavior patterns, improving detection accuracy through dynamic baseline matching. Traditional static strategies (such as SELinux) cannot adapt to behavior changes caused by system upgrades or the addition of new services, while this step, through real-time comparison and baseline updates, solves the problems of false positives and false negatives.

[0037] In one feasible implementation, step S20 specifically includes: Step S201: Compare the system call parameters, calling process identifiers, and permission change records in the kernel-mode event data with the initialization child process whitelist, legal system call sequence baseline, and permission allowable range in the preset behavior baseline, and obtain the comparison results.

[0038] It should be noted that in this step, the system parses each kernel event through the security service `securityd`. For example, if the event is a `sys_clone` (creating a child process) initiated by the `init` process, it checks whether the name of the newly created child process is in its child process whitelist; if the event is a system call sequence initiated by the `Zygote` process, it checks whether the sequence conforms to the predefined baseline pattern of legal system call sequences; if the event is a permission modification initiated by the `servicemanager` process, it audits whether the changes to `servicemanager`'s capabilities are within the allowed scope.

[0039] Step S202: If any item in the preset behavior baseline does not match the system call parameters, calling process identifier, and permission change record in the kernel-mode event data, the kernel-mode event data is marked as an abnormal event.

[0040] It should be noted that if any comparison in step S201 fails (for example, if init creates a child process that is not in the whitelist), the event will be marked as an abnormal event and proceed to the next risk assessment module.

[0041] Step S30: Conduct a risk assessment based on the abnormal event to obtain the risk level.

[0042] It's important to note that in this step, the system performs a quantitative assessment of the marked abnormal events. The assessment module determines the risk level of the current abnormal event (e.g., high risk, medium risk, low risk) based on the type of the abnormal event, the sensitivity of the resources attempted to be accessed, and the current privilege level of the process. Understandably, the purpose of this step is to provide a basis for subsequent response decisions, enabling intelligent responses rather than simple binary judgments.

[0043] Additionally, it should be noted that the risk level is a dynamically calculated indicator. For example, events involving loading kernel modules (finit_module) or obtaining CAP_SYS_ADMIN privileges will be assessed as high risk, while events involving access to sensitive devices can be assessed as medium risk.

[0044] Step S40: Implement layered protection for processes corresponding to abnormal events based on risk level.

[0045] It should be noted that this step is the final protection response execution phase. Based on the risk level determined in step S30, the system will take different levels of interception measures, forming a layered proactive defense system. Its core objective is to maximize system availability while ensuring security, avoiding system malfunctions due to over-protection. Furthermore, it should be noted that layered protection refers to a progressive security response mechanism that adopts the most appropriate handling method (such as tiered interception) for different levels of threats, rather than a single-minded blocking approach.

[0046] This embodiment provides a software security protection method for the system kernel layer. The method includes: acquiring kernel-mode event data during system startup; matching the kernel-mode event data with a preset behavioral baseline to obtain abnormal events; performing risk assessment based on the abnormal events to obtain risk levels; and implementing layered protection for the processes corresponding to the abnormal events based on the risk levels. In summary, this embodiment effectively captures kernel-level attacks that are difficult for traditional tools to detect by implementing non-intrusive real-time monitoring and establishing dynamic behavioral baselines at the kernel layer. It achieves a balance between precise protection and system functionality, and improves the accuracy and adaptability of security protection at the system kernel layer through risk-layered protection.

[0047] Based on the first embodiment of this application, in the second embodiment of this application, the content that is the same as or similar to that in Embodiment 1 above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 2 , Figure 2 This is a flowchart illustrating the second embodiment of the software security protection method for the system kernel layer of this application. Step S30 specifically includes: Step S301: parse the exception event to obtain the event type, scope of impact, and calling permissions of the exception event.

[0048] It should be noted that in this step, the system's security analysis service (securityd) parses the event data marked as anomalous and extracts three key evaluation dimensions: Event type, which identifies the specific type of anomalous behavior, such as process creation, abnormal system call sequence, permission change, or kernel module operation; Scope of impact, which assesses the range of system resources that the anomalous behavior may affect, such as affecting only a single process, involving multiple user data, or potentially compromising the integrity of the entire kernel; and Call permissions, which analyzes the kernel capabilities that the process that triggered the anomalous behavior possesses or is requesting.

[0049] Step S302: When the event type is kernel module loading type or first privilege escalation type, determine the risk level of the abnormal event as the first risk level.

[0050] It's important to note that kernel module loading types refer to actions such as loading kernel modules via the `finit_module` system call. Illegal kernel module loading (such as LKM) can bypass all system security mechanisms. First privilege escalation types refer to core privilege changes that fundamentally impact the system's overall stability and security. Examples include acquiring or using privileges such as `CAP_SYS_ADMIN` (approximately root privileges) or altering core privileges. Specifically, when the resolved event type is a kernel module loading type or a first privilege escalation type, the system will directly classify it as the highest risk level, i.e., first risk level (high risk).

[0051] Step S303: When the event type is sensitive device access type, determine the risk level of the abnormal event as the second risk level.

[0052] It's important to note that sensitive devices refer to special files created within the kernel that allow direct interaction with hardware or kernel core data structures. Accessing these devices typically requires higher privileges. Specifically, when an event involves access to a sensitive device (i.e., a sensitive system resource) (such as / dev / mem memory), but does not yet grant direct kernel-level code execution or complete control, the system classifies it as a second-level risk (medium risk). Such behavior is potentially dangerous, but the consequences are usually manageable.

[0053] Step S304: When the event type is a non-target resource access type or a second permission change type, determine the risk level of the abnormal event as the third risk level, wherein the first permission is greater than the second permission, the first risk level is greater than the second risk level, and the second risk level is greater than the third risk level.

[0054] It should be noted that non-target resource access refers to actions such as accessing non-critical ordinary files or network resources. Second-level permission change refers to system permission changes with a far less significant impact than first-level permissions. Specifically, when the event type is non-target resource access or a second-level permission change (i.e., a low-threat behavior), the system will classify it as a third-level risk (low-risk) event. These types of actions usually do not immediately lead to system compromise, but they serve as potential risk signals and need to be recorded and monitored.

[0055] Additionally, it should be noted that the first risk level (high risk), the second risk level (medium risk), and the third risk level (low risk) constitute an assessment system with progressively decreasing risk. This system forms the basis for implementing subsequent layered interception strategies, ensuring the accuracy and intelligence of security responses.

[0056] In this embodiment, by dynamically parsing the event type, scope of impact, and calling permissions of abnormal events to automatically assess the risk level, a layered proactive interception strategy based on different risks is realized. This solves the problem of excessive blocking or lagging protection caused by the binary decision-making of traditional security mechanisms, and improves the accuracy of kernel-level security protection and the availability of the system.

[0057] Based on the first and second embodiments of this application, in the third embodiment of this application, the content that is the same as or similar to that in embodiments one and two above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 3 , Figure 3 This is a flowchart illustrating the third embodiment of the software security protection method for the system kernel layer of this application. Step S40 specifically includes: Step S401: When the risk level is the third risk level, write the abnormal event to the security log and continuously monitor the process corresponding to the abnormal event.

[0058] It should be noted that, as Figure 4 As shown, when an abnormal event is assessed as level three (i.e., low risk), the system will take the lightest level of protection. The security analysis service (securityd) will record detailed information about the event (such as timestamp, process PID, description of abnormal behavior, etc.) in a designated security log file and initiate an enhanced behavior monitoring process for the process. For example, when a system service process is abnormally assessed as level three risk, the system will not immediately block the process's operation, but will record this unauthorized behavior and focus on monitoring file operations initiated by the process for a period of time. If its behavior returns to normal, the monitoring will be lifted; if the abnormality recurs, its risk level may be increased.

[0059] Additionally, it should be noted that continuous monitoring refers to increasing the frequency of collecting and analyzing kernel events related to the process within a preset time window, or comparing some of its behaviors (such as subsequent system calls) with stricter baseline rules to achieve early detection of potential threats.

[0060] Step S402: When the risk level is the second risk level, call the namespace isolation interface to isolate the process corresponding to the abnormal event to a restricted namespace and prohibit the process corresponding to the abnormal event from accessing the preset target device.

[0061] It should be noted that, as Figure 4 As shown, when an abnormal event is assessed as level two risk (i.e., medium risk), the system employs a policy sandbox for isolation protection. The security analysis service (securityd) calls the namespace API provided by the Linux kernel (e.g., unshare(CLONE_NEWNS)) to create a new, restricted mount namespace for the abnormal process. Within this sandbox environment, the system remounts the file system, thereby hiding or making pre-defined sensitive devices inaccessible from the process's view.

[0062] Step S403: When the risk level is the first risk level, call the interception interface to block the system call of the process corresponding to the abnormal event, or send a termination signal to the kernel to terminate the process corresponding to the abnormal event, and roll back the permission changes of the process corresponding to the abnormal event.

[0063] It should be noted that, as Figure 4 As shown, when an abnormal event is assessed as being at the highest risk level (i.e., high risk), the system will take the most stringent immediate blocking and remediation measures. The security analysis service (securityd) will intercept the process in one of two ways: (1) by calling the kernel's interception interface (such as the seccomp filter) to directly refuse to execute the currently dangerous system call; (2) by sending a termination signal such as SIGKILL to the kernel to immediately terminate the entire abnormal process. At the same time, the system will perform a privilege rollback operation, that is, by calling methods such as capset() to revoke the illegally elevated privileges of the process and restore it to its original privilege state.

[0064] Additionally, it should be noted that rolling back permission changes is a proactive remediation process designed to eliminate some of the impact caused by the attack and restore the system's permission state to its original state before the damage, thereby achieving a closed-loop security for post-incident repair.

[0065] In one possible implementation, after step S40, the method further includes: Step S50: Read security logs and interception records according to a preset cycle, and calculate the false positive rate and attack frequency of abnormal events.

[0066] It should be noted that in this step, the system's security analysis service (securityd) will periodically (e.g., every 24 hours) or automatically trigger an analysis task when a surge of abnormal events is detected. This task reads and analyzes the security logs stored in / var / log / security.log and a dedicated intercept record database, and uses data mining algorithms to statistically analyze two key metrics: first, the false positive rate, which is the proportion of events marked as abnormal but later confirmed as legitimate system behavior; and second, the attack frequency, which is the number of times the same type of high-risk abnormal event occurs per unit of time.

[0067] Additionally, it should be noted that the preset cycle can be configured and adjusted by the system administrator according to actual needs (such as setting it to hourly, daily, weekly, or real-time triggering) to achieve a flexible policy update rhythm. The interception log is a structured database that not only records the interception action itself, but also associates it with detailed information about the abnormal event that triggered the interception (such as event type, process, risk level, etc.) to facilitate trend analysis.

[0068] Step S60: When the risk level of an abnormal event is lower than the preset security risk level and the attack frequency is higher than the preset frequency, add the abnormal event to the child process whitelist.

[0069] It should be noted that this step is used to resolve false blocking issues caused by legitimate changes in the system environment (such as system upgrades or the installation of new applications). Specifically, when analysis reveals that an abnormal event consistently falls below the third risk level (low risk) and occurs more frequently than a preset frequency, the system can determine that this behavior is likely a new, normal, legitimate behavior not yet included in the baseline database. In this case, the system will automatically add this behavior characteristic to the whitelist of the corresponding core process's child processes or other relevant legitimate behavior baselines.

[0070] Step S70: When the risk level of an abnormal event is the first risk level and the attack frequency is higher than the preset frequency, reduce the risk judgment threshold of the abnormal event.

[0071] It should be noted that when the system detects an anomaly with a risk level of Level 1 (high risk) and its frequency is higher than the preset frequency, it indicates that the system is in the active phase of that attack pattern. To defend earlier and more proactively, the system will lower the risk assessment threshold for such events. Therefore, even if similar attacks occur in the future, they may be identified and judged as high risk in advance because they have reached the new, more sensitive threshold, thus triggering high-risk interception measures.

[0072] Step S80: When the false positive rate is higher than the preset false positive rate, increase the risk judgment threshold for abnormal events.

[0073] It's important to note that the preset false positive rate is a configuration parameter used to balance security and availability, set by the system administrator based on the actual scenario. Increasing the risk assessment threshold means the system's tolerance for such abnormal behavior increases. Specifically, when the false positive rate for a certain type of event exceeds the system's acceptable upper limit (i.e., the preset false positive rate), it indicates that the current judgment rules are too stringent. To reduce unnecessary security interception from interfering with normal functionality, the system will increase the risk assessment threshold for that type of event. This ensures that only more threatening and typical malicious behaviors will be judged as high-risk in the future, while some ambiguous borderline behaviors will be downgraded or treated as normal.

[0074] In this embodiment, by implementing a three-level risk-layered interception strategy (log monitoring, process isolation, and forced termination) and a subsequent strategy self-optimization mechanism (dynamically adjusting the whitelist and risk threshold based on the false positive rate and attack frequency), dynamic and precise protection against abnormal events at the kernel level is achieved. This solves the problems of false positives, false negatives, or abnormal system functions caused by static binary decision-making in traditional security mechanisms, and improves the accuracy of kernel-level security protection and the availability of the system.

[0075] This application also provides a software security protection device at the system kernel level; please refer to [reference needed]. Figure 5 The system kernel layer software security protection devices include: Data monitoring module 10 is used to acquire kernel-mode event data during the system startup phase; The anomaly monitoring module 20 is used to match kernel-mode event data with a preset behavior baseline to obtain anomaly events; Risk assessment module 30 is used to conduct risk assessments based on abnormal events and obtain risk levels; The layered protection module 40 is used to provide layered protection for processes corresponding to abnormal events based on risk levels.

[0076] The system kernel layer software security protection device provided in this application, employing the system kernel layer software security protection method described in the above embodiments, can solve the technical problem of how to improve the security protection capability of the system kernel layer. Compared with the prior art, the beneficial effects of the system kernel layer software security protection device provided in this application are the same as those of the system kernel layer software security protection method described in the above embodiments, and other technical features in the system kernel layer software security protection device are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0077] In one embodiment, the data monitoring module 10 is further configured to load the extended Berkeley packet filter into kernel mode during the system startup phase, and call the hook point to mount the extended Berkeley packet filter; collect kernel mode event data through the extended Berkeley packet filter, wherein the kernel mode event data includes at least system call parameters, calling process identifiers, and permission change records.

[0078] In one embodiment, the anomaly monitoring module 20 is further configured to initialize a baseline database, which stores the legal behavior rules of the core processes, including the initialization process, the incubation process, and the service manager process; and load the legal behavior rules into the core processes to obtain a preset behavior baseline, which includes: a whitelist of child processes defined for the initialization process, a legal system call sequence baseline established for the incubation process, and a permission range limited for the service manager process.

[0079] In one embodiment, the anomaly monitoring module 20 is further configured to compare the system call parameters, calling process identifiers, and permission change records in the kernel-mode event data with the initialization subprocess whitelist, the legal system call sequence baseline, and the permission allowed range in the preset behavior baseline, and obtain the comparison results; when the comparison results show that any item in the preset behavior baseline does not match the system call parameters, calling process identifiers, and permission change records in the kernel-mode event data, the kernel-mode event data is marked as an anomaly event.

[0080] In one embodiment, the risk assessment module 30 is further configured to parse abnormal events to obtain the event type, scope of impact, and access permissions of the abnormal events; when the event type is a kernel module loading type or a first privilege escalation type, the risk level of the abnormal event is determined to be a first risk level; when the event type is a sensitive device access type, the risk level of the abnormal event is determined to be a second risk level; when the event type is a non-target resource access type or a second privilege change type, the risk level of the abnormal event is determined to be a third risk level, wherein the first privilege is greater than the second privilege, the first risk level is greater than the second risk level, and the second risk level is greater than the third risk level.

[0081] In one embodiment, the layered protection module 40 is further configured to: write the abnormal event to the security log and continuously monitor the process corresponding to the abnormal event when the risk level is the third risk level; call the namespace isolation interface to isolate the process corresponding to the abnormal event to a restricted namespace when the risk level is the second risk level, and prohibit the process corresponding to the abnormal event from accessing the preset target device; and call the interception interface to block the system call of the process corresponding to the abnormal event when the risk level is the first risk level, or send a termination signal to the kernel to terminate the process corresponding to the abnormal event, and roll back the permission changes of the process corresponding to the abnormal event.

[0082] In one embodiment, the layered protection module 40 is further configured to read security logs and interception records according to a preset period, and to count the false positive rate and attack frequency of abnormal events; when the risk level of an abnormal event is lower than a preset security risk level and the attack frequency is higher than a preset frequency, the abnormal event is added to the subprocess whitelist; when the risk level of an abnormal event is the first risk level and the attack frequency is higher than a preset frequency, the risk judgment threshold of the abnormal event is reduced; and when the false positive rate is higher than a preset false positive rate, the risk judgment threshold of the abnormal event is increased.

[0083] This application provides a system kernel layer software security protection device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the system kernel layer software security protection method in the above embodiment 1.

[0084] The following is for reference. Figure 6 This document illustrates a structural diagram of a software security protection device suitable for implementing the system kernel layer of this application. The software security protection device for the system kernel layer in this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), and in-vehicle terminals (e.g., in-vehicle navigation terminals), as well as fixed terminals such as digital TVs and desktop computers. Figure 6 The software security protection device at the system kernel layer shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0085] like Figure 6As shown, the system kernel-level software security protection device may include a processing device 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to programs stored in ROM (Read Only Memory) 1002 or programs loaded from storage device 1003 into RAM (Random Access Memory) 1004. RAM 1004 also stores various programs and data required for the operation of the system kernel-level software security protection device. The processing device 1001, ROM 1002, and RAM 1004 are interconnected via bus 1005. Input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to I / O interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, LCDs (Liquid Crystal Displays), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the system kernel-level software security protection device to communicate wirelessly or wiredly with other devices to exchange data. Although the figure shows system kernel-level software security protection devices with various systems, it should be understood that it is not required to implement or possess all the systems shown. More or fewer systems can be implemented or possessed alternatively.

[0086] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0087] The system kernel layer software security protection device provided in this application, employing the system kernel layer software security protection method described in the above embodiments, can solve the technical problem of how to improve the security protection capability of the system kernel layer. Compared with the prior art, the beneficial effects of the system kernel layer software security protection device provided in this application are the same as those of the system kernel layer software security protection method described in the above embodiments, and other technical features in this system kernel layer software security protection device are the same as those disclosed in the method of the previous embodiment, and will not be repeated here.

[0088] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0089] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0090] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, which are used to execute the software security protection method of the system kernel layer in the above embodiments.

[0091] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, RAM (Random Access Memory), ROM (Read Only Memory), EPROM (Erasable Programmable Read Only Memory or Flash Memory), optical fibers, CD-ROM (CD-Read Only Memory), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0092] The aforementioned computer-readable storage medium may be included in the software security protection device at the system kernel layer; or it may exist independently and not be assembled into the software security protection device at the system kernel layer.

[0093] The aforementioned computer-readable storage medium carries one or more programs. When the aforementioned one or more programs are executed by the software security protection device at the system kernel level, the software security protection device at the system kernel level performs the following actions during the system startup phase: acquiring kernel-mode event data; matching the kernel-mode event data with a preset behavior baseline to obtain abnormal events; performing risk assessment based on the abnormal events to obtain risk levels; and providing layered protection for the processes corresponding to the abnormal events based on the risk levels.

[0094] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including LAN (Local Area Network) or WAN (Wide Area Network)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0095] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0096] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0097] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the software security protection method of the system kernel layer described above, and can solve the technical problem of how to improve the security protection capability of the system kernel layer. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as the beneficial effects of the software security protection method of the system kernel layer provided in the above embodiments, and will not be repeated here.

[0098] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the software security protection method for the system kernel layer as described above.

[0099] The computer program product provided in this application can solve the technical problem of how to improve the security protection capability of the system kernel layer. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as the beneficial effects of the software security protection method for the system kernel layer provided in the above embodiments, and will not be repeated here.

[0100] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A software security protection method for the system kernel layer, characterized in that, The method includes: During the system startup phase, kernel-mode event data is acquired; The kernel-mode event data is matched with a preset behavior baseline to obtain abnormal events; A risk assessment is performed based on the aforementioned abnormal events to obtain a risk level. Based on the risk level, the processes corresponding to the abnormal events are protected in layers.

2. The method as described in claim 1, characterized in that, The steps for obtaining kernel-mode event data during the system startup phase include: During the system startup phase, the extended Berkeley packet filter is loaded into kernel mode, and the hook point is invoked to mount the extended Berkeley packet filter. Kernel-mode event data is collected through the extended Berkeley package filter program, wherein the kernel-mode event data includes at least system call parameters, calling process identifiers, and permission change records.

3. The method as described in claim 1, characterized in that, Before the step of matching the kernel-mode event data with a preset behavior baseline to obtain the abnormal event, the method further includes: Initialize the baseline database, which stores the legal behavior rules of the core processes, including the initialization process, the incubation process, and the service manager process; The legal behavior rules are loaded into the core process to obtain a preset behavior baseline, wherein the preset behavior baseline includes: a whitelist of child processes defined for the initialization process, a legal system call sequence baseline established for the incubation process, and a permission range limited for the service manager process.

4. The method as described in claim 1, characterized in that, The step of matching the kernel-mode event data with a preset behavior baseline to obtain the abnormal event includes: The system call parameters, calling process identifiers, and permission change records in the kernel-mode event data are compared item by item with the initialization subprocess whitelist, legal system call sequence baseline, and permission allowance range in the preset behavior baseline to obtain the comparison results. If any item in the comparison result does not match the system call parameter, the calling process identifier, or the permission change record in the kernel-mode event data, the kernel-mode event data will be marked as an abnormal event.

5. The method as described in claim 1, characterized in that, The step of conducting a risk assessment based on the abnormal event to obtain the risk level includes: Analyze the abnormal event to obtain the event type, scope of impact, and access permissions of the abnormal event; When the event type is a kernel module loading type or a first privilege escalation type, the risk level of the abnormal event is determined to be the first risk level; When the event type is a sensitive device access type, the risk level of the abnormal event is determined to be the second risk level; When the event type is a non-target resource access type or a second permission change type, the risk level of the abnormal event is determined to be the third risk level, wherein the first permission is greater than the second permission, the first risk level is greater than the second risk level, and the second risk level is greater than the third risk level.

6. The method as described in claim 1, characterized in that, The step of providing tiered protection for processes corresponding to the abnormal event based on the risk level includes: When the risk level is the third risk level, the abnormal event is written to the security log, and the process corresponding to the abnormal event is continuously monitored; When the risk level is the second risk level, the namespace isolation interface is invoked to isolate the process corresponding to the abnormal event into a restricted namespace and prohibit the process corresponding to the abnormal event from accessing the preset target device. When the risk level is the first risk level, the interception interface is invoked to block the system call of the process corresponding to the abnormal event, or a termination signal is sent to the kernel to terminate the process corresponding to the abnormal event, and the permission changes of the process corresponding to the abnormal event are rolled back.

7. The method as described in claim 1, characterized in that, After the step of performing layered protection on the processes corresponding to the abnormal events according to the risk level, the method further includes: Security logs and interception records are read according to a preset period, and the false positive rate and attack frequency of the abnormal events are statistically analyzed. When the risk level of the abnormal event is lower than the preset security risk level and the attack frequency is higher than the preset frequency, the abnormal event is added to the subprocess whitelist. When the risk level of the abnormal event is the first risk level and the attack frequency is higher than the preset frequency, the risk judgment threshold of the abnormal event is reduced. When the false positive rate is higher than the preset false positive rate, the risk judgment threshold for the abnormal event is increased.

8. A software security protection device for the system kernel layer, characterized in that, The device includes: The data monitoring module is used to acquire kernel-mode event data during the system startup phase; An anomaly monitoring module is used to match the kernel-mode event data with a preset behavior baseline to obtain anomaly events; The risk assessment module is used to perform risk assessment based on the abnormal events and obtain the risk level; The layered protection module is used to provide layered protection for the processes corresponding to the abnormal events based on the risk level.

9. A software security protection device for the system kernel layer, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the software security protection method for the system kernel layer as described in any one of claims 1 to 7.

10. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the software security protection method of the system kernel layer as described in any one of claims 1 to 7.

Images