Method and system for secure access to a resource-pooled desktop of a Linux operating system

Abstract

The application provides a Linux operating system resource-pooled desktop security access method and system, the method comprising: when a process initiates a file access request, obtaining the resource pool label of the process through an eBPF program mounted at a kernel LSM hook point, and determining whether it is cross-pool access according to the resource pool to which the target file path belongs; reading the event information from the ring buffer by a user-mode monitoring process, determining the current resource pool label of the process according to the process identifier in the event information, querying a preset policy library, and generating a Landlock rule set corresponding to the current resource pool label; and notifying the process to call a landlock_restrict_self system call. The application not only ensures the kernel-level enforceability of process file access isolation, but also adapts to the dynamic change of process resource pool ownership, and supports controlled transit processing when cross-pool access occurs.

Description

Technical Field

[0001] This invention belongs to the field of operating system technology, and in particular relates to a secure access method and system for resource pooling desktops in the Linux operating system. Background Technology

[0002] In Linux desktop security access control, when desktop resources are divided into resource pools with different security policy domains (such as AI pool, security pool, application pool, and file pool) according to function, processes within different resource pools need to have different file system access boundaries, and the resource pool to which a process belongs may change during runtime. Existing mandatory access control methods, such as SELinux or AppArmor, rely on static policies pre-written by the administrator. Policy changes require overloading and do not distinguish between the instantaneous runtime context of the process, making it impossible to dynamically adjust file access permissions according to changes in the process's resource pool affiliation. Seccomp-BPF filters can only be attached once and cannot be modified after attachment, nor can they be controlled at the file path granularity. Although Landlock provides the ability for non-privileged processes to self-restrict, its rule set cannot be relaxed once attached by calling `landlock_restrict_self`. When a process switches from a strict pool to a lenient pool, it cannot restore the previously prohibited path access rights through subsequent attachment of rule sets, thus limiting its applicability. The above-mentioned defects make it difficult for existing technologies to dynamically adjust the boundaries of desktop process file access while ensuring kernel-level mandatory isolation. They also cannot form an intermediate state that can be orchestrated for policy between denying access and allowing access completely, thus failing to meet the dynamic requirements of resource pooled desktops for secure access control. Summary of the Invention

[0003] To address the challenges of ensuring kernel-level enforcement of process file access isolation while adapting to dynamic changes in process resource pool ownership and supporting controlled transfer processing during cross-pool access in Linux desktop resource pooling scenarios, this application provides a secure access method and system for Linux operating system resource pooling desktops.

[0004] This application first provides a secure access method for resource pooling desktops on a Linux operating system, including: When a process initiates a file access request, the eBPF program mounted on the kernel LSM hook point obtains the resource pool label of the process, determines whether it is a cross-pool access based on the resource pool to which the target file path belongs, and if so, writes the event information containing the process identifier, the resource pool label and the target file path into the kernel ring buffer. The user-mode monitoring process reads the event information from the circular buffer, determines the current resource pool label of the process based on the process identifier in the event information, queries the preset policy library, and generates a Landlock rule set corresponding to the current resource pool label. The Landlock rule set contains a whitelist of file paths that the process is allowed to access. The process is notified to call the landlock_restrict_self system call to attach the Landlock rule set, so that the process can only access paths in the file path whitelist, thereby achieving secure access between resource pools; The resource pool is a predefined logical grouping of desktop resources corresponding to different security policy domains.

[0005] Optionally, generating the Landlock rule set corresponding to the current resource pool label includes: A rule set file descriptor is created by calling the landlock_create_ruleset system call, and the file system access permission types to be managed are specified by a structure when the call is made; By invoking the landlock_add_rule system call, at least one LANDLOCK_RULE_PATH_BENEATH rule is added to the rule set file descriptor. The LANDLOCK_RULE_PATH_BENEATH rule specifies a parent path that is allowed access and the access permissions allowed under that parent path.

[0006] Optionally, the file system access permission type includes at least one of read, write, and execute.

[0007] Optionally, the eBPF program obtains the resource pool tag of the process, including: The eBPF program reads mapping records from BPFMaps with process identifier as the key and resource pool label as the value. These mapping records are written and updated by the user-mode monitoring process when the ownership of the process resource pool changes.

[0008] Optionally, the kernel ring buffer is a BPF ring buffer.

[0009] Optionally, determining whether it is a cross-pool access based on the resource pool to which the target file path belongs includes: Based on a pre-defined resource pool directory mapping table, the resource pool to which the target file path belongs is determined by path prefix matching.

[0010] Optional, also includes: After the user-mode monitoring process detects a change in the resource pool ownership of a process, it updates the resource pool tag value corresponding to the process in BPFMaps.

[0011] Optional, also includes: The user-mode monitoring process generates audit log records based on the read event information and writes the audit log records to the audit log file.

[0012] Optional, also includes: When a process's resource pool label changes and file access permissions need to be relaxed, the user-mode monitoring process restarts the process and appends the Landlock rule set corresponding to the new resource pool label to the restarted process.

[0013] This application also provides a secure access system for Linux operating system resource pooling desktops, including: The eBPF program module, mounted on the kernel LSM hook point, is used to obtain the resource pool label of the process when the process initiates a file access request, and determine whether it is a cross-pool access based on the resource pool to which the target file path belongs. If so, it writes the event information containing the process identifier, the resource pool label and the target file path into the kernel ring buffer. The user-mode monitoring module is used to read the event information from the circular buffer, determine the current resource pool label of the process based on the process identifier in the event information, query the preset policy library, generate a Landlock rule set corresponding to the current resource pool label, and notify the process to attach the Landlock rule set. The Landlock rule set contains a whitelist of file paths that the process is allowed to access. The Landlock security module is used to respond to the landlock_restrict_self system call invoked by the process, and restrict the process to access only paths in the file path whitelist according to the Landlock rule set, thereby achieving secure access between resource pools.

[0014] The embodiments provided in this application utilize eBPF to detect process file access events and the resource pool labels to which the process belongs in real time at kernel LSM hook points. Detected cross-pool access events are reported to the user-space monitoring process via a circular buffer. The monitoring process dynamically generates a corresponding Landlock rule set based on the real-time resource pool labels and notifies the target process to call `landlock_restrict_self` to attach this rule set. This leverages the kernel-level enforcement of Landlock to restrict processes to accessing only paths within their respective resource pools. During this process, eBPF does not directly reject cross-pool access requests but only reports the events, thus preserving the user-space opportunity to perform controlled transfer processing such as desensitization, watermarking, and approval for cross-pool access. Landlock implements forced isolation at the file path granularity, and its rule set content is dynamically determined by the user-space based on real-time labels. This allows the same process to tighten access permissions by attaching a new rule set after the resource pool label changes, achieving dynamic adjustment of the isolation policy according to the process state. When permissions need to be relaxed, a safe transition is completed by restarting the process and attaching a new rule set. In the entire solution, eBPF, user-space monitoring process, and Landlock form a closed loop of perception, decision-making, and execution. The decoupling of perception and execution ensures the unbypassable nature of mandatory isolation while retaining the flexibility of controlled transfer. At the same time, Landlock's path prefix check is completed at the VFS layer with extremely low overhead, having almost no performance impact on non-sandboxed processes. This achieves dynamic, transparent file access isolation and secure access in high-frequency desktop interaction scenarios. Attached Figure Description

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

[0016] Figure 1 This is a flowchart of a secure access method for Linux operating system resource pooling desktops in an embodiment of this application; Figure 2 This is a structural diagram of a secure access system for Linux operating system resource pooling desktops in an embodiment of this application. Detailed Implementation

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

[0018] This application provides a secure access method for resource-pooled desktops in a Linux operating system. This method, through the cooperation of kernel-mode and user-mode components, dynamically adjusts the file system access boundaries of desktop processes, meeting the security access control requirements of a resource-pooled desktop environment. A resource pool is a predefined logical grouping of desktop resources corresponding to different security policy domains. Different resource pools correspond to different file system access permission ranges, and processes obtain corresponding file access permissions based on their respective resource pools.

[0019] Specifically, one embodiment of this application provides a secure access method for Linux operating system resource pooling desktops, such as... Figure 1 As shown, it includes: S101: When a process initiates a file access request, the resource pool label of the process is obtained by the eBPF program mounted on the kernel LSM hook point. The resource pool to which the target file path belongs is used to determine whether it is a cross-pool access. If so, the event information containing the process identifier, the resource pool label and the target file path is written into the kernel ring buffer. S102: The user-mode monitoring process reads the event information from the circular buffer, determines the current resource pool label of the process based on the process identifier in the event information, queries the preset policy library, and generates a Landlock rule set corresponding to the current resource pool label. The Landlock rule set contains a whitelist of file paths that the process is allowed to access. S103: Notify the process to call the landlock_restrict_self system call to attach the Landlock rule set so that the process can only access paths in the file path whitelist, thereby achieving secure access between resource pools; The resource pool is a predefined logical grouping of desktop resources corresponding to different security policy domains.

[0020] In this embodiment, when a process initiates a file access request, the kernel performs a series of security checks at the virtual file system layer, including calling programs mounted on LSM hook points. LSM hook points are security extension interfaces provided by the kernel, allowing third-party security modules to insert custom check logic before critical system operations are executed. This application mounts the eBPF program on the `security_file_open` hook point, which is triggered when the process calls the `open` system call to open a file. At this time, the kernel has completed the copying of user-space data but has not yet performed the actual file opening operation, ensuring that the obtained process and file information is completely consistent with the information the kernel will use. Besides the `security_file_open` hook point, other related LSM hook points can be mounted on according to actual needs. For example, the `security_file_permission` hook point is used to check file access permissions, the `security_inode_create` hook point is used to monitor file creation operations, the `security_inode_delete` hook point is used to monitor file deletion operations, and the `security_inode_rename` hook point is used to monitor file renaming operations. By mounting multiple LSM hook points, comprehensive monitoring and control of process file system operations can be achieved.

[0021] It's important to note that eBPF is a virtual machine technology that runs within the kernel, allowing user-written programs to execute in kernel mode without modifying kernel code or loading kernel modules. Before loading, eBPF programs undergo checks by a kernel verifier to ensure they won't cause kernel crashes or introduce security vulnerabilities. The kernel verifier performs static analysis on the eBPF program's control flow, checking for infinite loops, access to illegal memory addresses, and exceeding instruction count limits, among other things. Only eBPF programs that pass the verifier's check can be loaded into the kernel for execution. eBPF programs attached to LSM hooks can obtain the current process's context information, including process ID, user ID, process group ID, and session ID, as well as information such as the target file's path, file type, access permissions, and file owner. This information provides the necessary basis for the eBPF program to determine whether cross-pool access is involved.

[0022] In this embodiment, the eBPF program obtains the resource pool label of a process by reading a mapping record from BPFMaps, where the process identifier is the key and the resource pool label is the value. BPFMaps is a data structure provided by eBPF for sharing data between eBPF programs and between eBPF programs and user-space programs. BPFMaps support various types, including hash tables, arrays, circular buffers, queues, stacks, and program arrays. Different types of BPFMaps are suitable for different application scenarios. Array-type BPFMaps are suitable for scenarios where the keys are consecutive integers, offering constant-level query efficiency, but they do not support sparse key space. Queue-type BPFMaps are suitable for first-in-first-out (FIFO) data transfer scenarios, while stack-type BPFMaps are suitable for last-in-first-out (LIFO) data transfer scenarios. Program array-type BPFMaps are used to store the file descriptors of eBPF programs, enabling dynamic invocation of eBPF programs. This application uses hash table-type BPFMaps to store the mapping relationship between process identifiers and resource pool labels because process creation and destruction are frequent in desktop environments, resulting in discontinuous process identifier space. Hash tables can support sparse key space and offer high query efficiency. Hash table-type BPFMaps have low average time complexity for insertion, deletion, and query operations, which can meet the needs of high-frequency process state changes in desktop environments.

[0023] For example, BPFMaps are created when the eBPF program is loaded. During creation, the mapping type, key size, value size, and maximum number of entries must be specified. The key size is set to 4 bytes, corresponding to a 32-bit process identifier. The value size is set to 16 bytes, sufficient to store the resource pool label string. The maximum number of entries needs to be set based on the maximum number of processes that may run simultaneously in the system, for example, 65536, to ensure that the resource pool label mapping relationships for all processes can be stored. User-space programs can read and write to BPFMaps via the bpf system call. The bpf system call is the main interface for interaction between user-space programs and the eBPF subsystem, supporting various commands, including creating BPFMaps, loading eBPF programs, querying BPFMaps elements, updating BPFMaps elements, and deleting BPFMaps elements. When a process starts, the user-space initiator sets a resource pool label for the process and writes the mapping relationship between the process identifier and the resource pool label to the BPFMaps. When the resource pool ownership of a process changes, the user-space monitoring process updates the resource pool label value corresponding to the process identifier in the BPFMaps. When a process exits, the user-space monitoring process detects the exit event and removes the process's mapping record from BPFMaps to free up BPFMaps storage space. When an eBPF program is triggered, it retrieves the current process identifier using the `bpf_get_current_pid_tgid` function, then queries BPFMaps using that identifier as the key to obtain the resource pool label corresponding to the process. If no entry for the process identifier exists in BPFMaps, the default resource pool label can be used, or the process can be marked as an unclassified process, applying the default security policy.

[0024] In this embodiment, after the eBPF program obtains the resource pool label of a process, it needs to determine whether it is a cross-pool access based on the resource pool to which the target file path belongs. The determination method is to use a pre-defined resource pool directory mapping table to determine the resource pool to which the target file path belongs through path prefix matching. The resource pool directory mapping table stores the root directory path corresponding to each resource pool. For example, if the root directory corresponding to a resource pool is / pool / ai / , then all files whose paths begin with / pool / ai / belong to that resource pool. Path prefix matching is a simple and efficient file classification method that can quickly determine the resource pool to which a file belongs. When performing path prefix matching, the kernel-resolved absolute path should be used, rather than the user-provided relative path, to prevent attackers from bypassing access control by constructing paths containing ".. / ". When processing file access requests, the kernel resolves the user-provided path to an absolute path and parses all symbolic links to obtain the final file path. The eBPF program can obtain the kernel-resolved file path using the bpf_d_path function, which copies the file path name to a specified buffer and returns the length of the path name.

[0025] It should be noted that the resource pool directory mapping table can be pre-configured in the system or dynamically maintained by the user-space monitoring process. To improve the query efficiency of eBPF programs, the resource pool directory mapping table can be stored in another BPFMaps, such as an array-type BPFMaps. Each array element stores the root directory path of a resource pool and its corresponding resource pool label. The size of the array is set according to the number of resource pools; for example, setting it to 16 supports a maximum of 16 resource pools. Each array element contains two fields: the first field is the root directory path string, with a length of 256 bytes, sufficient to store most file system paths; the second field is the resource pool label string, with a length of 16 bytes. When the user-space monitoring process starts, it loads the resource pool directory mapping table into this BPFMaps. When the resource pool directory mapping table changes, the user-space monitoring process updates the corresponding entries in this BPFMaps. When the eBPF program is triggered, it traverses all entries in this BPFMaps, performing prefix matching between the target file path and the root directory path of each entry to find the resource pool to which the target file belongs. If the target file path matches the root directory paths of multiple resource pools, the resource pool corresponding to the longest matching root directory path is selected. If the target file path does not belong to any predefined resource pool root directory path, it can be classified as an unclassified file. The access permissions for unclassified files are determined by the preset default policy. The default policy can be configured to allow access, deny access, or trigger an approval process, depending on the system's security requirements.

[0026] In this embodiment, if the eBPF program determines that the current access is a cross-pool access, it writes event information containing the process identifier, resource pool label, and target file path into the kernel circular buffer. The kernel circular buffer is a mechanism for efficiently transferring data between kernel mode and user mode. Data is transferred in a first-in-first-out manner, ensuring the order and integrity of events. Traditional methods for transferring data between kernel mode and user mode include system calls, the proc file system, the sysfs file system, and netlink sockets. These methods either require frequent context switching or have low performance, making them unsuitable for high-frequency event transmission. This application uses a BPF circular buffer as the event transmission channel between kernel mode and user mode. Compared to the traditional perfbuffer, the BPF circular buffer has better memory efficiency and performance, supporting higher frequency event transmission. The BPF circular buffer is implemented using shared memory, allowing kernel mode and user mode to directly access the same memory region without data copying, thereby improving data transfer efficiency.

[0027] For example, the BPF ring buffer is created using the `bpf_map_create` function when the eBPF program is loaded. During creation, the mapping type is specified as `BPF_MAP_TYPE_RINGBUF`, and the buffer size is specified. The buffer size needs to be set based on the maximum event rate that may occur in the system; for example, a size of 4MB can store thousands of events. If the buffer is set too small, events will be lost when the event generation rate exceeds the read rate of user-space processes. If the buffer is set too large, it will waste system memory. The BPF ring buffer supports a multi-producer, single-consumer mode, where multiple eBPF programs can write events to the same ring buffer simultaneously, while only one user-space process reads events from the ring buffer. The kernel automatically handles synchronization issues between multiple producers, ensuring the atomicity of event writes. The eBPF program writes event information to the ring buffer using the `bpf_ringbuf_output` function, which automatically handles buffer write pointer updates and overflow checks. If the buffer is full, the `bpf_ringbuf_output` function will determine whether to discard new events or wait for available space in the buffer based on the set flags. User-space processes create a circular buffer object using the `ring_buffer_new` function and wait for events using the `ring_buffer_poll` function. The `ring_buffer_poll` function blocks the current thread until data is available to read in the circular buffer or a timeout occurs. When an event is written to the circular buffer, the `ring_buffer_poll` function returns, and the user-space process can read and process the event using the `ring_buffer_consume` function. The `ring_buffer_consume` function automatically updates the read pointer and releases the buffer space occupied by the read event. The format of the event information can be defined according to actual needs. In addition to the process identifier, resource pool label, and target file path, it can also include user identifier, access type, event timestamp, process name, parent process identifier, etc., for subsequent auditing and analysis. The event timestamp can use the kernel's monotonic clock value to avoid time inconsistencies caused by system time adjustments.

[0028] In this embodiment, after the user-space monitoring process reads event information from the circular buffer, it needs to determine the process's current resource pool label based on the process identifier in the event information. It should be noted that the user-space monitoring process queries the process's current resource pool label again to avoid errors caused by time differences. There is a certain time interval between the eBPF program writing the event and the user-space monitoring process reading the event, during which the process's resource pool label may have changed. If the user-space monitoring process directly uses the resource pool label from the event information to generate a rule set, the generated rule set may not match the process's current actual state. For example, when a process initiates a file access request, it belongs to the AI ​​pool, and the eBPF program writes this event to the circular buffer. Before the user-space monitoring process reads this event, the user drags the process to the file pool, and the user-space monitoring process updates the label value in BPFMaps. If the user-space monitoring process directly uses the AI ​​pool label from the event information to generate a rule set, it will incorrectly attach the AI ​​pool's rule set to the process instead of the file pool's rule set.

[0029] Specifically, the user-space monitoring process reads the resource pool label of the current process from the BPFMaps, which stores the mapping relationship between process identifiers and resource pool labels, using the BPF_MAP_LOOKUP_ELEM command of the BPF system call. Since the data in BPFMaps is updated in real time, the user-space monitoring process can obtain the latest resource pool label for the process. If the entry corresponding to the process identifier does not exist in BPFMaps, it means that the process has exited, and the user-space monitoring process can ignore this event. After obtaining the current resource pool label of the process, the user-space monitoring process queries the preset policy library to generate a Landlock rule set corresponding to the current resource pool label. The preset policy library stores a file system access whitelist for each resource pool, containing the file paths and corresponding access permissions that processes within that resource pool are allowed to access. The policy library can be stored in text format for easy configuration and modification by administrators. The user-space monitoring process loads the policy library into memory at startup and monitors changes to the policy library file through a file system monitoring mechanism. When the policy library file is modified, the user-space monitoring process reloads the policy library and updates the policy cache in memory. The file system monitoring mechanism can use the inotify interface, which can monitor changes to the file system, including file creation, deletion, modification, and movement. When the inotify interface detects a modification to the policy library file, it sends an event to the user-space monitoring process, which then reloads the policy library upon receiving the event.

[0030] For example, each resource pool entry in the policy library contains a resource pool label and a corresponding whitelist rule list. Each whitelist rule contains allowed file paths and allowed access permissions, which can include read, write, execute, etc. For example, the AI ​​pool's whitelist rules might include allowing read and write access to the ` / pool / ai / workspace / ` path and read-only access to the ` / usr / share / ai-models / ` path. The application pool's whitelist rules might include allowing read and write access to the ` / pool / app / ` path, allowing read and write access to the ` / home / user / ` path, and execute access to the ` / usr / bin / ` path. The security pool's whitelist rules might only include allowing read-only access to the ` / pool / security / ` path. The user-space monitoring process retrieves the corresponding whitelist rule list from the policy library based on the process's current resource pool label, and then generates a Landlock rule set based on these rules. If the policy library does not contain an entry corresponding to the resource pool label, the default policy rules are used, such as denying all file access or only allowing access to necessary system paths.

[0031] In this embodiment, the Landlock rule set contains a whitelist of file paths that processes are allowed to access. After a process attaches to this rule set, it can only access paths specified in the whitelist; access to paths outside the whitelist will be denied. Landlock is a kernel security module that provides the ability for non-privileged processes to self-limit, allowing processes to restrict their own access to the file system without requiring root privileges or external configuration files. As a stackable LSM module, Landlock can run simultaneously with other security modules without conflict. Landlock's security model is based on the principle of least privilege; processes can only access resources they are explicitly allowed to access, thus limiting the scope of damage caused by malicious processes.

[0032] It's important to note that Landlock's rule sets employ a default design that allows uncontrolled permissions. This means that only access permissions explicitly declared as requiring control within the rule set are restricted; undeclared permissions remain unaffected. This design ensures backward compatibility; older applications running on newer kernels will not be incorrectly denied access due to a lack of recognition of new access permission types. Therefore, when generating Landlock rule sets, the access permission types to be controlled must be explicitly specified. If control of all file system access permissions is required, all supported access permission types must be included in the `handled_access_rights` field of the rule set attributes. If only partial access permissions need to be controlled, only the corresponding permission types need to be included. For example, if only read and write permissions for files need to be controlled, only the bitmasks corresponding to read and write permissions need to be set in the `handled_access_rights` field; execution permissions will not be restricted by this rule set.

[0033] In this embodiment, after the user-space monitoring process generates a Landlock rule set, it needs to notify the target process to call the `landlock_restrict_self` system call to append the rule set. The notification to the target process can be achieved using inter-process communication mechanisms, such as Unix domain sockets or pipes. Unix domain sockets are a mechanism for communication between processes on the same host, supporting both data streams and datagrams, and supporting the transfer of file descriptors. Pipes are a unidirectional inter-process communication mechanism and can only be used between related processes. This application chooses Unix domain sockets as the notification mechanism because it can efficiently transfer file descriptors, is simple to implement, and has good performance. A communication channel is pre-established between the user-space monitoring process and the target process. When the user-space monitoring process generates a new rule set, it sends a notification to the target process through this communication channel, containing the file descriptors of the rule set. After receiving the notification, the target process calls the `landlock_restrict_self` system call to append the rule set to itself.

[0034] For example, upon startup, the target process creates a Unix domain socket and binds it to a unique address, such as ` / tmp / pool-sandbox-.sock`, where ` / tmp / pool-sandbox-.sock` is the target process's identifier. The target process then listens on this socket, waiting for a connection from a user-space monitoring process. When the user-space monitoring process needs to send a notification to the target process, it connects to the target process's Unix domain socket and passes the file descriptor of the rule set through the socket. Passing the file descriptor requires using the `sendmsg` system call and setting a control message in the `msghdr` structure. The control message type is `SCM_RIGHTS`, and the data is the file descriptor of the rule set. The target process receives the message via the `recvmsg` system call and retrieves the file descriptor of the rule set from the control message. After receiving the file descriptor, the target process calls the `landlock_restrict_self` system call to append the rule set to itself. The `landlock_restrict_self` system call applies the rule set to the current process and all its future child processes, and once the rule set is appended, it cannot be removed or relaxed; access permissions can only be further tightened by appending new rule sets. If the target process encounters an error while attaching the rule set, such as an invalid rule set file descriptor or insufficient permissions, the target process will send an error message to the user-space monitoring process. Upon receiving the error message, the user-space monitoring process will perform corresponding processing, such as regenerating the rule set or logging the error.

[0035] In this embodiment, the specific steps for generating a Landlock rule set corresponding to the current resource pool label include first calling the `landlock_create_ruleset` system call to create a rule set file descriptor, and specifying the file system access permission types to be managed through a structure during the call. The `landlock_create_ruleset` system call is an interface provided by Landlock for creating rule sets, and its prototype is `intlandlock_create_ruleset(conststructlandlock_ruleset_attrattr, size, u32flags)`. Here, the `attr` parameter points to the rule set attribute structure, the `size` parameter is the size of the rule set attribute structure, and the `flags` parameter is a flag; currently, the supported flag is `LANDLOCK_CREATE_RULESET_VERSION`, used to specify the Landlock version. The rule set attribute structure is used to specify the access permission types that the rule set needs to manage; different access permission types correspond to different bitmasks. The rule set attribute structure is defined as struct landlock_ruleset\attr{\_u64handled_access_rights;} where the handled_access_rights field is a 64-bit bitmask, with each bit representing a type of access permission that needs to be controlled.

[0036] It's important to note that Landlock supports various file system access permission types, including reading files, writing files, executing files, creating files, deleting files, renaming files, creating directories, deleting directories, mounting file systems, and unmounting file systems. Different kernel versions may support different access permission types. When creating a rule set, the corresponding access permission bitmask needs to be set according to the kernel's supported versions. The Landlock ABI version supported by the current kernel can be obtained using the `prctl` system call `PR_SET_LANDLOCK_ABI`, and then the supported access permission types can be determined based on the ABI version. If an access permission bit that is not supported by the kernel is set, the `landlock_create_ruleset` system call will return an error. Therefore, when generating a rule set, the user-space monitoring process needs to first check the kernel's supported Landlock versions and then set the corresponding `handled_access_rights` field accordingly.

[0037] For example, in Landlock ABI version 1, the supported access permission types include LANDLOCK_ACCESS_FS_EXECUTE, LANDLOCK_ACCESS_FS_WRITE_FILE, LANDLOCK_ACCESS_FS_READ_FILE, LANDLOCK_ACCESS_FS_READ_DIR, LANDLOCK_ACCESS_FS_REMOVE_DIR, LANDLOCK_ACCESS_FS_REMOVE_FILE, LANDLOCK_ACCESS_FS_MAKE_CHAR, LANDLOCK_ACCESS_FS_MAKE_DIR, LANDLOCK_ACCESS_FS_MAKE_REG, LANDLOCK_ACCESS_FS_MAKE_SOCK, LANDLOCK_ACCESS_FS_MAKE_FIFO, LANDLOCK_ACCESS_FS_MAKE_BLOCK, and LANDLOCK_ACCESS_FS_MAKE_SYM. In this context, LANDLOCK_ACCESS_FS_EXECUTE corresponds to the permissions for executing files, LANDLOCK_ACCESS_FS_WRITE_FILE corresponds to the permissions for writing files, LANDLOCK_ACCESS_FS_READ_FILE corresponds to the permissions for reading files, and LANDLOCK_ACCESS_FS_READ_DIR corresponds to the permissions for reading directory contents. To control file read, write, and execute permissions, the bitmasks corresponding to LANDLOCK_ACCESS_FS_EXECUTE, LANDLOCK_ACCESS_FS_WRITE_FILE, and LANDLOCK_ACCESS_FS_READ_FILE are ORed and then assigned to the handled_access_rights field. For example, handled_access_rights = LANDLOCK_ACCESS_FS_EXECUTE | LANDLOCK_ACCESS_FS_WRITE_FILE | LANDLOCK_ACCESS_FS_READ_FILE. When calling the `landlock_create_ruleset` system call, a pointer to this structure is passed as the `attr` parameter, the `size` parameter is set to `sizeof(struct landlock_ruleset_attr)`, and the `flags` parameter is set to 0. The system call returns a non-negative rule set file descriptor, which is used for subsequent rule addition and rule set appending operations.If the system call fails, it will return -1 and set the errno variable to indicate the reason for the error.

[0038] In this embodiment, after creating the rule set file descriptor, at least one LANDLOCK_RULE_PATH_BENEATH rule is added to the rule set file descriptor by calling the landlock_add_rule system call. The landlock_add_rule system call is an interface provided by Landlock for adding rules to a rule set. The prototype of this system call is int landlock_add_rule(in rule set_fd, enum landlock_rule_type rule_type, const void rule_attr, _u32 flags). Here, the rule set_fd parameter is the rule set file descriptor, the rule_type parameter is the rule type, the rule_attr parameter points to the rule attribute structure, and the flags parameter is the flag bits. Currently, the supported rule type is LANDLOCK_RULE_PATH_BENEATH, which specifies that certain access permissions are allowed under a certain path. This rule applies to the specified path and all its subdirectories and files. The attribute structure of the LANDLOCK_RULE_PATH_BENEATH rule is defined as struct landlock_path_beneath\attr{\_u64allowed\access;\_s32parent_fd;} where the allowed_access field is a 64-bit bitmask specifying the allowed access permission types, and the parent_fd field is the file descriptor of the allowed file path.

[0039] It's important to note that when adding the LANDLOCK_RULE_PATH_BENEATH rule, you must first open the allowed file path and obtain its file descriptor. When opening the path, you need to use the O_PATH flag, which indicates that you are opening a path, not the file itself, and that you don't need actual access permissions to that path. Using the O_PATH flag avoids issues caused by insufficient permissions. After opening the path, fill the file descriptor into the parent_fd field of the rule attribute structure, fill the allowed access bitmask into the allowed_access field, and then call the landlock_add_rule system call to add the rule to the rule set. Multiple rules can be added to the same rule set, each corresponding to an allowed path. All rules in the rule set are ORed; that is, if a process accesses a path that matches any one of the rules, access is allowed.

[0040] For example, if it's necessary to allow processes to read and write access to the ` / pool / ai / workspace / ` path, the `open` system call is first invoked to open the ` / pool / ai / workspace / ` path, with the parameter `open(" / pool / ai / workspace / ", O_PATH|O_CLOEXEC)`. The `O_CLOEXEC` flag indicates that the file descriptor is closed when the `exec` system call is executed, preventing file descriptor leaks. If the `open` system call succeeds, it returns a file descriptor. Then, a `landlock_path_beneath_attr` structure is created, setting the `parent_fd` field to the returned file descriptor and the `allowed_access` field to `LANDLOCK_ACCESS_FS_READ_FILE|LANDLOCK_ACCESS_FS_WRITE_FILE|LANDLOCK_ACCESS_FS_READ_DIR`. Finally, the `landlock_add_rule` system call is invoked, setting the `ruleset_fd` parameter to the previously created ruleset file descriptor, the `rule_type` parameter to `LANDLOCK_RULE_PATH_BENEATH`, the `rule_attr` parameter to the created `landlock_path_beneath_attr` structure, and the `flags` parameter to 0. If the system call succeeds, the rule is added to the ruleset. After adding the rule, the `parent_fd` file descriptor can be closed, as the ruleset now holds a reference to that path.

[0041] In this embodiment, the file system access permission types include at least one of read, write, and execute. Read permission allows a process to read the contents of a file, corresponding to the LANDLOCK_ACCESS_FS_READ_FILE permission bit in Landlock. Write permission allows a process to modify the contents of a file, create new files, delete files, rename files, etc., corresponding to the LANDLOCK_ACCESS_FS_WRITE_FILE, LANDLOCK_ACCESS_FS_REMOVE_FILE, and LANDLOCK_ACCESS_FS_MAKE_REG permission bits in Landlock. Execute permission allows a process to execute a file, corresponding to the LANDLOCK_ACCESS_FS_EXECUTE permission bit in Landlock. Different resource pools can be configured with different access permission combinations according to their security requirements. For example, a security pool may only allow read-only access to specific paths, an application pool may allow read and write access to specific paths under the user's home directory, and a development pool may allow read, write, and execute access to the source code directory.

[0042] It's important to note that Landlock manages access permissions bit-by-bit, with each access permission corresponding to a bitmask. When creating a rule set, the bitmasks corresponding to the access permissions to be managed are ORed to generate the `handled_access_rights` value. When adding a rule, the bitmasks corresponding to the allowed access permissions are ORed to generate the `allowed_access` value. The bits set in the `allowed_access` value must be a subset of the bits set in the `handled_access_rights` value; otherwise, the `landlock_add_rule` system call will return an error. This is because rule sets can only manage permissions declared in `handled_access_rights`; for permissions not declared, the rule set cannot restrict them. Therefore, when generating a rule set, ensure that the `handled_access_rights` value contains all permissions that need to be managed, and then when adding a rule, set the corresponding `allowed_access` value according to the security requirements of each path.

[0043] For example, if the `handled_access_rights` value of a rule set is set to `LANDLOCK_ACCESS_FS_READ_FILE|LANDLOCK_ACCESS_FS_WRITE_FILE|LANDLOCK_ACCESS_FS_EXECUTE`, then when adding a rule, the `allowed_access` value can only be a combination of these three permission bits. For instance, for a read-only path, the `allowed_access` value can be set to `LANDLOCK_ACCESS_FS_READ_FILE`; for a read-write path, it can be set to `LANDLOCK_ACCESS_FS_READ_FILE|LANDLOCK_ACCESS_FS_WRITE_FILE`; and for an executable path, it can be set to `LANDLOCK_ACCESS_FS_READ_FILE|LANDLOCK_ACCESS_FS_EXECUTE`. If you attempt to set the allowed_access value to include the LANDLOCK_ACCESS_FS_READ_DIR permission bit, which is not set in handled_access_rights, the landlock_add_rule system call will return an EINVAL error.

[0044] In this embodiment, the eBPF program obtains the resource pool label of a process by reading a mapping record from BPFMaps, where the process identifier is the key and the resource pool label is the value. This mapping record is written and updated by the user-space monitoring process when the ownership of the process resource pool changes. BPFMaps is an efficient data sharing mechanism provided by eBPF, enabling fast data exchange between kernel space and user space. This application uses a hash table type BPFMaps to store the mapping relationship between process identifiers and resource pool labels. The key of the hash table is a 32-bit process identifier, and the value is the resource pool label string. Hash table type BPFMaps were introduced in Linux kernel version 3.19 and are one of the most commonly used BPFMaps types, suitable for storing arbitrary key-value pairs.

[0045] It's important to note that BPFMaps are created when the eBPF program loads. During creation, the mapping type, key size, value size, and maximum number of entries must be specified. The key and value sizes must be multiples of 4 bytes; otherwise, the `bpf_map_create` system call will return an error. The maximum number of entries determines the maximum number of key-value pairs that a BPFMap can store. When a BPFMap is full, attempting to insert a new key-value pair will fail. Therefore, the maximum number of entries needs to be set appropriately based on the system's actual requirements. For desktop environments, the number of concurrently running processes typically does not exceed several thousand, so setting the maximum number of entries to 65536 is sufficient. User-space programs can manipulate BPFMaps using commands such as `BPF_MAP_LOOKUP_ELEM`, `BPF_MAP_UPDATE_ELEM`, `BPF_MAP_DELETE_ELEM`, and `BPF_MAP_GET_NEXT_KEY` via the `bpf` system call. The BPF_MAP_LOOKUP_ELEM command is used to query the value corresponding to a specified key, the BPF_MAP_UPDATE_ELEM command is used to update or insert key-value pairs, the BPF_MAP_DELETE_ELEM command is used to delete the key-value pair corresponding to a specified key, and the BPF_MAP_GET_NEXT_KEY command is used to iterate through all keys in a BPFMap.

[0046] For example, when a process starts, the user-mode launcher allocates a resource pool label to the process. The resource pool label can be passed to the process via environment variables, such as setting the `__POOL_LABEL` environment variable to `AI`. The user-mode launcher then calls the `fork` system call to create a child process, which in turn calls the `execve` system call to execute the target program. Before calling the `execve` system call, the user-mode launcher calls the `BPF_MAP_UPDATE_ELEM` command of the `bpf` system call to write the mapping between the child process's identifier and the resource pool label to `BPFMaps`. The parameters of the `BPF_MAP_UPDATE_ELEM` command include the file descriptor of `BPFMaps`, a pointer to the key, a pointer to the value, and flags. The flags can be set to `BPF_ANY`, `BPF_NOEXIST`, or `BPF_EXIST`. `BPF_ANY` means inserting the key if it doesn't exist, and updating it if it does; `BPF_NOEXIST` means inserting the key only if it doesn't exist; `BPF_EXIST` means updating the key only if it exists. When a process starts, the BPF_ANY flag is used to ensure that the mapping is written correctly. When a user drags a process from one resource pool to another in the desktop environment, the desktop environment triggers an event. The user-space monitoring process captures this event, obtains the process identifier and the new resource pool label, and then calls the BPF_MAP_UPDATE_ELEM command of the BPF system call to update the resource pool label value of the corresponding process identifier in BPFMaps using the BPF_EXIST flag. Using the BPF_EXIST flag avoids inserting mappings for non-existent processes. When a process exits, the kernel sends a SIGCHLD signal to the parent process. The user-space monitoring process can detect process exit events by registering a SIGCHLD signal handler. Upon receiving the SIGCHLD signal, the user-space monitoring process calls the waitpid system call to obtain the identifier of the exiting process, and then calls the BPF_MAP_DELETE_ELEM command of the BPF system call to delete the mapping record of the process from BPFMaps, thereby freeing up the storage space of BPFMaps.

[0047] In this embodiment, the kernel circular buffer is a BPF circular buffer. The BPF circular buffer is a new kernel-to-user space data transfer mechanism introduced in Linux kernel version 5.8. Compared to the traditional perfbuffer, the BPF circular buffer offers better memory efficiency and performance. The perfbuffer, introduced in Linux kernel version 4.0, uses an independent buffer for each CPU, with each buffer having a fixed size. When a CPU's buffer is full, new events are discarded. In contrast, the BPF circular buffer uses a single shared buffer, supports dynamic resizing, and can utilize memory more efficiently. Furthermore, the BPF circular buffer supports batch reading of events, allowing user-space processes to read multiple events at once, reducing the number of system calls and improving read efficiency. The BPF circular buffer also supports variable-length events, enabling the storage of event data of different sizes, while the perfbuffer can only store fixed-size event data.

[0048] It's important to note that the size of the BPF ring buffer can be specified during creation. The size must be a power of 2 and cannot exceed the system's maximum limit. This maximum limit can be viewed and modified using the ` / proc / sys / kernel / bpf_ringbuf_max_size` file. The size of the BPF ring buffer affects system memory usage and event loss rate. If the buffer is set too small, event loss will occur when the event generation rate exceeds the read rate of user-space processes. If the buffer is set too large, it will waste system memory. Therefore, the buffer size needs to be set appropriately based on the actual event generation rate of the system. For desktop environments, the file access event generation rate is usually not very high, so a buffer size of 4MB to 16MB is suitable. The BPF ring buffer supports two operating modes: default mode and discardable mode. In default mode, the `bpf_ringbuf_output` function blocks when the buffer is full until available space becomes available. In discardable mode, the `bpf_ringbuf_output` function discards new events and returns an `-ENOSPC` error when the buffer is full. The discardable mode can be enabled by setting the BPF_RB_NO_WAKEUP flag when calling the bpf_ringbuf_output function. In this embodiment, the default mode is used to ensure that all cross-pool access events are reported to the user-space monitoring process.

[0049] For example, the BPF circular buffer is created using the `bpf_map_create` function when the eBPF program loads. During creation, the mapping type is specified as `BPF_MAP_TYPE_RINGBUF`, the key size is 0, the value size is 0, and the maximum number of entries is the size of the buffer. For instance, to create a 4MB BPF circular buffer, the parameters are `bpf_map_create(BPF_MAP_TYPE_RINGBUF,NULL,NULL,0,0,410241024,NULL)`. Upon successful creation, the file descriptor of the BPF circular buffer is returned. The eBPF program reserves a buffer space for storing event data using the `bpf_ringbuf_reserve` function, then copies the event data into the reserved space, and finally calls the `bpf_ringbuf_submit` function to submit the events. The parameters of the `bpf_ringbuf_reserve` function include the file descriptor of the BPF circular buffer, the size of the event data, and flags. If the reservation is successful, a pointer to the reserved space is returned; if it fails, NULL is returned. The `bpf_ringbuf_submit` function takes a pointer to reserved space and a flag as arguments. After an event is submitted, it can be read by the user-space process. The user-space process creates a ring buffer object using the `ring_buffer_new` function, which takes the file descriptor of the BPF ring buffer and the event handling callback function as arguments. Then, it calls the `ring\buffer\poll` function to wait for events, taking the ring buffer object and a timeout as arguments. When an event is submitted to the ring buffer, `ring\buffer\poll` returns, and the user-space process calls `ring\buffer\consume` to handle the event. `ring\buffer\consume` iterates through all unprocessed events in the ring buffer and calls the registered event handling callback function to process each event. After processing the events, `ring\buffer\consume` automatically updates the read pointer and releases the buffer space occupied by the processed events.

[0050] In this embodiment, the method for determining whether a file path belongs to a cross-pool access is based on a pre-defined resource pool directory mapping table, using path prefix matching to determine the resource pool to which the target file path belongs. The resource pool directory mapping table stores the mapping relationship between resource pool labels and corresponding root directory paths; each resource pool corresponds to one or more root directory paths. Path prefix matching compares the target file path with the root directory path of a resource pool; if the target file path begins with the root directory path of a resource pool, then the file belongs to that resource pool. Path prefix matching is a simple and efficient file classification method that can quickly determine the resource pool to which a file belongs, making it suitable for use in high-frequency file access scenarios.

[0051] It should be noted that the resource pool directory mapping table can be pre-configured in the system or dynamically maintained by the user-space monitoring process. The resource pool directory mapping table can be configured through a configuration file, allowing administrators to add, delete, or modify the root directory paths of resource pools according to actual needs. To improve the query efficiency of eBPF programs, the resource pool directory mapping table can be stored in another BPFMaps, such as an array-type BPFMaps. The array-type BPFMaps are indexed by the resource pool number, and each array element stores the root directory path and corresponding resource pool label for a resource pool. The array size is set according to the number of resource pools; for example, setting it to 16 supports a maximum of 16 resource pools. Each array element is 272 bytes in size, with 256 bytes used to store the root directory path string and 16 bytes used to store the resource pool label string. When the user-space monitoring process starts, it reads the configuration file for the resource pool directory mapping table and then writes the root directory path and label of each resource pool into the array-type BPFMaps. When the resource pool directory mapping table changes, the user-space monitoring process updates the corresponding entries in the BPFMaps. When an eBPF program is triggered, it obtains the absolute path of the target file using the `bpf_d_path` function. Then, it iterates through all entries in the array-type `BPFMaps`, performing prefix matching between the target file path and the root directory path of each entry. During prefix matching, it's crucial that the path ends with a slash (` / `) to avoid false matches. For example, if the root directory path of the resource pool is ` / pool / ai`, then the path ` / pool / ai-workspace / ` would also be falsely matched as belonging to the AI ​​pool. Therefore, when configuring the resource pool root directory path, a slash should be added to the end of the path, for example, ` / pool / ai / `. This way, only files whose paths begin with ` / pool / ai / ` will be identified as belonging to the AI ​​pool.

[0052] For example, the resource pool directory mapping table contains four resource pool entries, corresponding to the file pool, AI pool, security pool, and application pool, with corresponding root directory paths of / pool / file / , / pool / ai / , / pool / security / , and / pool / app / , respectively. When the user-space monitoring process starts, it writes the information of these four resource pools into an array-type BPFMaps, where index 0 corresponds to the file pool, index 1 to the AI ​​pool, index 2 to the security pool, and index 3 to the application pool. When the target file path is / pool / ai / workspace / data.csv, the eBPF program compares this path with the root directory paths of the four resource pools. Finding that the path begins with / pool / ai / , it determines that the file belongs to the AI ​​pool. When the target file path is / pool / file / documents / report.pdf, the eBPF program determines that the file belongs to the file pool. When the target file path is / home / user / documents / sensitive_data.csv, this path does not belong to any predefined resource pool root directory path, therefore the file is determined to be an unclassified file. If a process's resource pool label is AI and the target file belongs to a file pool, it is considered a cross-pool access. If a process's resource pool label is AI and the target file is an unclassified file, the default policy determines whether it is a cross-pool access. The default policy can be configured to treat unclassified files as not belonging to any resource pool, thus all access to unclassified files is considered a cross-pool access; or it can be configured to treat unclassified files as belonging to all resource pools, thus access to unclassified files is not considered a cross-pool access.

[0053] In this embodiment, after the user-mode monitoring process detects a resource pool ownership change event for a process, it updates the resource pool label value corresponding to the process in BPFMaps. The resource pool ownership change event can be triggered by the desktop environment, for example, when a user drags an application window from one resource pool area to another. The desktop environment typically uses a window manager to manage application windows, handling operations such as window creation, destruction, movement, and resizing. When a user drags a window, the window manager receives a mouse event and determines which resource pool area the window has been dragged to based on its position. A resource pool area is a pre-defined logical area in the desktop environment, with each resource pool area corresponding to a resource pool label. The window manager can obtain the position and size information of the resource pool areas through a configuration file; for example, each resource pool area occupies one quadrant of the screen.

[0054] It's important to note that the user-mode monitoring process and the desktop environment can communicate via inter-process communication (IPC) mechanisms, such as D-Bus or Unix domain sockets. D-Bus is a high-level IPC mechanism widely used in Linux desktop environments for communication between desktop components. D-Bus supports two types of buses: the system bus and the session bus. The system bus is used for system-level communication, while the session bus is used for user session-level communication. The desktop environment's window manager typically registers a service on the session bus, providing window-related information and operation interfaces. The user-mode monitoring process can connect to the session bus and subscribe to window move events or resource pool ownership change events emitted by the window manager. When the window manager detects that a window has been dragged to a new resource pool area, it sends a signal via D-Bus containing the window's identifier and the new resource pool label. Upon receiving the signal, the user-mode monitoring process retrieves the corresponding process identifier using the window identifier and then updates the resource pool label value in BPFMaps.

[0055] For example, the desktop environment's window manager registers a service named `org.freedesktop.WindowManager` on the session bus. This service provides a `WindowMoved` signal, which is emitted when a window is moved. The signal parameters include the window's XID, the window's current position coordinates, and the window's size. The user-mode monitoring process connects to the session bus and subscribes to the `WindowMoved` signal by calling the `dbus_bus_add_match` function. When a user drags an application window from the file pool area to the AI ​​pool area, the window manager detects the change in the window's position and calculates that the window's current resource pool area is the AI ​​pool. The window manager then emits the `WindowMoved` signal via the D-Bus, which contains the window's XID, new position coordinates, and size. Upon receiving the signal, the user-mode monitoring process retrieves the process ID corresponding to the window using the `XGetWindowProperty` function from the Xlib library. The Xlib library is a client library for the X Window system, providing an interface for interacting with the X server. The window's process ID is typically stored in the `_WM_PID` attribute. After obtaining the process identifier, the user-space monitoring process calls the BPF_MAP_UPDATE_ELEM command of the BPF system call to update the resource pool label value of the corresponding process identifier in BPFMaps to AI. After this update operation is completed, the next time the process triggers the LSM hook, the resource pool label read by the eBPF program will be AI.

[0056] In this embodiment, the user-space monitoring process generates audit log records based on the read event information and writes these records to an audit log file. The audit log records contain detailed event information, such as process identifier, user identifier, source resource pool label, target file path, access type, event timestamp, process name, parent process identifier, and process command-line parameters. Audit logs can be used for post-event security auditing and event tracing, helping administrators understand cross-pool access events occurring in the system and discover potential security threats. By analyzing audit logs, administrators can identify abnormal access behaviors, such as a process frequently attempting to access sensitive files that do not belong to its resource pool, and thus take timely measures to address the issue.

[0057] It's important to note that the audit log format can be designed according to actual needs. For example, the JSONLines format can be used, where each log entry is an independent JSON object, facilitating subsequent log analysis and processing. The advantages of the JSONLines format are its ease of parsing and support for various log analysis tools, such as grep, awk, and jq. Audit log files can be stored on the local disk or sent to a remote log server for centralized storage and analysis. Sending audit logs to a remote log server prevents local logs from being tampered with or deleted, improving log security. User-space monitoring processes can use the syslog protocol to send logs to a remote log server, or they can use dedicated log collection tools such as Fluentd and Logstash. User-space monitoring processes can configure log rotation policies to automatically create new log files and archive or delete old log files when they reach a certain size or have been stored for a certain period. Log rotation prevents individual log files from becoming too large and consuming excessive disk space. Log rotation can be implemented using the logrotate tool, a commonly used log management tool in Linux systems. Logrotate supports log rotation by size and time, and can be configured with features such as compression and email notifications.

[0058] For example, the user-space monitoring process reads a cross-pool access event from the circular buffer. The event information includes process ID 12345, user ID 1000, source resource pool label AI, target file path / home / user / documents / sensitive_data.csv, access type OPEN_FOR_READ, and event timestamp 1716624000. The user-space monitoring process obtains the process name and parent process ID by reading the / proc / 12345 / status file, and obtains the process's command-line arguments by reading the / proc / 12345 / cmdline file. This information is then organized into a JSON object with the following content: {"pid":12345,"uid":1000,"source_pool":"AI","target_path":" / home / user / documents / sensitive_data.csv","access_type":"OPEN _FOR_READ","timestamp":1716624000,"process_name":"data_analysis","ppid":12300,"cmdline":"data_analysis--inputdata.csv"} The user-space monitoring process writes the JSON object to the audit log file ` / var / log / pool-audit.log`, with each JSON object occupying one line. Simultaneously, the user-space monitoring process can send this log entry to a remote log server, which stores the log in a database for administrators to query and analyze. Administrators can use log analysis tools to query access records for specific processes, users, or resource pools to identify abnormal access behavior.

[0059] In this embodiment, when a process's resource pool label changes and file access permissions need to be relaxed, the user-space monitoring process restarts the process and appends the Landlock rule set corresponding to the new resource pool label to the restarted process. Landlock rule sets take effect in a layered manner; each call to the `landlock_restrict_self` system adds a new rule set layer on top of the existing one, and this new layer can only be stricter than the old one, not more lenient. This is a Landlock security design principle, preventing processes from escalating their access permissions after being sandboxed. Therefore, if a process needs to switch from a resource pool with stricter access permissions to one with more lenient permissions, it cannot restore prohibited access permissions by appending a new rule set to the existing process; the process must be restarted.

[0060] It's important to note that process restarting can be done automatically by the user-mode monitoring process or manually by the user. When the user-mode monitoring process detects that a process needs to have its access permissions relaxed, it can send a notification to the process requesting it to exit. Upon receiving the notification, the process can perform necessary cleanup tasks, such as saving the user's work state, and then exit normally. The user-mode monitoring process then starts a new process instance, setting a new resource pool label for it upon startup and attaching the Landlock rule set corresponding to the new resource pool label. In a desktop environment, process restarting typically manifests as closing and reopening application windows, with minimal impact on the user experience. Most desktop applications support session recovery, restoring previously opened files and window states after a restart, allowing the user to continue their previous work. The user-mode monitoring process can work with the desktop environment's session management component to achieve seamless state recovery during process restarts. The session management component manages the user's session state, including open applications, window positions and sizes, and open files. When a process needs to restart, the user-mode monitoring process can request the session management component to save the process's state and then restore it when the new process starts.

[0061] For example, a process currently belongs to a security pool, whose rule set only allows the process to access the ` / pool / security / ` path. The user drags this process to an application pool, whose rule set allows the process to access the ` / pool / app / ` and ` / home / user / ` paths. Upon receiving a resource pool ownership change event, the user-space monitoring process first compares the allowed access path sets of the security pool and the application pool. The allowed access path set of the security pool is `{ / pool / security / }`, while the allowed access path set of the application pool is `{ / pool / app / , / home / user / }`. Since the allowed access path set of the application pool is not a subset of the allowed access path set of the security pool, permission relaxation cannot be achieved by appending a new rule set to the existing process. At this point, the user-space monitoring process sends an exit notification to the process via a Unix domain socket, containing the reason for the need to restart. Upon receiving the notification, the process saves its current working state, such as open files and edited content, and then calls the `exit` system call to exit normally. After detecting the process exit, the user-space monitoring process starts a new process instance. When a new process is launched, the user-space launcher sets the application pool's resource pool label for the new process and writes the mapping between the new process's identifier and the resource pool label into BPFMaps. Then, the user-space monitoring process generates the application pool's Landlock rule set and notifies the new process to attach to that rule set. After attaching the rule set, the new process can access paths permitted by the application pool. Simultaneously, the desktop environment's session management component restores the new process's state, opening previous files and windows, allowing the user to continue their previous work.

[0062] In this application embodiment, a secure access system for resource pooling desktops on a Linux operating system is provided, such as... Figure 2 As shown, the system includes an eBPF program module 1 mounted on the kernel LSM hook point, a user-mode monitoring module 2, and a Landlock security module 3. The eBPF program module obtains the resource pool label of a process when it initiates a file access request. It determines whether the access is cross-pool based on the resource pool to which the target file path belongs. If so, it writes event information containing the process identifier, resource pool label, and target file path to the kernel circular buffer. The user-mode monitoring module reads event information from the circular buffer, determines the process's current resource pool label based on the process identifier in the event information, queries a preset policy library, generates a Landlock rule set corresponding to the current resource pool label, and notifies the process to attach the rule set. The Landlock security module responds to the `landlock_restrict_self` system call invoked by the process, restricting the process to access only paths in the file path whitelist based on the Landlock rule set, thus achieving secure access between resource pools.

[0063] It's important to note that the eBPF program module runs in kernel mode, loaded into the kernel by the eBPF program loader, and mounted to a specified LSM hook point. The eBPF program loader is a user-space tool responsible for loading the compiled eBPF bytecode into the kernel and creating the relevant BPFMaps. The main function of the eBPF program module is to monitor process file access events in real time, determine whether they are cross-pool accesses, and report these events to the user-space monitoring module. The logic of the eBPF program module is kept as simple as possible, performing only necessary checks and event reporting operations to minimize the impact on system performance. The user-space monitoring module runs in user mode and, as the core control component of the system, is responsible for receiving events reported by the eBPF program module, making policy decisions, generating Landlock rule sets, and notifying target processes to attach the rule sets. The user-space monitoring module is also responsible for managing process tag mappings and resource pool directory mappings in BPFMaps, handling resource pool ownership change events, and generating audit logs. The Landlock security module is a kernel-built-in security module responsible for performing actual access control checks and restricting process file system access based on the rule sets attached to the processes. The Landlock security module performs checks at LSM hook points in the VFS layer to ensure that all file system accesses are validated by the rule set.

[0064] In this embodiment, the eBPF program module and the user-space monitoring module communicate via a BPF circular buffer. The eBPF program module writes events to the circular buffer, and the user-space monitoring module reads events from the circular buffer. This communication method is asynchronous; the eBPF program module does not need to wait for a response from the user-space monitoring module after writing an event and can continue to perform subsequent operations. The user-space monitoring module communicates with the target process via Unix domain sockets. The user-space monitoring module uses this mechanism to send a rule set file descriptor to the target process, notifying the target process to attach the rule set. This communication method is synchronous; the user-space monitoring module can wait for a response from the target process after sending the notification to confirm whether the rule set has been successfully attached. The Landlock security module interacts with the target process via system calls. The target process calls the `landlock_restrict_self` system call to attach the rule set, and the Landlock security module performs access control checks when the process initiates a file access request.

[0065] For example, in a specific application scenario, the system has deployed four resource pool directories: / pool / file / , / pool / ai / , / pool / security / , and / pool / app / , corresponding to the file pool, AI pool, security pool, and application pool, respectively. Path whitelists for each pool are pre-configured and stored in the policy library. The file pool's whitelist allows access to the / pool / file / and / home / user / documents / paths; the AI ​​pool's whitelist allows access to the / pool / ai / workspace / and / usr / share / ai-models / paths; the security pool's whitelist only allows access to the / pool / security / path; and the application pool's whitelist allows access to the / pool / app / and / home / user / paths. The eBPF program has been loaded and mounted on the security_file_open hook. A mapping relationship between process identifiers and resource pool tags for all running processes has been established in BPFMaps. The user-space monitoring process is running, continuously reading events from the circular buffer.

[0066] In the desktop environment, a user drags an application process called "Data Analysis Tool" from the file pool area to the AI ​​pool area. The desktop environment's window manager captures this drag-and-drop event, identifies the target process as 12345, and sends an internal message to the user-mode monitoring process. The message contains the process ID 12345, the new resource pool label "AI," and the old resource pool label "FILE."

[0067] Upon receiving the message, the user-space monitoring process immediately invokes the BPF system call to update the resource pool tag value corresponding to process identifier 12345 in BPFMaps, changing it from FILE to AI. This update operation has low latency, and the next time this process triggers any LSM hook, the eBPF program will read the tag value as AI.

[0068] Simultaneously, the user-space monitoring process queries the AI ​​pool's file system whitelist from the policy library to obtain the paths allowed to access by the AI ​​pool and their corresponding access permissions. The user-space monitoring process calls the `landlock_create_ruleset` system call to create a new rule set file descriptor, specifying the access permission types to be controlled as read, write, and execute in the rule set attribute structure. Then, the user-space monitoring process opens the ` / pool / ai / workspace / ` and ` / usr / share / ai-models / ` paths respectively, obtaining the file descriptors for these two paths. Next, the user-space monitoring process calls the `landlock_add_rule` system call to add two `LANDLOCK_RULE_PATH_BENEATH` rules to the rule set. The first rule allows read and write access to the ` / pool / ai / workspace / ` path, and the second rule allows read-only access to the ` / usr / share / ai-models / ` path.

[0069] After the rule set is created, the user-space monitoring process passes the file descriptor of the rule set to the target process through a pre-established Unix domain socket connection. Upon receiving the file descriptor, the target process calls the `landlock_restrict_self` system call to append the rule set to itself. At this point, file system access for the target process and all its future child processes will be restricted by this rule set, allowing access only to the ` / pool / ai / workspace / ` and ` / usr / share / ai-models / ` paths.

[0070] Sometime after the Landlock rule set has been attached, the data analysis tool process performs a user action, attempting to open the file / home / user / documents / sensitive_data.csv. The process invokes the open system call, triggering the security_file_open hook at the virtual file system layer in the kernel.

[0071] The eBPF program is executed within the hook, retrieving the current process identifier (12345) using the `bpf_get_current_pid_tgid` function. Then, the eBPF program queries the BPFMaps, which stores the mapping between process identifiers and resource pool labels, using 12345 as the key. This retrieves the resource pool label for this process as AI. Next, the eBPF program performs prefix matching between the target file path ` / home / user / documents / sensitive_data.csv` and the root directory paths in the resource pool directory mapping table. Finding that this path does not belong to any predefined resource pool directory, it is therefore classified as an unclassified file.

[0072] The eBPF program compares the current process's tag AI with the origin of the target file and determines it to be a cross-pool access. Instead of directly rejecting the operation, the eBPF program writes an alert event to the BPF circular buffer. The event content includes the process ID 12345, user ID 1000, source resource pool tag AI, target file path / home / user / documents / sensitive_data.csv, access type OPEN_FOR_READ, and event timestamp.

[0073] Almost simultaneously, in the subsequent execution order of the LSM hook chain, the Landlock security module's inspection logic is also invoked in the `security_file_open` hook. The Landlock security module checks the rule sets already attached to the current process and finds that the target file path ` / home / user / documents / sensitive_data.csv` is not in the rule set's allowed access list, therefore returning a permission denied error. The kernel returns this error code to the user-space `open` system call, and the process receives a permission denied message.

[0074] After the user-space monitoring process reads the alarm event written by eBPF from the circular buffer, it formats the event information into audit log entries and writes them to the audit log file / var / log / pool-audit.log. The audit log entries contain the complete cross-pool access context, facilitating subsequent audit analysis and policy backtracking.

[0075] If the user decides to drag the data analysis tool back from the AI ​​pool to the file pool in subsequent operations, the user-space monitoring process will update the label value in BPFMaps again, changing it from AI to FILE. Simultaneously, the user-space monitoring process will attempt to generate a Landlock rule set for the file pool for that process. However, since the AI ​​pool rule set already prohibits the process from accessing the ` / pool / file / ` and ` / home / user / documents / ` paths, and Landlock does not allow relaxing existing restrictions, the user-space monitoring process cannot grant the process new access permissions by attaching the file pool rule set to the existing process. At this point, the user-space monitoring process will send an exit notification to the process, and the process will exit normally upon receiving the notification. Then, the user-space monitoring process will start a new data analysis tool process instance, setting the file pool resource pool label for the new process upon startup and attaching the file pool's Landlock rule set, enabling the new process to access paths permitted by the file pool.

[0076] In this embodiment, dynamic adjustment of file access boundaries for desktop processes is achieved by separating kernel-mode event awareness from user-mode policy decision-making and execution control. Traditional security mechanisms typically couple awareness and execution together. For example, SELinux and AppArmor perform all access control checks in the kernel, and policies are pre-written by the administrator, making dynamic adjustment based on the real-time state of processes impossible. SELinux employs a mandatory access control model, marking processes and files based on security contexts, resulting in highly complex policy rules that are difficult to write and maintain. AppArmor uses a path-based access control model, with relatively simple policy rules, but these rules remain static and cannot be dynamically adjusted during process execution. While Seccomp-BPF filters can be dynamically loaded by user-mode programs, they cannot be modified once loaded and can only filter system call parameters, lacking fine-grained control at the file path level. Seccomp-BPF primarily restricts the system calls a process can make, rather than restricting process access to the file system.

[0077] While eBPF can intercept file access requests in real-time at kernel LSM hook points when used alone for access control, the eBPF program runs in a restricted kernel environment and cannot execute complex security processing logic. The instruction set of an eBPF program is limited, lacking support for complex control flow structures such as loops and recursion, and it cannot call external functions. Therefore, eBPF programs cannot perform operations requiring significant computation or external resources, such as calling external tools for file desensitization, triggering user approval processes, or communicating with remote servers. Furthermore, the return value of an eBPF hook follows the principle of non-reversal of denial; if other security modules have already denied an operation, eBPF cannot change it to permission. This limits the flexibility of eBPF as the sole access control mechanism, as it cannot override the decisions of other security modules.

[0078] While Landlock can achieve self-restriction for non-privileged processes when used alone for access control, and rule sets can be appended multiple times during process execution, Landlock's rule sets can only be tightened, not loosened. When a process needs to switch from a resource pool with stricter access permissions to one with more lenient permissions, it cannot restore prohibited access permissions by appending a new rule set. This makes Landlock unable to adapt to the dynamic changes in process resource pool ownership in a resource-pooled desktop environment. In a resource-pooled desktop environment, users may frequently switch applications between different resource pools, requiring application access permissions to adjust in real time according to changes in resource pool ownership. If permissions can only be adjusted by restarting the process, it will affect the user experience, especially for applications that need to run for extended periods.

[0079] This application combines eBPF and Landlock. eBPF is responsible for real-time detection of process file access events and resource pool label changes, Landlock is responsible for performing the actual access control checks, and the user-space monitoring process is responsible for policy decisions and dynamic generation of rule sets. This architecture decouples the detection, decision-making, and execution stages, allowing each stage to focus on its own function, thus achieving a balance between dynamism and security. eBPF is mounted on kernel LSM hook points, enabling it to obtain accurate process and file information before file access operations are executed, eliminating the time lag problem inherent in user-space polling schemes. User-space polling schemes obtain process information by periodically reading the / proc file system, which inherently has a time lag; the process state may have changed within the polling interval, leading to inaccurate access control decisions. The eBPF program executes after the kernel has completed the user-space data copy and before the actual file operation is executed, ensuring that the information obtained is up-to-date.

[0080] eBPF programs perform only simple tag matching and event reporting operations, with simple logic and minimal impact on system performance. eBPF programs have a small instruction set and are optimized by the kernel verifier, resulting in fast execution speed. In normal desktop use, most file accesses are within the same pool; eBPF programs only need to perform simple tag matching and do not need to write events, therefore their impact on system performance is negligible. eBPF programs only write events to the circular buffer when cross-pool access occurs, and cross-pool access is a low-frequency event in normal use.

[0081] User-mode monitoring processes run in user space, possessing full access to system resources and capable of executing complex policy decision-making logic. They can make comprehensive decisions based on factors such as the severity of the event, the process's reputation, and the user's permissions, taking different actions accordingly. For example, for low-risk cross-pool access, access can be allowed and audit logs recorded; for medium-risk cross-pool access, files can be anonymized before access is permitted; and for high-risk cross-pool access, access can be directly denied and an alarm triggered. User-mode monitoring processes can also be integrated with other security systems, such as intrusion detection systems and security information and event management systems, to achieve more comprehensive security protection.

[0082] As a kernel-level security module, Landlock provides unbypassable mandatory access control. Landlock's access control checks are performed at the VFS layer; all file system accesses must pass through the VFS layer, making it impossible for user-space programs to bypass. User-space sandbox mechanisms, such as hooks based on LD_PRELOAD, can only intercept file access via C library functions, not direct system calls, making them vulnerable to malicious programs. Landlock's rule set is maintained in the kernel, preventing user-space programs from modifying or deleting it, thus ensuring the security of access control.

[0083] The user-mode monitoring process dynamically generates Landlock rule sets based on the process's real-time resource pool labels and notifies the process to attach these rule sets, allowing the process's access permissions to adjust according to changes in its resource pool ownership. When a process needs to tighten its access permissions, a new rule set can be attached. For example, when a process switches from the application pool to the AI ​​pool, the application pool's rule set allows access to more paths, while the AI ​​pool's rule set allows access to fewer paths. The new rule set is stricter than the old one, conforming to Landlock's restriction that access can only be tightened, not relaxed. When a process needs to relax its access permissions, it is achieved by restarting the process and attaching the new rule set. This approach conforms to Landlock's security model and adapts to the usage habits of desktop environments. In desktop environments, users typically close unnecessary applications and then open new ones; process restarting is a common operation with minimal impact on the user experience.

[0084] Furthermore, this application employs a BPF circular buffer as the event transmission channel between kernel mode and user mode, enabling efficient transmission of large numbers of file access events while ensuring no event loss and in-order delivery. The BPF circular buffer is implemented using shared memory, eliminating the need for data copying and resulting in high transmission efficiency. It also supports batch reading of events, reducing the number of system calls and improving the processing efficiency of user-mode processes. BPFMaps are used to store the mapping relationship between process identifiers and resource pool tags, as well as a resource pool directory mapping table, enabling fast data exchange between kernel mode and user mode and ensuring the immediacy of tag updates. Read and write operations on BPFMaps are atomic, preventing concurrent access issues.

[0085] This application's solution, while ensuring kernel-level mandatory isolation, dynamically adjusts the file access boundaries of desktop processes and supports controlled relay processing during cross-pool access, thus meeting the security access control requirements of resource-pooled desktops. The solution has low performance overhead, with almost no impact on normal desktop operations, making it suitable for deployment in high-frequency interactive desktop environments. This solution requires no modification to kernel code or loading of kernel modules; only the relevant programs and configuration files need to be installed in user space, making deployment and maintenance relatively simple. Furthermore, the solution has good scalability, allowing for the addition of new resource pools, adjustment of security policies, and expansion of the scope of access control as needed.

[0086] Those skilled in the art will understand that the embodiments of this application are not limited to the specific examples described above. Without departing from the spirit and scope of this application, those skilled in the art can make various modifications and variations to the technical solutions of this application. For example, the technical solutions of this application can be applied to other types of software authentication scenarios, or equivalent substitutions can be made to the technical features of this application. These modifications and variations should all fall within the protection scope of this application. Further details are omitted here.

Claims

1. A secure access method for resource-pooled desktops in a Linux operating system, comprising: When a process initiates a file access request, the eBPF program mounted on the kernel LSM hook point obtains the resource pool label of the process, determines whether it is a cross-pool access based on the resource pool to which the target file path belongs, and if so, writes the event information containing the process identifier, the resource pool label and the target file path into the kernel ring buffer. The user-mode monitoring process reads the event information from the circular buffer, determines the current resource pool label of the process based on the process identifier in the event information, queries the preset policy library, and generates a Landlock rule set corresponding to the current resource pool label. The Landlock rule set contains a whitelist of file paths that the process is allowed to access. The process is notified to call the landlock_restrict_self system call to attach the Landlock rule set, so that the process can only access paths in the file path whitelist, thereby achieving secure access between resource pools; The resource pool is a predefined logical grouping of desktop resources corresponding to different security policy domains; The generation of the Landlock rule set corresponding to the current resource pool label includes: A rule set file descriptor is created by calling the landlock_create_ruleset system call, and the file system access permission types to be managed are specified by a structure when the call is made; By invoking the landlock_add_rule system call, at least one LANDLOCK_RULE_PATH_BENEATH rule is added to the rule set file descriptor. The LANDLOCK_RULE_PATH_BENEATH rule specifies a parent path that is allowed access and the access permissions allowed under that parent path.

2. The method according to claim 1, characterized in that, The file system access permission types include at least one of read, write, and execute.

3. The method according to claim 1, characterized in that, The eBPF program obtains the resource pool label of the process, including: The eBPF program reads mapping records from BPFMaps with process identifier as the key and resource pool label as the value. These mapping records are written and updated by the user-mode monitoring process when the ownership of the process resource pool changes.

4. The method according to claim 1, characterized in that, The kernel ring buffer is a BPF ring buffer.

5. The method according to claim 1, characterized in that, The step of determining whether it is a cross-pool access based on the resource pool to which the target file path belongs includes: Based on a pre-defined resource pool directory mapping table, the resource pool to which the target file path belongs is determined by path prefix matching.

6. The method according to claim 3, characterized in that, Also includes: After the user-mode monitoring process detects a change in the resource pool ownership of a process, it updates the resource pool tag value corresponding to the process in BPFMaps.

7. The method according to claim 1, characterized in that, Also includes: The user-mode monitoring process generates audit log records based on the read event information and writes the audit log records to the audit log file.

8. The method according to claim 1, characterized in that, Also includes: When a process's resource pool label changes and file access permissions need to be relaxed, the user-mode monitoring process restarts the process and appends the Landlock rule set corresponding to the new resource pool label to the restarted process.

9. A secure access system for resource pooling desktops in a Linux operating system, comprising: The eBPF program module, mounted on the kernel LSM hook point, is used to obtain the resource pool label of the process when the process initiates a file access request, and determine whether it is a cross-pool access based on the resource pool to which the target file path belongs. If so, it writes the event information containing the process identifier, the resource pool label and the target file path into the kernel ring buffer. The user-mode monitoring module is used to read the event information from the circular buffer, determine the current resource pool label of the process based on the process identifier in the event information, query the preset policy library, generate a Landlock rule set corresponding to the current resource pool label, and notify the process to attach the Landlock rule set. The Landlock rule set contains a whitelist of file paths that the process is allowed to access. The generation of the Landlock rule set corresponding to the current resource pool label includes: A rule set file descriptor is created by calling the landlock_create_ruleset system call, and the file system access permission types to be managed are specified by a structure when the call is made; By calling the landlock_add_rule system call, at least one LANDLOCK_RULE_PATH_BENEATH rule is added to the rule set file descriptor. The LANDLOCK_RULE_PATH_BENEATH rule specifies a parent path that is allowed to access and the access permissions allowed under that parent path. The Landlock security module is used to respond to the landlock_restrict_self system call invoked by the process, and restrict the process to access only paths in the file path whitelist according to the Landlock rule set, thereby achieving secure access between resource pools.

Images