Linux access control system based on attributes

Abstract

The invention provides a Linux access control system based on attributes, and relates to the technical field of data access control. The system comprises a system monitor module, a data interaction module and a decision unit. The system monitor module collects attributes from a kernel and a user space and writes the attributes into the data interaction module; the access decision unit compiles the access control strategy into an eBPF program and mounts the eBPF program to a corresponding hook; executing the kernel to the hook, and triggering an eBPF program; an eBPF program queries a Flow rule; matching the attribute with the Flow rule, and if the matching is successful, executing a corresponding action; if all the Flow rules fail to match, executing a default action; the system can be expanded during operation, and can be loaded or unloaded based on dynamic loading characteristics and strategies of the eBPF program and the eBPF program during operation of the system, so that the problem that a kernel needs to be compiled in a traditional LSM scheme is solved; the method does not intrude the kernel, is completely based on an eBPF program, does not modify a kernel source code, and can guarantee the stability and compatibility.

Description

Technical Field

[0001] This invention relates to the field of data access control technology, and in particular to an attribute-based Linux access control system. Background Technology

[0002] Access control is a security mechanism designed to manage and control access permissions for different users, programs, or system components in a computer system. It determines which subjects can access which resources (e.g., a process can access file resources) and imposes appropriate restrictions during access. By preventing unauthorized users or programs from abusing resources, access control ensures the confidentiality, integrity, and availability of data.

[0003] Common Linux access control policies include: DAC (Discretionary Access Control), MAC (Mandatory Access Control), RBAC (Role-Based Access Control), and LSM (Linux Security Modules) framework.

[0004] When implementing attribute-based access control (ABAC) in Linux systems, existing technologies face the following pressing technical challenges:

[0005] Poor runtime scalability: Existing LSM-based solutions, such as ABAC Linux, typically require recompiling kernel modules or even restarting the entire system when updating policies or expanding functionality. This cannot meet the real-time adjustment requirements of security policies in modern dynamic environments such as cloud-native and zero-trust environments.

[0006] Highly invasive to the kernel and poorly compatible: Traditional solutions require modification of the kernel source code and compilation and integration, which not only increases the stability and security risks of the kernel, but also makes it heavily dependent on specific kernel versions, resulting in extremely high porting and maintenance costs.

[0007] The policy and execution mechanism are too tightly coupled: the policy logic is deeply bound to the underlying LSM hook functions, lacking an abstraction layer. This results in complex policy management, difficulty in reuse, and a high barrier to entry and a high risk of errors for policy developers, requiring them to have in-depth knowledge of kernel implementation details.

[0008] Lack of efficient, dedicated policy description languages: Existing general-purpose policy languages, such as XACML, have verbose syntax, low parsing efficiency, and cannot directly associate with real-time kernel attributes, such as process identifiers (PIDs) and file inodes; while writing eBPF (extended Berkeley Packet Filter) policies directly in C is too low-level and fails to achieve effective abstraction and decoupling. Summary of the Invention

[0009] To address the aforementioned technical problems in existing technologies, this invention aims to provide a Linux access control system that is runtime-extendable, has zero kernel intrusion, decouples policy from execution, and possesses strong expressive capabilities. Specifically, this invention provides an attribute-based Linux access control system, the technical solution of which is as follows:

[0010] It includes a system monitoring module, a data interaction module, and a decision-making unit;

[0011] The system monitor module collects attributes from the Linux kernel and user space and writes them to the data interaction module;

[0012] The access control policy is compiled into eBPF programs and Flow rules, the eBPF programs are attached to the corresponding hooks, and the Flow rules are written into eBPF Maps.

[0013] The Linux kernel executes the hook, triggering the eBPF program;

[0014] In the decision unit, the eBPF program jumps to the matching function through the tail call mechanism;

[0015] For each Flow rule: the matching function obtains the corresponding actual attribute value from the kernel function parameters, access task context and data interaction module according to the attribute identifier, and verifies it with the expected attribute value; if the verification is successful, the corresponding action is executed; otherwise, the next Flow rule is verified.

[0016] If all Flow rules fail to match, the default action is executed;

[0017] The actions include allowing access and denying access.

[0018] Preferably, the system monitor module collects various attributes from the Linux kernel and user space and writes them to the data interaction module, specifically including:

[0019] The system monitor module acquires attributes through the timed attribute acquisition module, extracts the attributes through the daemon and loads them into the eBPF program, and then loads the eBPF program into the Linux kernel through the libbpf-bootstrap framework and mounts it to the corresponding monitoring point.

[0020] When a system call or kernel event is triggered, the eBPF program executes. If a property change is detected, the changed property is written to the data interaction module.

[0021] The attributes to be retrieved include: process attributes from the / proc file system, and user, group, and system information from the / etc directory.

[0022] Preferably, the system monitor module collects attributes from the Linux kernel and user space and writes them to the data interaction module, specifically including:

[0023] In user mode, the system monitor module calls the raw event data decoder through the host program to decode the raw event data into event data according to the event type;

[0024] In the system monitor module, each plugin is registered to the plugin registry;

[0025] The plugin manager compiles plugin programs into dynamic shared files based on the plugin registry and loads them when the host program runs.

[0026] When a system call is made, the event handler passes the event data to the corresponding plugin for processing based on the dynamically shared file;

[0027] The plugin changes attributes and writes them to the data interaction module based on the associated external attribute source.

[0028] Preferably, the data interaction module adopts the eBPF RingBuffer mechanism and the eBPF Maps mechanism;

[0029] The eBPF RingBuffer mechanism is used to pass property change events to user space;

[0030] The eBPF Maps mechanism is used to store properties.

[0031] Optionally, in Linux versions 5.7 and above, eBPF programs are of type BPF_PROG_TYPE_LSM, and hooks are LSM hooks.

[0032] Furthermore, it also includes LSM function gateways;

[0033] The Linux kernel executes the hook, triggering the eBPF program, which specifically includes:

[0034] When the Linux kernel executes an LSM hook, it redirects the execution to the LSM function gateway, and then jumps to the matching functions via tail call functions.

[0035] If the verification is successful, the corresponding action will be executed, specifically including:

[0036] The attribute set is matched sequentially with each Flow rule, specifically including:

[0037] The tail call function jumps to the LSM to execute the action function. If all checks pass, access is allowed and 0 is returned. If any checks fail, access is denied and an error code is returned to block the operation.

[0038] The matching functions include LSM process attribute matching functions, LSM resource attribute matching functions, and LSM environment attribute matching functions.

[0039] Optionally, the eBPF procedure is of type BPF_PROG_TYPE_KPROBE, and the hook is a Kprobes hook.

[0040] Furthermore, it also includes the Kprobes function gateway;

[0041] The Linux kernel executes the hook, triggering the eBPF program, which specifically includes:

[0042] When the Linux kernel executes the Kprobes hook, it redirects the execution to the Kprobes function gateway, and then jumps to the matching functions via the tail call function.

[0043] If the verification is successful, the corresponding action will be executed, including:

[0044] The tail call function jumps to Kprobes to execute the action function. If all validations pass, access is allowed and 0 is returned. If any validation fails, access is denied and an error code is returned to block the operation.

[0045] The matching functions include Kprobes process attribute matching functions, Kprobes resource attribute matching functions, and Kprobes environment attribute matching functions.

[0046] Preferably, the tail call function is stored in eBPF Maps of type BPF_MAP_TYPE_PROG_ARRAY;

[0047] Key fields include total length, type of specified matching function, parameters of specified matching function, parameter order, attribute value length, attribute value, and specified action after matching.

[0048] Preferably, the access control policy is compiled into eBPF programs and Flow rules using the ALL language;

[0049] Compiling eBPF programs specifically includes:

[0050] Define access control policies, including attributes, events, rules, variables, and actions;

[0051] Write YAML files with the same names as the events in the lsm and kprobe directories of / var / eABAC / all / events;

[0052] ANTLR performs lexical and syntactic analysis based on predefined ALL language grammar rules, generating an abstract syntax tree;

[0053] Traverse the abstract syntax tree, perform symbol table management, type checking, constant immutability checking, and invalid code elimination, and generate a strategy structure;

[0054] By combining the strategy structure and code template, eBPF C code is generated based on BTF and CO-RE;

[0055] The attributes include the attribute name, data type, and attribute value;

[0056] An event includes the event type, event name, and the rules to be executed when the event occurs;

[0057] Rules include conditions and actions;

[0058] A variable includes its name, data type, and the fact that its value can change over time.

[0059] Actions include action type, action-related parameters, and the impact of the action on the system;

[0060] Action types include granting access, denying access, sending a termination signal, overriding the return value, providing a warning, and logging.

[0061] The compilation flow rules specifically include:

[0062] The rules are compiled into binary format Flow rules, and the code that stores them in eBPF Maps is generated.

[0063] Compared to existing technologies, the technical solution provided by this invention is scalable at runtime and has zero intrusion into the kernel. Specifically, based on the dynamic loading feature of eBPF programs, policies and eBPF programs can be loaded or unloaded at system runtime, solving the problem of traditional LSM solutions requiring kernel compilation; and being entirely based on eBPF programs without modifying the kernel source code, it ensures stability and compatibility.

[0064] Furthermore, it boasts advantages such as decoupling of policy and execution, and strong expressive capabilities. Specifically: the LSM function gateway or Kprobes function gateway abstracts the underlying execution logic, and flow rules are independently stored in eBPF Maps. Policy updates only require modifying the flow rules, without adjusting the eBPF program, thus achieving separation between high-level intent and low-level execution. The declarative syntax and kernel attribute support of the ALL language allow security administrators to write policies without needing to master eBPF programs or kernel knowledge, adapting to complex and dynamic scenarios. Attached Figure Description

[0065] Figure 1 This is a schematic diagram of the access control mechanism of the Linux access control system provided by the present invention.

[0066] Figure 2 This is a schematic diagram of the attribute-based access control flow using the eBPF program in the Linux access control system provided by the present invention.

[0067] Figure 3 This is a flowchart illustrating the workflow of the system monitor module in the Linux access control system provided by this invention.

[0068] Figure 4 This describes the overall workflow of the plug-in system in the Linux access control system provided by this invention.

[0069] Figure 5 This invention provides an access control decision-making process based on BPF-LSM (BPF Linux Security Modules, Berkeley Package Filter-Linux Security Module Framework) in the Linux access control system.

[0070] Figure 6 This invention provides an access control decision-making process based on LSM and Kprobes in the Linux access control system.

[0071] Figure 7 This is the core process of the unified decision-making method based on eBPF function gateway in the Linux access control system provided by the present invention.

[0072] Figure 8 This is an example of an eBPF function gateway in the Linux access control system provided by the present invention.

[0073] Figure 9 This describes the workflow of the ALL language used in the Linux access control system provided by this invention.

[0074] Figure 10 This diagram illustrates the types and data conversion of the ALL language used in the Linux access control system provided by this invention. Detailed Implementation

[0075] The technical solution provided by the present invention will be further described in detail below with reference to the accompanying drawings.

[0076] In existing technologies, DAC (Access Control Dependency) is a native Linux mechanism that uses file permission bits (r / w / x) to define access permissions for owners, groups, and other users. Permissions are assigned autonomously by the resource owner, but it suffers from low security and coarse-grained control. MAC (Multi-Level Security) enforces subject-object security levels through the kernel, such as SELinux's MLS (Multi-Level Security). Access decisions are preset by the system administrator, offering high security but lacking flexibility and complex configuration. RBAC (Role-Based Access Control) binds permissions to roles, allowing users to acquire permissions through assigned roles, simplifying permission management. However, the static binding of roles and permissions makes it difficult to handle dynamic permission requirements, such as temporary permission adjustments. The LSM (Low-Level Security) framework, introduced in Linux 2.6+, pre-defines hook functions in critical kernel paths (such as file opening and process creation), supports loading security modules (SELinux, AppArmor, BPF-LSM), and extends access control logic. It does not provide security features itself, only interfaces.

[0077] eBPF is a Linux kernel dynamic extension technology that allows user-space programs to load eBPF bytecode into the kernel via the bpf() system call. Its core features include:

[0078] Security verification: The eBPF verifier checks that the program has no infinite loops and no out-of-bounds accesses, ensuring kernel security;

[0079] Just-in-Time (JIT) compilation: converts bytecode into machine instructions, achieving execution efficiency close to that of native kernel code;

[0080] Data sharing: Data interaction between kernel space and user space, and between different eBPF programs, is achieved through eBPF Maps;

[0081] Probe mechanism: Supports mounting Kprobes (kernel function probes), Tracepoints (static trace points), and Uprobes (user-space function probes) to capture system events.

[0082] Linux version 5.7 introduced an LSM security module called BPF-LSM within its LSM framework, providing support for BPF. BPF-LSM is similar in implementation to a typical eBPF program, performing verification at load time and executing by attaching to an LSM hook point. Before BPF-LSM, there were only two options for implementing kernel security modules: configuring an existing LSM framework or writing a custom kernel module. BPF-LSM introduced a third, more secure and general approach, allowing for the customization of security modules similar to those in the previous LSM framework without recompiling the kernel.

[0083] The ABAC model makes access decisions by dynamically evaluating the attributes of subjects, resources, and the environment. Theoretically, it offers advantages such as high flexibility and fine granularity, making it an ideal model for addressing modern, complex access control needs. The core components of the ABAC model include:

[0084] Policy Enforcement Point (PEP): Intercepts access requests, forwards them to the decision point, and executes the decision result;

[0085] Policy Decision Point (PDP): Evaluates policies based on subject, resource, and environmental attributes, and returns an allow / deny decision;

[0086] Attribute Authority (AA): Manages and provides attributes for entities, resources, and the environment;

[0087] Placement Agent (PA): Defines and maintains access control policies.

[0088] Based on the aforementioned prior art, this invention constructs an eBPF-based access control system (hereinafter referred to as the system) to support the implementation of the ABAC model in the Linux system.

[0089] I. Safety Assumptions

[0090] The design and implementation of the Linux access control system provided in this invention are based on the following reasonable security assumptions, which are the foundation for the normal operation and security effectiveness of the system:

[0091] Attribute data reliability: The attribute data collected by the system monitor is from reliable sources, including data from the kernel, user space, and external plugins, and the data has been validated upon input.

[0092] Policy formulation and storage security: The creators of access control policies are trustworthy and will not intentionally introduce malicious policies; the policy storage system is protected and will not be tampered with by unauthorized parties.

[0093] Core component reliability: The core components of the system, including policy decision points, eBPF validators, BPF-LSM and Kprobes mechanisms, are secure and reliable in their implementation and can correctly execute the predetermined security logic.

[0094] Underlying infrastructure security: The eBPF virtual machine, the Linux kernel itself, and the communication channels between components are trusted infrastructures that are not subject to malicious damage.

[0095] Under the premise that the above security assumptions hold, the system achieves efficient access control through the collaborative work of the following modules.

[0096] II. System Model

[0097] This access control system has advantages such as runtime scalability, zero kernel intrusion, decoupling of policy and execution, and strong expressive power. Figure 1 As shown, the core idea of ​​this access control system is to use the eBPF technology stack to implement the core components of the ABAC model.

[0098] The specific solution approach is as follows:

[0099] To achieve runtime scalability and non-intrusiveness to the kernel, this project enhances system scalability by implementing a dynamically scalable attribute-based access control mechanism using eBPF. This mechanism implements an attribute management module called the System Monitor, built on eBPF, which collects attribute data from multiple dimensions. Leveraging eBPF's advantages in system observability, the System Monitor comprehensively collects system attribute data. Furthermore, it provides a plug-in mechanism for defining new attributes and user-mode data processing capabilities. The access control decision module has two implementations: a BPF-LSM-based decision module and an eBPF probe-based decision module. The former achieves access control strength comparable to traditional solutions, while the latter expands the coverage of system access control, freeing the solution from the limitations of predefined Hook points in LSM. Utilizing eBPF's runtime scalability, this solution can be dynamically loaded and unloaded during system operation without requiring a system restart or kernel recompilation, achieving true hot-swappable security control.

[0100] To achieve the goal of decoupling design, a unified access control decision-making method based on eBPF function gateways is integrated into the above mechanism. The core of this method is to model the system's underlying access events as a unified flow model, abstract the system's underlying access control events as flows, perform unified access control decisions for various system events, and propose Flow rules based on this, thus decoupling access control policy writing from underlying access control execution.

[0101] Furthermore, a domain-specific language, ALL, was proposed. By providing high-level abstractions and declarative syntax, it further reduces the complexity of policy definition and management, enabling security administrators to express access control intent more intuitively without needing to delve into the underlying implementation details. Figure 1 As shown, the system administrator uses ALL language code to express high-level control intent for access control. The ALL compiler compiles the corresponding code into eBPF programs and corresponding access control rules. The eBPF programs are mounted to the eBPF function gateway entry point, and the rules are loaded into the stored rule eBPF Maps for use in access control decisions.

[0102] Furthermore, the underlying eBPF programming method adopts libbpf combined with CO-RE technology. CO-RE technology solves the problem of eBPF programs' dependence on kernel data structure layout, enabling the same eBPF program to run on different kernel versions without recompiling and adapting, thus improving the cross-version portability of this mechanism.

[0103] III. Module Design

[0104] like Figure 2 As shown, the Linux system adopts the attribute-based access control mechanism eBPF. This mechanism adopts a modular design, which is divided into four major modules: data interaction module, system monitor module, access control execution module, and access control decision module. The access control execution module is not implemented in this invention. It is composed of the LSM mechanism and Kprobes mechanism in the system and is used to trigger access control behavior.

[0105] (a) System Monitor Module

[0106] The system monitor (system monitor module) is the implementation of the attribute structure of the ABAC model in this system. It is responsible for collecting, maintaining, and updating various attributes required for access decisions in real time and comprehensively from the Linux kernel and user space. This invention classifies attribute events into kernel events, user events, and hybrid events. Kernel-level event attributes can usually be accurately captured through system call parameters. In contrast, user-level events originate from the execution process of applications, and their related attributes mainly rely on the interfaces, configuration information, and log records provided by the application. Hybrid events combine the attribute characteristics of kernel mode and user mode. These attributes can be obtained from specific interfaces exposed by the kernel to user space (such as the / proc file system, sysctl control mechanism, etc.) or from user space interfaces. The core components of the system monitor are the user space daemon and the kernel space eBPF program. The user space daemon is responsible for attribute initialization, configuration management, and interaction with external systems during system startup, as well as receiving processed data through the plug-in system. The kernel space eBPF program captures attribute change events through eBPF programs mounted on critical system paths. The plugin system, as an extension component that supports the extended custom attribute collection function of this system, allows users to write shared library plugins to perform advanced processing and enrichment of the raw event data collected by the kernel in user space, and associate it with external attribute sources, thereby introducing new custom attribute sources to the system.

[0107] like Figure 3 As shown, the core workflow of the system monitor module is divided into two parts: initialization and runtime monitoring. The initialization phase occurs when the access control system starts. The system monitor module's daemon initializes system attributes, first constructing an attribute storage structure, then retrieving process-related attributes (such as PID, PPID, Cgroup, etc.) from the / proc file system, and user and group information (such as UID, GID, username, etc.) and system information (such as hostname, network configuration, timezone, etc.) from the / etc directory. Then, using the libbpf-bootstrap framework, it loads the eBPF program into the kernel and mounts it to the corresponding monitoring points. The trace points of the eBPF program used by the monitoring points are shown in Table 1. After system startup, the system monitor module enters runtime monitoring mode. At this time, the mounted eBPF program executes when a system call or kernel event is triggered, checking for attribute changes. If an attribute change is detected, the changed attributes are written to the data interaction module, and relevant parameters are extracted from the system call context. The attribute values ​​are analyzed and updated. The system monitor module also uses the eBPFRingBuffer mechanism to pass attribute change events to user space for consumption by user space programs.

[0108] Table 1. eBPF program mount points used by the system monitor

[0109] Mounting point Corresponding events raw_syscalls / sys_enter Entry event for each system call raw_syscalls / sys_exit Exit event for each system call exceptions / page_fault_user Page Error Events in User Space exceptions / page_fault_kernel Page fault events in kernel space signal / signal_deliver Operating system signal transmission events sched / sched_process_exec Process execution events sched / sched_process_fork Process creation event sched / sched_process_exit Process exit event sched / sched_switch Process scheduling switch event

[0110] To enable users to add new attributes to the system from user-mode events and implement advanced data processing functions in user mode, this invention designs a plugin-based user-mode event attribute acquisition method. However, this method cannot guarantee the real-time performance of newly added attribute data and is more suitable for scenarios where the real-time performance requirements of attributes are not high.

[0111] like Figure 4 As shown, in kernel mode, the eBPF program implemented by the system monitor is responsible for collecting system call event data and encoding it into raw event byte stream data. This data is then transferred from kernel space to user space via the eBPF Ring Buffer mechanism, achieving efficient event data transmission. In user space, the system monitor host program calls the raw event data decoder to decode the data into structured, specific event data for plugin processing, based on the event type. Plugins are implemented using a shared library model. The plugin system contains multiple independent plugin components, each conforming to a predefined API (Application Programming Interface) standard interface. Plugin programs are compiled into dynamic shared files and then loaded by the system monitor host program at runtime. The system monitor, as the host application, is responsible for loading and managing various plugins. When a system call event occurs, the system monitor passes this decoded event data to the corresponding plugin for processing. Plugins can process this event data in user-mode programs and associate it with external attribute sources, thereby adding new attribute sources to the system.

[0112] Specifically, in user mode, the system monitor module calls the raw event data decoder through the host program to decode the raw event data into event data according to the event type; in the system monitor module, each plugin is registered to the plugin registry; the plugin manager compiles the plugin program into a dynamic shared file according to the plugin registry and loads it when the host program runs; during system calls, the event handler passes the event data to the corresponding plugin for processing according to the dynamic shared file; the plugin changes its attributes according to the associated external attribute source and writes them to the data interaction module.

[0113] (ii) Data Interaction Module

[0114] The data interaction module acts as a data bridge between the system kernel and user modes, as well as between various kernel components. Its underlying implementation employs eBPF Ring Buffer and eBPF Maps mechanisms. Compared to the traditional SecurityFS mechanism's data transfer capabilities between kernel and user modes, the data interaction module offers significantly higher performance. eBPF Maps reduce context switching through shared memory, providing greater real-time data transfer. eBPF Maps are used to store data that needs to be persisted or shared within the kernel. For example, a Map of type BPF_MAP_TYPE_HASH stores the mapping between process PIDs and their attributes (such as program name and current capability set); BPF_MAP_TYPE_RINGBUF enables high-performance one-way event notification, sending kernel events (such as policy rejection logs) to user mode. The system monitor writes collected attributes into eBPF Maps, and the access control decision module reads attributes from these Maps to make decisions. All modules interact by accessing predefined Maps, avoiding the complex overhead of kernel-user communication.

[0115] (iii) Access Control Decision Module

[0116] The access control decision module is the core of the system. It is responsible for executing decision logic when an access event occurs. It adopts two complementary mechanisms to adapt to different scenarios and realizes a unified decision process through the eBPF function gateway.

[0117] 1. Decision unit based on BPF-LSM (first decision unit)

[0118] The BPF-LSM-based decision unit is designed for Linux 5.7 and later. An eBPF program of type BPF_PROG_TYPE_LSM is written and attached to a specific LSM hook. This eBPF program is triggered when the kernel executes the corresponding hook. Internally, the program collects the attributes needed for decision-making from function parameters, the current task context, and eBPF Maps. Subsequently, the program queries pre-loaded Flow rules (stored in eBPF Maps) for matching. If a match is successful and the policy is rejection, an error code such as -EPERM is returned to block the operation; if allowed, 0 is returned.

[0119] like Figure 5As shown, taking a process accessing and executing a file open operation as an example, the decision-making process of the access control system method provided by this invention is illustrated. The kernel path for the process executing the file open operation is `file_open`. When access control occurs, the LSM Hook intercepts this access control and triggers the execution of the corresponding `lsm / file_open` type eBPF program. In this eBPF function, the attributes required for decision-making are parsed from the eBPF Maps and the function's internal parameters. Based on the rules, attribute-based access control decisions are implemented. If the check fails, the execution of this access control is rejected.

[0120] 2. Kprobe-based decision-making unit (second decision-making unit)

[0121] It is mainly used to expand the scope of control or as an alternative to low-version kernels.

[0122] Kprobes is a kernel probing mechanism that inserts observation callback functions into most functions within the kernel, collecting necessary information within these callbacks without affecting the execution flow of the original kernel functions. Kprobes currently supports three probing methods: kprobe, jprobe, and kretprobe. kprobe is the foundation for the latter two, allowing probing at any location. jprobe is used to probe function input parameters, and kretprobe is used to probe function return values. This paper uses kprobe as the event source for an eBPF program, writing an eBPF program of type BPF_PROG_TYPE_KPROBE and attaching it to the entry or exit point of the target kernel function. When a kprobe is triggered, the corresponding eBPF program executes at the function entry or exit point of the kprobe. The corresponding eBPF program types are Kprobe and Kretprobe. Figure 6 The specific decision-making process of this method is described. Compared with the previous BPF-LSM-based method, Kprobes plays the role of the original LSM hook and can be regarded as a Kprobes hook used to drive the execution of eBPF programs. For the access control behavior of the process opening files, the 1sm / file_open function in the BPF-LSM scheme is replaced by the kprobe / x64 sys openat function. The rest of the access control process is roughly the same as the previous scheme, so it will not be described again.

[0123] Furthermore, the implementation of the denial operation also differs: one is to call bpf_send_signal(SIGKILL) to send a termination signal to the current process; the other is to call the bpf_override_return() function to hijack the return value of the original function if the kernel configuration allows it.

[0124] Kprobes-based decision units expand the control scope, but require hardware architecture support and enabling parameters related to the return value of hijacking functions will increase the system's attack surface. Furthermore, the original debugging information and fault diagnosis data may be tampered with or lost, making system fault diagnosis and performance tuning more difficult. Therefore, it can only be used as an alternative solution in special scenarios.

[0125] In summary: The eBPF program written by the first decision unit is attached to the corresponding LSM hook; the eBPF program written by the second decision unit is attached to the corresponding Kprobes hook. When the kernel executes the LSM hook or Kprobes hook, it triggers the corresponding eBPF program. The eBPF program internally collects the attributes required for decision-making from kernel function parameters, the current task context (i.e., accessing the task context), and eBPF Maps (belonging to the data interaction module).

[0126] eBPF programs match by querying preloaded Flow rules stored in eBPF Maps:

[0127] The attribute set is matched against each Flow rule in turn. For each Flow rule, if a match is successful, the corresponding action is executed; otherwise, the next Flow rule is matched. If all Flow rules fail to match, the default action is executed.

[0128] For each Flow rule, if a match is successful, the corresponding action is executed: if all validations pass, access is allowed and 0 is returned; if any validation fails, i.e. a match is successful and the policy is to deny, access is denied and an error code is returned to prevent the operation.

[0129] 3. Unified Decision Gateway

[0130] To decouple strategy and execution, this invention proposes an abstraction layer. Its core is a flow model, which abstracts all access control events into a unified "flow." To express the security intent of access control and bridge the semantic gap between high-level control intent and low-level program execution, this method introduces flow rules into the system flow model. The specific implementation of flow rules in eBPF Maps is a 4096-byte stream, which needs to be decoded before use. Important fields of the flow rule include: byte_len (total length), match_type (specifies the type of the matching function), match_arg (specifies the parameters of the matching function), arg_index (if the attribute definition originates from function parameters, the order of the function parameters needs to be specified), attr_len (the length of the attribute value in bytes), attr (the attribute value), and action (specifies the action after matching, such as sending a SIGKILL signal).

[0131] To enable the underlying eBPF program to uniformly process each access control event according to predefined rules, an eBPF function gateway is introduced, which aims to achieve unified triggering and execution of BPF-LSM and Kprobe programs.

[0132] The core process of the unified decision-making method based on eBPF function gateways is as follows: Figure 7 As shown, the user compiles the written access control policy into an eBPF program and Flow rules using the implemented ALL compiler. Flow rules are written into eBPFMaps for subsequent access control decisions. In the underlying access control decision-making process, the tail-call mechanism of the eBPF program is used to perform standard matching of attributes. If all rules pass validation, access is allowed; if validation fails, the corresponding action is executed to terminate the access. Furthermore, to improve the portability of the unified access control decision module, this invention requires the system to enable BTF support to load the eBPF program using CO-RE. BTF enables the eBPF program to understand the differences between kernel structures in different Linux versions and corrects field offsets in the access structure, allowing the same eBPF program to run across Linux versions.

[0133] like Figure 8 As shown, taking BPF-LSM as an example, in kernel space, all LSM Hook functions are forwarded to the same LSM gateway entry function. That is, different LSM Hook functions correspond to the same code segment, thus unifying the execution flow of access control decisions. eBPF's tail call mechanism allows the execution flow to jump from one BPF program to another in the kernel, a feature that effectively supports complex control flows.

[0134] Tail calls not only allow multiple eBPF programs to execute sequentially in a predetermined order, but also, under certain conditions, can skip redundant decision-making processes, thereby improving efficiency. After successfully implementing unified interception of Kprobes and LSM functions, this unit implements specific access control flows in kernel mode based on the eBPF tail call mechanism.

[0135] To achieve this goal, the unified decision gateway stores the tail call functions related to LSM and Kprobes in two eBPF Maps of type BPF_MAP_TYPE_PROG_ARRAY. Each eBPF Map acts as an array of function pointers, pointing to different BPF programs that will be used for subsequent unified access control decisions. The entry point for unified access control decisions is the corresponding eBPF function gateway, which then jumps to a series of independent, reusable eBPF programs for processing according to the system's preset execution logic. The rules upon which the decisions are based are expressed through Flow rules.

[0136] The execution logic jumps to matching process attributes first, then resource attributes, and finally the action; eBPF programs include abac_lsm_proc_attribute_match and abac_lsm_actions.

[0137] Specifically, when a hook (including LSM hooks and Kprobes hooks) is executed, it is forwarded to the corresponding eBPF function gateway, and then a tail call function is used to jump to the corresponding matching functions. Key fields are read from the corresponding eBPF function gateway and each matching function according to the flow rules, and are validated accordingly. A tail call function is used to jump to the corresponding eBPF execution action function. If all validations pass, access is allowed; if any validation fails, the corresponding action of the eBPF execution action function is executed, ending the access. Specifically, the eBPF function gateway corresponding to the LSM hook is an LSM function gateway, and the corresponding matching functions include LSM process attribute matching functions, LSM resource attribute matching functions, and LSM environment attribute matching functions; the corresponding eBPF execution action function is an LSM execution action function. Similarly, the eBPF function gateway corresponding to the Kprobes hook is a Kprobes function gateway, and the corresponding matching functions include Kprobes process attribute matching functions, Kprobes resource attribute matching functions, and Kprobes environment attribute matching functions; the corresponding eBPF execution action function is a Kprobes execution action function.

[0138] IV. Access Control Policy Language Design and Implementation

[0139] (a) ALL language

[0140] The ALL language is inspired by BPFTrace. BPFTrace uses a declarative language to reduce the complexity of eBPF programming in the field of system observation, making it widely used in this area. The ALL language is designed to be a declarative language, where users only need to declare "what action to perform under what event and what conditions," without needing to worry about the underlying implementation (such as how to mount eBPF programs or how to obtain properties).

[0141] The ALL language declares policies as rules rather than imperative steps, allowing complex access control requirements to be expressed through attributes. ALL's declarative language design reduces the complexity for programmers in understanding and maintaining programs, and also facilitates formal verification and conflict detection. ALL is a compiled language, requiring the generation of eBPF-related program code; therefore, a compiler is needed to support the generation of target code, such as... Figure 9 As shown, the ALL language is ultimately compiled into eBPF program code and generates eBPF Maps, which are then mounted into the unified decision gateway to execute specific access control decisions.

[0142] Another core feature of the ALL language is its event-driven architecture. This model, referencing Zeek's event handling mechanism, divides ALL's event-driven model into three modules: event definition, event handler, and decision result. The event definition module describes access control-related events that may occur in the system. The event handler handles policy processing logic for specific event types, triggered by condition matching and attribute filtering. The policy result expresses the actions to be taken when granting, denying, or issuing a warning. Unlike traditional policy languages ​​that can only represent stateless policies, ALL introduces variables to express stateful policies, such as recording the number of times an event occurs. The core mechanisms by which ALL implements stateful policies include:

[0143] 1) Variable definition: Users can define global variables, supporting variable, counter, and state persistence;

[0144] 2) Variable updates: Modifying variable values ​​during event handling. This allows policies to make decisions based on historical information (e.g., "reject login if more than 5 failed attempts within one minute").

[0145] 1. Definition of core concepts

[0146] Access control policy: This is the highest-level organizational unit for making access control decisions in a system. A policy consists of three parts: a set of constants, a set of variables, and a set of event definitions.

[0147] An attribute is a key-value pair that describes the characteristics of a subject, resource, or environment, and is the basis for access decisions. Its structure includes the attribute name, data type, and value. The collection of all attributes constitutes the attribute space at the time of decision-making.

[0148] Event: Represents a system event that occurs in the system for access control. An event is defined in three parts: event type (EventType), event name (EventName), and the rules (set R) to be executed when the event occurs.

[0149] A rule is the basic unit of execution for a strategy, consisting of a condition and an action. When the condition is met, the corresponding action is executed.

[0150] Variable (Value): Represents the set of attribute values ​​of the system at a certain point in time. ALL language uses variables to track changes in system state. It consists of a variable name (ValueName), a variable data type (ValueType), and a variable value that can change over time (Value(t)).

[0151] Action: The result of executing a rule, consisting of the action type (ActionType), the parameters associated with the action (Args), and the effect of the action on the system (Effect). The effect of the action on the system can be defined as a state transition function Effect: State → State', where State represents the system state.

[0152] 2. Grammar rules and language features

[0153] The core grammatical rules of the ALL language are defined using the Backus-Naur Form (BNF). BNF is a standard grammatical representation for formal language descriptions, which defines the language's construction rules through production rules. Table 2 shows the seven core grammatical rules of the ALL language, covering the basic construction of the language.

[0154] Table 2 ALL Core Syntax Rules

[0155] ALL language specific syntax meaning <program> ::= <policy> < / policy> < / program> The program consists of strategy elements. <policy>::= "policy" <identifier>"{"<policy_body>"}"<policy_body>::= (<constant_decl>|<variable_decl>|<event_handler>)* < / identifier> < / policy> A strategy element consists of constant definitions, variable definitions, and event handlers. <event_handler>::= "event"<event_type>":"<event_name>"{" <statement>* "}"<event_type>::= "lsm" | "kprobe" < / statement> Event handlers support defining lsm and kprobe events, with the same definition format as bpftrace. <constant_decl>::= "const" <identifier> ":" <type> "=" <expression>";"<variable_decl> ::="was" <identifier> ":" <type> "=" < / type> < / identifier> < / expression> < / type> < / identifier> Variable declaration statements and constant declaration statements <if_statement>::= "if" "(" <expression> ")" "{" <statement>* "}"<else_if_clause>*<else_clause>?<else_if_clause>::= "else" "if" "(" <expression> ")" "{" <statement>* "}"<else_clause>::= "else" "{" <statement> * "}" < / statement> < / statement> < / expression> < / statement> < / expression> Define conditional statements in the ALL language, supporting if-elseif-else conditional structures. <attributeexpr>: object<"." identifier>* ; < / attributeexpr> Attribute Expression <action_statement>::= ("allow" | "deny" | "sigkill"| "override" | "warn"|"log")<string_literal>? ";" Dynamic expressions support various behaviors such as allow, deny, warn, and log, and can take one parameter.

[0156] The basic data types in the ALL language include int, string, array, map, and counter. For example... Figure 10As shown, after the type is explicitly defined, the ALL compiler can support type inference and data conversion in conditional judgments. For example, the user.username property with high-level semantics can be converted to the user.uid property with low-level semantics. That is, when matching the username array, it will be automatically converted to the uid to judge the uid list.

[0157] The data types in the ALL language are designed with compatibility with the underlying libbpf C programs in mind, while providing higher-level abstractions.

[0158] In the ALL language, actions are the core component of access control policy enforcement, defining the specific measures the access control system should take when certain conditions are met. ALL defines a series of actions for program execution, including allowing access, denying access, sending a termination signal (sigkill), overriding return values, providing warnings, and logging. These actions follow specific priority and order rules and can be categorized into terminating actions and non-terminating actions. Terminating actions semantically imply a return, meaning that after their execution, the current event handling flow immediately ends, and no subsequent actions will be executed. Non-terminating actions do not interrupt the event handling flow, can be specified before any other action, and are guaranteed to be executed. These actions are mainly used for auxiliary functions, such as warnings and logging.

[0159] Because a function gateway unifies the event mount point, eBPF programs cannot know the number and types of kernel function parameters in an event at the event definition level. Therefore, the kernel function parameter types and their corresponding attributes need to be predefined by the developer. Developers create YAML files with the same names as the events in the `lsm` and `kprobe` directories of ` / var / eABAC / all / events`, specifying the specific kernel functions and their corresponding parameters. The compiler automatically reads these files when it parses the corresponding event definition.

[0160] 3. ALL compiler

[0161] The ALL compiler mainly consists of a syntax checker and a code generator, and its main process is as follows: Figure 9 As shown.

[0162] Lexical and Syntax Analysis: The ANTLR4 framework is used to parse ALL source files. ANTLR performs lexical and syntactic analysis based on predefined ALL language syntax rules (.g4 files) to generate an Abstract Syntax Tree (AST).

[0163] Semantic Analysis and Inspection: A thorough semantic inspection is performed by traversing the Abstract Syntax Tree (AST). This includes: symbol table management (checking for duplicate variable definitions), type checking (ensuring user.uid is compared with numeric values), constant immutability checks, and dead code elimination. The dead code elimination algorithm optimizes the generated code by constructing a Control Flow Graph (CFG) and analyzing active variables to identify and remove code that will never be executed (such as code after a deny statement) or statements that have no impact on program output.

[0164] Target code generation: The checked and optimized intermediate representation (IR), i.e., the policy structure, is generated and combined with pre-written code templates. Using BTF and CO-RE technologies, portable, libbpf-compliant eBPF C code (.bpf.c files) is generated. Simultaneously, the rules defined in the policy are compiled into binary format flow rules, and code is generated to insert them into the corresponding eBPF Map.

[0165] Furthermore, the core steps of invalid code elimination include constructing a control flow graph, calculating active variables, identifying invalid code, and finally deleting invalid code. First, the ALL compiler constructs a control flow graph to analyze the program's execution path, identifying statements that can be executed and those that will never be executed. Next, it performs active variable analysis to identify variables still used at a certain point in the program, determining which statements' execution will not affect subsequent program behavior and classifying these statements as invalid code. Then, the algorithm iterates through each statement in the program and determines whether each statement is invalid code. If a statement is invalid, meaning its deletion will not affect the program's result, then that statement is added to the deletion set. Finally, the compiler deletes these invalid statements, generating an optimized program.

[0166] As can be seen, the ABAC system based on eBPF includes four core modules;

[0167] The system monitor module's plug-in mechanism and attribute acquisition method: Through the user-mode plug-in mechanism, attributes from the kernel and external sources can be flexibly and extensibly acquired and enriched, providing a rich data foundation for dynamic decision-making.

[0168] Dual decision-making mechanism (BPF-LSM + Kprobes): While ensuring the best experience in mainstream environments (BPF-LSM), the Kprobes solution provides forward compatibility and broader coverage.

[0169] A unified decision-making mechanism based on eBPF function gateway and Flow rules: abstracting access events into a flow model, performing attribute matching through tail call chain, and decoupling strategy and execution through Flow rules, thus solving the problem of strategy binding to the underlying layer;

[0170] ALL, a domain-specific language dedicated to kernel-level ABAC, features declarative, event-driven, and stateful characteristics, as well as close integration with the underlying eBPF architecture. This lowers the barrier to entry for policy writing, solves the problem of poor adaptability of existing languages, and greatly enhances the expressiveness and ease of use of policies.

[0171] As can be seen from the accompanying figures, compared to existing technologies, the technical solution provided by this invention is scalable at runtime and has zero intrusion into the kernel. Specifically, based on the dynamic loading characteristics of eBPF programs, policies and eBPF programs can be loaded or unloaded at system runtime, solving the problem of traditional LSM solutions requiring kernel compilation; being entirely based on eBPF programs without modifying the kernel source code, it ensures stability and compatibility.

[0172] Furthermore, it boasts advantages such as decoupling of policy and execution, and strong expressive capabilities. Specifically: the LSM function gateway or Kprobes function gateway abstracts the underlying execution logic, and flow rules are independently stored in eBPF Maps. Policy updates only require modifying the flow rules, without adjusting the eBPF program, thus achieving separation between high-level intent and low-level execution. The declarative syntax and kernel attribute support of the ALL language allow security administrators to write policies without needing to master eBPF programs or kernel knowledge, adapting to complex and dynamic scenarios.

Claims

1. An attribute-based Linux access control system, characterized by, The system comprises a system monitor module, a data interaction module and a decision unit. The system monitor module collects attributes from the Linux kernel and user space and writes them into the data interaction module. The access control policy is compiled into eBPF programs and Flow rules, the eBPF programs are mounted to corresponding hooks, and the Flow rules are written into eBPF Maps. The Linux kernel executes to the hooks to trigger the eBPF programs. In the decision unit, the eBPF programs jump to matching functions through the tail call mechanism. For each Flow rule: the matching function acquires corresponding actual attribute values from the kernel function parameters, access task context and the data interaction module according to attribute identification, and checks them with expected attribute values; if the check is successful, the corresponding action is executed, otherwise the next Flow rule is checked. If all Flow rules fail to match, a default action is executed. The actions include allowing access and denying access.

2. An attribute-based Linux access control system as described in claim 1, wherein, The system monitor module collects various attributes from the Linux kernel and user space and writes them into the data interaction module, specifically including: The system monitor module acquires attributes through a timing attribute acquisition module, extracts attributes through a daemon program and loads them into eBPF programs, and then loads the eBPF programs into the Linux kernel through the libbpf-bootstrap framework and mounts them to corresponding monitoring points. When a system call or kernel event is triggered, the eBPF program is executed, and if a property change is detected, the changed attribute is written into the data interaction module. The attribute acquisition includes acquiring process attributes from the / proc file system and acquiring user information, group information and system information from the / etc directory.

3. An attribute-based Linux access control system as described in claim 1, wherein, The system monitor module collects attributes from the Linux kernel and user space and writes them into the data interaction module, specifically including: In the user space, the system monitor module calls an original event data decoder through a host program, decodes the original event data into event data according to the event type; In the system monitor module, each plugin is registered to a plugin registry; The plugin manager compiles the plugin program into a dynamic shared file according to the plugin registry, and loads it at runtime; When a system call is made, the event processor passes the event data to the corresponding plugin for processing according to the dynamic shared file; The plugin changes the attribute according to the associated external attribute source and writes it into the data interaction module.

4. The attribute-based Linux access control system according to any one of claims 1 to 3, wherein, The data interaction module uses eBPF RingBuffer mechanism and eBPF Maps mechanism; The eBPF RingBuffer mechanism is used to pass attribute change events to the user space; The eBPF Maps mechanism is used to store attributes.

5. An attribute-based Linux access control system as claimed in any one of claims 1 to 3, characterized in that, In Linux 5.7 and later versions, the eBPF program is of the BPF_PROG_TYPE_LSM type, and the hook is the LSM hook.

6. An attribute-based Linux access control system as in claim 5, wherein, It also includes an LSM function gateway. The Linux kernel executes to the hooks to trigger the eBPF programs, specifically including: The Linux kernel executes to the LSM hook, transfers it to the LSM function gateway, and then jumps to each matching function through a tail call function. If the check is successful, the corresponding action is performed, specifically including: The tail call function jumps to the LSM action function, and if all checks pass, access is allowed and 0 is returned, and if there is a check failure, access is denied and an error code is returned to prevent operation; The matching function includes an LSM process attribute matching function, an LSM resource attribute matching function, and an LSM environment attribute matching function.

7. An attribute-based Linux access control system as claimed in any one of claims 1 to 3, characterized in that, The eBPF program is of the BPF_PROG_TYPE_KPROBE type, and the hook is a Kprobes hook.

8. An attribute-based Linux access control system as in claim 7, wherein, It also includes a Kprobes function gateway; The Linux kernel executes to the hook, triggering the eBPF program, specifically including: The Linux kernel executes to the Kprobes hook, which is forwarded to the Kprobes function gateway, and then jumps to each matching function through the tail call function; If the check is successful, the corresponding action is performed, specifically including: The tail call function jumps to the Kprobes action function, and if all checks pass, access is allowed and 0 is returned, and if there is a check failure, access is denied and an error code is returned to prevent operation; The matching function includes a Kprobes process attribute matching function, a Kprobes resource attribute matching function, and a Kprobes environment attribute matching function.

9. An attribute-based Linux access control system as claimed in claim 6 or 8, wherein, The tail call function is stored in an eBPF Map of the BPF_MAP_TYPE_PROG_ARRAY type; The key fields include the total length, the type of the specified matching function, the parameters of the specified matching function, the parameter order, the attribute value length, the attribute value, and the specified action after matching.

10. An attribute-based Linux access control system as claimed in any one of claims 1 to 3, characterized in that, The access control policy is compiled into an eBPF program and a Flow rule through the ALL language; Compiling the eBPF program, specifically including: Defining the access control policy, including attributes, events, rules, variables, and actions; Writing YAML files with the same name as the event name under the lsm directory and the kprobe directory of / var / eABAC / all / events; ANTLR performs lexical analysis and syntax analysis according to the pre-defined ALL language syntax rules to generate an abstract syntax tree; Traverse the abstract syntax tree to perform symbol table management, type checking, constant immutability checking, and invalid code elimination to generate a policy structure; Combine the policy structure and the code template to generate eBPF C code based on BTF and CO-RE; The attribute includes attribute name, data type, and attribute value; The event includes event type, event name, and rules to be executed when the event occurs; The rule includes conditions and actions; The variable includes variable name, variable data type, and variable value that can change over time; The action includes action type, action associated parameter, and action impact on the system; The action type includes allowing access, denying access, sending a termination signal, overriding the return value, providing a warning, and logging. Compiling the Flow rule, specifically including: Compiling the rule into a binary format Flow rule and generating code to store it in eBPF Maps.

Images