Kernel auditing message transmission method based on structure

Abstract

The kernel audit message transmission method based on the structure body comprises the following steps: determining a core audit field set; designing an audit message structure body with member variables corresponding to the fields in the core audit field set one by one; when an audit event is generated by a kernel audit subsystem, extracting corresponding audit field information from a kernel data structure and filling the audit message structure body; transmitting the filled audit message structure body to a parser of a user state audit daemon; and directly accessing the member variables in the audit message structure body by the parser to obtain the audit field information, so as to realize direct memory access of the structured field. Through the combination of the structured design and the zero-copy technology, the efficiency bottleneck of the traditional Linux kernel audit system in a high-performance scene is solved, meanwhile, the flexible extension mechanism meets the complex audit demand, and the method can be widely applied to scenes with strict requirements for security audit, such as server clusters and cloud native environments.

Description

Technical Field

[0001] This invention relates to the field of operating system security auditing technology, and in particular to audit message transmission technology between kernel auditing subsystems (such as kaudit) and user-space auditing daemons (such as auditd) in the Linux kernel, especially to structured message transmission based on zero-copy mechanism and direct memory access to structured fields. Background Technology

[0002] In a Linux kernel auditing system, the kernel auditing subsystem (typically kaudit) is responsible for collecting various audit event information in the kernel, such as process operations, resource access, and network connections. This information is then transmitted to the user-space auditing daemon (typically auditd), which performs further processing, storage, and analysis to achieve security monitoring and audit tracing of the Linux system.

[0003] Currently, data transmission between the kernel audit subsystem and the user-space audit daemon in Linux kernel audit systems mostly uses a continuous buffer (byte stream), which is ultimately presented and processed as a text log. The kernel audit subsystem concatenates the collected audit field information into a byte stream according to a certain format, stores it in a fixed-size buffer, and then transmits the buffer to the user-space audit daemon. During this process, the data needs to be copied multiple times (e.g., from kernel space to page cache, and then from page cache to user space). After receiving the buffer, the user-space audit daemon needs to parse the byte stream according to a preset format, convert it into a text log, and then extract specific audit fields such as process identifier, process name, subject / object information, and operation type from the text log. This process involves a large number of string splitting and conversion operations.

[0004] However, this transmission method based on continuous buffers and text log processing has the following drawbacks:

[0005] 1. Complex parsing: Because the data in the buffer is a continuous byte stream, the user-space audit daemon needs to parse it byte by byte according to preset offsets and formats. For fields with variable lengths (such as process names, resource paths, etc.), it is also necessary to handle delimiters or length markers. The parsing process is cumbersome and prone to errors. Text logs require string matching, splitting, and other operations to extract fields.

[0006] 2. Poor scalability: When it is necessary to add or modify audit fields, not only is it necessary to modify the buffer filling logic in the kernel audit subsystem, but also to modify the corresponding parsing logic in the user-space audit daemon process as well as the format and processing method of text logs. This involves significant changes to the system, resulting in poor scalability and hindering system upgrades and maintenance.

[0007] 3. Inefficiency: On the one hand, the user-mode audit daemon process consumes a lot of CPU resources and time to parse byte streams and extract fields from text logs; on the other hand, the multiple copy operations during data transmission further increase system overhead and reduce the overall processing efficiency of the audit system.

[0008] 4. Type insecurity: The data in the buffer and the content in the text log do not have clear type identifiers. The user-mode audit daemon may encounter type conversion errors during parsing and extraction, resulting in inaccurate audit field information.

[0009] Compared with existing text log processing methods, direct memory access to structured fields has significant advantages, but existing technologies do not adopt this approach. Therefore, how to provide a Linux kernel audit message transmission method and system that can simplify the parsing process, reduce data copying, utilize the advantages of direct memory access to structured fields, and improve scalability and transmission efficiency has become an urgent problem for those skilled in the art. Summary of the Invention

[0010] To address the shortcomings of existing technologies, this invention provides a kernel audit message transmission method based on structures, comprising the following steps:

[0011] Step S1: Analyze the key audit information transmitted from the kernel audit subsystem to the user-mode audit daemon in the kernel audit scenario, and determine the core audit field set;

[0012] Step S2: Design an audit message structure that corresponds one-to-one with the member variables and fields in the core audit field set;

[0013] Step S3: When the kernel audit subsystem generates an audit event, it extracts the corresponding audit field information from the kernel data structure and fills it into the audit message structure;

[0014] Step S4: The kernel audit subsystem transmits the filled audit message structure to the parser of the user-mode audit daemon through the kernel-user space communication mechanism and the zero-copy mechanism;

[0015] Step S5: The parser of the user-mode audit daemon receives the audit message structure and directly accesses the member variables in the audit message structure to obtain audit field information, thereby realizing direct memory access to structured fields.

[0016] The audit message structure adopts a hierarchical nested structure design, including a metadata header structure, a basic process information structure, a contextual information union, and an extended field area structure.

[0017] The metadata header structure includes a magic number identifier, protocol version, event type, nanosecond-level timestamp, globally unique sequence number, and flag bits.

[0018] The basic process information structure includes process ID, parent process ID, actual user ID, effective user ID, actual group ID, process name, and session ID;

[0019] The contextualized information complex includes three types of dedicated structures: system call information structure, file operation information structure, and network event information structure. The corresponding dedicated structure type is activated according to the event type.

[0020] The extended field area structure contains a type identifier, value length, and variable-length data.

[0021] The system call information structure includes the system call number, CPU architecture, number of parameters, and parameter values.

[0022] The file operation information structure includes file permissions, inode number, device number, file path, and operation type;

[0023] The network event information structure includes the source IP address, destination IP address, source port, destination port, and protocol type.

[0024] The metadata header structure is a fixed length of 22 bytes.

[0025] The basic process information structure uses the __attribute__((packed)) attribute to ensure a compact layout, and the process name field is 16 bytes long.

[0026] Specifically, when filling audit field information into the audit message structure, the audit field information is validated. The validation includes verifying the correctness of the magic number identifier, the validity of the process ID, the length of the process name string, and the completeness of the subject and object information. If the validation fails, the corresponding audit message structure is marked as invalid and discarded.

[0027] Specifically, the definition version of the audit message structure is identified by the protocol version field in the metadata header structure. When an audit field is added or modified, a new version of the audit message structure is generated, while maintaining backward compatibility with the old version of the audit message structure.

[0028] The kernel audit subsystem is the Linux kaudit module, and the user-space audit daemon is the Linux auditd process. The kernel-user space communication mechanism is a socket communication mechanism, which uses a custom protocol type to encapsulate and transmit the audit message structure. The zero-copy mechanism uses memory mapping or direct I / O to directly transfer the audit message structure between kernel space and user space, avoiding data copy overhead.

[0029] The socket communication mechanism is the Linux Netlink socket communication mechanism, which combines Netlink's zero-copy extension interface to implement the transmission of audit message structures.

[0030] This invention solves the efficiency bottleneck of traditional Linux kernel auditing systems in high-performance scenarios by combining structured design with zero-copy technology. At the same time, it meets complex auditing needs through a flexible extension mechanism and can be widely used in scenarios with strict security auditing requirements, such as server clusters and cloud-native environments. Detailed Implementation

[0031] To gain a better understanding of the technical solution and beneficial effects of the present invention, the technical solution of the present invention and its beneficial effects are described in detail below.

[0032] The purpose of this invention is to overcome the shortcomings of existing Linux kernel auditing systems, such as complex parsing, poor scalability, and low efficiency, which use continuous buffer transmission of audit messages and text log processing. This invention provides a Linux kernel audit message transmission method and system based on structure and zero-copy mechanisms. By utilizing direct memory access of structured fields, it contrasts sharply with text log processing, thereby improving the efficiency and reliability of audit message transmission and processing.

[0033] The kernel audit message transmission method based on structure of the present invention includes the following steps S1-S5.

[0034] S1: Analyze the key audit information transmitted from the kernel audit subsystem to the user-space audit daemon in a Linux kernel audit scenario, and determine the core audit field set, including metadata headers, basic process information, scenario-specific information, and extended field areas. The kernel audit subsystem is the Linux kaudit module, and the user-space audit daemon is the Linux auditd process.

[0035] S2: Design an audit message structure based on structure syntax. The audit message structure adopts a hierarchical nested structure, and its member variables correspond one-to-one with the fields in the core audit field set. It also implements a version control mechanism for the structure, including:

[0036] The metadata header structure includes the magic number identifier, protocol version, event type, nanosecond-level timestamp, globally unique sequence number, and flag bits, which must be included in all audit events;

[0037] The basic process information structure includes process ID, parent process ID, actual user ID, effective user ID, actual group ID, process name, and session ID. Process-related events are required.

[0038] The contextualized information consortium includes three types of dedicated structures: system call information structure (containing system call number, CPU architecture, number of parameters and parameter values, etc.), file operation information structure (containing file permissions, inode number, device number, file path, operation type, etc.), and network event information structure (containing network event information such as source IP address, destination IP address, source port, destination port, protocol type, etc.). The corresponding dedicated structure type is activated according to the event type.

[0039] The extended field area structure uses the TLV (Type-Length-Value) encoding format and contains a type identifier, value length, and variable-length data, which is used to dynamically expand the audit field.

[0040] In this invention, the metadata header structure has a fixed length of 4+2+2+8+4+2=22 bytes; the basic process information structure uses the __attribute__((packed)) attribute to ensure a compact layout, and the process name field is fixed at 16 bytes to align with cache lines.

[0041] To improve the scalability of the system, this invention also adopts an audit message structure version control mechanism. By identifying the definition version of the audit message structure in the protocol version field of the metadata header structure, a new version of the audit message structure is generated when an audit field is added or modified, while maintaining backward compatibility with the old version of the audit message structure.

[0042] S3: When the kernel audit subsystem generates an audit event, it extracts the corresponding audit field information from the kernel data structure and fills it into the audit message structure.

[0043] During the filling process, the audit field information is validated. The validation includes verifying the correctness of the magic number identifier, the validity of the process ID, the length of the process name string, and the completeness of the subject and object information. If the validation fails, the corresponding audit message structure is marked as invalid and discarded to ensure the quality of transmitted data.

[0044] Subject-object information is the core data describing "who (subject) performed the operation on what (object)". Subject information refers to the "active party" that initiates the operation, which is usually related to processes or users, such as: process ID (PID), process name (comm), user identifier (uid / gid), valid user identifier (euid), process permission mask, etc.

[0045] Object information: refers to the "passive party" being manipulated, i.e., the target resource of the operation, which varies depending on the audit scenario, for example:

[0046] File operation scenarios: file path, inode number, device number, file permissions;

[0047] Network scenario: Source / destination IP address, port number, protocol type;

[0048] Process operation scenarios: PID of the process being operated on, process name, session ID.

[0049] The "completeness of subject and object information" check ensures that the core fields of the subject and object are not missing or empty. For example, in file operation auditing, it is necessary to check that "the file path is not empty and the inode number is valid", and in network auditing, it is necessary to check that "the source IP, the destination IP, and the port number all exist" to avoid audit events being untraceable due to the absence of key fields.

[0050] Step S4: The kernel audit subsystem transmits the filled audit message structure to the parser of the user-mode audit daemon through the kernel-user space communication mechanism and the zero-copy mechanism.

[0051] The kernel-user space communication mechanism is a socket communication mechanism, which uses a custom protocol type to encapsulate and transmit the audit message structure. The zero-copy mechanism uses memory mapping or direct I / O to directly transfer the audit message structure between kernel and user space, avoiding data copy overhead. The socket communication mechanism is Linux's Netlink socket communication mechanism, combined with Netlink's zero-copy extension interface to implement the transmission of the audit message structure.

[0052] Step S5: The parser of the user-mode audit daemon receives the audit message structure and directly accesses the member variables in the audit message structure to obtain audit field information for processing. This enables direct memory access to structured fields, eliminating the need for string parsing, splitting, and conversion as required by text logs, thus greatly improving processing efficiency.

[0053] In summary, this invention addresses the problems of complex parsing and poor scalability caused by the continuous buffer (byte stream) data transmission between the kernel audit subsystem (such as kaudit) and the user-space audit daemon (such as auditd) in existing Linux kernel audit systems. It extracts specific audit fields such as metadata headers, basic process information, and system call information into structures, and transmits these structures to the user-space parser using a zero-copy mechanism, achieving efficient message passing from the kernel audit subsystem to the external user-space audit daemon. This method, leveraging direct memory access to structured fields, significantly improves efficiency compared to text logs, simplifies the parsing process, enhances transmission efficiency and system scalability, and better meets the security auditing needs of Linux systems.

[0054] The specific examples of the metadata header structure, basic process information structure, contextual information union, and extended field area structure involved in this invention are as follows.

[0055] Metadata header structure: This is a required field for all audit events, using a fixed-length structure to implement data validity verification and basic attribute identification.

[0056] struct audit_metadata {

[0057] __u32 magic; / / 4 bytes, magic number 0xAUD1 (0x41554431), used for fast data integrity verification

[0058] __u16 version; / / 2 bytes, protocol version (e.g., 0x0102 indicates v1.2), supports cross-version compatibility.

[0059] __u16 type; / / 2 bytes, event type enumeration (AUDIT_SYSCALL=1300, AUDIT_FILE=1301, etc.)

[0060] __u64 timestamp; / / 8 bytes, nanosecond-level timestamp (high 32 bits for seconds + low 32 bits for nanoseconds, compatible with 64-bit systems)

[0061] __u32 seqnum; / / 4 bytes, globally unique sequence number (kernel atomic variable, auto-incrementing, to prevent replay and event loss)

[0062] __u16 flags; / / 2 bytes, flags (bit0 = AUDIT_FIELD_COMPRESSED indicates field compression)

[0063] } __attribute__((packed)).

[0064] Basic process information structure: A compactly laid-out process information structure is designed for process-related events (such as process creation and system call execution) to ensure cross-platform compatibility.

[0065] struct audit_process_fields {

[0066] __kernel_pid_t pid; / / 4 bytes, process ID (uses kernel-defined type to ensure cross-architecture compatibility)

[0067] __kernel_pid_t ppid; / / 4 bytes, parent process ID

[0068] uid_t uid; / / 4 bytes, actual user ID

[0069] uid_t euid; / / 4 bytes, valid user ID (used to differentiate between privilege escalation scenarios)

[0070] gid_t gid; / / 4 bytes, actual group ID

[0071] char comm[TASK_COMM_LEN]; / / 16 bytes, process name (TASK_COMM_LEN=16, aligned to a 64-byte cache line)

[0072] __u64 sessionid; / / 8 bytes, session ID (associated terminal / login session)

[0073] } __attribute__((packed)); / / Total length 4+4+4+4+4+16+8=44 bytes.

[0074] Contextualized Information Consortium: This consortium enables the on-demand transmission of contextualized fields, reducing invalid data transmission.

[0075] / / System call information structure (specifically for the SYSCALL event)

[0076] struct audit_syscall_fields {

[0077] __u32 syscall_nr; / / 4 bytes, system call number (e.g., __NR_openat=257)

[0078] __u16 arch; / / 2 bytes, CPU architecture (AUDIT_ARCH_X86_64=0xC000003E, etc.)

[0079] __u8 argc; / / 1 byte, the number of arguments (maximum 6 register arguments on x86_64 systems)

[0080] __u64 args[6]; / / 48 bytes, system call parameter values ​​(directly storing the original values ​​of the registers)

[0081] } __attribute__((packed));

[0082] / / File operation information structure (dedicated to FILE events)

[0083] struct audit_file_fields {

[0084] __u32 mode; / / 4 bytes, file permissions (e.g., 0644 represents -rw-r--r--)

[0085] __u64 inode; / / 8 bytes, the file inode number (uniquely identifies a file within the file system).

[0086] dev_t dev; / / 4 bytes, device number (high 12 bits major device number + low 20 bits minor device number)

[0087] char path

[256] ; / / 256 bytes, file path (truncated and flags set if too long)

[0088] __u8 operation; / / 1 byte, operation type (0=OPEN, 1=READ, 2=WRITE, 3=UNLINK, etc.)

[0089] } attribute((packed));

[0090] / / Network event information structure (for .NET events only)

[0091] struct audit_net_fields {

[0092] __be32 saddr [4]; / / 16 bytes, source IP address (IPv4 uses the first 4 bytes, IPv6 uses 16 bytes)

[0093] __be32 daddr [4]; / / 16 bytes, target IP address (stored in network byte order)

[0094] __be16 sport; / / 2 bytes, source port (network byte order)

[0095] __be16 dport; / / 2 bytes, target port (network byte order)

[0096] __u8 protocol; / / 1 byte, protocol type (6=TCP, 17=UDP, 1=ICMP, etc.)

[0097] } attribute((packed));

[0098] / / Contextualized Information Consortium

[0099] union audit_scene {

[0100] struct audit_syscall_fields syscall; / / System call scenarios (55 bytes)

[0101] struct audit_file_fields file; / / File operation scenarios (269 bytes)

[0102] struct audit_net_fields net; / / Network event scenarios (37 bytes)

[0103] };

[0104] Extending the field area structure, in process auditing and sensitive file access auditing in a container environment, is actually as follows:

[0105] 1. Process auditing in a container environment

[0106] In a Kubernetes environment, it is necessary to associate container IDs with process behavior, which is achieved through the following extended fields:

[0107] / / Add container ID extended field

[0108] struct audit_tlv container_ext = {

[0109] .type = 0x01,

[0110] .len = strlen(pod_uid),

[0111] .value = pod_uid / / e.g., "default / myapp-7f9d6c8b4-2xqzv"

[0112] };

[0113] During user-space resolution, the container ID can be directly associated with process behavior, enabling full-link auditing of "container-process-operation".

[0114] 2. Auditing of access to sensitive files

[0115] For sensitive files such as / etc / passwd, in addition to basic file information, the visitor's terminal information is recorded via TLV:

[0116] / / Add terminal information extended fields

[0117] struct audit_tlv tty_ext = {

[0118] .type = 0x02,

[0119] .len = strlen(ttyname),

[0120] .value = ttyname / / Such as " / dev / pts / 0"

[0121] };

[0122] When a sensitive file is detected to have been modified, all operations in the same session can be linked using seqnum to quickly locate the attack chain.

[0123] Integrating the aforementioned metadata header structure, basic process information structure, contextual information union, and extended field area structure, we obtain the complete audit message structure:

[0124] struct audit_msg {

[0125] struct audit_metadata meta; / / Metadata header (22 bytes)

[0126] struct audit_process_fields process; / / Basic process information (44 bytes)

[0127] union audit_scene scene; / / Contextual information (activated on demand)

[0128] struct audit_tlv extensions; / / Extends the field area (dynamic length)

[0129] __u32 ext_count; / / Number of extended fields (for iteration)

[0130] __u8 valid; / / Validity flag (1 = valid, 0 = invalid)

[0131] } __attribute__((packed)).

[0132] A specific embodiment of the present invention is as follows: Taking the transmission of file operation audit event messages between kaudit (kernel audit subsystem) and auditd (user-space audit daemon) in a Linux system as an example, the implementation process of the present invention is explained in detail, focusing on the application of the zero-copy mechanism and the differences between direct memory access of structured fields and text logs.

[0133] 1. Kernel-mode event capture and structure construction

[0134] Kernel auditing subsystems (such as kaudit) monitor critical system behavior by registering kernel hooks (kprobe) or using eBPF programs. By hooking kernel functions (such as sys_open and sys_write) through eBPF programs, they directly construct audit message structures in kernel space when audit events occur through the following steps.

[0135] Event type determination: Set the meta.type field according to the trigger point (e.g., sys_open corresponds to file events, sys_connect corresponds to network events);

[0136] Metadata population: The timestamp is obtained through kmet_get_ns(), and a global sequence number is generated through the atomic variable atomic_inc_return();

[0137] Basic information extraction: Extract basic process information such as process ID and user ID from the task_struct structure;

[0138] Scene data population: Activate the corresponding union member based on the event type (e.g., populate scene.file for file events);

[0139] Adding extended fields: For information that needs to be recorded additionally (such as container ID, SELinux context), add it to the extensions array via a TLV structure.

[0140] Taking the file open event triggered by the openat system call as an example, the kernel-mode filling process is as follows:

[0141] struct audit_msg fill_file_event(struct task_struct task, structfile file) {

[0142] struct audit_msg msg = {0};

[0143] / / Fill the metadata header

[0144] msg.meta.magic = 0xAUD1;

[0145] msg.meta.version = 0x0100; / / v1.0 version

[0146] msg.meta.type = AUDIT_FILE; / / File event type

[0147] msg.meta.timestamp = ktime_get_ns(); / / Get nanosecond-level timestamps

[0148] msg.meta.seqnum = atomic_inc_return(&global_seq_counter); / / Increment the global sequence number

[0149] msg.meta.flags = 0; / / No special flags

[0150] / / Fill in basic process information

[0151] msg.process.pid = task->pid;

[0152] msg.process.ppid = task->real_parent->pid;

[0153] msg.process.uid = task->cred->uid.val;

[0154] msg.process.euid = task->cred->euid.val;

[0155] msg.process.gid = task->cred->gid.val;

[0156] strncpy(msg.process.comm, task->comm, TASK_COMM_LEN-1);

[0157] msg.process.sessionid = task->sessionid; / / Get the session ID from the process descriptor

[0158] / / Fill in file operation information (contextualized data)

[0159] struct audit_file_fields file_info = &msg.scene.file;

[0160] file_info->mode = file->f_inode->i_mode;

[0161] file_info->inode = file->f_inode->i_ino;

[0162] file_info->dev = file->f_inode->i_rdev;

[0163] char path = d_path(&file->f_path, (char )__get_free_page(GFP_KERNEL), PAGE_SIZE);

[0164] if (path) {

[0165] strncpy(file_info->path, path, sizeof(file_info->path) - 1);

[0166] free_page((unsigned long)path);

[0167] }

[0168] file_info->operation = OP_FILE_OPEN;

[0169] / / Add extended fields (such as file hash)

[0170] struct audit_tlv hash_ext = kmalloc(sizeof(struct audit_tlv) +32, GFP_KERNEL);

[0171] hash_ext->type = 0x04; / / File hash type

[0172] hash_ext->len = 32;

[0173] compute_file_hash(file, hash_ext->value); / / Calculate the SHA256 hash

[0174] msg.extensions = hash_ext;

[0175] msg.ext_count = 1;

[0176] msg.valid = 1; / / Mark as valid message

[0177] return msg;

[0178] }

[0179] 2. The specific implementation of the zero-copy transmission mechanism adopts a hybrid transmission mode of "shared memory + Netlink control messages":

[0180] Shared memory creation: The kernel allocates a contiguous virtual address space through __get_vm_area(), with a size of sizeof(struct audit_msg) + the total length of the extended fields, and maps it to physical memory through vmalloc_to_page();

[0181] Access control: Set the memory page attribute to VM_USERMAP to allow user-mode processes to map the region using mmap();

[0182] Data writing: The kernel copies the complete audit_msg structure to shared memory (only one copy);

[0183] Notify user space: Send control messages via Netlink, including the shared memory address and structure length;

[0184] The specific code implementation is as follows:

[0185] / / Functions in the kernel that send structures using a zero-copy mechanism

[0186] int send_audit_msg_zero_copy(struct audit_msg msg) {

[0187] if (!msg || msg->valid != 1) {

[0188] return -1; / / Invalid messages will not be sent.

[0189] }

[0190] / / Calculate the total length (basic structure + extended fields)

[0191] size_t total_len = sizeof(struct audit_msg);

[0192] for (int i = 0; i < msg->ext_count; i++) {

[0193] total_len += sizeof(struct audit_tlv) +

[0194] msg->extensions[i].len;

[0195] }

[0196] / / Create a shared memory region (shared between kernel space and user space)

[0197] struct vm_struct vm_area = __get_vm_area(total_len, VM_ALLOC |VM_USERMAP, 0xffff0000, 0xffff1000);

[0198] if (!vm_area) {

[0199] return -2;

[0200] }

[0201] / / Map kernel virtual addresses to physical pages

[0202] void kernel_addr = vmalloc_to_page(vm_area->addr);

[0203] if (!kernel_addr) {

[0204] vfree(vm_area->addr);

[0205] return -3;

[0206] }

[0207] / / Copy structure data to shared memory

[0208] memcpy(vm_area->addr, msg, total_len);

[0209] / / Notify audiotd of the shared memory address and size (send control messages via Netlink)

[0210] struct sk_buff skb = nlmsg_new(sizeof(uint64_t) + sizeof(size_t), GFP_KERNEL);

[0211] struct nlmsghdr nlh = nlmsg_put(skb, 0, 0, NLMSG_DONE, sizeof(uint64_t) + sizeof(size_t), 0);

[0212] uint64_t shm_addr = (uint64_t )nlmsg_data(nlh);

[0213] size_t shm_size = (size_t (shm_addr + 1);

[0214] shm_addr = (uint64_t)vm_area->addr;

[0215] shm_size = total_len;

[0216] struct sock nl_sock = netlink_kernel_create(&init_net, NETLINK_AUDIT_STRUCT, 0, NULL, NULL, THIS_MODULE);

[0217] netlink_unicast(nl_sock, skb, auditd_pid, 0);

[0218] netlink_kernel_release(nl_sock);

[0219] return 0;

[0220] }

[0221] 3. User-space parsing and processing flow: After receiving control messages, the user space captures and transmits audit events in a structured manner through the auditd daemon or eBPF program.

[0222] In this step, the "control message" received by the user space is an auxiliary instruction message sent by the kernel to the user-space process (such as auditd), not the audit data itself. Its core function is to convey meta-information on "how to obtain audit data". Control messages are usually transmitted through lightweight communication channels (such as Netlink sockets) and are very small (only tens of bytes), with the purpose of letting the user-space process know "where to read the actual audit data".

[0223] The user space first "receives control messages" and then "accesses structure members." The specific steps are as follows:

[0224] In kernel mode, as described above: when an audit event occurs, the kernel first constructs a complete audit_msg structure (containing metadata, process information, scene data, etc.); the kernel writes the structure into a pre-allocated shared memory (a memory region accessible to both kernel and user mode); the kernel sends a control message via Netlink to inform the user-mode process of the "address and size of the shared memory".

[0225] In user space: auditd first receives control messages sent by the kernel and parses out the address and size of the shared memory. Following the guidance of the control messages, the user-space process maps the shared memory to its own address space using mmap(). After mapping, it directly accesses structure members (such as msg->process.pid) to obtain audit data.

[0226] After receiving control messages, the user space uses the auditd daemon to capture and transmit audit events in a structured manner, which is achieved through the following operations:

[0227] / / Functions in auditd that handle structures (direct memory access)

[0228] void handle_audit_struct(uint64_t shm_addr, size_t shm_size) {

[0229] / / Map shared memory to user space

[0230] struct audit_msg msg = (struct audit_msg )mmap(NULL, shm_size,PROT_READ, MAP_SHARED, -1, shm_addr);

[0231] if (msg == MAP_FAILED) {

[0232] return;

[0233] }

[0234] / / Validity check

[0235] if (msg->meta.magic != 0xAUD1 || msg->valid != 1) {

[0236] munmap(msg, shm_size);

[0237] return;

[0238] }

[0239] / / Extract core fields

[0240] printf("[%llu] FILE OPEN: pid=%d, comm=%s, path=%s, uid=%u\n",

[0241] msg->meta.timestamp,

[0242] msg->process.pid,

[0243] msg->process.comm,

[0244] msg->scene.file.path,

[0245] msg->process.uid);

[0246] / / Process extended fields (file hash)

[0247] if (msg->ext_count > 0) {

[0248] struct audit_tlv ext = msg->extensions;

[0249] for (int i = 0; i < msg->ext_count; i++) {

[0250] if (ext->type == 0x04) { / / File hash

[0251] printf("File SHA256: %. s\n", ext->len, ext->value);

[0252] }

[0253] / / Move to the next TLV structure (aligned to 4 bytes)

[0254] ext = (struct audit_tlv (char) )ext + sizeof(structaudit_tlv) + ext->len + (4 - (ext->len % 4)) % 4);

[0255] }

[0256] }

[0257] In comparison, existing technologies for parsing text logs use the following methods (pseudocode):

[0258] /

[0259] / / Example of text log format: "type=FILE msg=audit(1620000000.123:456) pid=1234 ppid=567 uid=1000 euid=0 comm=cat path= / etc / passwd inode=12345 mode=0644hash=abc123..."

[0260] char log_line = "type=FILE msg=audit(1620000000.123:456) pid=1234 ppid=567 uid=1000 euid=0 comm=cat path= / etc / passwd inode=12345 mode=0644hash=abc123...";

[0261] int pid = atoi(strstr(log_line, "pid=") + 4); / / String search and conversion

[0262] char comm = strtok(strstr(log_line, "comm=") + 5, " "); / / String splitting

[0263] / / ... Similar operations need to be repeated for other fields, which is tedious and time-consuming.

[0264] /

[0265] munmap(msg, shm_size);

[0266] }

[0267] The above implementation extends the kernel's native kaudit subsystem, addressing its inherent shortcomings and compensating for insufficient audit point coverage. Kaudit's static audit points may miss certain scenarios (such as private function calls of specific kernel modules). Dynamic hooking via kprobe / eBPF can supplement the monitoring of these behaviors "not covered by native audit points." In another specific embodiment of the invention, independent auditing is achieved entirely without kaudit dependency, based on the eBPF virtual machine. This involves writing eBPF programs to hook kernel tracepoints (such as syscalls / sys_enter_openat) or kprobe, directly capturing events and filling structures in kernel mode, and then transmitting the data to user mode via an eBPF circular buffer (map). The core principle is "dynamically injecting audit logic, independent of the kernel's native audit subsystem, and fully programmable."

[0268] The capture and structured transmission of kernel audit events are implemented using eBPF (Extended Berkeley Packet Filter). The specific process is as follows:

[0269] (1) eBPF program writing: By hooking kernel functions (such as sys_open, sys_write) through eBPF program, an audit message structure is directly constructed in kernel mode when an event occurs.

[0270] / / eBPF program fragment (kernel mode)

[0271] SEC("kprobe / sys_open")

[0272] int bpf_sys_open(struct pt_regs ctx) {

[0273] struct audit_msg msg = {};

[0274] msg.meta.magic = 0xAUD1;

[0275] msg.meta.version = 0x0100;

[0276] msg.meta.type = AUDIT_FILE;

[0277] msg.meta.timestamp = bpf_ktime_get_ns();

[0278] msg.process.pid = bpf_get_current_pid_tgid() >> 32;

[0279] bpf_get_current_comm(&msg.process.comm, sizeof(msg.process.comm));

[0280] msg.process.uid = bpf_get_current_uid_gid() >> 32;

[0281] msg.scene.file.operation = OP_FILE_OPEN;

[0282] / / ... Fill in other fields

[0283] msg.valid = 1;

[0284] / / Achieving zero-copy transfer via eBPF mapping (map)

[0285] bpf_map_update_elem(&audit_map, &msg.meta.seqnum, &msg, BPF_ANY);

[0286] return 0;

[0287] }

[0288] (2) User-mode loading and processing: User-mode programs load eBPF programs through the bpf system call and directly read structure data through shared mapping (map).

[0289] / / User-space program (eBPF loader)

[0290] int main() {

[0291] / / Load the eBPF application and create a shared mapping

[0292] struct bpf_object obj = bpf_object__open_file("audit_bpf.o",NULL);

[0293] bpf_object__load(obj);

[0294] struct bpf_map map = bpf_object__find_map_by_name(obj, "audit_map");

[0295] / / Polling to read structure data

[0296] struct audit_msg msg;

[0297] __u32 key = 0;

[0298] while (1) {

[0299] if (bpf_map_lookup_elem(bpf_map__fd(map), &key, &msg) == 0 &&msg.valid) {

[0300] / / Direct access to structure members (same as kaudit solution)

[0301] printf("eBPF Captured: PID=%d, File=%s\n", msg.process.pid,msg.scene.file.path);

[0302] }

[0303] usleep(1000);

[0304] }

[0305] return 0;

[0306] }

[0307] The advantage of this approach is that it does not require modification of the kernel source code and implements auditing functionality through the dynamic loading feature of eBPF, making it suitable for scenarios with low requirements for kernel intrusion.

[0308] 4. Security and compatibility design

[0309] Data integrity assurance: During user-space parsing, first check if meta.magic is 0xAUD1. Use ext_count and the len field of the TLV structure to ensure that the extended fields do not access out of bounds. Optionally, add a CRC32 check field at the end of the structure to detect data tampering during transmission.

[0310] Version compatibility strategy: The protocol version is identified by the meta.version field. The new version parser can recognize the old version structure and process it in a compatible manner. A version-field mapping table is maintained to record the fields added in each version, which facilitates dynamic adaptation of the parser.

[0311] Resource control mechanisms: The kernel reclaims shared memory after user-mode processing is completed using vfree(), supports compressed storage of path-length strings using the AUDIT_FIELD_COMPRESSED flag in the flags field, and controls the event sending rate using the token bucket algorithm to prevent the audit process from consuming too much CPU resources under high load.

[0312] The structured field direct memory access used in this invention has significant differences and advantages compared to traditional text log processing:

[0313] 1. Different access methods: Structured fields are accessed directly in memory through structure member variables. For example, to get the process ID, you only need to access msg->process.pid. Text logs, on the other hand, require splitting the string containing multiple fields first, and then converting the split string into the corresponding data type. For example, extracting "1234" from a string fragment like "pid=1234" and converting it into an integer.

[0314] 2. Efficiency difference: Direct memory access eliminates the need for string parsing, splitting, and type conversion, reducing CPU overhead and resulting in faster processing speed; text log parsing involves numerous string operations, which is time-consuming, especially when audit events occur frequently, making the efficiency difference more pronounced.

[0315] 3. Different accuracy: The member variables of structured fields have clear data types, which avoids type conversion errors that may occur during text log parsing, such as mistakenly converting strings to numbers, thus ensuring the accuracy of the data.

[0316] 4. Different scalability: When a new audit field needs to be added, the structured approach only requires adding the corresponding member variable to the structure or extending the field through TLV, and updating the filling and processing logic, which has little impact on the access method of existing fields; while text logs require modification of log format, parsing rules, etc., which involves a larger range of changes and poor scalability.

[0317] Compared with the prior art, the present invention has the following beneficial effects:

[0318] 1. Simplified parsing process: This invention extracts audit fields into structures. After receiving the data, the parser of the user-mode audit daemon can directly obtain the audit field information by accessing the structure member variables. There is no need to perform complex parsing of continuous byte streams, nor is it necessary to use flat byte streams like in text logs (such as "type=SYSCALL msg=audit(...) pid=123 ..."). This avoids string splitting and conversion, greatly simplifying the data processing process.

[0319] 2. Improved scalability: By constructing an extended field structure, when it is necessary to add or modify audit fields, only the definition of the structure needs to be modified or it can be implemented through TLV extended fields. The version control mechanism maintains backward compatibility without large-scale modifications to the entire transmission and parsing logic or the basic structure. Compared with text logs, which require modification of format and parsing rules, this invention improves the scalability and maintainability of the system and supports hot upgrades.

[0320] 3. Significantly improve transmission efficiency: Through a zero-copy mechanism (such as memory mapping), structure data can be directly transferred between the kernel space and the user space, resulting in low transmission time per transmission. This avoids the drawback of long transmission time caused by multiple data copying in traditional transmission methods. At the same time, direct access to structures reduces parsing time, which significantly improves the overall processing efficiency of the auditing system compared to string parsing of text logs.

[0321] 4. Ensure data accuracy: The member variables in the structure have clear type definitions, which avoids type conversion errors that may occur during text log parsing. At the same time, the validity check during the filling process also ensures the quality of transmitted data and improves the accuracy of audit information.

[0322] 5. Enhanced security: The globally unique sequence number in the metadata header structure prevents event replay, magic number verification and validity identifiers prevent the receipt of malformed data, and the binary storage mechanism based on structure message passing reduces the risk of string injection by comparing text messages. Compared with the text log processing method, which is susceptible to injection attacks (such as field values ​​containing spaces or equal signs), this invention is more secure.

[0323] This invention solves the efficiency bottleneck of traditional Linux kernel auditing systems in high-performance scenarios by combining structured design with zero-copy technology. At the same time, it meets complex auditing needs through a flexible extension mechanism and can be widely used in scenarios with strict security auditing requirements, such as server clusters and cloud-native environments.

[0324] Although the present invention has been described using the above preferred embodiments, it is not intended to limit the scope of protection of the present invention. Any changes and modifications made by those skilled in the art to the above embodiments without departing from the spirit and scope of the present invention shall still fall within the scope of protection of the present invention. Therefore, the scope of protection of the present invention shall be defined by the claims.

Claims

1. A kernel audit message transmission method based on structures, characterized in that, Includes the following steps: Step S1: Analyze the key audit information transmitted from the kernel audit subsystem to the user-mode audit daemon in the kernel audit scenario, and determine the core audit field set; Step S2: Design an audit message structure that corresponds one-to-one with the member variables and fields in the core audit field set; The audit message structure adopts a hierarchical nested structure design, including a metadata header structure, a basic process information structure, a contextual information union, and an extended field area structure; The metadata header structure includes a magic number identifier, protocol version, event type, nanosecond-level timestamp, globally unique sequence number, and flag bits; The basic process information structure includes process ID, parent process ID, actual user ID, effective user ID, actual group ID, process name, and session ID; The contextualized information complex includes three types of dedicated structures: system call information structure, file operation information structure, and network event information structure. The corresponding dedicated structure type is activated according to the event type. The extended field area structure contains a type identifier, value length, and variable-length data; The system call information structure includes the system call number, CPU architecture, number of parameters, and parameter values; The file operation information structure includes file permissions, inode number, device number, file path, and operation type; The network event information structure includes the source IP address, destination IP address, source port, destination port, and protocol type; The definition version of the audit message structure is identified by the protocol version field in the metadata header structure. When an audit field is added or modified, a new version of the audit message structure is generated, while maintaining backward compatibility with the old version of the audit message structure. Step S3: When the kernel audit subsystem generates an audit event, it extracts the corresponding audit field information from the kernel data structure and fills it into the audit message structure; When filling audit field information into the audit message structure, the audit field information is validated. The validation includes the correctness of the magic number identifier, the validity of the process ID, the length of the process name string, and the completeness of the subject and object information. If the validation fails, the corresponding audit message structure is marked as invalid and discarded. Step S4: The kernel audit subsystem transmits the filled audit message structure to the parser of the user-mode audit daemon through the kernel-user space communication mechanism and the zero-copy mechanism; Step S5: The parser of the user-mode audit daemon receives the audit message structure and directly accesses the member variables in the audit message structure to obtain audit field information, realizing direct memory access to structured fields; The kernel audit subsystem is the kaudit module of Linux, and the user-space audit daemon is the auditd process of Linux; The kernel-user space communication mechanism is a socket communication mechanism, which uses a custom protocol type to encapsulate and transmit the audit message structure; the zero-copy mechanism uses memory mapping or direct I / O to directly transfer the audit message structure between kernel space and user space, avoiding data copy overhead. The socket communication mechanism is the Linux Netlink socket communication mechanism, which combines Netlink's zero-copy extension interface to implement the transmission of audit message structures.

2. The kernel audit message transmission method based on a structure as described in claim 1, characterized in that, The metadata header structure is a fixed length of 22 bytes; The basic process information structure uses the __attribute__((packed)) attribute to ensure a compact layout, and the process name field is 16 bytes long.