Execution state determination method and device and electronic equipment

Abstract

The invention provides an execution state determination method and device and electronic equipment, and belongs to the technical field of computers. The method comprises the following steps: receiving a policy file which contains a service access control rule, loading the policy file into a kernel hook group, intercepting a service startup event through the kernel hook group, determining at least one target kernel hook from the kernel hook group according to the intercepted service startup event, executing the at least one target kernel hook, and executing the at least one target kernel hook. And determining the execution state of the service starting event according to the service access control rule. In this way, the strategy file is loaded to the kernel hook group to intercept the service starting event through the kernel hook group, so that the execution state of the service starting event is determined, and comprehensive, real-time, reliable and resource-efficient access control over the service starting behavior can be achieved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method, apparatus and electronic device for determining execution state. Background Technology

[0002] In the field of embedded systems, with the widespread application of critical business applications such as vehicle control, industrial automation, and IoT gateways, the security and reliability of the operating environment of embedded devices have become crucial. These devices typically run a Linux operating system and often only execute a small number of critical business processes. If these processes are attacked by malicious code or illegally elevated, it could not only lead to data leaks but also directly endanger physical security. Therefore, it is necessary to monitor and determine the execution status of software under the Linux system.

[0003] Currently, there are two main technical approaches for monitoring and determining the execution status of software in Linux systems. One approach is the user-space daemon solution, represented by Systemd, which defines services through service unit files and monitors the lifecycle status of processes. However, this approach runs in user space, making its monitoring capabilities susceptible to interference from the user-space environment. Furthermore, it requires frequent switching between kernel and user space during anomaly detection and recovery, introducing significant performance overhead and recovery latency. The other approach is a kernel module-based monitoring solution, which uses predefined security policies in kernel space to impose fine-grained constraints on access to resources such as processes, files, and networks. While this approach provides strong process isolation and access control, it focuses on generalized resource access control and does not deeply optimize for the specific execution chain of service startup. It lacks a full-path, lightweight, real-time interception mechanism for service startup events, resulting in an indirect, complete, and inaccurate determination of service execution status. [bK1] Summary of the Invention The purpose of this application is to provide a method, apparatus, and electronic device for determining execution status, which can solve the technical problems of poor real-time performance, incomplete coverage, susceptibility to user-mode interference, and high resource overhead in service monitoring, and achieve comprehensive, real-time, reliable, and resource-efficient access control over service startup behavior. The specific technical solution is as follows: In a first aspect of this application, an execution state determination method is provided, applied to the kernel state, the method comprising: Receive a policy file containing service access control rules; Load the policy file into the kernel hook group; The service startup event is intercepted through the kernel hook group; Based on the intercepted service startup event, at least one target kernel hook is identified from the kernel hook group; Execute the at least one target kernel hook and determine the execution status of the service startup event according to the service access control rules.

[0004] In an optional implementation, intercepting service startup events via the kernel hook group includes: The kernel hook group is used to determine whether the service startup event is a preset service startup event. When the service startup event is the preset service startup event, the service startup event is intercepted.

[0005] In an optional implementation, determining at least one target kernel hook from the kernel hook group based on the intercepted service startup event includes: Determine the event type of the service startup event; The kernel hook corresponding to the event type of the service startup event is determined from the kernel hook group and used as the target kernel hook.

[0006] In an optional implementation, the execution of the at least one target kernel hook, based on the service access control rules, to determine the execution status of the service startup event, includes: Process information is obtained through at least one target kernel hook; Obtain the service identifier from the process information; If the service identifier exists in the service access control rules, then the execution status of the service startup event is determined to be allowed to execute; If the service identifier does not exist in the service access control rule, then the execution status of the service startup event is determined to be not allowed.

[0007] In an optional implementation, the policy file contains file protection rules, and the method further includes: File operation events are intercepted through the kernel hook group; Based on the intercepted file operation events, at least one target file system hook is identified from the kernel hook group; Execute the at least one target file system hook and determine the execution status of the file operation event according to the file protection rules.

[0008] In an optional implementation, intercepting file operation events via the kernel hook group includes: The target file path corresponding to the file operation event is obtained through the kernel hook group; Determine whether the target file path exists in the preset protection list; If the target file path exists in the preset protection list, the file operation event is intercepted.

[0009] In an optional implementation, determining at least one target file system hook from the kernel hook group based on the intercepted file operation events includes: Determine the operation type of the file operation event; The kernel hook corresponding to the operation type of the file operation event is determined from the kernel hook group and used as the target file system hook.

[0010] In an optional implementation, determining the execution status of the file operation event based on the file protection rules includes: Obtain the executable file path corresponding to the file operation event; Determine whether the executable file path is in the allowed access list corresponding to the file protection rule; If the executable file path exists in the allowed access list corresponding to the file protection rule, then the execution status of the file operation event is determined to be allowed execution; If the executable file path does not exist in the allowed access list corresponding to the file protection rule, then the execution status of the file operation event is determined to be execution denied.

[0011] In a second aspect of this application, an execution state determination apparatus is also provided, applied in kernel mode, the apparatus comprising: The file receiving module is used to receive policy files, which contain service access control rules. The file loading module is used to load the policy file into the kernel hook group; The interception module is used to intercept service startup events through the kernel hook group; A kernel hook determination module is used to determine at least one target kernel hook from the kernel hook group based on the intercepted service startup event. The execution status determination module is used to execute the at least one target kernel hook and determine the execution status of the service startup event based on the service access control rules.

[0012] In an optional implementation, the interception module is specifically used for: The kernel hook group is used to determine whether the service startup event is a preset service startup event. When the service startup event is the preset service startup event, the service startup event is intercepted.

[0013] In an optional implementation, the kernel hook determination module is specifically used for: Determine the event type of the service startup event; The kernel hook corresponding to the event type of the service startup event is determined from the kernel hook group and used as the target kernel hook.

[0014] In an optional implementation, the execution state determination module is specifically used for: Process information is obtained through at least one target kernel hook; Obtain the service identifier from the process information; If the service identifier exists in the service access control rules, then the execution status of the service startup event is determined to be allowed to execute; If the service identifier does not exist in the service access control rule, then the execution status of the service startup event is determined to be not allowed.

[0015] In an optional implementation, the policy file contains file protection rules, and the apparatus further includes... The file interception module is used to intercept file operation events through the kernel hook group; A file system hook determination module is used to determine at least one target file system hook from the kernel hook group based on the intercepted file operation events. The file execution status determination module is used to execute the at least one target file system hook and determine the execution status of the file operation event according to the file protection rules.

[0016] In an optional implementation, the file interception module is specifically used for: The target file path corresponding to the file operation event is obtained through the kernel hook group; Determine whether the target file path exists in the preset protection list; If the target file path exists in the preset protection list, the file operation event is intercepted.

[0017] In an optional implementation, the file system hook determination module is specifically used for: Determine the operation type of the file operation event; The kernel hook corresponding to the operation type of the file operation event is determined from the kernel hook group and used as the target file system hook.

[0018] In an optional implementation, the file execution status determination module is specifically used for: Obtain the executable file path corresponding to the file operation event; Determine whether the executable file path is in the allowed access list corresponding to the file protection rule; If the executable file path exists in the allowed access list corresponding to the file protection rule, then the execution status of the file operation event is determined to be allowed execution; If the executable file path does not exist in the allowed access list corresponding to the file protection rule, then the execution status of the file operation event is determined to be execution denied.

[0019] In a third aspect of the embodiments of this application, an electronic device is also provided, including a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; Memory, used to store computer programs; When a processor executes a program stored in memory, it implements the execution state determination method described in any one of the first aspects above.

[0020] In a fourth aspect of the embodiments of this application, a storage medium is also provided, wherein the storage medium stores instructions that, when executed on a computer, cause the computer to perform any of the execution state determination methods described in the first aspect above.

[0021] In a fifth aspect of the embodiments of this application, a computer program product containing instructions is also provided, which, when run on a computer, causes the computer to execute any of the execution state determination methods described in the first aspect above.

[0022] The technical solution provided in this application embodiment receives a policy file containing service access control rules, loads the policy file into a kernel hook group, intercepts service startup events through the kernel hook group, determines at least one target kernel hook from the kernel hook group based on the intercepted service startup events, executes at least one target kernel hook, and determines the execution status of the service startup event according to the service access control rules. By loading the policy file into the kernel hook group in this way, and intercepting service startup events through the kernel hook group to determine the execution status of the service startup events, comprehensive, real-time, reliable, and resource-efficient access control over service startup behavior can be achieved. Attached Figure Description

[0023] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0024] 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, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0025] One or more embodiments are illustrated by way of example with reference numerals in the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements with the same reference numerals in the drawings are denoted as similar elements. Unless otherwise stated, the figures in the drawings are not to be limited by scale.

[0026] Figure 1 A schematic diagram illustrating the implementation process of an execution status determination method provided in this application embodiment; Figure 2 A schematic diagram illustrating the implementation flow of another execution state determination method provided in this application embodiment; Figure 3 A schematic diagram illustrating the implementation process of a target kernel hook determination method provided in this application embodiment; Figure 4 A schematic diagram illustrating an implementation process for determining the execution status of a service startup event, provided as an embodiment of this application; Figure 5 A schematic diagram illustrating an implementation process for determining the execution status of a file operation event, provided as an embodiment of this application; Figure 6 This is a schematic diagram of the structure of an execution state determination device provided in an embodiment of this application; Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0027] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0028] The following disclosure provides numerous different embodiments or examples for implementing various structures of this application. To simplify the disclosure, specific examples of components and arrangements are described below. These are merely examples and are not intended to limit the scope of this application. Furthermore, reference numerals and / or letters may be repeated in different examples. Such repetition is for simplification and clarity and does not in itself indicate a relationship between the various embodiments and / or arrangements discussed.

[0029] To address the technical problems of poor real-time performance, incomplete coverage, susceptibility to user-space interference, and high resource overhead in existing service monitoring technologies, this application provides a method, apparatus, and electronic device for determining execution status. The method involves receiving a policy file containing service access control rules, loading the policy file into a kernel hook group, intercepting service startup events through the kernel hook group, identifying at least one target kernel hook from the kernel hook group based on the intercepted service startup events, executing at least one target kernel hook, and determining the execution status of the service startup event according to the service access control rules. By loading the policy file into the kernel hook group and intercepting service startup events through the kernel hook group to determine the execution status of service startup events, comprehensive, real-time, reliable, and resource-efficient access control for service startup behavior can be achieved.

[0030] Figure 1 This is a schematic diagram illustrating the implementation flow of an execution state determination method provided in an embodiment of this application, applied to the kernel state, such as... Figure 1 As shown, the specific steps may include: S101, Receive policy file, which contains service access control rules.

[0031] In this embodiment, a policy file is received, which contains service access control rules. Kernel mode refers to the privileged mode in which the operating system kernel runs, possessing the highest access rights to hardware, memory, and system resources, and is unaffected by user-mode programs. The policy file is a serialized binary file generated by user-mode management tools. Service access control rules refer to a set of legal services used to characterize the names of allowed systemd service units (e.g., sshd.service, nginx.service).

[0032] Specifically, commands and data from the user-space `seaway-guard-ctl` can be monitored through Netlink sockets, a standard communication mechanism between the kernel and user space. When an administrator updates the configuration and executes the update command, `seaway-guard-ctl` sends the serialized policy file data via Netlink. The kernel module's Netlink processing function is responsible for receiving this raw data and caching it in kernel memory, preparing it for subsequent loading and parsing.

[0033] S102, load the policy file into the kernel hook group.

[0034] In this embodiment, the policy file is loaded into the kernel hook group, where the kernel hook group refers to a collection of security hook functions (hooks) registered based on the Linux security module framework, such as bprm_check_security, inode_create, etc. This embodiment does not limit the scope of the application.

[0035] Specifically, after receiving the policy file, the kernel module calls a specific parsing function to restore the binary data in the policy file into a kernel-readable policy structure. This policy structure can contain data structures such as a service whitelist hash table and a file protection path prefix tree. A pointer to this policy structure is then registered with the context of the LSM hook function it implements. For example, the service whitelist policy can be associated with the `bprm_check_security` hook. After loading is complete, these hook functions, when called, can access the latest policy rules to make decisions.

[0036] S103 intercepts service startup events through the kernel hook group.

[0037] In this embodiment, service startup events are intercepted through kernel hook groups. These service startup events refer to any action that executes a new executable program via system calls such as execve() or execveat().

[0038] S104, Based on the intercepted service startup event, determine at least one target kernel hook from the kernel hook group.

[0039] In this embodiment of the application, at least one target kernel hook is determined from the kernel hook group based on the intercepted service startup event. Here, a target kernel hook refers to a specific hook function that needs to be executed to handle the specific event currently being intercepted.

[0040] S105, execute at least one target kernel hook, and determine the execution status of the service startup event according to the service access control rules.

[0041] In this embodiment of the application, at least one target kernel hook is executed to determine the execution status of the service startup event based on the service access control rules, that is, to determine whether to run the service startup.

[0042] Based on the above description of the technical solution provided in the embodiments of this application, a policy file containing service access control rules is received. The policy file is loaded into a kernel hook group. Through the kernel hook group, service startup events are intercepted. Based on the intercepted service startup events, at least one target kernel hook is determined from the kernel hook group and executed. According to the service access control rules, the execution status of the service startup event is determined. By loading the policy file into the kernel hook group in this way, and intercepting service startup events through the kernel hook group to determine the execution status of the service startup events, comprehensive, real-time, reliable, and resource-efficient access control over service startup behavior can be achieved.

[0043] Figure 2 This is a schematic diagram illustrating the implementation flow of another execution state determination method provided in this application embodiment, applied to the kernel state, such as... Figure 2 As shown, it can specifically include the following: S201, Receive policy file, which contains service access control rules.

[0044] In this embodiment of the application, this step is similar to step S101 above, and will not be described in detail here.

[0045] In this embodiment of the application, there is no limitation on this.

[0046] S202, load the policy file into the kernel hook group.

[0047] In this embodiment of the application, this step is similar to step S102 above, and will not be described in detail here.

[0048] S203 uses kernel hook groups to determine whether the service startup event is a preset service startup event.

[0049] In this embodiment, a kernel hook group is used to determine whether a service startup event is a preset service startup event. A preset service startup event refers to a startup event initiated by a system initialization manager (such as systemd) for a system service unit, in order to enforce access control only on managed system services without affecting the execution of ordinary user processes or scripts.

[0050] Specifically, this can be achieved through registered LSM hook functions (such as bprm_check_security). When this hook is triggered, the kernel module determines the event by accessing the cgroup information of the current process. Systemd creates an independent cgroup for each service it manages, and its path usually includes the ".service" suffix. The kernel module obtains the cgroup path of the current process by calling interfaces such as task_cgroup(current, freezer_cgrp_id) and checks whether the path contains keywords such as "systemd" or ".service". If it does, the current event is determined to be a preset service startup event; otherwise, it is considered a normal process execution event and can be allowed to proceed.

[0051] S204, When the service startup event is the default service startup event, intercept the service startup event.

[0052] In this embodiment, when the service startup event is a preset service startup event, the service startup event is intercepted. Interception means pausing the default execution flow of the system call and instead executing the corresponding security policy check logic.

[0053] For example, when the service startup event is systemd attempting to start nginx.service, the bprm_check_security hook function, after determining that it is the default service startup event, will not immediately return success, but will instead intercept the event.

[0054] S205, Based on the intercepted service startup event, identify at least one target kernel hook from the kernel hook group.

[0055] In this embodiment of the application, at least one target kernel hook is determined from the kernel hook group based on the intercepted service startup event.

[0056] For details on how to identify at least one target kernel hook from the kernel hook group based on the intercepted service startup events, please refer to [reference needed]. Figure 3 The method shown. (As illustrated) Figure 3 The diagram shown illustrates the implementation flow of a target kernel hook determination method provided in this application embodiment, which may specifically include the following steps: S301, Determine the event type of the service startup event.

[0057] In this embodiment of the application, the event type of the service startup event is determined. The event type refers to an identifier used within the context of the Linux Kernel Security Framework (LSM) to classify an intercepted system operation for security purposes, characterizing the inherent security attributes of the operation and the applicable policy scope.

[0058] For example, core event types related to the service lifecycle include: "service execution events managed by systemd", "user-space normal process execution events", and "events sending termination signals to processes". Different event types will trigger different security check logic.

[0059] Specifically, the event type can be determined by analyzing the system call context that triggered the current LSM hook. When a hook function (such as bprm_check_security) is called, the kernel module checks the system call number (such as __NR_execve) and makes a comprehensive judgment by combining it with additional information about the current process (such as its control group cgroup path, parent process identifier, etc.).

[0060] For example, if the system call number is execve and the current process's cgroup path contains the ".service" suffix, then the event type is determined to be "service execution event managed by systemd". The kernel module can maintain an enumerated constant table to define all supported event types, ensuring the consistency and scalability of the judgment logic.

[0061] S302, determine the kernel hook from the kernel hook group that corresponds to the event type of the service startup event, and use it as the target kernel hook.

[0062] In this embodiment, the kernel hook corresponding to the event type of the service startup event is determined from the kernel hook group and used as the target kernel hook. The kernel hook group refers to the collection of security hook functions registered by this security module with the LSM framework, covering multiple dimensions such as process management and file system. The target kernel hook refers to a pre-designed hook function specifically designed to handle a specific event type.

[0063] Specifically, during kernel module initialization, a static or dynamic "event type-hook function" mapping table is established. This mapping table defines which kernel hook(s) should handle each event type. The mapping table can be implemented using a hash table or an array index structure. After the event type is determined in step S301, this mapping table is consulted to determine the kernel hook corresponding to the event type of the service startup event as the target hook.

[0064] For example, the event type "service execution event managed by systemd" is associated with the bprm_check_security hook in the mapping table. Therefore, bprm_check_security is identified as the target kernel hook for handling the current service startup event.

[0065] S206, execute at least one target kernel hook and determine the execution status of the service startup event according to the service access control rules.

[0066] In this embodiment of the application, at least one target kernel hook is executed to determine the execution status of the service startup event based on the service access control rules.

[0067] To determine how to execute at least one target kernel hook, the execution status of the service startup event is determined based on service access control rules. For details, please refer to... Figure 4 The method shown. (As illustrated) Figure 4 The diagram shown illustrates an implementation process for determining the execution status of a service startup event according to an embodiment of this application. Specifically, it may include the following steps: S401 obtains process information through at least one target kernel hook.

[0068] In this embodiment, process information is obtained through at least one target kernel hook. Here, process information refers to a set of data in the kernel that represents the process's identity, attributes, and current operating context.

[0069] Specifically, in the `bprm_check_security` hook function, `bprm->file` (a `struct file` structure pointing to the executable file) is obtained through its parameter `struct linux_binprm*bprm`. Then, the complete path of the executable file is resolved using kernel interfaces such as `d_path(&bprm->file->f_path, ...)`. Simultaneously, the `task_struct` structure of the current process is obtained through `current`, allowing access to its cgroups subsystem information.

[0070] S402, obtain the service identifier from the process information.

[0071] In this embodiment of the application, the service identifier can be obtained from the process information. The service identifier can be the name corresponding to the service.

[0072] Specifically, the service identifier can be obtained in the following ways: Extract from cgroup path: If the cgroup path format is / sys / fs / cgroup / system.slice / nginx.service, then extract nginx.service as the service identifier through string processing.

[0073] Parse from process command line or environment variables: Extract service identifiers by parsing process command line arguments or environment variables (such as SYSTEMD_UNIT) by accessing current->mm->arg_start and current->mm->env_start.

[0074] Read from executable file metadata: If the executable file contains extended attributes (xattr) such as security.service_id, then read them as service identifiers via vfs_getxattr().

[0075] For example, when systemd starts nginx.service, its cgroup path usually contains the service name, and the kernel module extracts nginx.service as the service identifier by parsing the cgroup path.

[0076] S403, if the service identifier exists in the service access control rule, then the execution status of the service startup event is determined to be allowed to execute.

[0077] In this embodiment of the application, if the service identifier exists in the service access control rules, the execution status of the service startup event is determined to be allowed to execute.

[0078] Specifically, service access control rules are stored as whitelists in a hash table or red-black tree maintained by the kernel module. This data structure is built during policy loading and supports lookups with O(1) or O(log n) time complexity. After obtaining the service identifier, it is matched against the entries in the service access control rules. If a match is found, 0 is returned (indicating permission), and the execve system call is allowed to continue execution.

[0079] S404 If the service identifier does not exist in the service access control rule, then the execution status of the service startup event is determined to be not allowed.

[0080] In this embodiment of the application, if the service identifier does not exist in the service access control rules, the execution status of the service startup event is determined to be not allowed to be executed.

[0081] Specifically, if the service identifier does not exist in the service access control rule, the error code -EACCES (permission denied) is returned, and the current execve system call is terminated.

[0082] S207, the policy file contains file protection rules, which intercept file operation events through kernel hook groups.

[0083] In this embodiment, the policy file contains file protection rules that intercept file operation events through a kernel hook group. The file protection rules define protected directory / file paths and a list of executable programs that are allowed to be modified. File operation events refer to kernel activities that attempt to change the state of the file system, such as creating a file via open(O_CREAT), deleting a file via unlink(), writing to a file via write(), or truncating a file via truncate().

[0084] Specifically, intercepting file operation events through kernel hook groups can include the following steps: Step 1: Obtain the target file path corresponding to the file operation event through the kernel hook group.

[0085] In this embodiment, the target file path corresponding to the file operation event is obtained through the kernel hook group. The target file path refers to the absolute path of the object (file or directory) directly affected by the file operation, represented as a string in the kernel space.

[0086] Specifically, when a registered file system LSM hook (such as path_unlink or inode_create) is triggered by a system call, the hook function receives one or more pointer parameters to the kernel path or dentry structure. By calling kernel functions such as d_path() or dentry_path_raw(), the internal structure is converted into a string that starts with " / " and ends with a null character, which is the target file path.

[0087] For example, when deleting / usr / bin / backdoor, the target file path obtained is " / usr / bin / backdoor".

[0088] Step 2: Determine if the target file path exists in the preset protection list.

[0089] In this embodiment, it is determined whether the target file path exists in a preset protection list. The preset protection list refers to the file protection rules in a policy file (such as read_only.json) issued by the user.

[0090] Step 3: If the target file path exists in the preset protection list, then intercept the file operation event.

[0091] In this embodiment of the application, if the target file path exists in the preset protection list, the file operation event is intercepted.

[0092] S208, based on the intercepted file operation events, determine at least one target file system hook from the kernel hook group.

[0093] In this embodiment, at least one target file system hook is determined from the kernel hook group based on the intercepted file operation events. The target file system hook is a subset of function carriers within the kernel hook group specifically designed for handling file system security events.

[0094] Specifically, determining at least one target file system hook from the kernel hook group based on intercepted file operation events may include the following steps: Step 1: Determine the operation type of the file operation event.

[0095] In this embodiment, the operation type of a file operation event is determined. The operation type refers to a refined classification of file operations based on underlying system calls and access patterns. Operation types include: file or directory creation (corresponding to inode_create or path_mkdir), file or link deletion (corresponding to path_unlink), directory deletion (corresponding to path_rmdir), file writing or truncation (corresponding to file_permission during write permission checks, or path_truncate), and file renaming (corresponding to path_unlink and inode_create, etc.).

[0096] Step 2: Determine the kernel hook from the kernel hook group that corresponds to the operation type of the file operation event, and use it as the target file system hook.

[0097] In this embodiment, a kernel hook corresponding to the operation type of a file operation event is determined from the kernel hook group and used as the target file system hook. The target file system hook is a series of hook functions used to execute specific security decision logic for the file operation event.

[0098] S209, execute at least one target file system hook and determine the execution status of file operation events according to file protection rules.

[0099] In this embodiment of the application, at least one target file system hook is executed, and the execution status of file operation events is determined according to file protection rules, that is, whether file operation events are allowed to be executed.

[0100] For details on how to determine the execution status of file operation events based on file protection rules, please refer to... Figure 5 The method shown. (As illustrated) Figure 5 The diagram shown illustrates an implementation process for determining the execution status of a file operation event according to an embodiment of this application. Specifically, it may include the following steps: S501, Get the executable file path corresponding to the file operation event.

[0101] In this embodiment, the executable file path corresponding to the file operation event is obtained. The executable file path refers to the absolute path (e.g., / bin / rm) of the executable program corresponding to the process that initiated the current file operation event in the file system.

[0102] Specifically, the `current` macro can be used to obtain the `ask_struct` structure of the current process, and then its `mm->exe_file` field can be accessed. Using the corresponding `dentry` and `vfsmount` structures, the `d_path()` function can be used to resolve the executable file path of the initiating process. This application does not limit this specific approach.

[0103] S502, determine whether the executable file path is in the allowed access list corresponding to the file protection rule.

[0104] In this embodiment, it is determined whether the executable file path is in the allowed access list corresponding to the file protection rule. The allowed access list is a whitelist configured by the file protection rule for each protected path, stored in the kernel (usually a hash table structure), and lists the programs authorized to modify that specific path.

[0105] S503 If the executable file path exists in the allowed access list corresponding to the file protection rule, then the execution status of the file operation event is determined to be allowed execution.

[0106] In this embodiment of the application, if the executable file path exists in the allowed access list corresponding to the file protection rule, the execution status of the file operation event is determined to be allowed execution.

[0107] S504 If the executable file path does not exist in the allowed access list corresponding to the file protection rule, then the execution status of the file operation event is determined to be execution denied.

[0108] In this embodiment of the application, if the executable file path does not exist in the allowed access list corresponding to the file protection rule, the execution status of the file operation event is determined to be execution denied.

[0109] In addition, after determining the execution status of the file operation event, an operation log can be generated. The operation log can contain information such as operation type, target file path, executable file path, process information, timestamp, and execution status.

[0110] Based on the above description of the technical solution provided in the embodiments of this application, a policy file containing service access control rules is received. The policy file is loaded into a kernel hook group. Through the kernel hook group, service startup events are intercepted. Based on the intercepted service startup events, at least one target kernel hook is determined from the kernel hook group and executed. According to the service access control rules, the execution status of the service startup event is determined. By loading the policy file into the kernel hook group in this way, and intercepting service startup events through the kernel hook group to determine the execution status of the service startup events, comprehensive, real-time, reliable, and resource-efficient access control over service startup behavior can be achieved.

[0111] Corresponding to the above method embodiments, this application also provides an execution state determination device, applied to the kernel state, such as... Figure 5 As shown, the device may include a file receiving module 601, a file loading module 602, an interception module 603, a kernel hook determination module 604, and an execution status determination module 605.

[0112] File receiving module 601 is used to receive policy files, which contain service access control rules. File loading module 602 is used to load policy files into the kernel hook group; Interception module 603 is used to intercept service startup events through kernel hook groups; Kernel hook determination module 604 is used to determine at least one target kernel hook from the kernel hook group based on the intercepted service startup event; The execution status determination module 605 is used to execute at least one target kernel hook and determine the execution status of the service startup event based on the service access control rules.

[0113] In an optional implementation, the interception module 603 is specifically used for: The kernel hook group is used to determine whether the service startup event is a preset service startup event. When the service startup event is the default service startup event, intercept the service startup event.

[0114] In an optional implementation, the kernel hook determination module 604 is specifically used for: Determine the event type for the service startup event; Identify the kernel hook from the kernel hook group that corresponds to the event type of the service startup event, and use it as the target kernel hook.

[0115] In an optional implementation, the execution status determination module 605 is specifically used for: Obtain process information through at least one target kernel hook; Obtain the service identifier from the process information; If the service identifier exists in the service access control rules, then the execution status of the service startup event is determined to be allowed to execute; If the service identifier does not exist in the service access control rules, the execution status of the service startup event is determined to be not allowed.

[0116] In one optional implementation, the policy file contains file protection rules, the apparatus, and also includes... The file interception module 606 is used to intercept file operation events through the kernel hook group; The file system hook determination module 607 is used to determine at least one target file system hook from the kernel hook group based on the intercepted file operation events. The file execution status determination module 608 is used to execute at least one target file system hook and determine the execution status of file operation events based on file protection rules.

[0117] In an optional implementation, the file interception module 606 is specifically used for: Obtain the target file path corresponding to the file operation event through the kernel hook group; Determine if the target file path exists in the preset protection list; If the target file path exists in the preset protection list, file operation events are intercepted.

[0118] In an optional implementation, the file system hook determination module 607 is specifically used for: Determine the operation type of the file operation event; Identify the kernel hook from the kernel hook group that corresponds to the operation type of the file operation event, and use it as the target file system hook.

[0119] In an optional implementation, the file execution status determination module 608 is specifically used for: Get the executable file path corresponding to the file operation event; Determine whether the executable file path is in the allowed access list corresponding to the file protection rule; If the executable file path exists in the allowed access list corresponding to the file protection rule, then the execution status of the file operation event is determined to be allowed execution; If the executable file path does not exist in the allowed access list corresponding to the file protection rule, then the execution status of the file operation event is determined to be execution denied.

[0120] This application also provides an electronic device, such as... Figure 7As shown, it includes a processor 701, a communication interface 702, a memory 703, and a communication bus 704, wherein the processor 701, the communication interface 702, and the memory 703 communicate with each other through the communication bus 704. Memory 703 is used to store computer programs; In one embodiment of this application, when the processor 701 executes a program stored in the memory 703, it performs the following steps: The system receives a policy file containing service access control rules, loads the policy file into the kernel hook group, intercepts service startup events through the kernel hook group, determines at least one target kernel hook from the kernel hook group based on the intercepted service startup events, executes at least one target kernel hook, and determines the execution status of the service startup events according to the service access control rules.

[0121] The communication bus mentioned in the above electronic devices can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not indicate that there is only one bus or one type of bus.

[0122] The communication interface is used for communication between the aforementioned electronic devices and other devices.

[0123] The memory may include random access memory (RAM) or non-volatile memory, such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.

[0124] The processors mentioned above can be general-purpose processors, including central processing units (CPUs), network processors (NPs), etc.; they can also be digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0125] In another embodiment provided in this application, a storage medium is also provided, which stores instructions that, when run on a computer, cause the computer to execute any of the execution state determination methods described in the above embodiments.

[0126] In another embodiment provided in this application, a computer program product containing instructions is also provided, which, when run on a computer, causes the computer to execute any of the execution state determination methods described in the above embodiments.

[0127] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a storage medium or transmitted from one storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid state disk (SSD)).

[0128] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0129] The various embodiments in this specification are described in a related manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0130] The above description is merely a specific embodiment of this application, enabling those skilled in the art to understand or implement this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features claimed herein. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application are included within the protection scope of this application.

Claims

1. A method of performing state determination, characterized by, Applied to a kernel state, the method comprises: receiving a policy file containing service access control rules; loading the policy file into a kernel hook group; intercepting a service start event through the kernel hook group; determining at least one target kernel hook from the kernel hook group according to the intercepted service start event; executing the at least one target kernel hook to determine an execution state of the service start event according to the service access control rules.

2. The method of claim 1, wherein, The intercepting a service start event through the kernel hook group comprises: determining whether the service start event is a preset service start event through the kernel hook group; intercepting the service start event when the service start event is the preset service start event.

3. The method of claim 1, wherein, The determining at least one target kernel hook from the kernel hook group according to the intercepted service start event comprises: determining an event type of the service start event; determining a kernel hook corresponding to the event type of the service start event from the kernel hook group as the target kernel hook.

4. The method of claim 1, wherein, The executing the at least one target kernel hook to determine an execution state of the service start event according to the service access control rules comprises: obtaining process information through the at least one target kernel hook; obtaining a service identifier from the process information; determining that the execution state of the service start event is allowed to execute if the service identifier exists in the service access control rules; determining that the execution state of the service start event is not allowed to execute if the service identifier does not exist in the service access control rules.

5. The method of claim 1, wherein, The policy file contains file protection rules, and the method further comprises: intercepting a file operation event through the kernel hook group; determining at least one target file system hook from the kernel hook group according to the intercepted file operation event; executing the at least one target file system hook to determine an execution state of the file operation event according to the file protection rules.

6. The method of claim 5, wherein, The intercepting a file operation event through the kernel hook group comprises: obtaining a target file path corresponding to the file operation event through the kernel hook group; determining whether the target file path exists in a preset protection list; intercepting the file operation event if the target file path exists in the preset protection list.

7. The method of claim 5, wherein, The determining at least one target file system hook from the kernel hook group according to the intercepted file operation event comprises: determining an operation type of the file operation event; determining a kernel hook corresponding to the operation type of the file operation event from the kernel hook group as the target file system hook.

8. The method of claim 5, wherein, The determining an execution state of the file operation event according to the file protection rules comprises: obtaining an executable file path corresponding to the file operation event; determining whether the executable file path is in an allowed access list corresponding to the file protection rules; If the executable file path exists in the allowed access list corresponding to the file protection rule, it is determined that the execution state of the file operation event is allowed execution; If the executable file path does not exist in the allowed access list corresponding to the file protection rule, it is determined that the execution state of the file operation event is denied execution.

9. An execution state determining apparatus characterized by comprising: Applied to the kernel state, the device comprises: A file receiving module for receiving a policy file, wherein the policy file contains a service access control rule; A file loading module for loading the policy file into a kernel hook group; An intercepting module for intercepting a service start event through the kernel hook group; A kernel hook determining module for determining at least one target kernel hook from the kernel hook group according to the intercepted service start event; An execution state determining module for executing the at least one target kernel hook and determining the execution state of the service start event according to the service access control rule.

10. An electronic device, comprising: The device comprises a processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory complete mutual communication through the communication bus; The memory is used for storing a computer program; The processor is used for executing the program stored on the memory to implement the method in any one of claims 1-8.

Images