Distributed mandatory access control method and system based on chained proxy

Abstract

The invention discloses a distributed mandatory access control method and system based on a chained proxy, and the control method comprises the steps: intercepting a security access event of a subject to an object through an LSM proxy module of a Linux kernel of a terminal host, collecting a security context to generate a first security request packet of a unique chained ID, and transmitting the first security request packet to a local proxy process; and the local agent process queries the cached security decision set, directly returns a decision result if the matching is hit, encapsulates a second security request packet and sends the second security request packet to the remote decision server if the matching is not hit, and the remote server generates a final decision and returns and executes the final decision. According to the embodiment provided by the invention, complete decoupling of the mandatory access control decision logic and the operating system kernel can be realized; through the remote decision server supporting cross hosts and cross security domains, the technical limitation that an existing mandatory access control scheme can only realize local decision is effectively broken through, the kernel mode processing overhead is reduced, and the security and availability are improved.

Description

A distributed mandatory access control method and system based on chained proxies Technical Field

[0001] This invention relates to the fields of information security and operating system access control technology, and in particular to a distributed mandatory access control method and system based on chained proxies. Background Technology

[0002] With the rapid development of cloud computing, edge computing, and distributed cluster technologies, enterprise IT architectures are gradually evolving from centralized single-machine deployments to distributed architectures spanning hosts, regions, and clouds. This presents new challenges to the security protection of host operating systems. Mandatory Access Control (MAC), as a core security mechanism at the operating system kernel level, enforces access restrictions on objects through system-level preset policies. These policies cannot be modified or bypassed by resource owners. Compared to traditional Discretionary Access Control (DAC), MAC effectively prevents security risks such as privilege abuse, unauthorized access, and malicious code execution. It is a core technical requirement in network security level protection and data security compliance systems.

[0003] Currently, the Linux operating system, as the mainstream underlying system for distributed clusters, cloud hosts, and edge nodes, primarily implements the MAC mechanism through the Linux Security Modules (LSM) framework. Mainstream implementations in the industry include SELinux, AppArmor, and Smack. SELinux employs a label-based type enforcement model, combined with role-based access control and multi-level security policies, enabling extremely fine-grained access control. However, its policy configuration logic is complex, its operational and maintenance threshold is extremely high, and policy rule updates require reloading kernel modules or restarting related services, making flexible online hot updates impossible. AppArmor uses a pathname-based access control model, with a lower configuration threshold, adapting to lightweight containers and embedded scenarios. However, its path matching mechanism is susceptible to soft links and path changes, and cannot support complex label-based policy systems. Smack is a lightweight MAC implementation for embedded scenarios, with simple policy rules, but it only meets the basic access control needs of resource-constrained environments and cannot adapt to the management requirements of complex distributed scenarios.

[0004] The above-mentioned mainstream solutions all have the following drawbacks: 1) The core logic of policy decision-making is implemented in the kernel module, which makes policy updates heavily dependent on kernel-mode operations and lacks hot-swappability; 2) Policy decision-making and execution can only be completed locally on a single host, and cannot support distributed unified policy management across hosts and security domains; 3) Audit logs can only be stored locally on each host, and cannot achieve centralized management and full-link traceability across nodes.

[0005] To address some of the aforementioned shortcomings, several improved technical solutions have emerged in the industry. For example, Chinese invention patent CN108345491B discloses a cross-platform virtual machine mandatory access control method in a cloud computing environment. This method binds access control labels to virtual machine processes and images on different platforms, completing label verification and binding during virtual machine startup and migration processes, thus achieving cross-platform static label management in the cloud environment. However, this solution can only perform access control at fixed lifecycle nodes such as virtual machine creation, startup, and migration, and cannot make dynamic decisions regarding runtime process access behavior. Furthermore, it does not involve core mechanisms such as kernel-mode event interception, user-mode proxy forwarding, and multi-level nested proxies, and therefore still cannot solve the problem of runtime distributed dynamic access control. Some research solutions attempt to introduce user-mode auxiliary processes to participate in policy decision-making through the Netlink communication mechanism, but these still focus on single-host local processing, failing to achieve cross-host remote proxy capabilities and not supporting multi-level nested proxy links, thus failing to solve the problem of unified management in a distributed environment.

[0006] Therefore, how to solve the above problems has become a technical problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0007] To address at least one of the aforementioned problems, this invention provides a distributed mandatory access control method based on a chained proxy, applied to a distributed mandatory access control system including a terminal host and a remote decision server. The method includes: intercepting security access events from a subject to an object via an LSM proxy module set up in the Linux kernel on the terminal host, collecting security event information related to the event, and generating a first security request packet including security event information and a chained ID, which is sent to a local proxy process on the terminal host. The chained ID uniquely identifies the security access event. The local proxy process queries the security access event according to a cached first security decision set. If the security access event matches the first security decision set, a first decision result is generated and returned to the LSM proxy module so that the LSM proxy module executes mandatory access control based on the first decision result. Otherwise, the first security request packet is encapsulated into a second security request packet including a link control field and sent to the remote decision server. The remote decision server queries the security access event according to the cached second security decision set, generates a second decision result based on the matching result between the security access event and the second security decision set, and sends it back to the LSM proxy module along the original link.

[0008] For example, in the distributed mandatory access control method provided in some embodiments of this application, the step of intercepting security access events from a subject to an object, collecting security event information related to the event, and generating a first security request packet including security event information and a chain ID and sending it to the local proxy process of the terminal host through an LSM proxy module set up in the Linux kernel on the terminal host further includes: the LSM proxy module registers hook functions in the Linux kernel for file access, process creation, and network access to critical security paths, and intercepts the security access events from the subject to the object; through Netlink The communication module establishes a synchronous communication channel between the LSM proxy module and the local proxy process, and sends the first security request packet to the local proxy process. The local proxy process queries the security access event according to the cached first security decision set. If the security access event matches the first security decision set, it generates a first decision result and returns it to the LSM proxy module so that the LSM proxy module can perform mandatory access control according to the first decision result. Otherwise, it encapsulates the first security request packet into a second security request packet including a link control field and sends it to the remote decision server. Further, the local proxy process queries the security access event according to the mapping relationship group of the cached first security decision set. The mapping relationship group includes a subject identifier, an object identifier, a permission mask, and an access control decision result. The local proxy process establishes a gRPC bidirectional stream communication channel with the remote decision server system, encapsulates the first security request packet into gRPC over TLS or JSON / HTTP format, and sends it to the remote decision server through a second security request packet including a link control field, which includes the maximum forwarding hop count and a list of traversed nodes.

[0009] For example, in the distributed mandatory access control method provided in some embodiments of this application, the local proxy process sets a timer and assigns an initial value to the timer before sending the second security request packet; when the local proxy process sends the second security request packet, it starts the timer to begin counting down; when the timer decrements to 0: it queries the historical decision records cached by the local proxy process; if there is a historical decision result that matches the subject identifier and the object identifier, it generates a corresponding access decision result based on the historical decision result and returns it to the LSM proxy module; if not, it generates an access denial decision result based on the first security request packet and transmits it to the LSM proxy module.

[0010] For example, in the distributed mandatory access control method provided in some embodiments of this application, the remote decision server queries the security access event according to the cached second security decision set, generates a second decision result based on the matching result of the security access event and the second security decision set, and sends it back to the LSM proxy module along the original link. This further includes: the remote decision server updating the second security decision set according to the loaded mandatory access control policy, wherein the mandatory access control policy is obtained in response to user operations; the remote decision server establishing a gRPC bidirectional stream communication channel with the terminal host, and sending the second decision result back to the LSM proxy module along the original link.

[0011] For example, in some embodiments of the distributed mandatory access control method provided in this application, the distributed mandatory access control system further includes a multi-level proxy node system located between the terminal host and the remote decision server. The distributed mandatory access control method further includes: the multi-level proxy node system forwards the second security request packet according to the node hierarchy; each node queries the security access event according to the cached third security decision set; if the security access event matches the third security decision set, a third decision result is generated and sent back to the LSM proxy module along the original link, and the forwarding of the second security request packet is stopped; if the security access events do not match the third security decision set of each node, the second security request packet is sent to the remote decision server.

[0012] For example, in the distributed mandatory access control method provided in some embodiments of this application, the multi-level proxy node system forwards the second security request packet according to the node hierarchy. Each node queries the security access event according to the cached third security decision set. If the security access event matches the third security decision set, a third decision result is generated and sent back to the LSM proxy module along the original link, and the forwarding of the second security request packet is stopped. If the security access events do not match the third security decision set of each node, the second security request packet is sent to the remote decision server. The method further includes: controlling the forwarding link of the second security request packet according to the link control field; decrementing the maximum forwarding hop count by 1 each time the second security request packet is forwarded, and recording the forwarded node in the list of passed nodes; stopping the forwarding of the second security request packet when the maximum forwarding hop count decreases to 0.

[0013] For example, in the distributed mandatory access control method provided in some embodiments of this application, the multi-level proxy node system forwards the second security request packet according to the node hierarchy. Each node queries the security access event according to the cached third security decision set. If the security access event matches the third security decision set, a third decision result is generated and sent back to the LSM proxy module along the original link, and the forwarding of the second security request packet is stopped. If the security access events do not match the third security decision set of each node, the second security request packet is sent to the remote decision server. The method further includes: the multi-level proxy node system includes multiple distributed nodes and forwards the second security request packet among the multiple distributed nodes. Before forwarding at each node, forwarding path detection is performed based on the node and multiple forwarding links are generated. The next forwarding node is determined from the multiple forwarding links according to a preset risk assessment item.

[0014] For example, in the distributed mandatory access control method provided in some embodiments of this application, the risk assessment item is the number of forwarding nodes, and the forwarding path detection forms multiple first forwarding links; in each first forwarding link, adjacent nodes are connected respectively, and multiple connection vectors connecting adjacent nodes are formed according to the link direction; the angle between the first connection vector and the nth connection vector of each first forwarding link is calculated respectively; when the angle is less than 90°, the number of forwarding nodes of the first forwarding link is recorded, and the first forwarding node of the first forwarding link with the most forwarding nodes is selected as the current forwarding node, where n is greater than or equal to 2 and less than or equal to the maximum number of forwarding hops.

[0015] For example, in the distributed mandatory access control method provided in some embodiments of this application, the risk assessment item is the vector angle, and the forwarding path detection forms multiple second forwarding links including a base point, a first detection node, and a second detection node; in each second forwarding link, the base point and the first detection node are connected and a first detection vector is formed according to the link direction, and the first detection node and the second detection node are connected and a second detection vector is formed according to the link direction; the vector angle between the first detection vector and the second detection vector of each second forwarding link is calculated, and the first forwarding node of the second forwarding link with the largest angle is selected as the current forwarding node.

[0016] For example, in the distributed mandatory access control method provided in some embodiments of this application, after the remote decision server queries the security access event according to the cached second security decision set, generates a second decision result based on the matching result of the security access event and the second security decision set, and sends it back to the LSM proxy module along the original link, the distributed mandatory access control method further includes: updating the cached decision result of the terminal host according to the second decision result, and atomically replacing the first security decision set of the local proxy process according to the cached decision result; forming an audit chain from the complete link of the security access event and recording it in the log of the terminal host and uploading it to the remote log of the remote decision server, wherein the audit chain includes a timestamp, policy version, decision source, and node identifier.

[0017] A second embodiment of the present invention provides a distributed mandatory access control system based on a chained proxy, including a terminal host and a remote decision server. The terminal host is configured to have an LSM proxy module set up in the Linux kernel intercept security access events from a subject to an object, collect the security event information involved, and generate a first security request packet including security event information and a chained ID, which is sent to a local proxy process on the terminal host. The chained ID uniquely identifies the security access event. The local proxy process queries the security access event according to a cached first security decision set. If the security access event matches the first security decision set, a first decision result is generated and returned to the LSM proxy module so that the LSM proxy module executes mandatory access control based on the first decision result. Otherwise, the first security request packet is encapsulated into a second security request packet including a link control field and sent to the remote decision server. The remote decision server is configured to query the security access event according to the cached second security decision set, generate a second decision result based on the matching result between the security access event and the second security decision set, and send it back to the LSM proxy module along the original link.

[0018] The beneficial effects of this invention are as follows: Addressing existing problems, this invention proposes a distributed mandatory access control method and system based on chained proxies. By using an LSM proxy module set up in the Linux kernel to complete security event interception and context collection only on the kernel side, the core logic of policy decision-making is migrated to a local proxy process or remote service, achieving complete decoupling of mandatory access control decision logic from the operating system kernel. Simultaneously, the architecture formed by the terminal host and the remote decision server overcomes the technical limitation of existing mandatory access control schemes that can only achieve local decision-making, thereby compensating for the problems existing in the prior art, effectively reducing kernel-mode processing overhead, and improving security and availability. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 shows a flowchart of a distributed mandatory access control method according to an embodiment of the present invention; Figure 2 shows a structural block diagram of a distributed mandatory access control system according to an embodiment of the present invention; Figure 3 shows a topology diagram of forwarding path detection according to an embodiment of the present invention; Figure 4 shows a topology diagram of forwarding path detection according to another embodiment of the present invention. Detailed Implementation

[0021] To more clearly illustrate the present invention, the following description, in conjunction with preferred embodiments and accompanying drawings, further explains the invention. Similar components in the drawings are indicated by the same reference numerals. Those skilled in the art should understand that the specific description below is illustrative rather than restrictive and should not be construed as limiting the scope of protection of the present invention.

[0022] This invention relates to the fields of information security and operating system access control technology, and in particular to a distributed mandatory access control method and system based on chained proxies. This invention can be widely applied to scenarios requiring high-security mandatory access control and end-to-end auditing, such as Linux server clusters, cloud-native container environments, edge computing nodes, and distributed industrial control systems. It solves the technical problems of traditional mandatory access control mechanisms being highly coupled with the kernel, insufficient unified policy management capabilities in distributed environments, and difficulty in centralized tracing of audit logs.

[0023] Based on the above problems, as shown in Figure 1, one embodiment of this application provides a distributed mandatory access control method based on chained proxies, applied to a distributed mandatory access control system including a terminal host and a remote decision server, including: intercepting security access events of a subject to an object through an LSM proxy module set in the Linux kernel of the terminal host, collecting security event information related to the security access events, and generating a first security request packet to send to the local proxy process of the terminal host.

[0024] In this context, the subject is a process running on a terminal host, and the object is an entity located on the terminal host that the subject accesses or operates upon. The security event information includes a subject identifier, an object identifier, and security context information such as a permission mask. The first security request packet includes the security event information and a chain ID, where the chain ID is a unique identifier assigned by the Linux system to the security access event. The local proxy process queries the security access event based on a cached first security decision set. If the security access event matches the first security decision set, a first decision result is generated and returned to the LSM proxy module, enabling the LSM proxy module to perform mandatory access control based on the first decision result. If the security access event does not match the security decision set, the first security request packet is encapsulated into a second security request packet including a link control field and sent to a remote decision server. The remote decision server queries the security access event based on a cached second security decision set, generates a second decision result based on the matching result between the security access event and the second security decision set, and sends it back to the LSM proxy module along the original link, enabling the LSM proxy module to perform mandatory access control based on the second decision result.

[0025] The distributed mandatory access control method in this embodiment completes security event interception and context collection only on the kernel side by setting up an LSM proxy module in the Linux kernel. The core logic of policy decision-making is migrated to the local proxy process or remote service, realizing complete decoupling of mandatory access control decision logic from the operating system kernel. At the same time, the architecture formed by the terminal host and the remote decision server breaks through the technical limitation of existing mandatory access control schemes that can only realize local decision-making, thereby making up for the problems existing in the prior art, effectively reducing kernel-mode processing overhead, and improving security and availability.

[0026] To facilitate a clear understanding of the technical solutions of this invention by those skilled in the art, the core terms used in this specification are uniformly defined as follows: Subject: The process or user thread running on the terminal host that initiates the access request; it is the initiator of the access operation. Object: The entity located on the terminal host that the subject accesses or operates upon, including but not limited to files, directories, network ports, network connections, hardware devices, inter-process communication objects, memory segments, etc. in the Linux system. LSM: Linux Security Modules, a hook framework provided by the Linux kernel to support various security access control mechanisms, allowing kernel modules to register security hook functions to intercept critical security operations in the kernel. Netlink: A mechanism provided by the Linux kernel for bidirectional communication between kernel-mode and user-mode processes, supporting asynchronous message passing and synchronous request-response modes. gRPC: A high-performance remote procedure call framework based on the HTTP / 2 protocol, supporting bidirectional streaming communication, TLS encryption authentication, and streaming data transmission. Chain ID: Also known as chain_id, it is a globally unique identifier assigned to each security access event, running through the entire request processing chain, used for auditing and tracing. LRU cache: Least Recently Used is a least recently used cache eviction policy used to cache access control decision results of high-frequency accesses and reduce link forwarding overhead; Vector Trace Packet (VTP) is a data structure encapsulated in a security request packet to record the geometric dynamics of the request forwarding link, used to achieve real-time loop risk avoidance.

[0027] In an optional embodiment, the distributed mandatory access control system further includes a multi-level proxy node system located between the terminal host and the remote decision server. The distributed mandatory access control method further includes: the multi-level proxy node system forwards the second security request packet according to the node hierarchy; each node queries the security access event according to the cached third security decision set; if the security access event matches the third security decision set, a third decision result is generated and sent back to the LSM proxy module along the original link, and the forwarding of the second security request packet is stopped; if the security access events do not match the third security decision set of each node, the second security request packet is sent to the remote decision server.

[0028] This embodiment effectively expands the application scope and meets more complex distributed deployment scenarios by setting up a multi-level proxy node system between the terminal host and the remote decision server. Specifically, this embodiment can realize request relay across security domains and isolated networks, expanding the system deployment adaptability; through the local decision-making capabilities of each level of proxy nodes, it shortens the decision-making link of high-frequency repetitive requests, reduces access latency, and at the same time offloads the concurrent pressure of the remote decision server, effectively improving the system's operational stability.

[0029] In a specific embodiment, Figure 2 shows a structural block diagram of the distributed mandatory access control system of this application. The distributed mandatory access control system includes a terminal host, a multi-level agent node system, and a remote decision server. The terminal host is a general-purpose server, virtual machine, container host, edge computing node, or embedded industrial control device with architectures such as X86_64, ARM64, and RISC-V. The minimum configuration requirement is 1 CPU core, 512MB of memory, and 1GB of storage, which is compatible with the operating requirements of mainstream Linux distributions.

[0030] The multi-level agent node system includes multiple distributed agent nodes. Each node is deployed in different security domains of a LAN, WAN, or multi-cloud environment, using a general-purpose server or cloud host. The nodes communicate with each other via IP networks and support static route configuration and dynamic service discovery. The remote decision server is a dedicated policy management and decision server deployed in the core security domain. It is deployed in a dual-machine hot standby or clustered manner, with a minimum configuration requirement of 4 CPU cores, 8GB of memory, and more than 100GB of storage. It is used to store global policies, execute centralized decisions, and aggregate end-to-end audit logs.

[0031] In a specific example, the terminal host's operating system can be a Linux kernel supporting the LSM framework, preferably kernel version 3.10 or higher. Compatible distributions include, but are not limited to, RHEL 7 / 8 / 9, Ubuntu 18.04 / 20.04 / 22.04, SUSE Linux Enterprise 12 / 15, Debian 10 / 11, and OpenEuler. Communication between kernel and user space uses the Netlink protocol, and communication between user space nodes uses the gRPC over TLS 1.3 protocol, compatible with JSON / HTTP protocols. User-space agent processes can be developed using memory-safe languages ​​such as Go and Rust. The remote decision server can integrate Open Policy Agent (OPA) as the policy engine, and audit logs can be stored in general-purpose storage components such as Elasticsearch, Kafka, and time-series databases, without requiring customized dedicated hardware or software.

[0032] This embodiment is based on the mature Linux ecosystem and general-purpose computer hardware architecture, requiring no intrusive modifications to the Linux kernel, effectively lowering the development and usage threshold. Taking the implementation of a chain-proxy-based distributed mandatory access control method as an example, the specific implementation method of this application is illustrated, including the following steps.

[0033] The first step involves intercepting security access events from a subject to an object through an LSM proxy module configured in the Linux kernel on the terminal host, collecting security event information related to the security access events, and generating a first security request packet which is then sent to the local proxy process on the terminal host. Here, the subject is a process running on the terminal host, and the object is an entity located on the terminal host that the subject accesses or operates upon. The security event information includes a subject identifier, an object identifier, and security context information such as a permission mask. The first security request packet includes the security event information and a chain ID, where the chain ID is a unique identifier assigned by the Linux system to the security access event. In this embodiment, the terminal host is the execution endpoint of the mandatory access control policy and the starting point for collecting security access events. Its core components include an LSM proxy module running in Linux kernel mode and a local proxy process running in user mode. The LSM proxy module intercepts security access events from a subject to an object, collects security event information related to the security access events, and generates a first security request packet which is then sent to the local proxy process on the terminal host.

[0034] In one example, the method further includes: First, the LSM proxy module registers hook functions in the Linux kernel for file access, process creation, and network access to critical security paths, intercepting security access events from the subject to the object. In this embodiment, the LSM proxy module is implemented as a loadable kernel module (LKM), eliminating the need to recompile the Linux kernel. It can be dynamically loaded and unloaded during system runtime, providing strong flexibility. When the LSM proxy module is loaded, it registers hook functions for critical security paths with the Linux kernel's LSM framework, covering three core scenarios: file system access, process lifecycle management, and network operations. The registered hook functions include, but are not limited to: 1) File system functions: `inode_permission` (inode permission check), `file_open` (file open), `inode_create` (file / directory creation), `inode_unlink` (file deletion), `inode_rename` (file renaming); 2) Process functions: `task_fork` (process creation), `task_setpgid` (process group setting), `task_kill` (process signal sending); 3) Network functions: `socket_create` (socket creation), `socket_connect` (network connection initiation), `socket_bind` (port binding), `socket_accept` (connection acceptance). When a subject initiates an access operation to an object, the Linux kernel intercepts the access operation by calling the registered hook functions before executing the operation, transferring control to the LSM proxy module to ensure that all access behaviors undergo mandatory access control checks and are not bypassed.

[0035] After the LSM proxy module intercepts a secure access event, it collects all the security context information corresponding to the event, i.e., the security event information, specifically including: 1) Subject identifier: process PID, process UID / GID, full path of the process's executable file, process security context, and process start time; 2) Object identifier: for file objects, collect the full file path, inode number, device number, and file security context; for network objects, collect the port number, protocol type, and source / destination IP address; for process objects, collect the target process PID and executable file path; 3) Permission mask: represented by a 32-bit unsigned integer, with each bit corresponding to a permission access, including but not limited to read (0x00000001), write (0x00000002), execute (0x00000004), create (0x00000008), delete (0x00000010), network connection (0x00000020), and port binding (0x00000040), which can be expanded to 64 bits as needed. This allows for more granular access control.

[0036] After completing the collection of security event information, the LSM proxy module generates the first security request packet. For example, the following data structure is defined using C language structure: struct mac_proxy_request {__u64 chain_id; / / Globally unique chain ID __u64 timestamp; / / Event timestamp, accurate to microseconds __u32 host_id; / / Unique identifier of terminal host __u32 req_seq; / / Request sequence number struct subject_info sub; / / Subject identifier information struct object_info obj; / / Object identifier information __u32 permission_mask; / / Permission mask __u8reserved

[16] ; / / Reserved field}; where the chain ID is a 64-bit unsigned integer, which is generated by the LSM proxy module based on the host ID, timestamp, random number and request sequence number. It is a globally unique identifier of the security access event, runs through the entire request processing chain, and serves as the core identifier for auditing and tracing.

[0037] Second, a synchronous communication channel is established between the LSM proxy module and the local proxy process through the Netlink communication module, and the first security request packet is sent to the local proxy process.

[0038] In this embodiment, the LSM proxy module achieves synchronous communication with the user-space local proxy process through a custom Netlink protocol, such as using NETLINK_MAC_PROXY (a custom value, an unused Netlink protocol number ranging from 24 to 31). When the module loads, it creates a Netlink socket, binds it to the kernel-side receive processing function, and listens for registration messages from the user-space local proxy process. When the local proxy process starts, it creates a corresponding Netlink socket, sends a registration request to the kernel module, and establishes a bidirectional synchronous communication channel. After generating the first security request packet, the LSM proxy module synchronously sends the first security request packet to the local proxy process through the Netlink channel, while simultaneously blocking the current kernel execution path and waiting for the local proxy process to return a decision result. Further, after receiving the decision result, the LSM proxy module performs the corresponding operation based on the decision result: if the decision result is "allow," it allows the access operation and returns control to the kernel to continue execution; if the decision result is "deny," it returns the -EACCES error code to the kernel and terminates the access operation.

[0039] In the second step, the local proxy process queries the security access event based on the cached first security decision set. If the security access event matches the first security decision set, a first decision result is generated and returned to the LSM proxy module so that the LSM proxy module can perform mandatory access control based on the first decision result. If the security access event does not match the security decision set, the first security request packet is encapsulated into a second security request packet including a link control field and sent to the multi-level proxy node system.

[0040] In this embodiment, the local agent process is the core decision-making and forwarding unit on the terminal host side. Running in user space, it possesses root privileges and CAP_NET_ADMIN and CAP_SYS_ADMIN permissions. It is used for communicating with kernel modules, executing cache decisions, forwarding requests upstream, handling policy hot updates, and recording audit logs. The local agent process adopts a modular design, with its core comprising six major units: a Netlink communication module, an LRU cache module, a forwarding module, a timeout fallback module, a policy update module, and an audit module.

[0041] Specifically, the local agent process is responsible for bidirectional communication with the kernel-mode LSM agent module through the Netlink communication module. This includes receiving the first security request packet sent by the kernel, returning the decision result to the kernel, heartbeat keep-alive, and exception handling. The module uses the epoll asynchronous I / O model to listen to Netlink sockets, supporting request processing in high-concurrency scenarios. A single process can support more than 100,000 kernel request processing per second.

[0042] In one example, the local agent process queries the security access event based on a mapping group of a cached first security decision set, the mapping group including the subject identifier, object identifier, permission mask, and access control decision result.

[0043] In this embodiment, the local agent process uses an LRU caching module to maintain a first security decision set, enabling rapid local decision-making for high-frequency access requests, avoiding repeated forwarding of requests upstream, and reducing processing latency. The first security decision set uses the subject identifier, object identifier, and permission mask as cache keys, and generates fixed-length hash values ​​using the SHA-256 hash algorithm as key indexes. The cache values ​​include access control decision results, and may further include policy version numbers, cache expiration times, decision sources, and other information. The cache in the LRU caching module employs an LRU eviction policy, with a default maximum cache capacity of 100,000 entries, which can be adjusted via a configuration file. The default cache expiration time is 5 minutes, which can be dynamically adjusted by those skilled in the art, for example, extended to 24 hours in a static policy scenario. Cache query, insertion, and deletion operations all use read-write locks to ensure concurrency safety, guaranteeing no dirty reads and no data contention in multi-threaded scenarios. Specifically, in this embodiment, when the LRU cache module receives the first security request packet sent by the kernel, the module first extracts the subject identifier, object identifier, and permission mask to generate a cache key and queries the LRU cache. If the cache is hit and has not expired, the first decision result is directly generated and transmitted to the LSM proxy module through the Netlink communication module without forwarding it upstream. If the cache is missed or expired, the forwarding process is initiated.

[0044] In one example, the local agent process establishes a gRPC bidirectional streaming communication channel with the multi-level agent node system, encapsulates the first security request packet in gRPC over TLS or JSON / HTTP format, and sends it to the multi-level agent node system via a second security request packet including a link control field, which includes the maximum forwarding hop count and a list of nodes already passed.

[0045] In this embodiment, the local proxy process is responsible for encapsulating and forwarding requests when the cache misses through the forwarding module. First, it encapsulates the first security request packet into a second security request packet, for example, encapsulating the first security request packet into gRPC over TLS or JSON / HTTP format. Second, it establishes a gRPC bidirectional streaming communication channel with the multi-level proxy node system to achieve reliable forwarding of requests.

[0046] Specifically, the second security request packet adds a link control field to the first security request packet. For example, using Protocol Buffers, it can be defined as follows: `message SecondMacRequest {MacRequest base_request = 1; / / Full content of the first security request packet LinkControl link_control = 2; / / Link control field VectorTracePacket vtp = 3; / / Vector trace packet, optional, used for loop avoidance repeated NodeInfo reverse_path = 4; / / Original link path, used for decision result feedback} message LinkControl {uint32 max_forward_hops = 1; / / Maximum forwarding hops, i.e., TTL repeated string visited_list = 2; / / List of visited nodes uint32 current_hop = 3; / / ` The current forwarding hop count is defined as follows: the maximum forwarding hop count has a default value of 3 and a configurable range of 1-16. It is used to limit the maximum forwarding level of a request and avoid link storms. The list of passed nodes records the unique identifiers of all nodes that the request has passed through, which is used for basic loop detection. The original link path records the forwarding path of the request, which is used for the reverse transmission of decision results.

[0047] The forwarding module establishes a bidirectional communication channel with the multi-level proxy node system using the gRPC over TLS 1.3 protocol, supporting two-way certificate authentication to ensure the confidentiality and integrity of communication. It also supports JSON / HTTP protocols as an alternative, adapting to resource-constrained edge device scenarios. The forwarding module supports load balancing across multiple upstream nodes and automatic failover; when the primary upstream node becomes unreachable, it automatically switches to a backup node, thus ensuring link availability.

[0048] Considering the timeout issue in forwarding the second security request packet to the multi-level proxy node system, to improve the stability of the distributed mandatory access control system, in one example, the local proxy process sets a timer and assigns an initial value to the timer before sending the second security request packet; when the local proxy process sends the second security request packet, the timer starts counting down; when the timer decrements to 0: the local proxy process queries the historical decision records cached; if there is a historical decision result matching the subject identifier and object identifier, the corresponding access decision result is generated based on the historical decision result and returned to the LSM proxy module; if not, an access denial decision result is generated based on the first security request packet and transmitted to the LSM proxy module.

[0049] In this embodiment, the local proxy process uses a timeout fallback module to address system congestion issues caused by upstream link unavailability or excessive network latency, ensuring the service availability of the terminal host. The timeout fallback module creates an independent timer for each request forwarded upstream. The initial timer value is 500ms by default, but those skilled in the art can configure it to 100ms-5s depending on the network environment or actual application requirements. The timer starts simultaneously with the request; if no decision result is received from the upstream before the timer expires, the fallback strategy is triggered.

[0050] Specifically, the system first queries the local persistent storage of historical decision records. These records, stored in a local SQLite database, document the latest decision results verified by the remote decision server, corresponding to the subject and object. If a matching historical decision record exists, such as one matching the subject and object identifiers, an access decision is generated based on this historical decision. This decision can be either an allow or deny decision, and the result is returned to the kernel's LSM proxy module. If no matching historical decision record exists, a default deny decision is generated and returned to the kernel module, while simultaneously logging the audit log.

[0051] The local agent process also includes a policy update module, responsible for establishing a bidirectional gRPC stream with the remote decision server, receiving policy update pushes, and enabling hot updates of local policies and caches. When the local agent process starts, it calls the remote decision server's SubscribePolicy interface to establish a long-lived bidirectional stream, sending the node identifier and the current policy version number. The remote decision server actively pushes policy addition, modification, and deletion events through this bidirectional stream. Upon receiving an update event, it verifies the policy's digital signature (to prevent tampering) and then atomically replaces the local first security decision set and LRU cache. The entire update process does not require restarting the local agent process and does not affect normal business operations.

[0052] The local agent process also includes an auditing module, which is responsible for generating local audit logs and collecting endpoint data for end-to-end auditing. After each security access event is processed, such as when a matching decision result is received from a multi-level agent node system or a remote decision server, the auditing module generates a corresponding audit log after processing the security access event based on the decision result. This log includes the chain ID, terminal host ID, timestamp, security event information, decision result, decision source, processing time, and policy version number. The audit log is written to a local log file and asynchronously uploaded to the centralized audit storage system of the remote decision server to ensure the complete retention of audit data.

[0053] Third, the multi-level proxy node system forwards the second security request packet according to the node hierarchy. Each node queries the security access event according to the cached third security decision set. If the security access event matches the third security decision set, a third decision result is generated and sent back to the LSM proxy module along the original link so that the LSM proxy module can perform mandatory access control according to the third decision result and stop forwarding the second security request packet. If the security access events do not match the third security decision set of each node, the second security request packet is sent to the remote decision server.

[0054] In this embodiment, the multi-level proxy node system is a distributed proxy link connecting the terminal host and the remote decision server, realizing policy forwarding and distributed decision-making across hosts, security domains, and levels. It supports a nested proxy architecture of 2-16 levels and can be flexibly configured according to the enterprise's network topology and security domain division. Each proxy node in the multi-level proxy node system adopts a modular architecture with the same origin as the local proxy process on the terminal host. The core includes a communication module, a third security decision set caching module, a forwarding decision module, a loop avoidance module, and an auditing module, possessing full capabilities for local decision-making, request forwarding, link control, policy updates, and audit logging.

[0055] Each agent node can be configured with different third-party security decision sets according to its deployment location and security requirements to achieve hierarchical policy control: for example, a first-level agent node deployed in a branch office can be configured with a branch office-specific access control policy to enable local decision-making for access requests within the branch office without forwarding them to the remote decision server at headquarters; an agent node deployed in a cloud environment can be configured with a cloud resource-specific access policy to achieve distributed decision-making across availability zones.

[0056] In one example, the multi-level proxy node system controls the forwarding link of the second security request packet according to the link control field. Each time the second security request packet is forwarded, the maximum forwarding hop count is decremented by 1, and the forwarding node is recorded in the forwarding node list. When the maximum forwarding hop count decreases to 0, the forwarding of the second security request packet is stopped.

[0057] In this embodiment, after the proxy node receives the second security request packet sent by the terminal host or the lower-level proxy node, it first performs link legality verification, such as verifying the maximum forwarding hops: if max_forward_hops (TTL) in the link control field is ≤0, then the request is rejected and the fallback decision result is returned to the original link; if TTL>0, then the TTL is decremented by 1 and the link control field is updated.

[0058] The multi-level proxy node system in this embodiment also includes basic loop detection, such as checking whether its own node identifier exists in the visited node list. If it exists, it means that a loop has occurred in the request, so it refuses to forward the request and returns an error message to the original link; if it does not exist, it appends its own node identifier to the visited_list.

[0059] The multi-level agent node system in this embodiment also includes original link update, which appends the communication address of its own node to the reverse_path original link path for subsequent reverse transmission of decision results.

[0060] After completing the link verification, the proxy node queries its local third security decision set cache, with a caching mechanism similar to the LRU cache of the terminal host. If the cache is hit, a third decision result is generated and transmitted back to the local proxy process of the terminal host in reverse order according to the original link recorded in reverse_path, and finally delivered to the kernel LSM proxy module, while stopping the further forwarding of the request. If the cache is not hit, the second security request packet is forwarded to the upstream proxy node according to the configured routing rules, until all levels of proxy nodes have not hit the cache, and finally forwarded to the remote decision server.

[0061] Considering the risk of loops, in an optional embodiment, the multi-level proxy node system includes multiple distributed nodes and forwards the second security request packet among the multiple distributed nodes. Before forwarding at each node, forwarding path detection is performed based on that node and multiple forwarding links are generated. The next forwarding node is determined from the multiple forwarding links according to a pre-set risk assessment item.

[0062] In this embodiment, considering the loop risk in the multi-level proxy node forwarding scenario of the distributed mandatory access control system based on chained proxies, such as a security request packet carrying a link control field initiated by a terminal host, during the forwarding process between distributed multi-level nested chained proxy nodes, the forwarding path may experience vector backtracking and drastic azimuth reversal, leading to the potential risk of the request being forwarded in a loop and repeatedly passing through proxy nodes. This loop risk includes both the direct loop risk of the request repeatedly passing through already visited nodes and the hidden backtracking loop risk, which cannot be identified by traditional loop detection based on the list of visited nodes, and the hidden backtracking loop risk of the forwarding direction being deviated in the opposite direction. To address this loop risk, this embodiment performs forwarding path detection before each node forwards in the distributed system and selects the next forwarding node based on risk assessment items. This solves the problem that traditional loop detection based on the list of visited nodes can only avoid direct repeated loops but cannot avoid potential backtracking loops. Based on the real-time connection status and geometric dynamics characteristics of the nodes, the loop risk is dynamically calculated and the optimal forwarding path is selected.

[0063] In this embodiment, a vector trajectory packet is defined. This packet is transmitted between proxy nodes along with the second security request packet, recording the geometric dynamics of the request forwarding link. The data structure is defined as follows: `message VectorTracePacket {Coordinate base_point = 1; / / Topological coordinates of the current node (base point) Vector inbound_vector = 2; / / Inbound vector repeated Vector history_vectors = 3; / / List of historical vectors uint32 max_hops = 4; / / Maximum forwarding hops uint32 current_hop = 5; / / Current forwarding hops} message Coordinate {int32 x = 1; / / Two-dimensional coordinate X-axis int32 y = 2; / / Two-dimensional coordinate Y-axis} message Vector {int32 dx = 1; / / Vector X component int32 dy = 2; / / Vector Y component}` The topological coordinates of the node are generated based on the node's network location mapping. The mapping rule is, for example, mapping the node's IP address... The first two octets of the address are mapped to the X-axis coordinates, and the last two octets are mapped to the Y-axis coordinates; alternatively, coordinates can be generated based on the Autonomous System (AS) number, data center location, and security domain number to ensure that adjacent nodes in the topology have closer coordinate distances and continuous vector directions. The inbound vector is the direction vector requesting to reach the current node from the previous hop node. The calculation formula is: if the coordinates of the previous hop node are (x0, y0) and the coordinates of the current node are (x1, y1), then the inbound vector V_in = (x1-x0, y1-y0).

[0064] In an optional embodiment, the risk assessment item is the number of forwarding nodes, and the forwarding path detection forms multiple first forwarding links; in each first forwarding link, adjacent nodes are connected and multiple connection vectors connecting adjacent nodes are formed according to the link direction; the angle between the first connection vector and the nth connection vector of each first forwarding link is calculated; when the angle is less than 90°, the number of forwarding nodes of the first forwarding link is recorded, and the first forwarding node of the first forwarding link with the most forwarding nodes is selected as the current forwarding node, where n is greater than or equal to 2 and less than or equal to the maximum number of forwarding hops.

[0065] In this embodiment, after the current proxy node (base point) completes the link validity verification and the cache miss, it first obtains its own candidate next-hop node list. Candidate nodes can be obtained through static configuration or dynamically discovered by the Consul / etcd service. Then, for each candidate next-hop node, a gRPC health check probe packet is sent to obtain the reachability, latency, and next-hop node list of the candidate node. Based on the probe results, multiple candidate forwarding links are generated, such as a first forwarding link, a second forwarding link, and a third forwarding link.

[0066] When the risk assessment item is set to the number of forwarding nodes, this implementation method is used for path selection. That is, in links with a risk of backtracking, the more forwarding nodes there are, the stronger the link's scalability, indicating a lower loop risk. Specifically, it includes: First, for each candidate next-hop node, generating a first forwarding link with that node as the first hop, the maximum length of which does not exceed the current maximum number of remaining forwarding hops.

[0067] Second, for each first forwarding link, generate the connection vector of the adjacent nodes: for example, if the first forwarding link is N0 (current base point) → N1 → N2 → … → Nn, then the connection vectors are V1=(N1-N0), V2=(N2-N1), …, Vn=(Nn-Nn-1).

[0068] Third, calculate the angle θ between the first connection vector V1 and the nth connection vector Vn in each first forwarding link. The angle is calculated using the vector dot product formula:

[0069] Where V1·Vn is the dot product of two vectors, and |V1| and |Vn| are the magnitudes of the vectors. The angle θ between the vectors is calculated using the inverse cosine function.

[0070] Specifically, the formation of a loop in the physical topology necessarily manifests as a vector reversal or a sharp reversal of azimuth angle. For example, the path a→b→a is a typical 180-degree reversal; the path a→b→c→b shows an azimuth angle reversal from b→c to c→b. Based on this, this embodiment can accurately determine the loop risk simply by calculating the angle between the inbound or outbound vectors and the azimuth drift of the node relative to the target in real time. That is, the angle between the final forwarding direction and the initial forwarding direction in the forwarding link will inevitably fall below 90° as the number of loop nodes increases. At this time, the angle θ can be used to determine the presence of loop risk. When the angle θ of each first forwarding link is below 90°, the first forwarding link with the most forwarding nodes has the lowest loop risk. Therefore, this embodiment selects the first forwarding link with the most forwarding nodes and uses the first hop candidate node of this first forwarding link as the next forwarding node for the current request.

[0071] In a specific example, as shown in Figure 3, the forwarding base point is node N2, which is a second-level proxy node in a multi-level proxy node system. The remaining maximum forwarding hops for this request are 8. Link validity checks have been completed, such as TTL checks and loop checks of the passed node list, both of which passed. Furthermore, the local third security decision set cache was not hit, so a next-hop forwarding node needs to be selected. The nodes connected to node N2 are nodes N3, N5, and N6. Based on the real-time health detection results of the three candidate nodes, three independent first forwarding links are generated, named Link A (first-hop node N3), Link B (first-hop node N5), and Link C (first-hop node N6), respectively. The maximum length of each of the three links does not exceed the remaining maximum forwarding hops of 8. In this example, based on the network security domain and IP address range to which each node belongs, two-dimensional topological coordinates are mapped for each node. Each node includes a node identifier and topological coordinates, as follows: Base node N2: Topological coordinates (0, 0); Link A node sequence: Node N3 (6, 0), Node N10 (6, 2), Node N11 (5, 3), Node N12 (4, 3), Node N13 (3, 2), Node N14 (4, 1); Link B node sequence: Node N5 (0, 6), Node N15 (-1, 6), Node N16 (-2, 5), Node N17 (-1, 6); Link C node sequence: Node N6 (3, 3), Node N18 (4, 0), Node N19 (-1, 0), Node N10 ...9 (-1, 0), Node N10 (-1, 0), Node N10 (-1, 0), Node N19 (-1, 0), Node N10 (-1, 0), Node N10 (-1, 0), Node N19 (-1, 0), Node N10 (-1, 0), Node N10 (-1, 0), 4); The following performs loop risk assessment and forwarding node count on the three links respectively: 1) Link A, complete forwarding path: N2→N3→N10→N11→N12→N13→N14 First, determine the base vector V1: the forwarding vector from the base node N2 to the first hop node N3, V1= (6-0, 0-0) =(6, 0).

[0072] Secondly, calculate the forwarding vector for each hop along the link sequentially, and determine the angle between it and V1: Second hop (node ​​N3 → node N10): Forwarding vector V2 = (6-6, 2-0) = (0, 2), V1 V2 = 6 × 0 + 0 × 2 = 0 → θ = 90°, which does not satisfy θ < 90°. Third hop (node ​​N10 → node N11): Forwarding vector V3 = (5-6, 3-2) = (-1, 1), V1 V3 = 6 × (-1) + 0 × 1 = -6 < 0 → θ > 90°, which does not satisfy θ < 90°. Fourth hop (node ​​N11 → node N12): Forwarding vector V4 = (4-5, 3-3) = (-1, 0), V1 V4 = 6 × (-1) + 0 × 0 = -6 < 0 → θ > 90°, which does not satisfy θ < 90°. Fifth hop (node ​​N12 → node N13): Forwarding vector V5 = (3-4, 2-3) = (-1, -1), V1 V5 = 6 × (-1) + 0 × (-1) = -6 < 0 → θ > 90°, which does not satisfy θ < 90°. The 6th hop (node ​​N13 → node N14): forwarding vector V6 = (4-3, 1-2) = (1, -1), V1 V6 = 6 × 1 + 0 × (-1) = 6 > 0 → θ < 90°, which is the first forwarding hop in the link that satisfies θ < 90°.

[0073] Finally, the final hop of this link is determined to be the target node N14 of the 6th hop. The number of forwarding nodes from the first hop node N3 to the final hop node N14 is counted: nodes N3, N10, N11, N12, N13, and N14, a total of 6 forwarding nodes.

[0074] 2) Link B, complete forwarding path: N2→N5→N15→N16→N17 ​​First, determine the base vector V1: the forwarding vector from base node N2 to first hop node N5, V1= (0-0, 6-0)= (0, 6).

[0075] Secondly, calculate the forwarding vector for each hop along the link sequentially, and determine the angle between it and V1: Second hop (node ​​N5 → node N15): Forwarding vector V2 = (-1-0, 6-6) = (-1, 0), V1 V2 = 0 × (-1) + 6 × 0 = 0 → θ = 90°, which does not satisfy θ < 90°. Third hop (node ​​N15 → node N16): Forwarding vector V3 = (-2 - (-1), 5 - 6) = (-1, -1), V1 V3 = 0 × (-1) + 6 × (-1) = -6 < 0 → θ > 90°, which does not satisfy θ < 90°. Fourth hop (node ​​N16 → node N17): Forwarding vector V4 = (-1 - (-2), 6 - 5) = (1, 1), V1 V4 = 0×1 + 6×1 = 6>0 → θ<90°, which is the first forwarding hop in the link that satisfies θ<90°.

[0076] Finally, the final hop of this link is determined to be the target node N17 of the 4th hop. The number of forwarding nodes from the first hop node N5 to the final hop node N17 is counted: nodes N5, N15, N16, and N17, a total of 4 forwarding nodes.

[0077] 3) Link C, complete forwarding path: N2→N6→N18 First, determine the base vector V1: the forwarding vector from base node N2 to first hop node N6, V1= (3-0, 3-0)= (3, 3).

[0078] Secondly, calculate the forwarding vector for each hop along the link sequentially, and determine the angle between it and V1: Second hop (node ​​N6 → node N18): Forwarding vector V2 = (4-3, 4-3) = (1, 1), V1 V2 = 3×1 + 3×1 = 6>0 → θ<90°, which is the first forwarding hop in the link that satisfies θ<90°.

[0079] Finally, the final hop of this link is determined to be the target node N18 of the second hop. The number of forwarding nodes from the first hop node N6 to the final hop node N18 is counted: nodes N6 and N18, a total of 2 forwarding nodes.

[0080] In summary, all three first-hop forwarding links exhibited an angle θ < 90°. Link A had the most forwarding nodes and the lowest risk of loop backtracking. Therefore, node N3, the first-hop candidate node of link A, was selected as the next forwarding node for the current request. Upon receiving the request, node N3 will use itself as the new forwarding base point and repeat the path detection, vector calculation, and risk assessment process described above until a match is found and forwarding stops, or the request reaches the remote decision server, or the remaining TTL is exhausted.

[0081] In another optional embodiment, the risk assessment item is the vector angle, and the forwarding path detection forms multiple second forwarding links including a base point, a first detection node, and a second detection node; in each second forwarding link, the base point and the first detection node are connected to form a first detection vector according to the link direction, and the first detection node and the second detection node are connected to form a second detection vector according to the link direction. The vector angle between the first detection vector and the second detection vector of each second forwarding link is calculated, and the first forwarding node of the second forwarding link with the largest angle is selected as the current forwarding node.

[0082] In this embodiment, after the current proxy node (base point) completes the link validity verification and the cache miss, it first obtains its own candidate next-hop node list. Candidate nodes can be obtained through static configuration or dynamic discovery via Consul / etcd service. Then, for each candidate next-hop node, a gRPC health check probe packet is sent to obtain the reachability, latency, and next-hop node list of the candidate node. Based on the probe results, multiple candidate forwarding links are generated, such as a first forwarding link and a second forwarding link.

[0083] When the risk assessment item is set as the vector angle, this implementation method is used for path selection. That is, in links with backtracking risk, the larger the angle between the inbound and outbound vectors of the forwarding node, the stronger the directional continuity of the link, and the lower the probability of backtracking to form a loop, indicating a lower loop risk. Specifically, it includes: First, for each candidate next-hop node, a second forwarding link is generated, with the link structure being base point N0 → candidate node N1 → candidate next-hop node N2 of N1, i.e., a two-hop probing link.

[0084] Second, for each second forwarding link, generate a first probe vector V_in1 = N1 - N0 (the vector from the base point to the candidate node) and a second probe vector V_in2 = N2 - N1 (the vector from the candidate node to its next hop).

[0085] Third, using the dot product formula mentioned above, calculate the angle θ between V_in1 and V_in2 in each second forwarding link.

[0086] Fourth, select the node with the largest θ value among all candidate nodes as the next forwarding node for the current request.

[0087] In a specific example, as shown in Figure 4, the candidate nodes for the current base point N0 include N1, N2, and N3. The generated second forwarding links are as follows: Link 1: N0→N1→N4, V_in1=(1,0), V_in2=(0,1), and θ=90° is calculated; Link 2: N0→N2→N5, V_in1=(0,1), V_in2=(-1,0), and θ=90° is calculated; Link 3: N0→N3→N6, V_in1=(2,0), V_in2=(-1,1), and θ=135° is calculated.

[0088] Node N3 is ultimately selected as the next-hop forwarding node because it has the largest vector angle, the best directional continuity, and the lowest risk of loops. After receiving the request, node N3 will use itself as the new forwarding base point and repeat the above path detection, vector calculation, and risk assessment process until a match is found and forwarding stops, or the request reaches the remote decision server, or the remaining TTL is exhausted.

[0089] This embodiment can accurately identify potential loop risks through real-time vector geometry calculations. It features low computational cost and high real-time performance, effectively avoiding nested and non-directly repeating hidden loops, and solving link storm and loop problems in distributed chained proxies.

[0090] Fourth step, the remote decision server queries the security access event according to the cached second security decision set, generates a second decision result based on the matching result between the security access event and the second security decision set, and sends it back to the LSM proxy module along the original link so that the LSM proxy module can perform mandatory access control according to the second decision result.

[0091] In this embodiment, the remote decision server serves as the global policy management and decision-making center of the system. It is responsible for storing and managing all mandatory access control policies, executing final centralized decisions, pushing hot policy updates, and aggregating and storing end-to-end audit logs. It adopts a clustered deployment and supports high availability and horizontal scaling. Specifically, the remote decision server employs a modular design, with its core comprising six major units: a policy management module, a policy engine module, a second security decision set cache module, a bidirectional streaming communication module, a centralized audit module, and a user and permission management module.

[0092] In one example, the remote decision server updates the second security decision set according to a loaded mandatory access control policy, which is obtained in response to a user operation; the remote decision server establishes a gRPC bidirectional streaming communication channel with the multi-level agent node system and the terminal host, and transmits the second decision result back to the LSM agent module along the original link.

[0093] In this embodiment, the policy engine module of the remote decision server integrates OPA (Open Policy Agent) as the core policy engine. It is responsible for receiving the second security request packet forwarded by the multi-level agent node system, parsing security event information, loading the global mandatory access control policy, performing policy matching, and generating the second decision result. Specifically, it includes the following steps: First, receiving the second security request packet and extracting security context information such as subject identifier, object identifier, and permission mask.

[0094] Second, load the latest version of the global mandatory access control policy, and pass the security context information as input to the policy engine.

[0095] Third, the policy engine performs rule matching and generates a second decision result of allowing or denying, while attaching extended information such as cache expiration time and audit level.

[0096] Fourth, the second decision result is transmitted back to the kernel LSM proxy module of the terminal host in reverse order, following the original link of the reverse_path in the second security request packet.

[0097] The remote decision server provides a visual policy management interface through the policy management module, supporting security administrators in adding, modifying, deleting, publishing, and versioning policies. It supports Role-Based Access Control (RBAC), allowing different administrators to manage policies across different security domains and levels. The policies are written in languages ​​such as Rego, are compatible with OPA policy engines, and support various mandatory access control models, including type-based enforcement, role-based access control, and multi-level security. Access control rules can be set based on multiple dimensions such as subject, object, time, and network environment. For example, when an administrator publishes a policy, the policy management module generates a new policy version and actively pushes the policy update event to all subscribed terminal host local agent processes and multi-level agent nodes via a bidirectional streaming communication module, achieving real-time hot updates of global policies.

[0098] The remote decision server caches the decision results of the global policy through the second security decision set caching module, which is implemented using a distributed caching cluster (such as Redis). The cache key is consistent with the cache key rules of the terminal host, and the cache expiration time is synchronized with the expiration time of the policy publication. This is used to improve the decision efficiency of high-frequency requests and reduce the computational overhead of the policy engine.

[0099] The remote decision server is responsible for establishing long-term bidirectional connections with all terminal hosts and multi-level agent nodes through a bidirectional streaming communication module. For example, it supports hundreds of thousands of concurrent node connections based on the gRPC framework. This includes receiving policy subscription requests from nodes, maintaining node connection status and heartbeat keep-alive; actively pushing policy update events to nodes to achieve real-time hot updates of global policies; receiving security request packets forwarded by nodes and transferring them to the policy engine module for processing; and sending the decision results back to the corresponding nodes.

[0100] The remote decision server, through a centralized audit module, is responsible for aggregating audit logs across the entire chain. For example, it uses an Elasticsearch cluster to implement distributed storage of audit logs, supporting petabyte-level log storage and fast retrieval. The module receives audit records uploaded from terminal hosts, multi-level proxy nodes, and the policy engine module. Based on chained IDs, it links the entire chain of audit records for the same security access event, forming a complete audit chain. It supports multi-dimensional retrieval and source tracing analysis based on chained IDs, subjects, objects, time, decision results, and other dimensions. It also provides functions such as compliance report generation, abnormal behavior detection, and security alerts to meet security compliance requirements.

[0101] This embodiment achieves complete decoupling of mandatory access control decision logic from the operating system kernel by using an LSM proxy module set up in the Linux kernel to perform security event interception and context collection only on the kernel side. At the same time, by supporting a multi-level nested chained proxy architecture and remote decision server across hosts and security domains, it breaks through the technical limitation of existing mandatory access control schemes that can only achieve local decision-making, effectively reducing kernel-mode processing overhead and improving security and availability.

[0102] In an optional embodiment, after receiving the third decision result sent by the multi-level proxy node system, the LSM proxy module of the terminal host performs mandatory access control on the security access event initiated by the subject to the object based on the third decision result; or, after receiving the second decision result sent by the remote decision server, the LSM proxy module of the terminal host performs mandatory access control on the security access event initiated by the subject to the object based on the second decision result; the local proxy process updates the cached decision result of the terminal host based on the received decision result, and atomically replaces the first security decision set of the local proxy process based on the cached decision result.

[0103] In this embodiment, after the local agent process of the terminal host receives the decision result transmitted back along the original link from the multi-level agent node system or the remote decision server, it first parses and extracts the subject identifier, object identifier, permission mask, decision value, policy version number, and cache validity period parameter corresponding to the result. Using the fixed value generated by SHA-256 hash calculation of the subject identifier, object identifier, and permission mask as the cache key, a new cache entry conforming to the format of the first security decision set is generated. Simultaneously, the policy version number of this entry is verified to be higher than the version of the existing entry with the same key locally. The local agent process locks the LRU cache write queue with a read-write lock and uses CPU memory atomic replacement instructions to complete the full replacement of old entries with new entries, synchronously evicting expired entries in the LRU queue. The replacement process is completed without any intermediate dirty data. After the replacement is completed, the queue is unlocked, and an update confirmation message is returned to the remote decision server. That is, this embodiment can achieve seamless hot updates of the security decision set without restarting the terminal host or the local agent process during the update of the first security decision set, avoiding business execution interruptions and jitter, and ensuring the consistency and execution continuity of the access control policy.

[0104] To further illustrate the specific implementation of this application, a security access event in which a subject initiates access to an object is used as an example: Step S1: Security access event interception and generation of the first security request packet. The subject on the terminal host initiates an access operation to the object. Before executing the operation, the Linux kernel calls the hook function registered by the LSM proxy module to intercept the security access event. The LSM proxy module collects security event information such as the subject identifier, object identifier, and permission mask corresponding to the event, generates a first security request packet carrying a globally unique chain ID, and sends the first security request packet to the local proxy process in user space through the Netlink synchronous communication channel, while blocking the kernel execution path and waiting for the decision result.

[0105] Step S2: Local Agent Process Cache Query and Request Forwarding. After receiving the first security request packet, the local agent process extracts the subject identifier, object identifier, and permission mask to generate a cache key. It then queries the first security decision set in the local LRU cache. If the cache hits and the cache has not expired, the first decision result is generated directly and returned to the kernel LSM agent module through the Netlink channel, proceeding to step S5. If the cache misses or the cache expires, the first security request packet is encapsulated into a second security request packet carrying a link control field and sent to the multi-level agent node system through the gRPC bidirectional stream channel. At the same time, a timeout timer is started, proceeding to step S3.

[0106] Step S3: Forwarding and Decision-Making in a Multi-Level Agent Node System. After receiving the second security request packet, the lower-level agent node in the multi-level agent node system first performs link validity verification: checks the maximum forwarding hop count (TTL), decrements the TTL by 1, and stops forwarding if the TTL ≤ 0; checks the list of nodes already passed, and if its own node identifier exists, it is determined to be a loop and forwarding stops; it appends its own node identifier to the list of nodes already passed and updates the original link path.

[0107] After verification, the proxy node queries the local third security decision set cache: if the cache is hit, a third decision result is generated and transmitted back to the local proxy process of the terminal host in reverse order of the original link, proceeding to step S5; if the cache is not hit, the second security request packet is forwarded to the upstream proxy node, and the above verification and query process is repeated; if the cache is not hit by all proxy nodes at all levels, the second security request packet is sent to the remote decision server, proceeding to step S4.

[0108] Step S4: Centralized decision-making and backhaul of the remote decision server. After receiving the second security request packet, the remote decision server parses the security event information, calls the policy engine module, loads the latest global mandatory access control policy, matches the second security decision set, generates the second decision result, and then backhauls it step by step along the original link. After passing through the multi-level proxy node system, it is finally delivered to the local proxy process of the terminal host, and then proceeds to step S5.

[0109] Step S5: Decision Execution and End-to-End Audit. After receiving the decision result, the local agent process of the terminal host returns the decision result to the kernel LSM agent module through the Netlink channel. The LSM agent module executes mandatory access control according to the decision result: if it is allowed, the access operation is allowed; if it is denied, the access is terminated and an insufficient permission error is returned.

[0110] After the decision is executed, the following operations are performed: The local agent process updates the local LRU cache and the first security decision set based on the received decision results to enable fast local decision-making for subsequent identical requests; The terminal host, multi-level agent nodes, and remote decision server generate audit records for the corresponding links. All audit records carry the same chain ID and are uploaded to the centralized audit storage system to form a complete end-to-end audit chain, supporting subsequent source tracing and analysis.

[0111] Thus, distributed mandatory access control for a single security access event initiated by a subject to an object is completed. In this embodiment, the LSM proxy module set up in the Linux kernel of the terminal host performs security event interception and context collection only on the kernel side, migrating the core logic of policy decision-making to the local proxy process or remote service, thereby achieving complete decoupling of the mandatory access control decision logic from the operating system kernel. At the same time, by supporting a multi-level nested chained proxy architecture and remote decision server across hosts and security domains, it overcomes the technical limitation of existing mandatory access control schemes that can only achieve local decision-making, effectively reducing kernel-mode processing overhead and improving security and availability.

[0112] Based on the above-described distributed mandatory access control method using a chain-proxy, this application also provides a distributed mandatory access control system using a chain-proxy, as shown in Figure 2. This system includes a terminal host and a remote decision server. The terminal host is configured to use an LSM proxy module set in the Linux kernel to intercept security access events from a subject to an object, collect related security event information, and generate a first security request packet including security event information and a chain ID, which is then sent to a local proxy process on the terminal host. The chain ID uniquely identifies the security access event. The local proxy process queries a cached first security decision set. If the security access event matches the first security decision set, a first decision result is generated and returned to the LSM proxy module, enabling the LSM proxy module to execute mandatory access control based on the first decision result. Otherwise, the first security request packet is encapsulated into a second security request packet including a link control field and sent to the remote decision server. The remote decision server is configured to query the security access event based on the cached second security decision set, generate a second decision result based on the matching result between the security access event and the second security decision set, and then send the result back to the LSM proxy module along the original link. This embodiment achieves complete decoupling of mandatory access control decision logic from the operating system kernel by setting up an LSM proxy module in the Linux kernel of the terminal host to intercept security events and collect context only on the kernel side, thus migrating the core logic of policy decision to the local proxy process or remote service. At the same time, the architecture formed by the terminal host and the remote decision server breaks through the technical limitation of existing mandatory access control schemes that can only achieve local decision-making, effectively reducing kernel-mode processing overhead and improving security and availability.

[0113] Those skilled in the art should understand that the present invention is not limited to the specific embodiments described above. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

[0114] Obviously, the above embodiments of the present invention are merely examples for clearly illustrating the present invention, and are not intended to limit the implementation of the present invention. For those skilled in the art, other variations or modifications can be made based on the above description. It is impossible to exhaustively list all the implementation methods here. All obvious variations or modifications derived from the technical solutions of the present invention are still within the protection scope of the present invention.

Claims

1. A distributed mandatory access control method based on chained proxies, characterized in that, A distributed mandatory access control system, applied to a terminal host and a remote decision server, includes: a local agent process that intercepts security access events from a subject to an object through an LSM proxy module set up in the Linux kernel of the terminal host, collects the security event information involved, and generates a first security request packet including security event information and a chain ID, which is sent to the terminal host. The chain ID uniquely identifies the security access event. The local agent process queries a cached first security decision set. If the security access event matches the first security decision set, a first decision result is generated and returned to the LSM proxy module so that the LSM proxy module can execute mandatory access control according to the first decision result. Otherwise, the first security request packet is encapsulated into a second security request packet including a link control field and sent to the remote decision server. The remote decision server queries the security access event according to the cached second security decision set, generates a second decision result based on the matching result between the security access event and the second security decision set, and sends it back to the LSM proxy module along the original link.

2. The distributed mandatory access control method according to claim 1, characterized in that, The local proxy process, which intercepts security access events from a subject to an object, collects relevant security event information, and generates a first security request packet including security event information and a chain ID, and sends it to the terminal host via an LSM proxy module set up in the Linux kernel on the terminal host, further includes: the LSM proxy module registers hook functions in the Linux kernel for file access, process creation, and network access to critical security paths, intercepting the security access events from the subject to the object; and uses Netlink... The communication module establishes a synchronous communication channel between the LSM proxy module and the local proxy process, and sends the first security request packet to the local proxy process. The local proxy process queries according to the cached first security decision set. If the security access event matches the first security decision set, it generates a first decision result and returns it to the LSM proxy module so that the LSM proxy module can perform mandatory access control according to the first decision result. Otherwise, it encapsulates the first security request packet into a second security request packet including a link control field and sends it to the remote decision server. Further, the local proxy process queries the security access event according to the mapping relationship group of the cached first security decision set. The mapping relationship group includes a subject identifier, an object identifier, a permission mask, and an access control decision result. The local proxy process establishes a gRPC bidirectional stream communication channel with the remote decision server system, encapsulates the first security request packet into gRPC over TLS or JSON / HTTP format, and sends it to the remote decision server through a second security request packet including a link control field, which includes the maximum forwarding hop count and a list of traversed nodes.

3. The distributed mandatory access control method according to claim 2, characterized in that, Before sending the second security request packet, the local proxy process sets a timer and assigns an initial value to the timer. When sending the second security request packet, the local proxy process starts the timer to begin counting down. When the timer decrements to 0, the local proxy process queries the historical decision records cached in the local proxy process. If a historical decision result matching the subject identifier and object identifier exists, the corresponding access decision result is generated based on the historical decision result and returned to the LSM proxy module. If no such result exists, an access denial decision result is generated based on the first security request packet and transmitted to the LSM proxy module.

4. The distributed mandatory access control method according to claim 2, characterized in that, The remote decision server queries the security access event based on the cached second security decision set, generates a second decision result based on the matching result between the security access event and the second security decision set, and sends the result back to the LSM proxy module via the original link. This further includes: the remote decision server updating the second security decision set according to a loaded mandatory access control policy, wherein the mandatory access control policy is obtained in response to user operations; and the remote decision server establishing a gRPC bidirectional streaming communication channel with the terminal host, sending the second decision result back to the LSM proxy module via the original link.

5. The distributed mandatory access control method according to any one of claims 2-4, characterized in that, The distributed mandatory access control system further includes a multi-level proxy node system located between the terminal host and the remote decision server. The distributed mandatory access control method further includes: the multi-level proxy node system forwards the second security request packet according to the node hierarchy; each node queries the security access event according to the cached third security decision set; if the security access event matches the third security decision set, a third decision result is generated and sent back to the LSM proxy module along the original link, and the forwarding of the second security request packet is stopped; if the security access events do not match the third security decision set of each node, the second security request packet is sent to the remote decision server.

6. The distributed mandatory access control method according to claim 5, characterized in that, The multi-level proxy node system forwards the second security request packet according to the node hierarchy. Each node queries the security access event based on the cached third security decision set. If the security access event matches the third security decision set, a third decision result is generated and sent back to the LSM proxy module along the original link, and the forwarding of the second security request packet is stopped. If the security access events do not match the third security decision sets of any node, the second security request packet is sent to the remote decision server. This further includes: controlling the forwarding link of the second security request packet according to the link control field; decrementing the maximum forwarding hop count by 1 each time the second security request packet is forwarded, and recording the forwarded node in the list of passed nodes; stopping the forwarding of the second security request packet when the maximum forwarding hop count decreases to 0.

7. The distributed mandatory access control method according to claim 5, characterized in that, The multi-level proxy node system forwards the second security request packet according to the node hierarchy. Each node queries the security access event based on the cached third security decision set. If the security access event matches the third security decision set, a third decision result is generated and sent back to the LSM proxy module along the original link, and the forwarding of the second security request packet is stopped. If the security access events do not match the third security decision sets of any node, the second security request packet is sent to the remote decision server. The system further includes: the multi-level proxy node system includes multiple distributed nodes and forwards the second security request packet among the multiple distributed nodes. Before forwarding at each node, forwarding path detection is performed based on the node and multiple forwarding links are generated. The next forwarding node is determined from the multiple forwarding links according to a pre-set risk assessment item.

8. The distributed mandatory access control method according to claim 7, characterized in that, The risk assessment item is the number of forwarding nodes. The forwarding path detection forms multiple first forwarding links. In each first forwarding link, adjacent nodes are connected and multiple connection vectors connecting adjacent nodes are formed according to the link direction. The angle between the first connection vector and the nth connection vector of each first forwarding link is calculated. When the angle is less than 90°, the number of forwarding nodes of the first forwarding link is recorded. The first forwarding node of the first forwarding link with the most forwarding nodes is selected as the current forwarding node, where n is greater than or equal to 2 and less than or equal to the maximum number of forwarding hops.

9. The distributed mandatory access control method according to claim 7, characterized in that, The risk assessment item is the vector angle. The forwarding path detection forms multiple second forwarding links, including a base point, a first detection node, and a second detection node. In each second forwarding link, the base point and the first detection node are connected to form a first detection vector according to the link direction, and the first detection node and the second detection node are connected to form a second detection vector according to the link direction. The vector angle between the first detection vector and the second detection vector of each second forwarding link is calculated, and the first forwarding node of the second forwarding link with the largest angle is selected as the current forwarding node.

10. The distributed mandatory access control method according to claim 1, characterized in that, after the remote decision server queries the security access event according to the cached second security decision set, generates a second decision result based on the matching result of the security access event and the second security decision set, and sends it back to the LSM proxy module along the original link, the distributed mandatory access control method further includes: The cache decision result of the terminal host is updated according to the second decision result, and the first security decision set of the local agent process is atomically replaced according to the cache decision result; The complete chain of the secure access event is formed into an audit chain and recorded in the logs of the terminal host and uploaded to the remote logs of the remote decision server. The audit chain includes timestamps, policy versions, decision sources, and node identifiers.

11. A distributed mandatory access control system based on chained agents, characterized in that, The system includes a terminal host and a remote decision server. The terminal host is configured to use an LSM proxy module set up in the Linux kernel to intercept security access events from a subject to an object, collect related security event information, and generate a first security request packet including security event information and a chain ID, which is sent to a local proxy process on the terminal host. The chain ID uniquely identifies the security access event. The local proxy process queries a cached first security decision set. If the security access event matches the first security decision set, a first decision result is generated and returned to the LSM proxy module, enabling the LSM proxy module to execute mandatory access control based on the first decision result. Otherwise, the first security request packet is encapsulated into a second security request packet including a link control field and sent to the remote decision server. The remote decision server is configured to query the security access event based on the cached second security decision set, generate a second decision result based on the matching result between the security access event and the second security decision set, and send it back to the LSM proxy module along the original link.

Images