Kernel configuration security promotion method and device, terminal and storage medium

Abstract

This invention discloses a method, apparatus, terminal, and storage medium for enhancing kernel configuration security, belonging to the field of kernel configuration security technology. It includes: splitting kernel CONFIG configuration symbols into symbol-level atomic configuration files and storing them by subsystem, obtaining an initial layered atomic configuration library divided into a baseline layer, a general layer, and an architecture-specific layer; migrating configurations with identical values ​​across multiple architectures from the architecture-specific layer to the general layer, forming a hierarchical regularized configuration library; parsing Kconfig to construct a configuration symbol dependency graph and identifying and intercepting the association links between newly added symbols and baseline layer symbols, obtaining a risk-filtered configuration library; identifying configuration constraint conflict information, converting it into logical operation parameters to solve for the minimum incremental adjustment data, and correcting the configuration directories at each level to generate the target kernel configuration file. By splitting CONFIG symbols into atomic configurations, and through layered regularization, dependency graph analysis, and constraint solving, secure and compliant generation of kernel configurations for multiple architectures and versions is achieved.

Description

Technical Field

[0001] This invention relates to the field of kernel configuration security technology, and in particular to a method, apparatus, terminal and storage medium for enhancing kernel configuration security. Background Technology

[0002] The Linux kernel is the core carrier of various computing systems. The enabling and disabling of various kernel functions, hardware drivers, and security mechanisms all rely on the massive number of CONFIG configuration symbols in the .config configuration file for definition and control. With increasingly complex computing applications, the Linux kernel also needs to be compatible with multiple hardware architectures such as x86, ARM64, and RISC-V, and adapt to different business product forms such as servers, embedded systems, and desktops. Therefore, kernel configuration management requirements are becoming increasingly diverse.

[0003] Traditional kernel configuration uses a centralized management model, where all configuration items are aggregated into a single, massive configuration file for unified management. This management model not only makes it difficult to quickly locate core security configuration items for auditing, but also makes it prone to the passive invalidation of existing security configurations during kernel version upgrades due to logical dependencies of newly added configurations. Furthermore, the lack of a unified configuration synchronization mechanism across multiple hardware architectures means that relying on manual maintenance and repetitive configurations easily leads to missed security configurations.

[0004] Currently, the mainstream approach in the industry is to use kernel-provided scripts to merge configurations. This method can only perform simple overlay and splicing of configuration files, lacking comprehensive capabilities for identifying configuration differences, managing multi-architecture collaboration, and modular organization. The overall management system is incomplete and cannot meet the current needs for kernel configuration security governance and efficient maintenance. Summary of the Invention

[0005] This invention provides a method, apparatus, terminal, and storage medium for enhancing kernel configuration security, in order to solve the problems in the prior art where kernel configuration management is messy, easily leading to security configuration failure, difficult to adapt to multi-architecture scenarios, and unable to effectively handle configuration dependency conflicts.

[0006] In a first aspect, embodiments of the present invention provide a method for enhancing kernel configuration security, including: Obtain the Linux kernel CONFIG configuration symbols, split the CONFIG configuration symbols to generate independent symbol-level atomic configuration files, classify and store the symbol-level atomic configuration files according to the preset kernel subsystem directories, and obtain the initial hierarchical atomic configuration library; The initial hierarchical atomic configuration library is divided into a baseline layer, a general layer, and an architecture-specific layer. The configuration content of different hardware architectures under the same type of kernel is retrieved. The symbol-level atomic configuration files with the same value are migrated from the architecture-specific layer to the general layer to obtain a hierarchical regularized configuration library. Parse the kernel's native Kconfig file, construct a configuration symbol dependency graph, identify the association links between newly added configuration symbols and configuration symbols in the baseline layer of the hierarchical regularization configuration library based on the configuration symbol dependency graph, and perform interception processing to obtain the risk filtering configuration library; The configuration constraint conflict information in the risk filtering configuration library is identified using the configuration symbol dependency graph. The configuration constraint conflict information is converted into logical operation parameters, and the minimum incremental adjustment data is obtained. The minimum incremental adjustment data is used to correct the configuration directories at each level in the risk filtering configuration library, and the target kernel configuration file is generated.

[0007] Secondly, embodiments of the present invention also provide a kernel configuration security enhancement device, comprising: The splitting module is used to obtain Linux kernel CONFIG configuration symbols, split the CONFIG configuration symbols to generate independent symbol-level atomic configuration files, and classify and store the symbol-level atomic configuration files according to the preset kernel subsystem directories to obtain the initial hierarchical atomic configuration library. The migration module is used to divide the initial hierarchical atomic configuration library into a baseline layer, a general layer and an architecture-specific layer, retrieve the configuration content of different hardware architectures under the same type of kernel, and migrate the symbol-level atomic configuration files with the same values ​​from the architecture-specific layer to the general layer to obtain a hierarchical regularized configuration library. The identification module is used to parse the kernel's native Kconfig file, construct a configuration symbol dependency graph, identify the association links between newly added configuration symbols and configuration symbols in the baseline layer of the hierarchical regularization configuration library based on the configuration symbol dependency graph, and perform interception processing to obtain a risk filtering configuration library. The correction module is used to identify configuration constraint conflict information in the risk filtering configuration library using the configuration symbol dependency graph, convert the configuration constraint conflict information into logical operation parameters, solve for the minimum incremental adjustment data, use the minimum incremental adjustment data to correct the configuration directories at each level in the risk filtering configuration library, and generate the target kernel configuration file.

[0008] Thirdly, embodiments of the present invention also provide a terminal, including: One or more processors; Storage device for storing one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the kernel configuration security enhancement method provided in the above embodiments.

[0009] Fourthly, embodiments of the present invention also provide a storage medium containing computer-executable instructions, which, when executed by a computer processor, are used to perform the kernel configuration security enhancement method provided in the above embodiments.

[0010] The kernel configuration security enhancement method, apparatus, terminal, and storage medium provided in this invention involve: obtaining Linux kernel CONFIG configuration symbols; splitting the CONFIG configuration symbols into independent symbol-level atomic configuration files; classifying and storing the symbol-level atomic configuration files according to a preset kernel subsystem directory to obtain an initial layered atomic configuration library; dividing the initial layered atomic configuration library into a baseline layer, a general layer, and an architecture-specific layer; retrieving configuration content from different hardware architectures under the same type of kernel; migrating symbol-level atomic configuration files with the same values ​​from the architecture-specific layer to the general layer to obtain a hierarchical regularized configuration library; parsing the kernel's native Kconfig file to construct a configuration symbol dependency graph; identifying the association links between newly added configuration symbols and configuration symbols in the baseline layer of the hierarchical regularized configuration library based on the configuration symbol dependency graph and performing interception processing to obtain a risk-filtering configuration library; using the configuration symbol dependency graph to identify configuration constraint conflict information in the risk-filtering configuration library; converting the configuration constraint conflict information into logical operation parameters; solving for the minimum incremental adjustment data; using the minimum incremental adjustment data to correct the configuration directories of each level in the risk-filtering configuration library; and generating a target kernel configuration file. By splitting, classifying, and managing kernel configuration symbols in a hierarchical manner, combined with multi-architecture configuration standardization, dependency link risk interception, and intelligent correction of configuration conflicts, standardized management and security protection of Linux kernel configuration are achieved, ensuring stable and compliant kernel configuration operation. Attached Figure Description

[0011] The accompanying drawings, which form part of this invention, are used to provide a further understanding of the invention. The illustrative embodiments of the invention and their descriptions are used to explain the invention and do not constitute an improper limitation of the invention.

[0012] Figure 1 This is a flowchart of the kernel configuration security enhancement method provided in Embodiment 1 of the present invention; Figure 2 This is a flowchart of the kernel configuration security enhancement method provided in Embodiment 2 of the present invention; Figure 3 This is a schematic diagram of the kernel configuration security enhancement device provided in Embodiment 3 of the present invention; Figure 4 This is a structural diagram of the terminal provided in Embodiment 4 of the present invention. Detailed Implementation

[0013] The present invention will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and not intended to limit it. Furthermore, it should be noted that, for ease of description, the accompanying drawings show only the parts relevant to the present invention, and not all of the structures.

[0014] Example 1 Figure 1 This is a flowchart of the kernel configuration security enhancement method provided in Embodiment 1 of the present invention. This embodiment is applicable to application scenarios of Linux kernel configuration overall management and security optimization under multiple hardware architectures, and specifically includes the following steps: Step 110: Obtain the Linux kernel CONFIG configuration symbols, split the CONFIG configuration symbols to generate independent symbol-level atomic configuration files, and classify and store the symbol-level atomic configuration files according to the preset kernel subsystem directories to obtain the initial hierarchical atomic configuration library.

[0015] CONFIG configuration symbols are the core configuration units during the Linux kernel compilation and runtime phases. In traditional implementations, all CONFIG configuration symbols and their values ​​are stored uniformly in a single .config configuration file. This centralized coupling of thousands of configuration items lacks independent management capabilities, posing a major obstacle to subsequent configuration auditing, maintenance, and security control. Symbol-level atomic configuration files, on the other hand, are independent configuration carriers with a single CONFIG configuration symbol as the smallest unit. By extracting the name, value, and dependency rules of each individual CONFIG configuration symbol from the traditional centralized .config file, they generate physically independent files. Each symbol-level atomic configuration file corresponds to only one CONFIG configuration symbol, and its content only stores the core information of the configuration item, such as CONFIG_SECURITY_APPARMOR=y. It does not share file resources with other configuration items, achieving complete decoupling of the configuration unit.

[0016] For example, firstly, all kernel configuration symbols prefixed with CONFIG_ and their current values ​​are extracted in batches from the Kconfig configuration framework in the Linux kernel source tree or existing .config configuration files, covering different types of configuration items such as security, network, and file system categories. Then, each extracted configuration symbol is broken down and separated from the traditional centralized configuration file, generating physically independent symbol-level atomic configuration files. Each file stores only the name and value information of a single configuration item, achieving complete decoupling of configuration units. Next, according to the directory structure of the kernel's native logical subsystems, such as security, net, and fs, the generated atomic configuration files are categorized and stored, constructing a hierarchical atomic configuration library. This achieves a physical topology mapping of basic configuration data from unordered centralization to modular organization, ultimately resulting in the initial hierarchical atomic configuration library.

[0017] Addressing the inherent shortcomings of traditional centralized kernel configuration management, this project achieves multiple technological breakthroughs through atomic configuration decoupling and modular refactoring. This overcomes the problem of highly coupled configuration items in config files, enhancing the independence and controllability of configuration management. A modular directory structure matching the kernel's logical architecture is constructed, resolving the pain points of difficulty in quickly locating and auditing configuration items. Simultaneously, it provides a foundation for subsequent layered control, cross-architecture configuration aggregation, and security governance, supporting unified kernel configuration management across multiple scenarios and improving the maintainability and adaptability of configuration management.

[0018] Step 120: Divide the initial hierarchical atomic configuration library into a baseline layer, a general layer, and an architecture-specific layer. Retrieve the configuration content of different hardware architectures under the same type of kernel. Migrate the symbol-level atomic configuration files with the same values ​​from the architecture-specific layer to the general layer to obtain a hierarchical regularized configuration library.

[0019] To address the shortcomings of traditional multi-architecture kernel configurations, such as redundant configurations, high maintenance costs, and difficulty in unified management of cross-architecture security configurations, a three-level hierarchical management system is constructed and cross-architecture configurations are automatically aggregated. This achieves standardized deduplication and hierarchical management of configurations, laying a structural foundation for subsequent kernel configuration security governance.

[0020] For example, a three-tiered priority management system is first constructed. The initial layered atomic configuration library obtained in step 110 can be divided into a baseline layer, a general layer, and an architecture-specific layer. The functions and control boundaries of each layer are clearly defined. The baseline layer, with the highest priority, is the global security red line layer, storing security specifications and basic attributes that must be forcibly inherited by all product forms. No architecture configuration may modify or overwrite the baseline layer configuration. The general layer is a cross-architecture general layer, storing general business function configurations that are independent of the underlying hardware architecture and divided according to specific product forms, for sharing by all hardware architectures under the same product line. The architecture-specific layer is an architecture differentiation layer, storing underlying drivers and feature configurations specifically for target hardware chip architectures (such as ARM, x86, RISC-V, etc.), which only take effect under the corresponding architecture. The layered system breaks the chaotic management problem of traditional configurations without hierarchy and priority, and clarifies the control logic of different types of configurations.

[0021] Optionally, after completing the layered construction, an automated cross-architecture configuration aggregation process is executed. First, the complete configuration sets of all hardware architectures under the same kernel type or product form are collected, and all symbol-level atomic configuration files corresponding to each architecture are extracted. Next, the values ​​of configuration symbols with the same name in the complete configuration sets of each architecture are compared to determine whether their value states (e.g., y / m / n) are completely consistent across different architectures. Then, all configuration symbols with consistent values ​​across architectures are selected, and their corresponding atomic configuration files are physically removed from the architecture-specific layer directories. Finally, a physical topology reconstruction of the configuration space is performed, creating new atomic files in the subsystem locations corresponding to the general layer, completing the migration from the architecture-specific layer to the general layer. Through the above process, repetitive general configurations originally scattered across various architecture-specific layers are uniformly aggregated into the general layer. Configurations in each layer are free of redundancy and have clear boundaries, ultimately forming a hierarchically organized configuration library, achieving deduplication and hierarchical management of configurations.

[0022] Step 130: Parse the kernel native Kconfig file, construct a configuration symbol dependency graph, and based on the configuration symbol dependency graph, identify the association links between newly added configuration symbols and configuration symbols in the baseline layer of the hierarchical regularization configuration library and perform interception processing to obtain the risk filtering configuration library.

[0023] The symbolic dependency graph is a kernel configuration logical relationship model. It uses all CONFIG configuration symbols in the Linux kernel as independent nodes and various configuration association rules defined in the Kconfig syntax as directed edges, such as the keywords `dependson` (dependency declaration), `select` (forced selection), and `if` (conditional constraint). This results in a structured graph that fully reconstructs the direct dependencies, indirect transitive dependencies, and conditional triggering relationships between configuration symbols, serving as the core data foundation for subsequent configuration security interception and conflict resolution.

[0024] Step 130, to prevent the risk of new configurations disrupting the existing security system during kernel cross-version upgrades, introduces a static code analysis mechanism to achieve deep modeling of configuration symbol dependencies. The system first reads all native Kconfig files in the kernel source code and generates an Abstract Syntax Tree (AST) through lexical and syntactic analysis, converting unstructured text such as configuration definitions and logical constraints in the Kconfig files into a structured set of syntax nodes. Then, it traverses the AST, extracting dependency keyword information for each configuration symbol, and identifying the dependencies, dependents, and conditional constraint rules for each configuration symbol. Finally, using configuration symbols as nodes and dependencies as edges, a complete symbol dependency graph is constructed, accurately capturing the logical connections between all configurations.

[0025] To prevent the risk of new configurations undermining baseline security configurations through dependencies during kernel version iterations, proactive defense is implemented based on a constructed configuration symbol dependency graph. For example, firstly, based on the configuration symbol dependency graph, the system analyzes the association links between new configuration symbols and baseline security configuration symbols in the hierarchical configuration library. The focus is on detecting whether new configurations use dependency keywords such as `select` in `Kconfig` to form malicious dependency links that forcibly disable or override baseline security enhancements (such as `CONFIG_FORTIFY_SOURCE`). When such configuration dependency attacks are identified, the system triggers a high-risk warning through AST path tracing and forcibly intercepts the process of adding configuration symbols, preventing malicious dependencies from taking effect and eliminating potentially risky configurations. After the above risk interception process, all configurations in the hierarchical configuration library have completed security verification, and there are no malicious association links that threaten baseline security, ultimately forming a risk-filtered configuration library. Through the dependency graph-driven association link identification and interception mechanism, the system accurately prevents silent attacks on baseline security configurations by new configurations, effectively ensuring the security and integrity of the kernel configuration system and building a solid security defense for the stable and compliant operation of subsequent kernel configurations.

[0026] Step 140: Use the configuration symbol dependency graph to identify configuration constraint conflict information in the risk filtering configuration library, convert the configuration constraint conflict information into logical operation parameters, solve to obtain minimum incremental adjustment data, use the minimum incremental adjustment data to correct the configuration directories at each level in the risk filtering configuration library, and generate the target kernel configuration file.

[0027] Minimum incremental adjustment data is the optimal repair solution data proposed for kernel configuration constraint conflict issues. It refers to the minimum set of configuration adjustments that can simultaneously satisfy all configuration constraints, calculated by the logic solving engine, under the premise of absolutely prioritizing the immutability of the baseline layer security configuration. In other words, it can eliminate all dependency conflicts and configuration drift issues by making the fewest modifications to the configuration of the general layer or architecture-specific layer, without large-scale changes to the existing configuration structure, thus achieving seamless self-healing repair of configuration conflicts.

[0028] For example, to address the configuration drift issue caused by dependency conflicts during kernel configuration merging, a minimum incremental self-healing mechanism based on a Boolean satisfiability problem (SAT) logic solving engine is introduced. First, the configuration symbolic dependency graph is invoked to perform a full traversal of the risk-filtering configuration library, identifying all configuration constraint conflicts between the developer's customized configuration intentions and the final kernel generation rules, especially risk scenarios where security baseline items are silently disabled due to dependency conflicts. Then, all identified configuration constraint conflict information is converted into logical operation parameters to construct a Boolean satisfiability problem model. Next, using the configuration content of the baseline layer in the risk-filtering configuration library as a fixed constraint benchmark, the overall logical operation rules are clarified, meaning that no adjustment scheme may modify or cover the security configuration of the baseline layer. The system's built-in SAT solving engine performs logical calculations on the logical operation parameters according to the logical operation rules, calculating the minimum incremental adjustment data that simultaneously satisfies all constraints while prioritizing the preservation of the security baseline. Finally, the minimum incremental adjustment data is used to correct the configuration directories of the general layer and architecture-specific layer in the risk-filtering configuration library, generating the final target kernel configuration file and thus resolving the configuration conflict.

[0029] By using configuration dependency graph-based conflict identification and SAT logic solving, we can achieve accurate detection and minimal-cost self-healing of kernel configuration constraint conflicts. While ensuring that the baseline security configuration is not compromised, we can eliminate configuration drift problems with minimal configuration adjustments. This avoids the high cost and risk of manual conflict investigation and ensures the compliance and stability of kernel configuration, providing a reliable closed-loop guarantee for the secure generation of kernel configuration.

[0030] This embodiment obtains Linux kernel CONFIG configuration symbols, splits these symbols into independent symbol-level atomic configuration files, and categorizes and stores these symbol-level atomic configuration files according to a preset kernel subsystem directory to obtain an initial layered atomic configuration library. The initial layered atomic configuration library is divided into a baseline layer, a general layer, and an architecture-specific layer. Configuration content for different hardware architectures under the same kernel type is retrieved, and symbol-level atomic configuration files with the same values ​​are migrated from the architecture-specific layer to the general layer to obtain a hierarchical regularized configuration library. The kernel's native Kconfig file is parsed to construct a configuration symbol dependency graph. Based on this graph, the association links between newly added configuration symbols and configuration symbols in the baseline layer of the hierarchical regularized configuration library are identified and intercepted to obtain a risk-filtering configuration library. The configuration symbol dependency graph is used to identify configuration constraint conflict information in the risk-filtering configuration library. This conflict information is converted into logical operation parameters, and the minimum incremental adjustment data is obtained. This minimum incremental adjustment data is used to correct the configuration directories at each level in the risk-filtering configuration library to generate the target kernel configuration file. By splitting, classifying, and managing kernel configuration symbols in a hierarchical manner, combined with multi-architecture configuration standardization, dependency link risk interception, and intelligent correction of configuration conflicts, standardized management and security protection of Linux kernel configuration are achieved, ensuring stable and compliant kernel configuration operation.

[0031] Example 2 Figure 2 This is a flowchart of a kernel configuration security enhancement method provided in Embodiment 2 of the present invention. This embodiment is based on the above embodiment and optimized. After the steps of dividing the initial layered atomic configuration library into a baseline layer, a general layer and an architecture-specific layer, retrieving the configuration content of different hardware architectures under the same type of kernel, and migrating the symbol-level atomic configuration files with the same value from the architecture-specific layer to the general layer to obtain the layered regularized configuration library, the method further includes: binding the corresponding audit subject to each layered configuration directory in the layered regularized configuration library; and establishing a targeted audit association mechanism that matches and triggers the corresponding audit subject when the symbol-level atomic configuration file changes.

[0032] See Figure 2 The method for enhancing kernel configuration security includes: Step 210: Obtain the Linux kernel CONFIG configuration symbols, split the CONFIG configuration symbols to generate independent symbol-level atomic configuration files, and classify and store the symbol-level atomic configuration files according to the preset kernel subsystem directories to obtain the initial hierarchical atomic configuration library.

[0033] Step 220: Divide the initial hierarchical atomic configuration library into a baseline layer, a general layer, and an architecture-specific layer. Retrieve the configuration content of different hardware architectures under the same type of kernel. Migrate the symbol-level atomic configuration files with the same values ​​from the architecture-specific layer to the general layer to obtain a hierarchical regularized configuration library. Bind the corresponding audit subject to each level configuration directory in the hierarchical regularized configuration library. Establish a targeted audit association mechanism that matches and triggers the corresponding audit subject when the symbol-level atomic configuration file changes.

[0034] The auditing entity refers to a responsible entity with corresponding professional auditing capabilities and security responsibilities, pre-bound to configuration directories of different levels and subsystems in the hierarchical configuration library. Each auditing entity is bound to a configuration directory; when a configuration in the corresponding directory changes, the auditing entity performs a targeted audit, enabling refined and professional control over configuration changes and preventing unauthorized or non-professional personnel from arbitrarily modifying critical configurations.

[0035] For example, after obtaining the hierarchical configuration repository, the CODEOWNERS function of the Git version control mechanism is integrated to bind corresponding auditing bodies to each level of configuration directory in the hierarchical configuration repository, realizing fine-grained configuration security responsibility binding. Specifically, based on an atomic storage structure, the system maps symbolic atomic configuration files to corresponding physical subsystem directories, and then configures exclusive auditing bodies for different directories. For example, the / configs / * / common / security / directory is bound to the security audit team, the / configs / * / common / net / directory is bound to the network maintenance team, and the / configs / Baseline / directory is forcibly bound to the highest security committee. Subsequently, a targeted audit association mechanism is established. When any underlying atomic configuration file changes, the system automatically triggers and routes it to the corresponding audit flow based on its physical directory. For example, changes to atomic files in the general security directory are automatically routed to the security audit team for auditing, changes to the network subsystem directory are routed to the network maintenance team for auditing, and changes to the global baseline directory are forcibly routed to the highest security committee for auditing. The mechanism establishes a clear security responsibility chain for configuration changes from both physical isolation and process control perspectives, ensuring that critical configuration changes are reviewed by the corresponding professional entities, effectively preventing arbitrary configuration changes and potential security risks.

[0036] Step 230: Parse the kernel native Kconfig file, construct a configuration symbol dependency graph, and based on the configuration symbol dependency graph, identify the association links between newly added configuration symbols and configuration symbols in the baseline layer of the hierarchical regularization configuration library and perform interception processing to obtain the risk filtering configuration library.

[0037] Step 240: Use the configuration symbol dependency graph to identify configuration constraint conflict information in the risk filtering configuration library, convert the configuration constraint conflict information into logical operation parameters, solve to obtain minimum incremental adjustment data, use the minimum incremental adjustment data to correct the configuration directories at each level in the risk filtering configuration library, and generate the target kernel configuration file.

[0038] This embodiment obtains the Linux kernel CONFIG configuration symbols, splits these symbols into independent symbol-level atomic configuration files, and categorizes and stores these symbol-level atomic configuration files according to a preset kernel subsystem directory to obtain an initial hierarchical atomic configuration library. The initial hierarchical atomic configuration library is divided into a baseline layer, a general layer, and an architecture-specific layer. Configuration content for different hardware architectures under the same kernel type is retrieved, and symbol-level atomic configuration files with the same values ​​are migrated from the architecture-specific layer to the general layer to obtain a hierarchical standardized configuration library. Each hierarchical configuration directory in the hierarchical standardized configuration library is bound to a corresponding auditing entity; symbol-level atomic configuration files are then established. When a change occurs, the corresponding audit association mechanism of the audit subject is matched and triggered; the kernel's native Kconfig file is parsed to construct a configuration symbol dependency graph; based on the configuration symbol dependency graph, the association links between the newly added configuration symbols and the configuration symbols in the baseline layer of the hierarchical configuration library are identified and intercepted to obtain the risk filtering configuration library; the configuration constraint conflict information in the risk filtering configuration library is identified using the configuration symbol dependency graph, the configuration constraint conflict information is converted into logical operation parameters, the minimum incremental adjustment data is obtained, and the minimum incremental adjustment data is used to correct the configuration directories of each level in the risk filtering configuration library to generate the target kernel configuration file. Using the above method, hierarchical regularization and precise auditing of kernel configuration are achieved, ensuring that configuration changes can be automatically associated with the corresponding audit subject, thereby forming a closed-loop management mechanism for security policies.

[0039] Example 3 Figure 3 This is a schematic diagram of the kernel configuration security enhancement method apparatus provided in Embodiment 3 of the present invention, as shown below. Figure 3 As shown, the device includes: The splitting module 310 is used to obtain the Linux kernel CONFIG configuration symbols, split the CONFIG configuration symbols to generate independent symbol-level atomic configuration files, and classify and store the symbol-level atomic configuration files according to the preset kernel subsystem directory to obtain the initial hierarchical atomic configuration library. The migration module 320 is used to divide the initial hierarchical atomic configuration library into a baseline layer, a general layer and an architecture-specific layer, retrieve the configuration content of different hardware architectures under the same type of kernel, and migrate the symbol-level atomic configuration files with the same value from the architecture-specific layer to the general layer to obtain a hierarchical regularized configuration library. The identification module 330 is used to parse the kernel native Kconfig file, construct a configuration symbol dependency graph, identify the association links between the newly added configuration symbols and the configuration symbols in the baseline layer of the hierarchical regularization configuration library based on the configuration symbol dependency graph, and perform interception processing to obtain the risk filtering configuration library. The correction module 340 is used to identify configuration constraint conflict information in the risk filtering configuration library using the configuration symbol dependency graph, convert the configuration constraint conflict information into logical operation parameters, solve for the minimum incremental adjustment data, use the minimum incremental adjustment data to correct the configuration directories at each level in the risk filtering configuration library, and generate the target kernel configuration file.

[0040] The kernel configuration security enhancement device provided in this embodiment obtains Linux kernel CONFIG configuration symbols, splits the CONFIG configuration symbols to generate independent symbol-level atomic configuration files, and categorizes and stores the symbol-level atomic configuration files according to a preset kernel subsystem directory to obtain an initial layered atomic configuration library. The initial layered atomic configuration library is divided into a baseline layer, a general layer, and an architecture-specific layer. Configuration content for different hardware architectures under the same type of kernel is retrieved, and symbol-level atomic configuration files with the same values ​​are migrated from the architecture-specific layer to the general layer to obtain a hierarchical regularized configuration library. The kernel's native Kconfig file is parsed to construct a configuration symbol dependency graph. Based on the configuration symbol dependency graph, the association links between newly added configuration symbols and configuration symbols in the baseline layer of the hierarchical regularized configuration library are identified and intercepted to obtain a risk-filtering configuration library. The configuration symbol dependency graph is used to identify configuration constraint conflict information in the risk-filtering configuration library, and the configuration constraint conflict information is converted into logical operation parameters to obtain minimum incremental adjustment data. The minimum incremental adjustment data is used to correct the configuration directories at each level in the risk-filtering configuration library to generate the target kernel configuration file. By splitting, classifying, and managing kernel configuration symbols in a hierarchical manner, combined with multi-architecture configuration standardization, dependency link risk interception, and intelligent correction of configuration conflicts, standardized management and security protection of Linux kernel configuration are achieved, ensuring stable and compliant kernel configuration operation.

[0041] Based on the above embodiments, the migration module includes: The priority setting unit is used to set the hierarchical priority for the baseline layer, the general layer and the architecture-specific layer, wherein the priority is from high to low as the baseline layer, the general layer and the architecture-specific layer; Configure a full set collection unit to collect the full set of hardware architecture configurations corresponding to the same type of kernel; The value comparison unit is used to compare the value status of the same configuration symbol with the complete set of configurations for each hardware architecture to obtain the comparison result; The configuration file filtering unit is used to filter symbol-level atomic configuration files with consistent values ​​in each hardware architecture based on the comparison results. The hierarchical regularization configuration library acquisition unit is used to migrate the filtered symbol-level atomic configuration files from the architecture-specific layer to the general layer to obtain the hierarchical regularization configuration library.

[0042] Based on the above embodiments, the identification module includes: Abstract syntax tree generation unit, used to parse the kernel native Kconfig file and generate an abstract syntax tree; The symbolic dependency graph construction unit is used to parse configuration dependency keywords according to the abstract syntax tree and construct a symbolic dependency graph. The association link identification unit is used to identify the association link between the newly added configuration symbol and the configuration symbol in the baseline layer of the hierarchical regularization configuration library; The interception unit is used to intercept the process of adding configuration symbols when there are attack behaviors in the associated link that force the new configuration symbols to be overridden through dependencies and silently disable security configuration items in the baseline layer, so as to obtain the risk filtering configuration library.

[0043] Based on the above embodiments, the correction module includes: The traversal identification unit is used to call the configuration symbol dependency graph and traverse and identify all configuration constraint conflict information existing in the risk filtering configuration library; A conversion unit is used to convert the identified configuration constraint conflict information into logical operation parameters. The constraint unit is used to constrain the overall logical operation rules by using the configuration content of the baseline layer in the risk filtering configuration library as a fixed constraint benchmark. The solving unit is used to perform logical calculations on the logical operation parameters according to the overall logical operation rules, and solve for the minimum incremental adjustment data.

[0044] The kernel configuration security enhancement device provided in the embodiments of the present invention can execute the kernel configuration security enhancement method provided in any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of the method execution.

[0045] Example 4 Figure 4 This is a schematic diagram of the structure of a terminal provided in Embodiment 4 of the present invention. Figure 4 A block diagram is shown that is suitable for implementing an exemplary terminal 12 of the present invention. Figure 4 The terminal 12 shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of the present invention.

[0046] like Figure 4As shown, terminal 12 is presented in the form of a general-purpose computing terminal. The components of terminal 12 may include, but are not limited to: one or more processors or processing units 16, system memory 28, and bus 18 connecting different system components (including system memory 28 and processing unit 16).

[0047] Bus 18 represents one or more of several bus architectures, including a memory bus or memory controller, a peripheral bus, a graphics acceleration port, a processor, or a local bus using any of the various bus architectures. For example, these architectures include, but are not limited to, the Industry Standard Architecture (ISA) bus, the Micro Channel Architecture (MAC) bus, the Enhanced ISA bus, the Video Electronics Standards Association (VESA) local bus, and the Peripheral Component Interconnect (PCI) bus.

[0048] Terminal 12 typically includes a variety of computer system readable media. These media can be any available media that can be accessed by terminal 12, including volatile and non-volatile media, removable and non-removable media.

[0049] System memory 28 may include computer system readable media in the form of volatile memory, such as random access memory (RAM) 30 and / or cache 32. Terminal 12 may further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, storage system 34 may be used to read and write non-removable, non-volatile magnetic media (… Figure 4 Not shown; usually referred to as a "hard drive"). Although Figure 4 Not shown, a disk drive for reading and writing to a removable non-volatile disk (e.g., a "floppy disk") and an optical disk drive for reading and writing to a removable non-volatile optical disk (e.g., a CD-ROM, DVD-ROM, or other optical media) may be provided. In these cases, each drive may be connected to bus 18 via one or more data media interfaces. System memory 28 may include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of the embodiments of the present invention.

[0050] A program / utility 40 having a set (at least one) of program modules 42 may be stored, for example, in system memory 28. Such program modules 42 include, but are not limited to, an operating system, one or more application programs, other program modules, and program data. Each or some combination of these examples may include an implementation of a network environment. Program modules 42 typically perform the functions and / or methods described in the embodiments of the present invention.

[0051] Terminal 12 can also communicate with one or more external devices 14 (e.g., keyboard, pointing terminal, display 24, etc.), and with one or more terminals that enable a user to interact with terminal 12, and / or with any terminal (e.g., network card, modem, etc.) that enables terminal 12 to communicate with one or more other computing terminals. This communication can be performed via input / output (I / O) interface 22. Furthermore, terminal 12 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 20. As shown, network adapter 20 communicates with other modules of terminal 12 via bus 18. It should be understood that, although not shown in the figures, other hardware and / or software modules can be used in conjunction with terminal 12, including but not limited to: microcode, terminal drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0052] The processing unit 16 executes various functional applications and data processing by running programs stored in the system memory 28, such as implementing the kernel configuration security enhancement method provided in the embodiments of the present invention.

[0053] Example 5 Embodiment 5 of the present invention also provides a storage medium containing computer-executable instructions, which, when executed by a computer processor, are used to perform the kernel configuration security enhancement method as described in any of the above embodiments.

[0054] The computer storage medium of this invention can be any combination of one or more computer-readable media. A computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of computer-readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this document, a computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0055] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, capable of sending, propagating, or transmitting programs for use by or in connection with an instruction execution system, apparatus, or device.

[0056] Program code contained on a computer-readable medium may be transmitted using any suitable medium, including—but not limited to—wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0057] Computer program code for performing the operations of this invention 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 "C" 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 terminal. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0058] Note that the above description is merely a preferred embodiment of the present invention and the technical principles employed. Those skilled in the art will understand that the present invention is not limited to the specific embodiments described herein, and various obvious changes, readjustments, and substitutions can be made without departing from the scope of protection of the present invention. Therefore, although the present invention has been described in detail through the above embodiments, the present invention is not limited to the above embodiments, and may include many other equivalent embodiments without departing from the concept of the present invention, the scope of which is determined by the scope of the appended claims.

Claims

1. A method for kernel configuration security elevation, the method comprising: include: Obtain the Linux kernel CONFIG configuration symbols, split the CONFIG configuration symbols to generate independent symbol-level atomic configuration files, classify and store the symbol-level atomic configuration files according to the preset kernel subsystem directories, and obtain the initial hierarchical atomic configuration library; The initial hierarchical atomic configuration library is divided into a baseline layer, a general layer, and an architecture-specific layer. The configuration content of different hardware architectures under the same type of kernel is retrieved. The symbol-level atomic configuration files with the same value are migrated from the architecture-specific layer to the general layer to obtain a hierarchical regularized configuration library. Parse the kernel's native Kconfig file, construct a configuration symbol dependency graph, identify the association links between newly added configuration symbols and configuration symbols in the baseline layer of the hierarchical regularization configuration library based on the configuration symbol dependency graph, and perform interception processing to obtain the risk filtering configuration library; The configuration constraint conflict information in the risk filtering configuration library is identified using the configuration symbol dependency graph. The configuration constraint conflict information is converted into logical operation parameters, and the minimum incremental adjustment data is obtained. The minimum incremental adjustment data is used to correct the configuration directories at each level in the risk filtering configuration library, and the target kernel configuration file is generated.

2. The method of claim 1, wherein, The step of dividing the initial hierarchical atomic configuration library into a baseline layer, a general layer, and an architecture-specific layer also includes: A hierarchical priority is set for the baseline layer, the general layer, and the architecture-specific layer, with the priority from high to low being the baseline layer, the general layer, and the architecture-specific layer.

3. The method of claim 1, wherein, After the steps of dividing the initial hierarchical atomic configuration library into a baseline layer, a general layer, and an architecture-specific layer, retrieving configuration content from different hardware architectures under the same type of kernel, and migrating the symbol-level atomic configuration files with the same values ​​from the architecture-specific layer to the general layer to obtain the hierarchical regularized configuration library, the method further includes: Bind the corresponding auditing entity to each level configuration directory in the hierarchical configuration library; When a symbol-level atomic configuration file is changed, a targeted audit association mechanism is established to match and trigger the corresponding audit subject.

4. The method of claim 1, wherein, The process of parsing the kernel's native Kconfig file and constructing a configuration symbol dependency graph includes: Parse the kernel's native Kconfig file to generate an abstract syntax tree; Based on the abstract syntax tree, configuration dependency keywords are parsed to construct a symbolic dependency graph.

5. The method of claim 1, wherein, The process involves retrieving configuration content from different hardware architectures under the same kernel type, migrating symbol-level atomic configuration files with identical values ​​from the architecture-specific layer to the general layer, resulting in a hierarchical configuration library, including: Collect the complete set of hardware architecture configurations corresponding to the same type of kernel; For each hardware architecture configuration set, compare the value status of the same configuration symbol to obtain the comparison result; Based on the comparison results, select symbol-level atomic configuration files with consistent values ​​in each hardware architecture; The selected symbol-level atomic configuration files are migrated from the architecture-specific layer to the general layer to obtain a hierarchical regularized configuration library.

6. The method of claim 1, wherein, The process of identifying configuration constraint conflict information in the risk filtering configuration library using the configuration symbolic dependency graph, converting the configuration constraint conflict information into logical operation parameters, and solving for the minimum incremental adjustment data includes: The configuration symbol dependency graph is invoked to traverse and identify all configuration constraint conflict information existing in the risk filtering configuration library; The identified configuration constraint conflict information is converted into logical operation parameters; The configuration content of the baseline layer in the risk filtering configuration library is used as a fixed constraint benchmark to constrain the overall logical operation rules; Based on the overall logical operation rules, logical calculations are performed on the logical operation parameters to obtain the minimum incremental adjustment data.

7. The method of claim 1, wherein, The process of identifying the association links between newly added configuration symbols and baseline layer configuration symbols in the hierarchical regularization configuration library and performing interception processing yields a risk filtering configuration library, including: Identify the association links between newly added configuration symbols and configuration symbols within the baseline layer of the hierarchical regularization configuration library; When there are attacks in the associated links where new configuration symbols are forcibly overwritten through dependencies or security configuration items in the baseline layer are silently disabled, the process of adding configuration symbols is intercepted to obtain the risk filtering configuration library.

8. A kernel configuration security enhancing apparatus, comprising: include: The splitting module is used to obtain Linux kernel CONFIG configuration symbols, split the CONFIG configuration symbols to generate independent symbol-level atomic configuration files, and classify and store the symbol-level atomic configuration files according to the preset kernel subsystem directories to obtain the initial hierarchical atomic configuration library. The migration module is used to divide the initial hierarchical atomic configuration library into a baseline layer, a general layer and an architecture-specific layer, retrieve the configuration content of different hardware architectures under the same type of kernel, and migrate the symbol-level atomic configuration files with the same values ​​from the architecture-specific layer to the general layer to obtain a hierarchical regularized configuration library. The identification module is used to parse the kernel's native Kconfig file, construct a configuration symbol dependency graph, identify the association links between newly added configuration symbols and configuration symbols in the baseline layer of the hierarchical regularization configuration library based on the configuration symbol dependency graph, and perform interception processing to obtain a risk filtering configuration library. The correction module is used to identify configuration constraint conflict information in the risk filtering configuration library using the configuration symbol dependency graph, convert the configuration constraint conflict information into logical operation parameters, solve for the minimum incremental adjustment data, use the minimum incremental adjustment data to correct the configuration directories at each level in the risk filtering configuration library, and generate the target kernel configuration file.

9. A terminal, characterized by comprising: The terminal includes: One or more processors; Storage device for storing one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the kernel configuration security enhancement method as described in any one of claims 1-7.

10. A storage medium containing computer-executable instructions, which, when executed by a computer processor, are used to perform the kernel configuration security enhancement method as described in any one of claims 1-7.

Images