Interactive linux kernel signature verification loading method, apparatus and device

Abstract

This invention relates to an interactive Linux kernel signature verification loading method, apparatus, and device, belonging to the field of information security technology. It solves the problems of insufficient system flexibility and lack of third-party module loading operation log recording caused by overly strict kernel module signature verification mechanisms in existing technologies. The method includes integrating a predefined kernel module whitelist into the initial memory disk image and configuring access control policies. When the system is in a relaxed security mode, it determines whether to enable the interactive verification function. If enabled, when an unsigned or invalid signed kernel module loading request is detected, it determines whether the kernel module to be loaded is in the kernel module whitelist. If so, loading the kernel module is allowed; otherwise, a user interaction confirmation process is triggered, and the loading of the kernel module is determined based on the confirmation result. The loading event information of the kernel module to be loaded is recorded in the audit log.

Description

Technical Field

[0001] This invention relates to the field of information security technology, and in particular to an interactive Linux kernel signature verification loading method, apparatus, and device. Background Technology

[0002] With increasingly stringent security requirements for computer systems, the security protection mechanisms of operating system kernels are receiving growing attention. In modern Linux systems, kernel module signing technology is widely used as a crucial security measure. This technology ensures through digital signatures that only kernel modules with authorized signatures can be loaded and executed by the system, effectively preventing malicious code or unauthorized programs from illegally accessing and damaging the operating system kernel, thus significantly enhancing the overall system security.

[0003] Existing kernel module signature verification mechanisms employ relatively strict verification strategies in their implementation. Under default configuration, the system either mandates that all kernel modules to be loaded must have a valid digital signature, rejecting any unsigned or invalidally signed modules; or it requires the system administrator to manually disable signature verification by modifying kernel boot parameters to allow unsigned modules to load. This either-or approach lacks flexibility and has significant limitations in practical applications. First, it is inconvenient to operate and affects business continuity: When in mandatory signature verification mode, if an unsigned but valid module needs to be temporarily loaded, the kernel startup parameters must be modified and the system restarted to complete the operation. For online production environments, frequent or unplanned system restarts are often unacceptable, seriously affecting business continuity and operational efficiency.

[0004] Second, there is a lack of auditing and tracing capabilities for loading behavior: the existing mechanism fails to provide sufficient behavior logging support during the loading of unsigned or incorrectly signed third-party modules. Especially after enabling lenient policies or disabling signature verification, it is difficult to track key information such as which modules were loaded, when they were loaded, and who triggered the loading. This not only weakens the auditability of the system but also increases the difficulty of troubleshooting and responding to security incidents.

[0005] For specific application environments, such as those requiring a domestically developed and controllable operating system, this strict signature verification mechanism can effectively meet security compliance requirements and provide reliable security for the system. However, in commercially deployed product versions, overly strict default security policies often reduce the system's usability and adaptability. Especially in practical application scenarios involving hardware device driver loading and third-party functional component extensions, due to various objective limitations, there may be some kernel modules that are legal and compliant but cannot obtain valid digital signatures temporarily. Summary of the Invention

[0006] Based on the above analysis, the embodiments of the present invention aim to provide an interactive Linux kernel signature verification loading method, apparatus, and device to solve the problems of insufficient system flexibility and lack of third-party module loading operation log recording caused by the overly strict existing kernel module signature verification mechanism.

[0007] On one hand, embodiments of the present invention provide an interactive Linux kernel signature verification loading method, including the following steps: Integrate a predefined kernel module whitelist into the initial memory disk image and configure access control policies; When the system is in a relaxed security mode, it determines whether to enable the interactive verification function. If enabled, when an unsigned or invalid signed kernel module loading request is detected, it determines whether the kernel module to be loaded is in the kernel module whitelist. If so, then loading the kernel module to be loaded is permitted; If not, a user interaction confirmation process is triggered, and a decision is made based on the confirmation result as to whether to allow the loading of the kernel module to be loaded. Among these measures, the loading event information of the kernel module to be loaded is recorded in the audit log.

[0008] Furthermore, the user interaction confirmation process includes: Add the request information of the kernel module to be loaded to the queue to be processed; The request information in the queue to be processed is transmitted to the started user-space daemon process through the kernel-user space communication mechanism between kernel mode and user mode. Depending on the current stage of the system and the interface environment, the user-mode daemon process calls the appropriate interactive interface to interact and confirm with the user.

[0009] Furthermore, the user-mode daemon includes a basic daemon and a complete daemon; wherein the basic daemon is deployed in the initrd stage, and the complete daemon is deployed in the system runtime stage.

[0010] Furthermore, the access control policy pre-defines privileged administrator users as users with interactive permissions; During the period from system startup to login, users with interactive permissions can interact and confirm their login status through the terminal's text interface. During the system login phase, if the loading request information comes from the command-line terminal, the user with interactive permissions will confirm the request through a text interface on the terminal; if the loading request comes from a background task and the system has a graphical environment, the user with interactive permissions will confirm the request through a graphical dialog box interface.

[0011] Furthermore, the confirmation result includes agreeing to load, refusing to load, and refusing to load after timeout; wherein, agreeing to load and refusing to load are obtained based on the user's selection on the interactive interface; refusing to load after timeout is obtained in the following way: Each loading request has an interaction time limit during the confirmation process. If the user does not perform any action within the time limit, the confirmation result is a timeout and loading is rejected.

[0012] Furthermore, the method also includes: For each unsigned or invalidly signed kernel module loading request, the number of times it triggers the user interaction confirmation process is accumulated within a preset time window; When the number of times exceeds a preset threshold, the corresponding kernel module to be loaded will be added to the kernel-level rejection list; For kernel modules located in the kernel-level rejection list, subsequent loading requests will be rejected, and the user interaction confirmation process will no longer be triggered.

[0013] Furthermore, recording the loading event information of the kernel module to be loaded to the audit log includes: Record the loading event information of the kernel module to be loaded, including the kernel module identifier, loading time, loading result, and triggering user; The recorded audit logs are stored in encrypted form, and the log files are set to append-only write mode.

[0014] Furthermore, the method also includes setting a dynamic configuration switch to control the activation and deactivation of the interactive verification function; when the dynamic configuration switch is turned on, the interactive verification function is enabled; when the dynamic configuration switch is turned off, the system reverts to the kernel module signature verification mode.

[0015] On the other hand, embodiments of the present invention provide an interactive Linux kernel signature verification loading device, comprising: The whitelist management module is used to integrate a predefined kernel module whitelist into the initial memory disk image and configure access control policies. The kernel interaction verification module is used to determine whether to enable the interaction verification function when the system is in a relaxed security mode and an unsigned or invalid signed kernel module loading request is detected. If enabled, it determines whether the kernel module to be loaded is in the kernel module whitelist. If yes, loading the kernel module to be loaded is allowed; otherwise, a user interaction confirmation process is triggered, and the loading of the kernel module to be loaded is determined based on the confirmation result. The audit log management module is used to record loading event information of kernel modules to be loaded into the audit log.

[0016] This invention also provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the computer program is executed by the processor, it implements the interactive Linux kernel signature verification loading method described above.

[0017] Compared with the prior art, the present invention can achieve at least one of the following beneficial effects: This invention provides an interactive Linux kernel signature verification loading method, apparatus, and device. While retaining existing security control capabilities, it introduces interactive verification functionality. When encountering unsigned or failed-signature modules, the user interface prompts operators to make a judgment, and based on the confirmation result, decides whether to continue loading the module, achieving policy adjustment without restarting the system. Detailed logging is performed for each loading action of unsigned or incorrectly signed third-party modules, facilitating post-event analysis, problem localization, and security management. This method, while maintaining high security, possesses dynamic policy adjustment capabilities and a complete loading behavior auditing mechanism, improving the product's practicality and adaptability while ensuring system security.

[0018] In this invention, the above-described technical solutions can be combined with each other to achieve more preferred combinations. Other features and advantages of this invention will be set forth in the following description, and some advantages may become apparent from the description or be learned by practicing the invention. The objects and other advantages of this invention can be realized and obtained from what is particularly pointed out in the description and drawings. Attached Figure Description

[0019] The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Throughout the drawings, the same reference numerals denote the same parts. Figure 1 This is a flowchart illustrating the interactive Linux kernel signature verification loading method provided in Embodiment 1 of the present invention; Figure 2 This is a schematic diagram illustrating the specific workflow of the interactive Linux kernel signature verification loading method provided in Embodiment 1 of the present invention. Detailed Implementation

[0020] Preferred embodiments of the present invention will now be described in detail with reference to the accompanying drawings, which form part of this application and are used together with the embodiments of the present invention to illustrate the principles of the present invention, but are not intended to limit the scope of the present invention.

[0021] Example 1 A specific embodiment of the present invention discloses an interactive Linux kernel signature verification loading method, such as... Figure 1 As shown, it includes: Integrate a predefined kernel module whitelist into the initial memory disk image and configure access control policies; When the system is in a relaxed security mode, it determines whether to enable the interactive verification function. If enabled, when an unsigned or invalid signed kernel module loading request is detected, it determines whether the kernel module to be loaded is in the kernel module whitelist. If so, then loading the kernel module to be loaded is permitted; If not, a user interaction confirmation process is triggered, and a decision is made based on the confirmation result as to whether to allow the loading of the kernel module to be loaded. Among these measures, the loading event information of the kernel module to be loaded is recorded in the audit log.

[0022] Specifically, during the system configuration phase, a predefined kernel module whitelist is packaged and integrated into the designated system configuration directory of the initial memory disk image (initramfs image). Simultaneously, a corresponding access control policy is established, which presupposes that the system privileged administrator user is a user with interactive permissions, ensuring that only authorized users can participate in the interactive confirmation process of kernel module loading. The system privileged administrator user can configure the kernel module whitelist file. More specifically, the dracut instruction is used to place the kernel module whitelist file in a specified directory under initramfs, and the whitelist module is maintained and updated by the system privileged administrator.

[0023] In practice, the method further includes setting a dynamic configuration switch to control the enabling and disabling of the interactive verification function; when the dynamic configuration switch is turned on, the interactive verification function is enabled; when the dynamic configuration switch is turned off, the system reverts to the kernel module signature verification mode, and the interactive verification function can be enabled and disabled without restarting the system.

[0024] Specifically, the enabling status of the interactive verification function can be controlled through the sysctl interface or a dedicated configuration file.

[0025] Specifically, if the interactive verification function is enabled, when an unsigned or invalid signature is detected as a kernel module loading request, the loading request will be immediately intercepted before proceeding with the subsequent interactive verification function.

[0026] More specifically, a lightweight interception mechanism based on kprobe technology is adopted to monitor the critical path of kernel module loading through dynamic probe technology. When the system is in a relaxed security mode and an unsigned or invalid kernel module loading request is detected, the process of interactive verification is immediately intercepted.

[0027] Understandably, the non-intrusive design approach minimizes modifications to the original kernel code. The interception function can be achieved simply by deploying the kprobe probe at the entry point of the relevant kernel module loading function. It is fully compatible with the existing kernel signature verification mechanism, and achieves flexible module loading while ensuring security. The entire implementation process has been rigorously verified and there are no related logical vulnerabilities. The impact on the system's operating efficiency is negligible.

[0028] Specifically, the relaxed security mode is the CONFIG_MODULE_SIG policy, which is a built-in module loading policy of Linux. This embodiment is based on this policy.

[0029] In implementation, the user interaction confirmation process includes: Add the request information of the kernel module to be loaded to the queue to be processed; The request information in the queue to be processed is transmitted to the started user-space daemon process through the kernel-user space communication mechanism between kernel mode and user mode. Depending on the current stage of the system and the interface environment, the user-mode daemon process calls the appropriate interactive interface to interact and confirm with the user.

[0030] Specifically, the pending queue has a maximum capacity of 64.

[0031] Specifically, the confirmation results include agreeing to load, refusing to load, and refusing to load after timeout; wherein, agreeing to load and refusing to load are obtained based on the user's selection on the interactive interface; refusing to load after timeout is obtained in the following way: Each loading request has an interaction time limit during the confirmation process. If the user does not perform any action within the time limit, the confirmation result is a timeout and loading is rejected.

[0032] Specifically, the interaction time limit is a balanced choice based on comprehensive consideration of security, user experience, and system stability; for example, it is set to 15 seconds, at which point the system is sufficiently secure, stable, and user-friendly.

[0033] In specific implementation, the user-mode daemon includes a basic daemon and a full daemon; the basic daemon is deployed during the initrd stage, and the full daemon is deployed during the system runtime stage. That is, the basic daemon is a minimal version that starts during the initrd stage, providing only text-based interactive capabilities, while the full daemon runs after the system has fully booted, supporting a graphical interface and advanced functions.

[0034] Specifically, the basic daemon receives the queue of pending requests through a kernel-user space communication mechanism, performs user interaction confirmation on the kernel module loading requests in the queue in turn, and feeds back the confirmation results to the kernel space. The kernel space components then decide whether to execute the kernel module loading operation based on the confirmation results. The kernel-user space communication mechanism can be Netlink.

[0035] Specifically, the full user-space daemon takes over the pending queue from the basic daemon and automatically selects the type of interactive interface based on the current system environment: if the system has a graphical desktop environment, it supports graphical dialog interface interaction; if the system is a plain text environment, it uses text user interface interaction; it also supports interactive request routing in multi-session environments, including local TTY, SSH sessions and graphical desktop sessions.

[0036] It should be noted that during system startup, the timing of the basic daemon and the full daemon working together includes: during the initrd stage, only the basic daemon runs, handling early kernel module loading requests; after switching to the real file system, the basic daemon notifies the full daemon to start; after the full daemon starts, it takes over all subsequent interaction requests, and the basic daemon exits.

[0037] In specific implementation, during the user interaction confirmation process, in the initrd stage, before the basic daemon is started, the request information of the kernel module to be loaded is added to the pending queue; after entering the systemd initialization stage, the request information in the pending queue is passed to the started basic daemon through the kernel-user space communication mechanism between kernel mode and user mode.

[0038] In practice, during the user interaction confirmation process, while the system is waiting for the user to log in, the request information for the kernel module to be loaded is added to the queue to be processed. Once any user with interaction permissions completes the login authentication, the system will then extract and process the corresponding kernel module loading request from the queue.

[0039] In practice, during the period from system startup to login, users with interactive permissions will interact and confirm their login information through the terminal's text interface.

[0040] In practice, during the system login phase, if the loading request information comes from the command-line terminal, the user with interactive permissions will interact and confirm the request through a text interface on the terminal. The text interface is an nmtui-style interactive interface implemented based on the ncurses library, which provides module information display and keyboard selection functions.

[0041] In practice, during the system login phase, if the loading request comes from a background task and the system has a graphical environment, then the user with interactive permissions will interact and confirm the request through a graphical dialog box interface; the background task includes background scripts, automated tasks, or device hot-plug events.

[0042] Specifically, the graphical dialog box interface is a security warning dialog box implemented based on the GTK+ library, which displays detailed module information, risk warnings, and confirmation options; if the current desktop session user is a regular user, the dialog box prompts them to switch to the system privileged administrator user to confirm the operation.

[0043] In practice, during the system login phase, if the loading request comes from a background task and the system does not have a graphical environment, the location of the privileged administrator user's terminal is determined through a multi-TTY detection mechanism, and the user confirms the connection through a text user interface on that terminal.

[0044] Specifically, the multi-TTY detection mechanism includes: scanning all active terminal sessions, identifying the logged-in user's identity, and prioritizing the terminal where the system privileged administrator user is located; if no administrator user is logged in, all terminals are notified through a system broadcast message, and an interactive confirmation process is initiated in the first responding terminal.

[0045] Preferably, when a user with interactive privileges logs in via SSH remote connection, for kernel module loading requests that require interactive confirmation, interactive confirmation is performed in the SSH session through a simulated text terminal interface.

[0046] Specifically, the interactive confirmation in the SSH session supports session timeout and connection interruption detection. If the SSH connection is lost during the interaction, the loading request will be rejected by default and the corresponding audit log will be recorded.

[0047] During implementation, the loading event information of the kernel module to be loaded is recorded in the audit log, including: Record the loading event information of the kernel module to be loaded, including the kernel module identifier, loading time, loading result, and triggering user; The recorded audit logs are stored in encrypted form, and the log files are set to append-only write mode.

[0048] Specifically, the loading event information of the kernel module to be loaded is output to the kernel log buffer in real time. At the same time, the kernel-user space communication mechanism is used to pass detailed user interaction information and module loading status to the user space log daemon. The log records are encrypted and stored using the SM4 encryption algorithm, and strict access control policies are set. The log file is configured to append-only mode and file permissions are locked, which effectively prevents unauthorized users from illegally modifying or deleting the log content. This improves the flexibility of module loading while ensuring a complete security audit chain, and solves the technical problems of difficult problem investigation and lack of security traceability caused by the lack of effective operation records in the existing technology.

[0049] Preferably, the method further includes: For each unsigned or invalidly signed kernel module loading request, the number of times it triggers the user interaction confirmation process is accumulated within a preset time window; When the number of times exceeds a preset threshold, the corresponding kernel module to be loaded will be added to the kernel-level rejection list; For kernel modules located in the kernel-level rejection list, subsequent loading requests will be rejected, and the user interaction confirmation process will no longer be triggered.

[0050] Specifically, the rejected load event is loaded into the audit log in real time through the kernel-user space communication mechanism, including information such as the module name, the reload protection mechanism has rejected the load, and the timestamp.

[0051] Specifically, time windows and frequency thresholds are set based on a comprehensive consideration of security protection, user experience, and actual operation and maintenance scenarios. For example, the time window is set to 24 hours to cover the typical operation and maintenance cycle. This avoids the problem of frequently blocking legitimate debugging behavior due to its short duration, while also preventing the loss of protection against continuous attacks due to its long duration. The frequency threshold is set to 3 times to give users a limited number of retry opportunities (such as for typos or configuration adjustments). If the number of attempts exceeds 3, it is highly suspected of being a malicious attempt or an automated attack, and automatic blocking can effectively protect against brute-force loading attempts.

[0052] Furthermore, the kernel-level denial list is reset based on the set rules; wherein the reset rules reach the set reset time or the operating system is restarted; wherein the reset time is set based on the balance between operation and maintenance efficiency and security protection to avoid permanent false blocking; for example, it is set to 24 hours to give the administrator sufficient response time to handle possible false blocking, while preventing the module from being permanently blocked due to configuration errors or testing behavior.

[0053] In summary, as Figure 2 As shown, the overall operation of the method in this embodiment is as follows: Before the system starts up and you log in, this includes: During initrd initialization, a kernel module whitelist file is loaded. Kernel modules on the whitelist are allowed to load directly without user confirmation, while a user permission verification mechanism is established to limit the scope of users who can participate in interactive confirmation. Simultaneously, kernel loading events are recorded in the audit log, including module name, operation type (agreement), timestamp, and other information. For modules not on the whitelist, the system first loads the interactive verification program kernel module, establishing a basic module loading interception mechanism and building an initial security verification framework. When an unsigned or invalidly signed module loading request is detected, the system stores the relevant information of the request in a pending queue for temporary storage. After entering the systemd initialization phase (sysinit.target), the system sequentially completes the initialization operations of the virtual console and device enumeration, and then starts the basic user-space daemon. At this point, the basic kernel module signature verification loading mechanism is completed. The system uses the kernel-user space communication mechanism to pass the request data temporarily stored in the pending queue to the started daemon process. The daemon process interacts with the user in the terminal interface for confirmation. Each request has a reasonable interaction time limit. If the timeout occurs, the loading request of the corresponding module is rejected by default, thereby ensuring that all module loading behavior has been effectively authorized and confirmed by the user, effectively avoiding module loading failures caused by the user-space daemon service not being ready. At the same time, the kernel loading event is recorded in the audit log, including information such as module name, operation type (agree / reject / timeout rejection), triggering user, and timestamp.

[0054] After switching to the real file system, the system executes a direct loading strategy for trusted modules in the pre-defined whitelist, completing the module loading operation without user interaction confirmation. Simultaneously, the kernel loading event is recorded in the audit log, including information such as module name, operation type (agree), and timestamp. For modules not included in the whitelist, since the system has already initialized the basic kernel module signature verification loading mechanism during the initrd stage, when an unsigned or invalid signature module loading request is detected, the system will immediately trigger a user interaction confirmation process on the current terminal. If the interaction times out, loading is rejected by default, thus obtaining explicit authorization from the user for the module loading behavior. Simultaneously, the kernel loading event is recorded in the audit log, including information such as module name, operation type (agree / reject / timeout rejection), triggering user, and timestamp.

[0055] While the system is waiting to log in, the phases include: While the system awaits user login, it executes a direct loading strategy for trusted modules in a pre-defined whitelist, completing the module loading operation without user interaction confirmation. Simultaneously, the kernel loading event is recorded in the audit log, including information such as module name, operation type (agree), and timestamp. For modules not included in the whitelist, if a kernel module loading request is detected and no user is currently logged in, the system temporarily stores the request in a pre-defined queue. Once any user with interactive permissions completes login authentication, the system retrieves and processes the corresponding module loading request from the queue. Again, the kernel loading event is recorded in the audit log, including information such as module name, timestamp, and whether no user is currently logged in.

[0056] After logging into the system, the stages include: After logging into the system, the system executes a direct loading strategy for trusted modules in the pre-defined whitelist, completing the module loading operation without requiring user interaction or confirmation. Simultaneously, the kernel loading event is recorded in the audit log, including information such as the module name, operation type (agreement), and timestamp.

[0057] After system login, for modules not included in the whitelist, when a user manually loads an unsigned or incorrectly signed module via the `insmod` or `modprobe` command in the terminal, the kernel interactive module intercepts the signature verification result via `kprobe`. In operating systems with and without a graphical desktop, the `nmtui` security warning and confirmation prompt are directly displayed in the terminal interface executing the command. After the user selects confirmation via keyboard input, the confirmation result is returned to the kernel module through the kernel-user space communication mechanism to determine whether to continue loading. If the interaction times out, loading is rejected by default, thus obtaining explicit authorization from the user for the module loading behavior. Simultaneously, the kernel loading event is recorded in the audit log, including the module name, operation type (agree / reject / timeout rejection), triggering user, timestamp, and other information.

[0058] After system login, for modules not included in the whitelist, when a module loading request for an unsigned or incorrectly signed module originates from a background script, automated task, or during device hot-plugging, the following actions are taken: In a graphical desktop operating system, the system displays a GTK confirmation dialog box in the currently active desktop session to interact with the user. If the current user is a regular user, they are prompted to switch to a privileged administrator user for confirmation. The user's selection on the graphical interface is transmitted to the kernel interaction module via the kernel-user space communication mechanism through the desktop notification service to determine whether to load the module. In a non-graphical desktop operating system, if the current user is a privileged administrator user, nmtui interaction confirmation is performed directly. If the user is a regular user, a system notification mechanism informs them to switch to a privileged administrator user for confirmation. The specific terminal location of the notification is determined through a multi-TTY login detection mechanism. The user's selection is transmitted to the kernel interaction module via the kernel-user space communication mechanism to determine whether to load the module. Loading is rejected by default upon interaction timeout to obtain explicit authorization from the user for module loading. Simultaneously, the kernel loading event is recorded in the audit log, including the module name, operation type (agree / reject / timeout rejection), triggering user, and timestamp.

[0059] If logging in via SSH, for modules not included in the whitelist, if the current user is a regular user, they will be prompted to switch to a privileged administrator user for confirmation. Confirmation is made directly via SSH using the nmtui interface. The user's selection is then transmitted to the kernel interaction module through the kernel-user space communication mechanism to determine whether to load the module. Loading is refused by default if the interaction times out. Simultaneously, the kernel loading event is logged to the audit log, including the module name, operation type (agree / reject / timeout rejection), triggering user, and timestamp.

[0060] Compared with existing technologies, this embodiment provides an interactive Linux kernel signature verification loading method. While retaining the original security control capabilities, it introduces an interactive verification function. When encountering unsigned or signed modules that have failed verification, the user interface prompts the operator to make a judgment, and the operator decides whether to continue loading the module based on the confirmation result. Policy adjustment can be achieved without restarting the system. Detailed logging should be performed for each loading action of unsigned or incorrectly signed third-party modules to facilitate post-event analysis, problem localization, and security management. This method maintains high security while providing dynamic policy adjustment capabilities and a complete loading behavior auditing mechanism, thereby improving the practicality and adaptability of the product while ensuring system security.

[0061] Example 2 A specific embodiment of the present invention discloses an interactive Linux kernel signature verification loading device, comprising: The whitelist management module is used to integrate a predefined kernel module whitelist into the initial memory disk image and configure access control policies. The kernel interaction verification module is used to determine whether to enable the interaction verification function when the system is in a relaxed security mode and an unsigned or invalid signed kernel module loading request is detected. If enabled, it determines whether the kernel module to be loaded is in the kernel module whitelist. If yes, loading the kernel module to be loaded is allowed; otherwise, a user interaction confirmation process is triggered, and the loading of the kernel module to be loaded is determined based on the confirmation result. The audit log management module is used to record loading event information of kernel modules to be loaded into the audit log.

[0062] Preferably, the whitelist management module also provides a method for dynamically updating the whitelist: S1. Monitor and collect kernel module loading request events and related context information to obtain a historical dataset of module events.

[0063] In practice, the context information of the loading request event includes module static metadata, loading dynamic context, approval history, and runtime behavior data after the module is loaded. Among them, module static metadata includes digital signature information, compilation environment information, and version dependency information; loading dynamic context includes trigger source, system running mode, and environment load status; approval history includes approval administrator identity, decision result, decision delay, and rejection reason classification; and runtime behavior data after the module is loaded includes resource usage mode and system interaction behavior.

[0064] It should be noted that for modules loaded for the first time, the approval history and runtime behavior data fields are empty or use preset default values.

[0065] S2. Based on the historical dataset of module events, calculate the comprehensive reputation score of the kernel module using an integrated machine learning model; the comprehensive reputation score is obtained based on the kernel module's historical approval performance, source credibility, and runtime behavior characteristics.

[0066] In practice, the overall reputation score of the kernel module is calculated in the following way: Based on the historical dataset of module events, a first feature subset is obtained to characterize historical approval performance, a second feature subset is obtained to characterize source credibility, and a third feature subset is obtained to characterize runtime behavior characteristics. The first, second, and third feature subsets are input into a pre-trained ensemble machine learning model, which outputs a comprehensive reputation score.

[0067] Specifically, integrated machine learning models include: The first prediction sub-model is constructed based on the gradient boosting tree algorithm. The input is the first feature subset, and the output is the initial sub-score and confidence level, which are used to evaluate historical approval performance. The second prediction sub-model is built based on the logistic regression algorithm. The input is the second feature subset, and the output is the initial sub-score and confidence level, which are used to evaluate the credibility of the source. The third prediction sub-model is built on a multilayer perceptron neural network. The input is the third feature subset, and the output is the initial sub-score and confidence level, which are used to evaluate runtime behavioral features. The meta-learner is used to output a comprehensive reputation score by weighted summation of the initial sub-scores and confidence levels output by each of the received prediction sub-models.

[0068] Specifically, the first feature subset includes the ratio of the total number of times the kernel module is loaded within a preset time window to the number of times the administrator approves it; the number of different administrator identities that approve the kernel module and the consistency measure of the approval decision; the regularity entropy value of the kernel module loading requests distributed over time; and the average decision delay time of the system administrator.

[0069] Specifically, the second subset of features includes the integrity of the kernel module's digital signature certificate chain and the recognized reputation level of the issuing authority; the historical records of the source entity of the kernel module in the vulnerability database and community activity indicators; and the kernel module's version information and its compatibility score with the current system kernel version.

[0070] Specifically, the third feature subset includes stability indicators of kernel memory usage over time after the kernel module is loaded; behavioral pattern encoding of intercepting or modifying critical system calls during kernel module execution; and symbol dependency conflict detection results between the kernel module and other loaded modules in the system.

[0071] It should be noted that, based on the historical dataset of module events, feature values ​​of each module in multiple dimensions are calculated. The calculated feature values ​​are grouped according to business meaning to form a first feature subset for characterizing historical approval performance, a second feature subset for characterizing source credibility, and a third feature subset for characterizing runtime behavior characteristics.

[0072] It's important to note that training the integrated machine learning model is a phased, iterative optimization process. This includes collecting historically accumulated module loading, approval, and operational data to construct a labeled dataset containing multi-dimensional features and corresponding administrator final decision results. Three predictive sub-models are trained in parallel: a gradient boosting tree algorithm is used to train a historical approval performance expert, focusing on learning time series and statistical patterns; logistic regression is used to train a source credibility expert, focusing on identity verification based on explicit rules; and a neural network is used to train a runtime behavior expert, uncovering complex non-linear behavioral features. Finally, based on the predictive sub-models, the prediction results and confidence scores of these sub-models on the validation set are used as input features to train a meta-learner (such as a shallow neural network or linear model). This learner dynamically adjusts the weights of each sub-model according to different contextual scenarios, thereby maximizing the prediction accuracy for the administrator's actual decisions. Furthermore, the entire training process is periodically updated with new data increments to ensure the model continuously adapts to changes.

[0073] S3. When the overall reputation score of the kernel module is greater than or equal to the preset recommendation threshold, generate a smart recommendation to add it to the whitelist for the system administrator and obtain the recommendation result; the recommendation result includes agreeing or rejecting.

[0074] Specifically, the recommendation threshold is set by considering the best balance between security and recommendation efficiency, and it is dynamically adjusted. For example, the threshold can be initially set to 85 points, which is obtained through statistical analysis of historical data. Modules with scores exceeding 85 points have a very high probability of being accepted by the administrator. Subsequently, it is dynamically and adaptively adjusted according to the system operating environment, the administrator's personalized acceptance rate, and the current security situation.

[0075] Specifically, kernel modules exceeding the recommended threshold, along with their corresponding comprehensive reputation scores and module information, are presented to the system administrator through the system interface. The system administrator then confirms on the interface whether to agree to add them to the whitelist. Once the kernel modules that the system administrator agrees to add to the whitelist are added, their loading requests will bypass the user interaction confirmation process.

[0076] Understandably, through continuous learning and optimization based on actual usage patterns and approval feedback, the system can automatically identify and add frequently used and trustworthy modules to the whitelist, thereby significantly reducing unnecessary interactive confirmations and greatly improving administrator efficiency and system deployment smoothness. At the same time, this mechanism ensures the accuracy and security of the whitelist content through real-time reputation assessment and behavior monitoring, preventing the trustworthy module list from becoming rigid or outdated. It effectively reduces the risk of accidental releases or management burden that static whitelists may introduce. It not only optimizes the user experience while maintaining or even enhancing the security baseline, but also enables the system to evolve on its own and adapt to complex and ever-changing environments, thus establishing a sustainable and dynamic balance between security and convenience.

[0077] The specific implementation process of this invention can be found in the above method embodiments, and will not be repeated here.

[0078] Since this embodiment is based on the same principle as the above method embodiment, this device also has the corresponding technical effects of the above method embodiment.

[0079] Example 3 In one specific embodiment of the present invention, a computer device is also disclosed, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the computer program is executed by the processor, it implements the interactive Linux kernel signature verification loading method as described in Embodiment 1.

[0080] Those skilled in the art will understand that all or part of the processes of the methods described in the above embodiments can be implemented by a computer program instructing related hardware, and the program can be stored in a computer-readable storage medium. The computer-readable storage medium may be a disk, optical disk, read-only memory, or random access memory, etc.

[0081] The above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in the present invention should be included within the scope of protection of the present invention.

Claims

1. An interactive Linux kernel signature verification loading method, characterized in that, Includes the following steps: Integrate a predefined kernel module whitelist into the initial memory disk image and configure access control policies; When the system is in a relaxed security mode, it determines whether to enable the interactive verification function. If enabled, when an unsigned or invalid signed kernel module loading request is detected, it determines whether the kernel module to be loaded is in the kernel module whitelist. If so, then loading the kernel module to be loaded is permitted; If not, a user interaction confirmation process is triggered, and a decision is made based on the confirmation result as to whether to allow the loading of the kernel module to be loaded. Among these measures, the loading event information of the kernel module to be loaded is recorded in the audit log; The user interaction confirmation process includes: Add the request information of the kernel module to be loaded to the queue to be processed; The request information in the queue to be processed is transmitted to the started user-space daemon process through the kernel-user space communication mechanism between kernel mode and user mode. Depending on the current stage of the system and the interface environment, the user-mode daemon process calls the appropriate interactive interface to interact and confirm with the user. The user-mode daemon process includes a basic daemon and a complete daemon; wherein, the basic daemon is deployed in the initrd stage, and the complete daemon is deployed in the system runtime stage; The method further includes: For each unsigned or invalidly signed kernel module loading request, the number of times it triggers the user interaction confirmation process is accumulated within a preset time window; When the number of times exceeds a preset threshold, the corresponding kernel module to be loaded will be added to the kernel-level rejection list; For kernel modules located in the kernel-level rejection list, subsequent loading requests will be rejected and the user interaction confirmation process will no longer be triggered. The kernel-level rejection list is reset based on set rules; the reset rules are reaching the set reset time or restarting the operating system.

2. The interactive Linux kernel signature verification loading method according to claim 1, characterized in that, During the period from system startup to login, users with interactive permissions can interact and confirm their login status through the terminal's text interface. During the system login phase, if the loading request information comes from the command-line terminal, the user with interactive permissions will confirm the request through a text interface on the terminal; if the loading request comes from a background task and the system has a graphical environment, the user with interactive permissions will confirm the request through a graphical dialog box interface.

3. The interactive Linux kernel signature verification loading method according to claim 1, characterized in that, The confirmation results include agreeing to load, rejecting load, and rejecting load after timeout; wherein, agreeing to load and rejecting load are obtained based on the user's selection on the interactive interface; rejecting load after timeout is obtained in the following way: Each loading request has an interaction time limit during the confirmation process. If the user does not perform any action within the time limit, the confirmation result is a timeout and loading is rejected.

4. The interactive Linux kernel signature verification loading method according to claim 3, characterized in that, The loading event information of the kernel module to be loaded is recorded in the audit log, including: Record the loading event information of the kernel module to be loaded, including the kernel module identifier, loading time, loading result, and triggering user; The recorded audit logs are stored in encrypted form, and the log files are set to append-only write mode.

5. The interactive Linux kernel signature verification loading method according to claim 1, characterized in that, The method further includes setting a dynamic configuration switch to control the activation and deactivation of the interactive verification function; when the dynamic configuration switch is turned on, the interactive verification function is enabled; when the dynamic configuration switch is turned off, the system reverts to the kernel module signature verification mode.

6. An interactive Linux kernel signature verification and loading device, characterized in that, include: The whitelist management module is used to integrate a predefined kernel module whitelist into the initial memory disk image and configure access control policies. The kernel interactive verification module is used to determine whether to enable the interactive verification function when the system is in a relaxed security mode and an unsigned or invalid signed kernel module loading request is detected. If enabled, it determines whether the kernel module to be loaded is in the kernel module whitelist. If so, it allows the loading of the kernel module to be loaded. If not, a user interaction confirmation process is triggered, and a decision is made based on the confirmation result as to whether to allow the loading of the kernel module to be loaded. The user interaction confirmation process includes: Add the request information of the kernel module to be loaded to the queue to be processed; The request information in the queue to be processed is transmitted to the started user-space daemon process through the kernel-user space communication mechanism between kernel mode and user mode. Depending on the current stage of the system and the interface environment, the user-mode daemon process calls the appropriate interactive interface to interact and confirm with the user. The user-mode daemon process includes a basic daemon and a complete daemon; wherein, the basic daemon is deployed in the initrd stage, and the complete daemon is deployed in the system runtime stage; The kernel interaction verification module also includes: For each unsigned or invalidly signed kernel module loading request, the number of times it triggers the user interaction confirmation process is accumulated within a preset time window; When the number of times exceeds a preset threshold, the corresponding kernel module to be loaded will be added to the kernel-level rejection list; For kernel modules located in the kernel-level rejection list, subsequent loading requests will be rejected and the user interaction confirmation process will no longer be triggered. The kernel-level denial list is reset based on set rules; the reset rules are reaching a set reset duration or restarting the operating system. The audit log management module is used to record loading event information of kernel modules to be loaded into the audit log.

7. A computer device, characterized in that, It includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program, when executed by the processor, implements the interactive Linux kernel signature verification loading method as described in any one of claims 1 to 5.

Images