Kernel layer-oriented file operation request discrimination method and device and storage medium

Abstract

The invention provides a kernel layer-oriented file operation request judgment method and device and a storage medium, and belongs to the technical field of data processing. The method is applied to a kernel layer and comprises the steps that when an application layer process initiates a target file operation request, the file operation request is intercepted, and a unique identity label of a system calling interface transmitted into the application layer process is obtained; obtaining pre-registered legal identity identification information, and comparing the unique identity identification with the legal identity identification information; and when the unique identity identifier belongs to the legal identity identifier information, judging that the target file operation request is a self-behavior, and performing release processing on the target file operation request. According to the method, the unique identity label is actively transmitted through the application layer process, and direct verification is carried out on the kernel layer, so that the key defects that the injection library behavior cannot be identified, bypassing is easy, and the performance loss is large in the prior art are overcome.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a method, device and storage medium for identifying file operation requests at the kernel layer. Background Technology

[0002] In the field of endpoint data loss prevention, to ensure that sensitive information is not illegally leaked, file filtering drivers are typically deployed at the operating system kernel level to monitor and control the file operation behavior of various applications in real time. However, a key issue exists in this process: the loss prevention software itself (including its main program and dynamic libraries injected into third-party processes) also generates necessary file operation behaviors during normal operation. If the kernel layer cannot accurately identify such "self-behavior," it can lead to false blocking, duplicate processing, or logic re-entry, thereby affecting the normal operation of the endpoint system.

[0003] Currently, common self-behavior identification methods in the industry mainly rely on process feature recognition. One method is matching based on process program names, which involves intercepting the process path initiating the file operation at the kernel level, extracting its filename, and comparing it with a pre-set list. The other method is verification based on process program file digests, which calculates the MD5 hash value (or similar hash value) of the executable file corresponding to the process and matches it with pre-stored feature values. Both methods attempt to determine whether the current file operation belongs to the anti-leakage software itself by identifying the process identity.

[0004] However, neither of these two methods can effectively deal with the "library injection" scenario. When the anti-leakage component is injected into a third-party application process in the form of a dynamic library, the file operations it initiates are manifested as the behavior of the host process at the kernel level. It cannot be distinguished by the process name, nor can it be accurately identified by the file digest of the host process, thus causing the self-behavior recognition mechanism to fail.

[0005] Therefore, there is an urgent need to propose a method that can universally identify self-file operation behavior at the kernel level in order to solve the technical problem of failure in injection library scenarios. Summary of the Invention

[0006] The purpose of this application is to provide a kernel-level file operation request discrimination method, device, and storage medium to solve the above-mentioned problems.

[0007] To achieve the above objectives, firstly, this application proposes a kernel-level file operation request discrimination method, which is applied at the kernel level and includes: When the application layer process initiates a target file operation request, the file operation request is intercepted, and the unique identifier of the system call interface passed by the application layer process is obtained; Obtain pre-registered legitimate identity information and compare the unique identity with the legitimate identity information; When the unique identifier belongs to the legitimate identifier information, the target file operation request is determined to be a self-initiated action, and the target file operation request is allowed.

[0008] In some implementations, before intercepting the file operation request and obtaining the unique identifier passed to the system call interface by the application layer process when the application layer process initiates the target file operation request, the following steps are included: The application layer process initiates a target file operation request and passes a unique identifier to the system call interface, which is the NtCreateFile system interface. The unique identifier is passed through the extended attribute parameters of the NtCreateFile system interface.

[0009] In some implementations, the extended attribute parameter is the EaBuffer parameter.

[0010] In some implementations, intercepting the file operation request when the application layer process initiates the target file operation request and obtaining the unique identifier of the system call interface passed by the application layer process includes: When an application layer process initiates a target file operation request, the target file operation request is intercepted by a file filter driver registered in the operating system kernel. In the callback routine of the file filtering driver, the extended attribute parameters are parsed from the data structure associated with the target file operation request, and the unique identifier of the system call interface passed by the application layer process is read.

[0011] In some implementations, after obtaining pre-registered legitimate identity information and comparing the unique identity with the legitimate identity information, the method further includes: If the unique identifier is empty, or the unique identifier does not belong to the legitimate identifier information, then the target file operation request is determined to be a non-self behavior, and the corresponding security policy is executed on the target file operation request.

[0012] In some implementations, the application layer process includes at least one of the following: The executable program process of the anti-leakage software itself; Dynamic link library modules injected into the process space of third-party applications by anti-leakage software; Other third-party processes.

[0013] In some implementations, both the unique identifier and the legitimate identifier information are in string format, and comparing the unique identifier with the legitimate identifier information includes: The unique identifier is compared with the legal identifier information using a case-sensitive string comparison.

[0014] In some implementations, prior to obtaining the pre-registered legitimate identity information, the following steps are included: When the file filter driver registered in the operating system kernel is initialized, the legal identity information is compiled as a predefined constant into the program code of the file filter driver.

[0015] Secondly, to achieve the above objectives, this application also proposes an electronic device, comprising: one or more processors; and a memory for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors execute the kernel-level file operation request discrimination method described above.

[0016] Thirdly, to achieve the above objectives, this application also proposes a computer storage medium storing executable instructions, which, when executed by a processor, cause the processor to perform the file operation request discrimination method for the kernel layer as described above.

[0017] Compared with the prior art, the beneficial effects of this application include: Firstly, this application identifies application-layer processes using unique identifiers. This ensures that regardless of whether the application-layer process is the executable process of the anti-leakage software itself or a dynamic link library module injected into the process space of a third-party application by the anti-leakage software, as long as the unique identifier it transmits is legitimate, the kernel layer can accurately identify its own behavior. This mechanism breaks away from the traditional reliance on process identity, achieving reliable identification of injected library behavior.

[0018] Secondly, this application only requires string comparison of the unique identifier, which has a much lower computational cost than traditional methods that require calculating MD5 (high resource consumption) or obtaining the process path and then extracting the filename for comparison. This allows this application to maintain extremely low performance loss when handling massive file operations, avoiding system lag and improving user experience.

[0019] Thirdly, this application transmits information by directly utilizing existing system call interfaces of the operating system (such as the EaBuffer parameter of NtCreateFile), without relying on complex process information query APIs (which may fail or return unstable values ​​in some scenarios), and without needing to maintain a large process feature library. This simplicity reduces the complexity of code implementation and maintenance. At the same time, due to its reliance on stable and widely supported system mechanisms (such as the Windows filter manager), this application has stronger compatibility and robustness in different system versions and environments. Attached Figure Description

[0020] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly described below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation on the scope of this application.

[0021] Figure 1 This is a flowchart illustrating a file operation request discrimination method for the kernel layer in one embodiment; Figure 2 This is a schematic diagram illustrating the technical principle of a file operation request discrimination method for the kernel layer in one embodiment. Figure 3 This is a detailed flowchart illustrating how, in one embodiment, when an application layer process initiates a target file operation request, the file operation request is intercepted, and the unique identifier of the system call interface passed by the application layer process is obtained. Figure 4 This is a schematic diagram of the electronic device involved in the file operation request discrimination method for the kernel layer in the embodiments of this application. Detailed Implementation

[0022] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0023] As mentioned earlier, current industry-standard self-behavior identification methods primarily rely on process feature recognition. One method is matching based on process program names, which involves intercepting the process path initiating the file operation at the kernel level, extracting its filename, and comparing it with a pre-set list. The other method is verification based on process program file digests, which calculates the MD5 hash value of the executable file corresponding to the process and matches it with pre-stored feature values. Both methods attempt to determine whether the current file operation belongs to the anti-leakage software itself by identifying the process identity.

[0024] However, the aforementioned existing technologies have significant drawbacks. Process name-based methods are highly vulnerable to malicious exploitation; by masquerading as legitimate process names, detection can be bypassed, creating security vulnerabilities. While file digest-based methods raise the bar for forgery, each authentication requires a complete hash calculation, resulting in significant performance overhead in high-frequency file operation scenarios, causing system lag and impacting user experience. More importantly, neither method effectively addresses "library injection" scenarios—when the anti-leakage component is injected into a third-party application process as a dynamic library, its file operations manifest as host process behavior at the kernel level. This cannot be distinguished by process name or accurately identified using the host process's file digest, rendering the self-behavior recognition mechanism ineffective.

[0025] Therefore, there is an urgent need to propose a method that can universally identify self-operated file behavior at the kernel level to solve the technical problem of identification failure in injection library scenarios. To this end, this application proposes a kernel-level file operation request discrimination method, device, and storage medium. By actively transmitting a unique identifier through the application layer process and performing direct verification at the kernel level, it solves the key defects of existing technologies, such as inability to identify injection library behavior, susceptibility to bypass, and significant performance overhead.

[0026] like Figure 1 and Figure 2 As shown in the figure, this application provides a file operation request discrimination method for the kernel layer. The method is applied to the kernel layer and includes the following steps: Step S10: When the application layer process initiates a target file operation request, the file operation request is intercepted, and the unique identifier of the system call interface passed by the application layer process is obtained.

[0027] In this embodiment, the application layer process refers to a program instance running in the user mode of the operating system, including at least one of the executable program process (main program) of the anti-leakage software itself, the dynamic link library module (injection library) injected by the anti-leakage software into the process space of a third-party application, and other third-party processes.

[0028] Target file operation requests refer to file operations that need to be monitored and judged by the kernel layer, such as requests to create or open files. System call interfaces refer to the call interfaces used by application-layer processes when switching from user mode to kernel mode to request kernel services; specifically, these can be the lowest-level interfaces in the Windows NT kernel, namely the NtCreateFile system interface.

[0029] A unique identifier is a predefined identity credential used to uniquely identify the self-behavior of a leak prevention software. It can be a string form of a globally unique identifier (GUID).

[0030] In some implementations, the unique identifier may further include an identity field and a behavior context field. The identity field may include a component ID (used to distinguish different processes and injection libraries), and the behavior context field may include the security operation types supported by that component ID, such as read, write, and delete. It is understood that processes or injection libraries with different security levels may have different operation permissions, corresponding to different security operation types. For example, some processes may only allow read operations and not write operations to certain specific paths.

[0031] Understandably, before step S10, the application layer process initiates a target file operation request and passes a unique identifier to the system call interface, which is the NtCreateFile system interface. The unique identifier is passed through the extended attribute parameter of the NtCreateFile system interface, namely the EaBuffer parameter. EaBuffer is a parameter passing mechanism natively supported by the operating system kernel. Its content, after being passed from user space, can be directly accessed in kernel space without complex inter-process communication or memory mapping, and the channel itself is stable and reliable.

[0032] For example, NTSYSCALLAPI NTSTATUS NtCreateFile( [out]PHANDLEFileHandle, [in]ACCESS_MASKDesiredAccess, [in]POBJECT_ATTRIBUTES ObjectAttributes, [out]PIO_STATUS_BLOCKIoStatusBlock, [in, optional] PLARGE_INTEGERAllocationSize, [in]ULONGFileAttributes, [in]ULONGShareAccess, [in]ULONGCreateDisposition, [in]ULONGCreateOptions, [in, optional] PVOIDEaBuffer, [in]ULONGEaLength ) In some implementations, such as Figure 3 As shown, step S10 includes: Step S11: When the application layer process initiates a target file operation request, the target file operation request is intercepted by a file filter driver registered in the operating system kernel.

[0033] In this embodiment, the file filter driver refers to a special type of kernel-mode driver that registers itself with the operating system's file system filter manager (such as Windows' Filter Manager) and inserts itself into the processing stack of target file operation requests. It does not manage specific hardware or file systems, but rather transparently monitors, modifies, or blocks target file operation requests passing through the stack.

[0034] In some implementations, a kernel-mode driver (.sys file) is written by the developer, whose entry point (DriverEntry) contains the registration logic. In the entry function, FltRegisterFilter is called, passing in an FLT_REGISTRATION structure. This structure defines the types of operations the file filter driver can intercept (specified in the OperationRegistration field, specifically IRP_MJ_CREATE, i.e., file creation / open) and the corresponding pre-operation callback function pointers. After successful registration, the filter manager inserts the file filter driver into the appropriate position on the file system driver stack. From then on, all IRP_MJ_CREATE requests destined for that volume will first be dispatched by the filter manager to the file filter driver's pre-operation callback function before reaching the file system driver (such as NTFS.sys).

[0035] Step S12: In the callback routine of the file filter driver, the extended attribute parameters are parsed from the data structure associated with the target file operation request, and the unique identifier of the system call interface passed by the application layer process is read.

[0036] In this embodiment, a callback routine refers to a function automatically invoked by the file filter driver when a target file operation request occurs. For example, for an IRP_MJ_CREATE request, this is a pre-operation callback, meaning it is invoked before the request is actually executed.

[0037] In this embodiment, the data structure associated with the target file operation request specifically refers to the FLT_CALLBACK_DATA structure passed as a parameter to the callback routine. It is a wrapper and enhancement of the original target file operation request (such as an IRP) by the filter manager, containing all the context information of this operation and serving as the core data interface driving the request processing. From the complex information contained in FLT_CALLBACK_DATA, the extended attribute parameters (such as the EaBuffer parameter) and their length information passed by the application layer process when calling NtCreateFile can be located and extracted.

[0038] In some implementations, when a target file operation request occurs, the system calls a callback function registered by the driver, such as `PreOperationCallback`. The callback function receives two key parameters: `PCFLT_RELATED_OBJECTS` (the associated kernel object) and `PFLT_CALLBACK_DATA Data` (the request data). The parameter block (IO_PARAMETER_BLOCK) for this target file operation request is obtained via `Data->Iopb`. Taking the `IRP_MJ_CREATE` request as an example, the parameter block contains a `Create` substructure. The memory address of the `EaBuffer` parameter is obtained from `Data->Iopb->Parameters.Create.EaBuffer` (within the address space of the requesting process). The length of the `EaBuffer` parameter is obtained from `Data->Iopb->Parameters.Create.EaLength`. Since the `EaBuffer` address resides in the user-space process space, the kernel driver cannot directly dereference it. A safe kernel function (such as `ProbeForRead` for probing, followed by `RtlCopyMemory`) can be used to copy the specified length of data to a non-paged pool buffer controlled by the kernel driver. The "unique identifier" is parsed from the copied buffer according to a predefined format (e.g., a NULL-terminated GUID string).

[0039] For example, notepad.exe, injected with DLPHook.dll, calls NtCreateFile and passes a string, such as "{550e8400-e29b-41d4-a716-446655440000}", into EaBuffer. The kernel driver DLPFilter.sys's PreCreateCallback is invoked. The EaBuffer address (e.g., 0x007ff1234567) and length (38 bytes) are found in Data->Iopb->Parameters.Create. The driver confirms the user address is readable using ProbeForRead, then allocates a kernel buffer and calls RtlCopyMemory to copy the 38 bytes of data. The driver verifies that the buffer content is a valid GUID string terminated with \0 and temporarily stores it as a "unique identifier" for this request, to be used in the next comparison. If the copy fails or the content is invalid, the identifier is set to null.

[0040] Step S20: Obtain the pre-registered legal identity information and compare the unique identity with the legal identity information.

[0041] In this embodiment, the legitimate identity information refers to the baseline identity information stored in the kernel layer for comparison. This includes the executable program process (main program) of the anti-leakage software itself, and the unique identity information declared by the dynamic link library module (injection library) injected by the anti-leakage software into the process space of a third-party application. This legitimate identity information can be compiled into the file filter driver's program code as a predefined constant during initialization, registered in the operating system kernel.

[0042] It is understandable that when both the unique identifier and the legitimate identifier information are in string format, the unique identifier and the legitimate identifier information can be compared using a case-sensitive string comparison.

[0043] In some implementations, step S20 is followed by: Step S40: If the unique identifier is empty, or the unique identifier does not belong to the legitimate identifier information, then the target file operation request is determined to be a non-self behavior, and the corresponding security policy is executed on the target file operation request.

[0044] In this embodiment, an empty unique identifier means that the kernel driver fails to obtain any valid identifier data when attempting to extract the unique identifier from the target file operation request. Empty identifiers include both physically empty and logically empty. Physically empty means that when the application layer process calls the NtCreateFile system interface, the EaBuffer parameter is passed as NULL or EaLength is 0. Logically empty means that although the unique identifier is passed to the buffer, the kernel driver, during parsing, cannot obtain a meaningful identifier string for comparison due to format mismatch, read failure (such as access violation), or content being all zeros.

[0045] Non-self-behavior, as opposed to self-behavior, refers to all target file operation requests that fail identity verification. Initiators include: completely unrelated third-party applications, malware attempting to impersonate but failing, and components of the anti-leakage software itself that have crashed or are behaving abnormally (failing to properly transmit the identifier).

[0046] A security policy refers to a set of predefined rules or actions that specify how to handle target file operation requests deemed "non-self-behavior". These can include blocking actions, redirection actions, and marking actions. A blocking action might set Data->IoStatus.Status to an error status code, such as STATUS_ACCESS_DENIED (access denied). A redirection action might modify the target file name (Data->Iopb->TargetFileObject->FileName), redirecting it to a safer location. A marking action might initially allow the target file operation request but mark it in the context so that subsequent read / write operations on the target file can be dynamically encrypted / decrypted or scanned for viruses in later operation callbacks.

[0047] Step S30: When the unique identifier belongs to the legitimate identifier information, determine that the target file operation request is a self-action and allow the target file operation request.

[0048] In this embodiment, "self-behavior" refers to file operation behavior initiated by the anti-leakage software's own components (the anti-leakage software's own executable program process and the dynamic link library modules injected by the anti-leakage software into the process space of third-party applications) to support its normal function and which has passed the aforementioned identity authentication. "Allowing the process" means that the kernel filter driver instructs the system to continue processing the target file operation request normally.

[0049] In some implementations, when the unique identifier belongs to legitimate identity information, two-way verification can be performed on the application layer. After the two-way verification is successful, the target file operation request is determined to be a self-initiated behavior, and the target file operation request is allowed.

[0050] Specifically, when the unique identifier belongs to legitimate identity information, a verification instruction (such as a random number) is sent to the application layer process, requiring the application layer process to sign it using a preset key and return it. The system receives the signature response sent by the application layer process through a pre-registered verification interface. The signature response is verified to confirm that the application layer process is a legitimate component of executable code, rather than a malicious program that has stolen the unique identifier, which significantly improves the security confidence of the system against complex attacks.

[0051] It should be noted that in the scenario of injection libraries, when the kernel layer sends a verification instruction to the application layer process, the receiver is the injected third-party application process, which cannot provide a correct signature response. Therefore, this application proposes a feasible implementation method for establishing a bidirectional verification channel between the kernel and the injection library injected into the third-party process. During initialization, the injection library registers a dedicated system call number or IOCTL code with the kernel. This registration process itself requires authentication (e.g., using the injection library's code segment characteristics). When the kernel needs to verify, it intentionally causes the current file operation request to fail, returning a special error code (such as STATUS_NEEDS_VERIFICATION).

[0052] In the kernel-level file operation request discrimination method proposed in this application embodiment, firstly, application-layer processes are discriminated using unique identifiers. This ensures that regardless of whether the application-layer process is the executable process of the anti-leakage software itself or a dynamic link library module injected into the process space of a third-party application by the anti-leakage software, as long as the unique identifier it transmits is legitimate, the kernel layer can accurately identify its own behavior. This mechanism breaks the traditional method's dependence on process identity, achieving reliable identification of injected library behavior.

[0053] Secondly, this application only requires string comparison of the unique identifier, which has a much lower computational cost than traditional methods that require calculating MD5 (high resource consumption) or obtaining the process path and then extracting the filename for comparison. This allows this application to maintain extremely low performance loss when handling massive file operations, avoiding system lag and improving user experience.

[0054] Thirdly, this application transmits information by directly utilizing existing system call interfaces of the operating system (such as the EaBuffer parameter of NtCreateFile), without relying on complex process information query APIs (which may fail or return unstable values ​​in some scenarios), and without needing to maintain a large process feature library. This simplicity reduces the complexity of code implementation and maintenance. At the same time, due to its reliance on stable and widely supported system mechanisms (such as the Windows filter manager), this application has stronger compatibility and robustness in different system versions and environments.

[0055] In one embodiment, a computer storage medium is provided that stores executable instructions that, when executed by a processor, cause the processor to perform the steps in the above method embodiments.

[0056] In one embodiment, an electronic device is also provided, including one or more processors; and a memory storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors perform the steps in the above method embodiments.

[0057] In one embodiment, such as Figure 4 The diagram illustrates the structure of an electronic device used to implement an embodiment of this application. The electronic device includes a central processing unit (CPU) 101, which can perform various appropriate actions and processes based on a program stored in a read-only memory (ROM) 102 or a program loaded from a storage portion 108 into a random access memory (RAM) 103. The RAM 103 also stores various programs and data required for the operation of the electronic device 100. The CPU 101, ROM 102, and RAM 103 are interconnected via a bus 104. An input / output (I / O) interface 105 is also connected to the bus 104.

[0058] The following components are connected to I / O interface 105: an input section 106 including a keyboard, mouse, etc.; an output section 107 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 108 including a hard disk, etc.; and a communication section 109 including a network interface card such as a LAN card, modem, etc. The communication section 109 performs communication processing via a network such as the Internet. A drive 110 is also connected to I / O interface 105 as needed. A removable medium 111, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on drive 110 as needed so that computer programs read from it can be installed into storage section 108 as needed.

[0059] Specifically, according to embodiments of this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this application include a computer program product comprising a computer-readable medium carrying instructions that, in such embodiments, can be downloaded and installed from a network via communication section 109, and / or installed from removable medium 111. When the instructions are executed by central processing unit (CPU) 101, the various method steps described in this application are performed.

[0060] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

[0061] All terms used in this application (including technical and scientific terms) have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein should be interpreted in a manner consistent with the context of this specification, and not in an idealized or overly rigid way.

[0062] For example, the terms "first," "second," etc., used in this application may be used herein to describe various elements, but these elements are not limited by these terms. These terms are only used to distinguish the first element from another element. For instance, without departing from the scope of this application, the first element may be referred to as the second element, and similarly, the second element may be referred to as the first element. Both the first element and the second element are elements, but they are not the same element.

[0063] For example, the terms "comprising" or "including" used in this application indicate the presence of features, steps, operations and / or components, but do not exclude the presence or addition of one or more other features, steps, operations or components.

[0064] Furthermore, those skilled in the art will understand that although some embodiments herein include certain features included in other embodiments but not others, combinations of features from different embodiments are intended to be within the scope of this application and form different embodiments. For example, any of the embodiments or implementations claimed above can be used in any combination. The information disclosed in this background section is intended only to enhance the understanding of the general background of this application and should not be construed as an admission or in any way implying that such information constitutes prior art known to those skilled in the art.

Claims

1. A method for determining file operation requests at the kernel layer, characterized in that, The method described is applied to the kernel layer and includes: When the application layer process initiates a target file operation request, the file operation request is intercepted, and the unique identifier of the system call interface passed by the application layer process is obtained; Obtain pre-registered legitimate identity information and compare the unique identity with the legitimate identity information; When the unique identifier belongs to the legitimate identifier information, the target file operation request is determined to be a self-initiated action, and the target file operation request is allowed.

2. The file operation request discrimination method for the kernel layer according to claim 1, characterized in that, Before intercepting the file operation request and obtaining the unique identifier of the system call interface passed by the application layer process when the application layer process initiates the target file operation request, the process includes: The application layer process initiates a target file operation request and passes a unique identifier to the system call interface, which is the NtCreateFile system interface. The unique identifier is passed through the extended attribute parameters of the NtCreateFile system interface.

3. The file operation request discrimination method for the kernel layer according to claim 2, characterized in that, The extended attribute parameter is the EaBuffer parameter.

4. The file operation request discrimination method for the kernel layer according to claim 2, characterized in that, When the application layer process initiates a target file operation request, the process intercepts the file operation request and obtains the unique identifier of the system call interface passed by the application layer process, including: When an application layer process initiates a target file operation request, the target file operation request is intercepted by a file filter driver registered in the operating system kernel. In the callback routine of the file filtering driver, the extended attribute parameters are parsed from the data structure associated with the target file operation request, and the unique identifier of the system call interface passed by the application layer process is read.

5. The file operation request discrimination method for the kernel layer according to claim 1, characterized in that, After obtaining the pre-registered legitimate identity information and comparing the unique identity with the legitimate identity information, the process further includes: If the unique identifier is empty, or the unique identifier does not belong to the legitimate identifier information, then the target file operation request is determined to be a non-self behavior, and the corresponding security policy is executed on the target file operation request.

6. The file operation request discrimination method for the kernel layer according to claim 1, characterized in that, The application layer process includes at least one of the following: The executable program process of the anti-leakage software itself; Dynamic link library modules injected into the process space of third-party applications by anti-leakage software; Other third-party processes.

7. The file operation request discrimination method for the kernel layer according to claim 1, characterized in that, Both the unique identifier and the legitimate identifier information are in string format. The comparison of the unique identifier and the legitimate identifier information includes: The unique identifier is compared with the legal identifier information using a case-sensitive string comparison.

8. The file operation request discrimination method for the kernel layer according to claim 1, characterized in that, Before obtaining the pre-registered legitimate identity information, the process includes: When the file filter driver registered in the operating system kernel is initialized, the legal identity information is compiled as a predefined constant into the program code of the file filter driver.

9. An electronic device, characterized in that, include: One or more processors; Memory, used to store one or more programs. When the one or more programs are executed by the one or more processors, the one or more processors are caused to execute the kernel-level file operation request discrimination method as described in any one of claims 1 to 8.

10. A computer storage medium, characterized in that, The storage medium stores executable instructions, which, when executed by a processor, cause the processor to perform the file operation request discrimination method oriented towards the kernel layer as described in any one of claims 1 to 8.

Images