A process security dynamic management method and system based on LSM

Abstract

The application provides a process security dynamic management and control method and system based on LSM, and the management and control is realized based on a policy rule library combined with a user domain and a process domain. When a target process executes an execve system call, a double-domain attribute is extracted in a security execution window, a rule library is traversed to complete matching and decision, and a policy domain mark is generated and written into a process security credential structure. When a subsequent system call is triggered, an LSM hook function reads the mark to determine an effective policy and decides an operation, and if the operation is rejected, an exception event is generated and hierarchical restriction is triggered. The application separates policy matching and runtime decision, reduces system call overhead, avoids kernel crash risk, and guarantees system stability and process security.

Description

Technical Field

[0001] This invention relates to the field of computer process security management technology, and in particular to a process security dynamic management method and system based on LSM. Background Technology

[0002] In cloud-native multi-tenant environments, implementing fine-grained security control of processes using a combination of user domain and process domain is essential for ensuring multi-tenant isolation. Achieving this within the existing LSM framework of the Linux kernel faces a technical dilemma. A single-dimensional approach that only matches executable file paths is relatively simple, but it cannot distinguish between different programs under the same user or different users under the same program, failing to meet the differentiated management needs of multi-tenants. If a combined approach is adopted, synchronously extracting the process's user attributes and executable program attributes in each LSM hook triggered by a system call and performing a full rule traversal and matching introduces both performance and stability issues. In terms of performance, each hook execution repeatedly traverses the rule base and performs attribute matching, increasing the system call response time with the number of rules. In terms of stability, LSM hooks run in the RCU read critical section, where the kernel prohibits file path resolution operations that might trigger page faults, as well as memory allocation and time-consuming traversal operations. Forcing these operations could lead to kernel crashes or service interruptions. Existing technologies optimize the matching process within the framework of each hook execution, without changing the coupled execution of matching and adjudication within the same LSM hook function. Therefore, it is difficult to simultaneously meet the requirements of composable fine-grained control, low performance overhead, and system stability, and thus has shortcomings. Summary of the Invention

[0003] This application provides a method for dynamic process security management based on LSM. In multi-tenant scenarios where there is a need to implement combined management of user identity and executable program for processes, this method can avoid the kernel performance loss caused by performing full rule matching every system call, and also prevent kernel stability risks caused by performing operations such as file path resolution in the RCU read critical section of LSM hook functions.

[0004] This application discloses a method for dynamic process security management based on LSM, including: Process operation control is implemented based on a pre-built policy rule base, which is a collection of rules configured based on a combination of user domain and process domain. The method includes: When the target process executes the execve system call, within the secure execution window after the process security credential structure is initialized and before the executable file is loaded, the user domain attributes and process domain attributes of the target process are extracted. The policy rule base is traversed to complete the combination matching and conflict resolution of user domain and process domain, determine the effective policy and generate a uniquely bound policy domain tag, and write the policy domain tag into the process security credential structure. The secure execution window is the execution period when the process is in a single-threaded state and is not in the RCU read critical section. When the target process subsequently triggers a system call, the policy domain flag is read from the process security credential structure in the LSM hook function to determine the effective policy, and the current operation is adjudicated based on the longest prefix matching and explicit rejection priority rules; When the ruling is a rejection, an exception event is generated and tiered restriction measures are triggered.

[0005] Optionally, the step of extracting the user domain attributes and process domain attributes of the target process, traversing the policy rule base to complete the combination matching and conflict adjudication of user domain and process domain, determining the effective policy, and generating a uniquely bound policy domain tag includes: Obtain the valid user identifier, user name, and user group information mapped by the target process within its user namespace, and use them as the user domain attributes; Obtain the absolute path of the executable file and the process namespace isolation attribute of the target process within its mounted namespace, and use them as the process domain attribute; Traverse the rules in the policy rule base, filter out the rules whose user domain selector matches the user domain attribute and whose process domain selector matches the process domain attribute, and form a candidate rule set; Conflict resolution is performed on the candidate rule set to determine the effective policy and generate a policy domain tag that uniquely corresponds to the effective policy.

[0006] Optionally, the conflict resolution of the candidate rule set includes: The rule that takes effect is selected from the candidate rule set in the following decision order: priority of explicit rejection rule, priority of matching accuracy, and priority of explicit priority value.

[0007] Optionally, writing the policy domain tag into the process security credential structure includes: Within the secure execution window, the policy domain flag is written into the security extension field of the process security credential structure, and the kernel RCU mechanism and copy-on-write mechanism are configured for the policy domain flag in the process security credential structure.

[0008] Optional, also includes: When it is detected that the target process modifies the user identity or namespace attributes through a system call, the execution of the current system call is paused, the user domain attributes and process domain attributes of the target process are extracted again, the policy rule base is re-traversed to complete the combination matching and conflict resolution of user domain and process domain, a new policy domain tag is generated and updated to the process security credential structure, and then the current system call is allowed to continue execution.

[0009] Optionally, reading the policy domain flag from the process security credential structure in the LSM hook function to determine the effective policy includes: The read operation marked by the policy domain is performed within the RCU read critical section. During the read process, no locking is performed, no page fault is triggered, and no sleep operation is performed. The corresponding effective policy is retrieved from the pre-maintained policy mapping table based on the read policy domain flag.

[0010] Optionally, the decision on the current operation based on the longest prefix match and the explicit rejection priority rule includes: Iterate through the rules in the effective strategy that match the operation type of the current operation, and filter out the valid rules that match the operation object with the prefix defined in the rule definition; Record the longest prefix length of the allowed rules and the longest prefix length of the rejected rules in the valid rules respectively; When a matching rejection rule exists and the longest prefix length of the rejection rule is greater than or equal to the longest prefix length of the allow rule, the current operation is decided as a rejection; When there is no matching rejection rule, or the longest prefix length of the rejection rule is less than the longest prefix length of the allow rule, the current operation is ruled as allowable.

[0011] Optionally, generating abnormal events and triggering tiered restriction measures includes: A structured exception event is generated based on the exception type of the current operation, the operation object, the process identifier of the target process, and the namespace information. The structured exception event is written to a lock-free circular buffer in kernel space through atomic operations, and then asynchronously pushed to the user space event queue through the Netlink communication mechanism. Within a preset sliding time window, abnormal events corresponding to the target process are counted. When an abnormal event triggers a preset threshold condition, a graded restriction measure is issued to the target process.

[0012] Optionally, the step of issuing tiered restriction measures to the target process when an abnormal event triggers a preset threshold condition includes: Depending on the severity of the anomaly, corresponding levels of restrictive measures are issued to the target process. These tiered restrictive measures include alarms, resource rate limiting, resource flow limiting, and system call blocking.

[0013] This application also discloses a process security dynamic management system based on LSM, including: The pre-verification policy adjudication module is used to extract the user domain attributes and process domain attributes of the target process within the safe execution window after the process security credential structure is initialized and before the executable file is loaded when the target process executes the execve system call. It then traverses the policy rule base to complete the combination matching and conflict adjudication of user domain and process domain, determines the effective policy, generates a uniquely bound policy domain tag, and writes the policy domain tag into the process security credential structure. The safe execution window is the execution period when the process is in a single-threaded state and is not in the RCU read critical section. The hook execution verification module is used to read the policy domain flag from the process security credential structure in the LSM hook function to determine the effective policy when the target process subsequently triggers a system call, and adjudicate the current operation based on the longest prefix matching and explicit rejection priority rule; The closed-loop detection response module is used to generate an abnormal event and trigger tiered restriction measures when the decision result is rejection.

[0014] As described in the above technical solution, when the target process executes the `execve` system call, it utilizes the secure execution window after the process security credential structure is initialized and before the executable file is loaded. Within this window, the process is in a single-threaded state and not in the RCU read critical section, possessing the conditions for file path resolution and full rule traversal. Within this window, the extraction of user domain attributes and process domain attributes, full rule traversal, and conflict resolution are completed in one go, and the matching result is compressed into a policy domain flag and written to the process security credential structure. Subsequently, when the target process triggers any system call during runtime and enters the corresponding LSM hook function, the LSM hook function only needs to directly read the policy domain flag from the process security credential structure to determine the effective policy, without needing to perform attribute extraction and full rule traversal again, reducing the computational load on each system call path from full traversal to a single flag read. Since the mark-read operation only involves field access to kernel-resident memory structures, without file path resolution, page faults, or sleep operations, it conforms to the RCU critical section execution specification, thus avoiding the kernel crash risk that might be caused by performing abnormal operations in LSM hook functions. Simultaneously, after the policy domain mark is written to the process security credential structure, it is protected by the structure's own copy-on-write mechanism, preventing unauthorized modifications from taking effect. Furthermore, when the adjudication result is rejection, an exception event is generated and asynchronously pushed to user space via a lock-free circular buffer. Exception events are statistically analyzed based on a sliding time window, and tiered restriction measures are triggered according to the statistical results, forming a complete processing procedure from operation interception to process control. These features work together to confine complex policy matching calculations to a security window. The runtime adjudication path only retains mark reading and lightweight prefix matching, thereby reducing the performance overhead of system calls and maintaining system stability while achieving combined control of user identity and executable programs. Attached Figure Description

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

[0016] Figure 1 This is a flowchart illustrating a process security dynamic management method based on LSM in an embodiment of this application; Figure 2 This is a flowchart illustrating S100 of a process security dynamic management method based on LSM in an embodiment of this application. Figure 3This is a flowchart illustrating the process security dynamic management method based on LSM in embodiment of this application, where S200 determines the effective policy. Figure 4 This is a flowchart illustrating the S200 operation decision of a process security dynamic control method based on LSM in an embodiment of this application. Figure 5 This is a flowchart illustrating S300, a process security dynamic management method based on LSM, in an embodiment of this application. Figure 6 This is a schematic diagram of a process security dynamic management method and system based on LSM in an embodiment of this application. Detailed Implementation

[0017] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not limiting, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application can also be implemented in other embodiments without such specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods are omitted so as not to obscure the description of this application with unnecessary detail.

[0018] In this embodiment, process security management is implemented based on the Linux kernel's LSM framework. The LSM framework provides a series of LSM hook functions along multiple system call execution paths within the kernel. Security modules can register these LSM hook functions. When a process triggers a corresponding system call, the kernel calls back the registered LSM hook functions, executing security verification logic within them. In the Linux kernel, the execve system call is used to load and execute an executable file. Its internal processing flow includes: parsing the executable file's binary format, initializing a new process security credential structure, loading the executable file's code and data segments, and switching the process address space.

[0019] It's important to note that the Process Security Credentials (PSC) structure is a core data structure in the kernel that stores process security attribute information. It includes the process's effective user identifier, actual user identifier, file system user identifier, saved settings user identifier, primary group identifier, list of secondary group identifiers, capability set bitmap, and LSM security extension fields. Almost all permission verification operations in the kernel refer to the fields in the PSC structure. Concurrent access to this structure is protected by two mechanisms: the Restricted Read Control (RCU) mechanism allows readers to read any field of the structure without locks within the RCU critical section, but requires that page access that might cause a page fault, active sleeping, and scheduling switching not occur within the critical section; the Copy-on-Write (COW) mechanism requires that any operation that needs to modify the structure must first call the kernel's PSC structure copy function to obtain an independent copy of the current structure, complete the necessary modifications on the copy, and then call the commit function to atomically replace the original structure pointer with the copy pointer. After an RCU grace period, confirming that all processor cores have exited reference to the old structure, the original structure is reclaimed and released by the kernel.

[0020] For example, let's first describe an existing LSM-based process security management scheme. This scheme uses the executable file path as the matching dimension to configure uniform access rules for a specified executable file, restricting the program's access to specific directories or files. In a specific multi-tenant scenario, two container instances, belonging to tenant A and tenant B, run simultaneously on a physical host. Tenant A runs a web service program with user ID 1001, and the executable file path is / usr / bin / webserver; tenant B runs the same web service program with a different user ID 1002, and the executable file path is also / usr / bin / webserver. The administrator wants to implement differentiated security management policies: allowing tenant A's web service process to read static files in the / var / www / static directory, but prohibiting it from reading configuration files in the / etc / webserver / directory; while allowing tenant B's web service process to read both directories. When using the existing path-based single-dimensional matching scheme, since both tenants are running the same executable file, the system can only configure the same set of rules for all web server processes, making it impossible to distinguish the tenant affiliation of the process to achieve differentiated management. If we attempt to synchronously read the process's user ID and executable file path in each LSM hook function corresponding to a file access, and perform combination matching of user attributes and program paths, then a full rule traversal and string prefix comparison operation needs to be performed in each LSM hook function. When an LSM hook function is called, it is already within the RCU read critical section. Reading the executable file path may access user-space pages that have not yet been mapped to physical memory, triggering a page fault. The page fault handling process may trigger process scheduling, violating the execution rules of the RCU read critical section, and in severe cases, triggering the kernel's RCU deadlock detection or protection mechanism, leading to a system restart. Furthermore, the repeated rule traversal in each LSM hook function accumulates considerable computational overhead in scenarios where processes frequently trigger system calls.

[0021] Based on this, this application provides a method for dynamic process security management based on LSM, which implements process operation management based on a pre-built policy rule base. The policy rule base is a collection of rules configured based on a combination of user domain and process domain, such as... Figure 1 As shown, the method includes: S100: When the target process executes the execve system call, within the secure execution window after the process security credential structure is initialized and before the executable file is loaded, the user domain attributes and process domain attributes of the target process are extracted. The policy rule base is traversed to complete the combination matching and conflict resolution of user domain and process domain, determine the effective policy and generate a uniquely bound policy domain tag, and write the policy domain tag into the process security credential structure. The secure execution window is the execution period when the process is in a single-threaded state and is not in the RCU read critical section.

[0022] S200: When the target process subsequently triggers a system call, the policy domain flag is read from the process security credential structure in the LSM hook function to determine the effective policy, and the current operation is adjudicated based on the longest prefix matching and explicit rejection priority rule; S300: When the ruling is a rejection, an exception event is generated and a tiered restriction measure is triggered.

[0023] It should be noted that this application proposes a method to separate the matching calculation of process security policies from runtime operation adjudication in terms of both time and execution environment. In existing technologies, policy matching is always completed in the LSM hook with each system call. Due to the RCU read critical section constraint where the hook is located, operations such as file path resolution cannot be performed safely, while the combined control of user identity and executable program requires such operations. This invention utilizes a specific execution period in the execve system call process, namely the time after the process security credential structure is initialized and before the executable file is loaded. During this period, the process is in a single-threaded state and has not yet held an RCU read lock, is not in the RCU read critical section, and has the safe conditions to perform file path resolution, full rule traversal, and memory allocation. Within this safe execution window, user domain attribute extraction, process domain attribute extraction, full policy rule traversal, and conflict adjudication are completed in one go. The matching result is compressed into a policy domain tag, and this tag is written into the process security credential structure. Subsequently, when a process triggers an arbitrary system call, the corresponding LSM hook function only needs to read the policy domain flag directly from the process security credential structure to determine the effective policy, and then perform lightweight operation adjudication, without having to perform attribute extraction and rule traversal again. This method concentrates the time-consuming matching operations within a single security window, reducing the computational load on the runtime adjudication path to flag reading and prefix matching, and achieving composable process control without violating the kernel RCU critical section execution specification.

[0024] The embodiments of this application will be described in detail below.

[0025] The LSM-based dynamic process security management method provided in this application, through analysis of the internal execution flow of the `execve` system call, reveals that during the execution period after the process security credential structure is initialized and before the executable file's code and data segments are officially loaded and begin execution, the process is in a single-threaded execution path in kernel mode. At this time, it does not hold an RCU read lock and is not in an RCU read critical section. Within this secure execution window, the kernel allows operations that may cause blocking or page faults, such as file system access, pathname component resolution, and dynamic memory allocation. This application utilizes this window characteristic to centralize time-consuming operations such as user attribute extraction, program attribute extraction, full rule traversal, and conflict resolution, which were originally scattered across various LSM hook functions, into a single secure execution window. This generates a policy domain marker uniquely corresponding to the effective policy and writes this marker into the process security credential structure. Subsequently, when any system call is triggered during process execution, the corresponding LSM hook function only needs to read this policy domain marker from the process security credential structure.

[0026] In this embodiment, the policy rule base is a set of rules pre-built and distributed to the kernel space. Each rule in the policy rule base consists of a user domain selector, a process domain selector, and rule action information. The user domain selector defines the scope of user identities to which the rule applies. It can be configured as one or more of the following: user identifier value, username string, and user group identifier. The matching logic can be specified as either passing if any one of the specified items is met or passing only if all the specified items are met. The process domain selector defines the scope of executable programs to which the rule applies. It can be configured as the absolute path or path prefix of the executable file, the mount namespace isolation attribute status, the network namespace isolation attribute status, etc., and also supports configuring matching logic. The rule action information includes the action type and operation definition. The action type is divided into allow and deny, and the operation definition includes the operation type and the operation object prefix. The policy rule base supports dynamic incremental updates during system runtime. During the update, the kernel builds a new complete rule base in a temporarily allocated memory area, performs syntax checks and conflict pre-checks on the new rule base, and atomically replaces the pointer of the currently effective rule base with the pointer of the new rule base through the RCU mechanism after the check passes. The old rule base is reclaimed after the RCU grace period ends. The entire replacement process does not involve restarting business processes, nor does it affect the rule matching of ongoing system calls.

[0027] In alternative implementations, such as Figure 2 As shown, step S100 extracts the user domain attributes and process domain attributes of the target process, traverses the policy rule base to complete the combination matching and conflict adjudication of user domain and process domain, determines the effective policy, and generates a uniquely bound policy domain tag, including: S110: Obtain the valid user identifier, user name, and user group information mapped by the target process within its user namespace, and use them as the user domain attributes.

[0028] S120: Obtain the absolute path of the executable file and the process namespace isolation attribute of the target process within its mounted namespace, and use them as the process domain attribute.

[0029] S130: Traverse the rules in the policy rule base, filter out the rules whose user domain selector matches the user domain attribute and whose process domain selector matches the process domain attribute, and form a candidate rule set.

[0030] S140: Perform conflict resolution on the candidate rule set, determine the effective policy, and generate a policy domain tag that uniquely corresponds to the effective policy.

[0031] In this embodiment, when the target process executes the execve system call, the kernel, following the execve execution flow, first initializes a new process security credential structure for the process, parses the binary format information of the executable file, and then, before loading the actual content of the executable file, enters the LSM hook function registered in this application. This LSM hook function first extracts the user domain attributes of the target process within the execution context.

[0032] User domain attribute extraction involves reading the valid user identifier value from the process security credential structure; obtaining the valid user identifier of the process after mapping within its own user namespace from the user identifier mapping relationship of the user namespace. In containerized environments with user namespace isolation, the user identifier within the container may differ from the global user identifier on the host; therefore, the extracted user identifier is the valid user identifier from the perspective of the process within the container; reading the username string; and reading the primary group identifier and the list of secondary group identifiers. This attribute information is obtained directly from the process security credential structure and the user namespace data structure, without involving access to user-mode memory.

[0033] Meanwhile, the LSM hook function extracts the process domain attributes of the target process, obtains the absolute path of the executable file in the process's own mount namespace from the executable file path field of the process. This path is a path description from the perspective of the process's own runtime environment, rather than a path under the host's global root file system. It reads the isolation status indicators of the mount namespace, user namespace, network namespace, and process identifier namespace from the process's namespace descriptor, such as whether the mount namespace is the same as the initial namespace, and whether it is in an independent container network namespace, etc.

[0034] After extracting user domain and process domain attributes, the LSM hook function iterates through all rule entries in the policy rule base. For each rule, the extracted user domain attributes are compared with the rule's user domain selector, and the extracted process domain attributes are compared with the rule's process domain selector. A rule is included in the candidate rule set only if both dimensions' selectors are determined to match. For example, if a rule's user domain selector is configured to match user ID 1001 or username webapp, and its process domain selector is configured to match executable file path prefixes / usr / bin / webserver and requires the mount namespace to be isolated, then the rule will only enter the candidate rule set if a process's effective user ID is 1001 or username is webapp, and its executable file path begins with / usr / bin / webserver and is located in an isolated mount namespace. If a process's executable path and isolation attributes meet the requirements of the process domain selector, but its valid user identifier does not fall within the scope specified by the user domain selector, then the rule will not be included in the candidate rule set.

[0035] In an optional implementation, S140 performs conflict resolution on the candidate rule set, including: S141: Select the only effective rule from the candidate rule set as the effective strategy according to the decision order of explicit rejection rule priority, matching accuracy priority, and explicit priority value priority.

[0036] After all rules have been traversed, if the candidate rule set contains only one rule, that rule is directly selected as the effective policy. If the candidate rule set contains multiple rules, conflict resolution is performed on these rules to select a unique effective policy. Conflict resolution is performed in a three-level order. The first level prioritizes explicit rejection rules: it checks if there are rules in the candidate rule set with the action type "reject." If so, these rejection rules are weighted in the priority ranking. This does not mean that any rejection rule wins unconditionally, but rather proceeds to the second level for comparison. The second level prioritizes matching accuracy: it compares the number of attribute items actually matched by each rule in the user domain selector and process domain selector, as well as the length of the executable file path prefix in the process domain selector. The more attribute items matched and the longer the path prefix matched, the higher the matching accuracy of the rule, and the higher its priority in the ranking. The third level prioritizes explicit priority values: when the above two levels of comparison still cannot distinguish the priority, the priority value field configured in the rule is compared, and the rule with the smaller value has a higher priority. Through the above three-level decision-making order, a unique rule is determined from the candidate rule set as the effective policy.

[0037] After the effective policy is determined, the LSM hook function generates a uniquely bound policy domain tag for that policy. The policy domain tag is a numerical identifier that has a one-to-one correspondence with the effective policy. The kernel maintains a policy mapping table, which uses the policy domain tags as indexes to store the memory address or policy content reference of the effective policy corresponding to each tag. After the policy domain tag is generated, the correspondence between the tag's value and the effective policy is written into the policy mapping table, allowing for direct lookup of the corresponding effective policy content using the tag's value later.

[0038] In an optional implementation, step S100, writing the policy domain tag into the process security credential structure, includes: S110: Within the secure execution window, the policy domain marker is written into the security extension field of the process security credential structure, and the kernel RCU mechanism and copy-on-write mechanism are configured for the policy domain marker in the process security credential structure.

[0039] Specifically, after the policy domain marker is generated, the LSM hook function writes the value of the marker into the security extension field of the target process's process security credential structure within the current secure execution window. The security extension field is a private storage area allocated by the LSM framework for each registered LSM module within the process security credential structure. Security data from different LSM modules is stored at different offsets, ensuring they do not interfere with each other. The write operation occurs within the secure execution window, at which point the process security credential structure is initialized and not yet referenced by other processor cores or execution paths, eliminating concurrent reads and making the write process safe. After the write is complete, the policy domain marker becomes part of the process security credential structure. Subsequent reads of this marker can be completed lock-free within the RCU read critical section using the kernel's native RCU read path. Modifications to this marker must adhere to the copy-on-write rule: the caller must first obtain an independent copy of the current structure through the kernel-provided process security credential structure copy interface, modify the value of the policy domain marker in the security extension field of the copy, and then call the commit interface to atomically replace the original structure pointer with the copy pointer. Any operation that bypasses the copy and commit process and directly modifies the flag field in the original structure will not have a visible impact on other processor cores that are using the structure, under the protection of the copy-on-write mechanism. This is because other cores still read the old value through the original structure pointer until the core exits the RCU read critical section and enters a new RCU grace period, at which point it will be aware of the pointer replacement.

[0040] In an optional implementation, the LSM-based dynamic process security management method further includes: S400: When it is detected that the target process modifies the user identity or namespace attributes through a system call, the execution of the current system call is paused, the user domain attributes and process domain attributes of the target process are extracted again, the policy rule base is re-traversed to complete the combination matching and conflict resolution of user domain and process domain, a new policy domain tag is generated and updated to the process security credential structure, and then the current system call is allowed to continue execution.

[0041] Furthermore, this application inserts an identity change monitoring mechanism into the LSM hook function corresponding to the process security credential structure submission function. During process execution, a process may modify its effective user identifier or effective group identifier through the setuid and setgid system calls, or switch or create a new namespace through the setns and unshare system calls. These operations will cause substantial changes to the process's user domain attributes or process domain attributes, and the previously generated policy domain marker may no longer correspond to the correct effective policy. The identity change monitoring mechanism works as follows: when a process executes the above-mentioned system calls that may change user identity or namespace attributes, the kernel will call the LSM hook function registered in this application before submitting these attribute changes to the process security credential structure. The LSM hook function checks the attribute types involved in the change. If it finds changes to the valid user ID, valid group ID, mounted namespace, user namespace, or network namespace, it pauses the execution of the current system call. Using the updated user domain and process domain attributes as input, it re-executes a full policy rule traversal and conflict resolution. Based on the new matching results, it generates a new policy domain tag. Then, in the copy of the new process security credential structure to be submitted, it updates the policy domain tag of the security extension field to the new value, and allows the system call to continue its submission operation. Through this mechanism, the process identity change and policy tag update are completed atomically within the same system call execution flow, avoiding the time window between identity change and policy update, and preventing processes from bypassing control policies by using identity switching.

[0042] In alternative implementations, such as Figure 3 As shown, S200 reads the policy domain flag from the process security credential structure in the LSM hook function to determine the effective policy, including: S210: Execute the read operation marked by the policy domain within the RCU read critical section. During the read process, no locking is performed, no page fault exception is triggered, and no sleep operation is performed. S220: Based on the read policy domain tag, look up the corresponding effective policy from the pre-maintained policy mapping table.

[0043] After the target process completes the `execve` system call and officially enters user-mode program execution, it will trigger various system calls during its operation, such as file opening, file reading and writing, network socket creation and connection, port listening, and process capability verification. When the target process triggers a system call, the kernel will call the LSM hook function registered in this application at the corresponding checkpoint in the execution flow of that system call. The LSM hook function is already within the RCU read critical section when it is called. The LSM hook function first obtains the process descriptor pointer of the target process through the current process macro provided by the kernel, locates the process security credential structure pointer of the process from the process descriptor, and then reads the value of the policy field flag from the security extension field of the process security credential structure. This read process only involves accessing fields at fixed offset positions in the kernel resident memory structure, does not involve file system operations, does not access user-mode memory areas that may not yet be mapped to physical pages, does not trigger page faults, and does not execute kernel function calls that may cause sleep, fully complying with the execution constraints of the RCU read critical section. After reading the policy domain tag, the LSM hook function looks up the corresponding effective policy from the pre-maintained policy mapping table using the tag as the index, and directly obtains all the control rules corresponding to the process. The whole process does not require any attribute extraction or rule base traversal operations.

[0044] In alternative implementations, such as Figure 4 As shown, the S200 operation, which decides the current operation based on the longest prefix match and the explicit rejection priority rule, includes: S230: Traverse the rules in the effective strategy that match the operation type of the current operation, and filter out the valid rules that match the operation object with the prefix of the rule definition; S240: Record the longest prefix length of the allowed rule and the longest prefix length of the rejected rule in the valid rules respectively; S250: When a matching rejection rule exists and the longest prefix length of the rejection rule is greater than or equal to the longest prefix length of the allow rule, the current operation is decided as a rejection; S260: When there is no matching rejection rule, or the longest prefix length of the rejection rule is less than the longest prefix length of the allow rule, the current operation is ruled as allowable.

[0045] LSM hook functions extract the operation type and operation object from the parameters of the current system call request. The operation type is determined based on the semantics of the system call. For file-related system calls, such as open, read, write, rename, and unlink, the operation types are file open, file read, file write, file rename, and file delete, respectively. For network-related system calls, such as connect, bind, and listen, the operation types are network connection, port binding, and port listening, respectively. For permission-related system calls, such as capability checks, the operation type is capability verification. The operation object varies depending on the operation type: for file operations, the operation object is the file path string specified in the system call parameters; for network operations, the operation object is the target network address and port number; for capability operations, the operation object is the requested capability identifier value.

[0046] After extracting the operation type and operation object, the LSM hook function searches for the rule group corresponding to that operation type in the effective policy. The effective policy is divided into multiple independent rule groups based on different operation types, such as file operation rule groups, network operation rule groups, and capability operation rule groups. If there is no corresponding rule group for the current operation type, the default policy is applied, which can be either all allowed or all denied. If a corresponding rule group exists, the LSM hook function iterates through each rule in that rule group, comparing the current operation object with the prefix defined in the rule. Prefix matching is performed by checking if the beginning of the operation object string is exactly the same as the prefix string defined in the rule. For example, if a rule defines the prefix as / var / www / static, then the operation object / var / www / static / index.html matches the rule because / var / www / static is the prefix of that path; the operation object / var / log / messages does not match the rule because there is no prefix relationship between them. During the iteration process, successfully matched rules are recorded according to their action types. If the rule's action type is "allow," its prefix length is recorded; if the rule's action type is "deny," its prefix length is also recorded. After traversal, the rule with the largest prefix length among all matching allow rules is selected as the prefix length of the longest allow rule; similarly, the rule with the largest prefix length among all matching deny rules is selected as the prefix length of the longest deny rule. After prefix matching and length recording, the final allow or deny decision is made according to the explicit deny priority rule. The decision logic is as follows: if a matching deny rule exists, and the maximum prefix length of the deny rule is greater than or equal to the maximum prefix length of the allow rule, the current operation is decided as a denial; if no matching deny rule exists, or if a matching deny rule exists but its longest prefix length is less than the longest prefix length of the allow rule, the current operation is decided as an allow. This decision logic ensures that denial actions take precedence when deny rules are matched with the same or higher precision.

[0047] When the decision is "allow," the LSM hook function returns an "execution allowed" result to the kernel, and the kernel continues to execute the subsequent processing flow of the system call, with normal process operation unaffected. When the decision is "deny," the LSM hook function returns a "execution denied" result to the kernel, the system call is aborted, and an insufficient privilege error code is returned to user space.

[0048] In alternative implementations, such as Figure 5 As shown, the S300 generates an abnormal event and triggers tiered restriction measures, including: S310: Generate a structured exception event based on the exception type of the current operation, the operation object, the process identifier of the target process, and the namespace information; S320: The structured exception event is written to the kernel-mode lock-free circular buffer through atomic operations, and the structured exception event is asynchronously pushed to the user-mode event queue through the Netlink communication mechanism; S330: Within a preset sliding time window, count the abnormal events corresponding to the target process. When an abnormal event triggers a preset threshold condition, issue a graded restriction measure to the target process.

[0049] While returning a rejection result, the LSM hook function generates a structured exception event based on the currently rejected operation. The structured exception event includes: an exception type field, categorized as a file exception, network exception, or capability exception based on the operation type; an operation target field, recording the specific details of the file path, network address, or capability identifier that was denied access; a process identifier field, recording the process ID of the target process that triggered the exception; a namespace information field, recording the mounted namespace identifier and process identifier namespace identifier of the target process, used to distinguish potentially duplicate process IDs in different namespaces in a multi-container environment; and a timestamp field, recording the kernel time when the exception event occurred. The LSM hook function writes the generated structured exception event to a pre-allocated lock-free circular buffer in kernel memory space using atomic operations. The lock-free circular buffer maintains independent read and write pointers. The write operation updates the write pointer position through an atomic swap instruction, copies the event data to the position pointed to by the write pointer in the buffer, and then moves the write pointer forward by the corresponding step using an atomic addition instruction. When multiple processor cores simultaneously trigger exception event writes, each competes for the right to update the write pointer through atomic operations, without the need for mutexes or spinlocks. The write operation does not block the execution flow of the LSM hook function. After the write is complete, the LSM hook function sends an event arrival notification to the user-space daemon via a Netlink socket. Netlink is an asynchronous communication mechanism provided by the Linux kernel; notification sending is non-blocking and does not affect the return of the LSM hook function or the end of system calls. The actual reading of the event data is performed by the user-space program from the circular buffer after receiving the notification. The user-space daemon creates a Netlink socket at startup and binds it to the kernel's event notification group, receiving asynchronous notifications from the kernel through this socket. Upon receiving the notification, the daemon reads the exception event data from the read pointer position of the lock-free circular buffer, stores the event data in the event queue maintained in user space, and updates the read pointer. The daemon aggregates abnormal events in the event queue using the process identifier as the primary key. It maintains a sliding time window statistical structure with a preset fixed duration and a fixed sliding step. At the end of each sliding step, the statistical window slides forward one step, removing all events with timestamps earlier than the current window's start time from the count, retaining only events within the current window. Within the window, for each target process, the number of abnormal events is accumulated, and a weighted cumulative value is added based on the preset weight value corresponding to the exception type of each event. Different exception types are configured with different weights; for example, accessing sensitive system configuration files has a lower weight than accessing user authentication information files. When a process's number of exceptions within the sliding time window reaches a preset threshold, or its weighted cumulative value reaches a preset weight threshold, the daemon determines that the process has triggered a restriction condition.

[0050] When an abnormal event triggers a preset threshold condition, the S330 sends tiered restriction measures to the target process, including: S331: Based on the severity of the anomaly, issue corresponding level of restriction measures to the target process. The hierarchical restriction measures include alarms, resource rate limiting, resource flow limiting, and system call blocking.

[0051] Specifically, based on the severity of the anomaly, corresponding tiered restrictions are dynamically issued to the process, with four levels increasing in severity. Level 1 is an alert, which only records the details of the anomaly and sends a notification to the administrator, without imposing resource restrictions on the process. Level 2 is a light resource rate limit, which sets relatively lenient limits on processor utilization and memory usage limits for the process by calling the cgroup subsystem's control interface. Level 3 is a strict resource rate limit, which sets stricter processor and memory usage limits for the process through the cgroup subsystem, and simultaneously restricts the set of system calls that the process can call through the seccomp subsystem, cutting off the execution permissions of some high-risk system calls. Level 4 is a system call blocking, which further tightens the system call whitelist based on the measures in Level 3. The application of these restrictions is executed by directly calling the kernel internal interfaces of the cgroup and seccomp subsystems. These internal interfaces bypass the general virtual file system layer and LSM hook functions, avoiding the rule matching and anomaly reporting triggered during the issuance of the restrictions, thus preventing a loop of interception.

[0052] This application also provides a process security dynamic management system based on LSM, such as... Figure 6 As shown, the system includes a pre-verification strategy adjudication module, a hook execution verification module, and a closed-loop detection response module.

[0053] The pre-verification policy adjudication module is used to extract the user domain attributes and process domain attributes of the target process when the target process executes the execve system call, within the safe execution window after the process security credential structure is initialized and before the executable file is loaded. It then traverses the policy rule base to complete the combination matching and conflict adjudication of user domain and process domain, determines the effective policy, generates a uniquely bound policy domain tag, and writes the policy domain tag into the process security credential structure. The safe execution window is the execution period when the process is in a single-threaded state and is not in the RCU read critical section. The hook execution verification module is used to read the policy domain flag from the process security credential structure in the LSM hook function to determine the effective policy when the target process subsequently triggers a system call, and adjudicate the current operation based on the longest prefix matching and explicit rejection priority rule; The closed-loop detection response module is used to generate an abnormal event and trigger tiered restriction measures when the decision result is rejection.

[0054] This application provides an LSM-based dynamic process security management system, including a pre-verification policy adjudication module, a hook execution verification module, and a closed-loop detection response module. The pre-verification policy adjudication module, when the target process executes the `execve` system call, extracts the user domain and process domain attributes of the target process within the security execution window after the process security credential structure is initialized and before the executable file is loaded. It then traverses the policy rule base to perform combination matching and conflict adjudication of user domain and process domain, determines the effective policy, generates a uniquely bound policy domain marker, and writes the policy domain marker into the process security credential structure. The hook execution verification module, when the target process subsequently triggers a system call, reads the policy domain marker from the process security credential structure in the LSM hook function to determine the effective policy and adjudicates the current operation based on the longest prefix matching and explicit rejection priority rules. The closed-loop detection response module, when the adjudication result is rejection, generates an exception event and triggers tiered restriction measures. These modules work together to achieve dynamic security management throughout the entire process lifecycle.

[0055] In this embodiment, inheritance rules are also configured for the effective policy within the process lifecycle. The inheritance rules are divided into two modes. The first is the inheritance mode during child process creation. When the target process creates a child process via the fork or clone system call, since the child process's process security credential structure is derived from the parent process's structure through a copy-on-write mechanism, the policy domain markers stored in the security extension field of the parent process's process security credential structure are automatically inherited by the child process. The child process does not need to re-execute policy matching to obtain the same control policy as the parent process. The second is the re-marking mode when the child process executes a new program. When the child process loads a new executable program different from the parent process via the execve system call, the executable file path in the process domain attributes changes, and the effective policy corresponding to the original policy domain marker may no longer be applicable. Therefore, a complete extraction of user domain attributes and process domain attributes, full rule traversal, and conflict resolution are re-triggered within the execve security execution window to generate new policy domain markers adapted to the new program and replace the old markers.

[0056] For example, continuing with the aforementioned multi-tenant scenario example, the solution in this application will be further explained. The administrator writes two policy rules using the policy management tool. The first rule's user domain selector is configured to match user ID 1001, and the process domain selector is configured to match the executable file path / usr / bin / webserver, requiring the namespace isolation attribute to be true. The rule action includes two parts: one is to allow file read operations to access paths prefixed with / var / www / static, and the other is to deny file read operations to access paths prefixed with / etc / webserver. The second rule's user domain selector is configured to match user ID 1002, and the process domain selector is also configured to match the executable file path / usr / bin / webserver, requiring the namespace isolation attribute to be true. The rule action includes two parts: one is to allow file read operations to access paths prefixed with / var / www / static, and the other is to allow file read operations to access paths prefixed with / etc / webserver. The policy management tool serializes the two rules and sends them to the kernel via the Netlink interface. The kernel builds a new policy rule base containing these two rules in temporary memory, performs syntax and conflict pre-checks, and then uses the RCU mechanism to atomically replace the pointer of the currently running rule base with the pointer of the new rule base. After the replacement is completed, it returns an effective confirmation to the user space.

[0057] When tenant A starts the webserver program with user ID 1001 within its container, the shell process executes ` / usr / bin / webserver` via the `execve` system call. In the `execve` process, the kernel first initializes the process security credential structure corresponding to the webserver process, and then calls the LSM hook function of this application within the secure execution window. The LSM hook function extracts the process's user domain attributes: valid user ID 1001, username `weba`, and primary group ID 100. It also extracts the process domain attributes: the absolute path of the executable file within its container's mounted namespace is ` / usr / bin / webserver`, and the mounted namespace is in an isolated state. The policy rule base is traversed. The first rule's user domain selector matches user ID 1001, and its process domain selector matches the path ` / usr / bin / webserver` and the isolation attribute. The match is successful, and the rule is added to the candidate rule set. The second rule requires user ID 1002, which does not match the current process's 1001, so the rule is excluded. The candidate rule set only contains the first rule, which becomes the effective policy after conflict resolution. The LSM hook function assigns a policy domain tag to the effective policy in the policy mapping table, writes the tag to the security extension field of the process security credential structure, and then returns the allow result to the kernel.

[0058] After the webserver process is running normally, it calls the `open` system call to open the file ` / var / www / static / index.html` in read-only mode. During the `open` system call process, the LSM hook function is triggered. Within the RCU read critical section, the LSM hook function reads the policy domain flag from the current process's process security credential structure and looks up the effective policy in the policy mapping table based on the flag. It identifies the current operation type as file read and the operation object as ` / var / www / static / index.html`. It iterates through the rules corresponding to file read in the effective policies. If the operation object matches the prefix ` / var / www / static` of the allowed rules, and no matching denial rule is found, the decision is made to allow the file, and the system call opens the file normally.

[0059] Subsequently, the webserver process calls the `open` system call to attempt to open the ` / etc / webserver / config.conf` file in read-only mode. The LSM hook function also reads the policy domain flags and locates the effective policy, with the operation type being file read and the operation object being ` / etc / webserver / config.conf`. After traversing the rules, the operation object matches the prefix ` / etc / webserver` in the deny rule, resulting in a denial, and the kernel returns an insufficient permissions error to user space. The LSM hook function synchronously generates a structured exception event, with the exception type being file exception, the operation object being ` / etc / webserver / config.conf`, the process identifier being the webserver process ID, and the namespace information being the mount namespace identifier and process identifier namespace identifier corresponding to the container. The event is written to a lock-free circular buffer via atomic operations, and Netlink notifies the user-space daemon.

[0060] After reading exception events, the user-mode daemon aggregates them by process identifier. If the webserver process accumulates three exceptions within a 5-second sliding time window, the daemon determines that a restriction condition has been triggered. It sets the process's processor utilization cap to 20% and memory usage cap to 100MB via the cgroup subsystem and sends an alert to the administrator. If the number of exceptions continues to increase within subsequent windows, reaching a higher-level threshold, the daemon further escalates the restrictions to strict resource throttling, blocking the process's setuid, mount, and other system call permissions via the seccomp subsystem.

[0061] If the webserver process executes the `setuid` system call during runtime to attempt to switch the valid user identity from 1001 to another user, the kernel invokes the identity change monitoring hook of this application before submitting the new process security credential structure. This hook detects the change in the valid user identity, pauses the execution of `setuid`, re-extracts the user domain attributes with the new valid user identity, and redoes the full rule traversal and conflict resolution. If the new user identity is 1002, the second rule matches, a new policy domain flag is generated, the flag field is updated in the upcoming new process security credential structure, and then `setuid` is allowed to continue execution. Afterward, the process's file access and other operations are subject to the rules in the newly effective policy, consistent with tenant B's management policy.

[0062] Those skilled in the art will understand that this application analyzes the execution window characteristics between the initialization of the process security credential structure and the loading of the executable program in the internal process of the execve system call. It concentrates operations such as user domain attribute extraction, process domain attribute extraction, full rule traversal, and conflict resolution within this window, generates policy domain tags and writes them into the process security credential structure. At runtime, the LSM hook only performs tag reading and prefix matching, distinguishing the appropriate execution environment for complex matching operations and high-speed resolution operations. At the same time, it uses the process security credential structure's own RCU and copy-on-write mechanism to protect the tag data and triggers re-verification when the process identity changes. Combined with the asynchronous transmission and hierarchical response of abnormal events, a complete dynamic process security management scheme is formed.

[0063] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A dynamic process security management method based on LSM, characterized in that, Process operation control is implemented based on a pre-built policy rule base, which is a collection of rules configured based on a combination of user domain and process domain. The method includes: When the target process executes the execve system call, within the secure execution window after the process security credential structure is initialized and before the executable file is loaded, the user domain attributes and process domain attributes of the target process are extracted. The policy rule base is traversed to complete the combination matching and conflict resolution of user domain and process domain, determine the effective policy and generate a uniquely bound policy domain tag, and write the policy domain tag into the process security credential structure. The secure execution window is the execution period when the process is in a single-threaded state and is not in the RCU read critical section. When the target process subsequently triggers a system call, the policy domain flag is read from the process security credential structure in the LSM hook function to determine the effective policy, and the current operation is adjudicated based on the longest prefix matching and explicit rejection priority rules; When the ruling is a rejection, an exception event is generated and tiered restriction measures are triggered; The steps of extracting the user domain attributes and process domain attributes of the target process, traversing the policy rule base to complete the combination matching and conflict adjudication of user domain and process domain, determining the effective policy, and generating a uniquely bound policy domain tag include: Obtain the valid user identifier, user name, and user group information mapped by the target process within its user namespace, and use them as the user domain attributes; Obtain the absolute path of the executable file and the process namespace isolation attribute of the target process within its mounted namespace, and use them as the process domain attribute; Traverse the rules in the policy rule base, filter out the rules whose user domain selector matches the user domain attribute and whose process domain selector matches the process domain attribute, and form a candidate rule set; Conflict resolution is performed on the candidate rule set to determine the effective policy and generate a policy domain tag that uniquely corresponds to the effective policy; The conflict resolution of the candidate rule set includes: The rule that takes effect is selected from the candidate rule set in the following decision order: priority of explicit rejection rule, priority of matching accuracy, and priority of explicit priority value.

2. The process security dynamic management method according to claim 1, characterized in that, The step of writing the policy domain tag into the process security credential structure includes: Within the secure execution window, the policy domain flag is written into the security extension field of the process security credential structure, and the kernel RCU mechanism and copy-on-write mechanism are configured for the policy domain flag in the process security credential structure.

3. The process security dynamic control method according to claim 1, characterized in that, Also includes: When it is detected that the target process modifies the user identity or namespace attributes through a system call, the execution of the current system call is paused, the user domain attributes and process domain attributes of the target process are extracted again, the policy rule base is re-traversed to complete the combination matching and conflict resolution of user domain and process domain, a new policy domain tag is generated and updated to the process security credential structure, and then the current system call is allowed to continue execution.

4. The process security dynamic control method according to claim 1, characterized in that, The step of reading the policy domain flag from the process security credential structure in the LSM hook function to determine the effective policy includes: The read operation marked by the policy domain is performed within the RCU read critical section. During the read process, no locking is performed, no page fault is triggered, and no sleep operation is performed. The corresponding effective policy is retrieved from the pre-maintained policy mapping table based on the read policy domain flag.

5. The process security dynamic management method according to claim 1, characterized in that, The decision on the current operation based on the longest prefix matching and explicit rejection priority rule includes: Iterate through the rules in the effective strategy that match the operation type of the current operation, and filter out the valid rules that match the operation object with the prefix defined in the rule definition; Record the longest prefix length of the allowed rules and the longest prefix length of the rejected rules in the valid rules respectively; When a matching rejection rule exists and the longest prefix length of the rejection rule is greater than or equal to the longest prefix length of the allow rule, the current operation is decided as rejection; when no matching rejection rule exists, or the longest prefix length of the rejection rule is less than the longest prefix length of the allow rule, the current operation is decided as allow.

6. The process security dynamic control method according to claim 1, characterized in that, The generation of abnormal events and triggering of tiered restriction measures include: A structured exception event is generated based on the exception type of the current operation, the operation object, the process identifier of the target process, and the namespace information. The structured exception event is written to a lock-free circular buffer in kernel space through atomic operations, and then asynchronously pushed to the user space event queue through the Netlink communication mechanism. Within a preset sliding time window, abnormal events corresponding to the target process are counted. When an abnormal event triggers a preset threshold condition, a graded restriction measure is issued to the target process.

7. The process security dynamic control method according to claim 6, characterized in that, The step of issuing tiered restriction measures to the target process when an abnormal event triggers a preset threshold condition includes: Depending on the severity of the anomaly, corresponding levels of restrictive measures are issued to the target process. These tiered restrictive measures include alarms, resource rate limiting, resource flow limiting, and system call blocking.

8. A process security dynamic management and control system based on LSM, characterized in that, include: The pre-verification policy adjudication module is used to extract the user domain attributes and process domain attributes of the target process within the safe execution window after the process security credential structure is initialized and before the executable file is loaded when the target process executes the execve system call. It then traverses the policy rule base to complete the combination matching and conflict adjudication of user domain and process domain, determines the effective policy, generates a uniquely bound policy domain tag, and writes the policy domain tag into the process security credential structure. The safe execution window is the execution period when the process is in a single-threaded state and is not in the RCU read critical section. The hook execution verification module is used to read the policy domain flag from the process security credential structure in the LSM hook function to determine the effective policy when the target process subsequently triggers a system call, and adjudicate the current operation based on the longest prefix matching and explicit rejection priority rule; The closed-loop detection and response module is used to generate an abnormal event and trigger tiered restriction measures when the decision result is rejection; This process includes extracting the user domain and process domain attributes of the target process, traversing the policy rule base to complete the combination matching and conflict adjudication of user domain and process domain, determining the effective policy, and generating a uniquely bound policy domain tag. Obtain the valid user identifier, user name, and user group information mapped by the target process within its user namespace, and use them as the user domain attributes; Obtain the absolute path of the executable file and the process namespace isolation attribute of the target process within its mounted namespace, and use them as the process domain attribute; Traverse the rules in the policy rule base, filter out the rules whose user domain selector matches the user domain attribute and whose process domain selector matches the process domain attribute, and form a candidate rule set; Conflict resolution is performed on the candidate rule set to determine the effective policy and generate a policy domain tag that uniquely corresponds to the effective policy; The conflict resolution of the candidate rule set includes: The rule that takes effect is selected from the candidate rule set in the following decision order: priority of explicit rejection rule, priority of matching accuracy, and priority of explicit priority value.

Images