File protection method, device, system and equipment, storage medium and program product

Abstract

The embodiment of the invention provides a file protection method, device and system, equipment, a storage medium and a program product, and relates to the technical field of computing security. The file protection method comprises the following steps: in response to an access request of a user process to a file in a kernel space, loading a file access strategy based on an extended Berkley data packet filter eBPF, performing security check on the access request based on the file access strategy, and releasing or intercepting the access request according to a security check result; wherein the file access strategy is that the security service module of the user space receives the file access strategy from the server side and sends the file access strategy to the file security module, and the file security module stores the file access strategy in the kernel space in advance based on the eBPF. The technical scheme provided by the embodiment of the invention is relatively high in universality and security for various kernel versions.

Description

Technical Field

[0001] This application relates to the field of computer security technology, and in particular to a file protection method, apparatus, system, device, storage medium, and program product, which can be applied to the field of cloud security technology. Background Technology

[0002] Currently, there are numerous kernel versions for Linux (an operating system), with many new kernel versions being released daily. Traditional file protection solutions are kernel-level, and with so many fragmented kernel versions, these solutions require adaptation to different kernel versions, resulting in poor universality and making adaptation extremely labor-intensive and difficult to implement. Furthermore, simultaneously operating on the user kernel is a very high-risk operation; improper operation could directly lead to system crashes, causing significant losses to users. Summary of the Invention

[0003] This application provides a file protection method, apparatus, cloud security system, device, storage medium, and program product to alleviate or solve one or more technical problems existing in the prior art.

[0004] In a first aspect, embodiments of this application provide a file protection method applied to a file security module of a client. The client's operating system includes user space and kernel space, and the file security module is deployed in the kernel space. The method includes: responding to a user process's access request to a file in the kernel space, loading a file access policy based on an extended Berkeley Packet Filter (eBPF), performing a security check on the access request based on the file access policy, and allowing or blocking the access request based on the result of the security check; wherein the file access policy is received from the server by the user space security service module and sent to the file security module, and is pre-stored in the kernel space by the file security module based on eBPF.

[0005] Secondly, embodiments of this application provide a file protection device applied to a client. The client's operating system includes user space and kernel space. The device includes: a security service module deployed in user space, used to receive file access policies sent by the server and send the file access policies to a file security module in the kernel space; and a file security module deployed in kernel space, used to respond to user process access requests to files in kernel space, load the file access policies based on eBPF, perform security checks on the access requests based on the file access policies, and allow or block the access requests based on the results of the security checks.

[0006] Thirdly, this application provides a cloud security system, including: a console, configured to configure a corresponding file access policy in response to received policy configuration conditions, and send the configured file access policy to a server; a server, communicatively connected to the console, configured to receive the file access policy sent by the console and send the file access policy to a client; and a client, communicatively connected to the server, configured to execute the method provided in the first aspect of the embodiments of this application.

[0007] Fourthly, embodiments of this application provide an electronic device that serves as a client or server. The device includes a memory, a processor, and a computer program stored in the memory. When the processor executes the computer program, it implements the method provided in the first aspect of embodiments of this application.

[0008] Fifthly, embodiments of this application provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the method provided in the first aspect of embodiments of this application.

[0009] In a sixth aspect, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the method provided in the first aspect of embodiments of this application.

[0010] According to the technical solution provided in this application, file protection / anti-tampering can be achieved by storing and loading file access policies based on eBPF. eBPF does not require loading the kernel driver layer, therefore it does not need to be adapted to different kernel versions and can be directly applied to various kernel versions, exhibiting strong versatility. Furthermore, because eBPF does not involve operations on the kernel driver layer, its security is also strong, preventing user operating system crashes due to functional vulnerabilities in the cloud security system itself. In addition, file access policies can be dynamically configured, distributed, and loaded, thereby dynamically processing (allowing or blocking) user process access requests, effectively improving the timeliness of security checks based on file access policies.

[0011] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application, it can be implemented according to the contents of the specification. In order to make the above and other objects, features and advantages of this application more obvious and understandable, specific embodiments of this application are given below. Attached Figure Description

[0012] In the accompanying drawings, unless otherwise specified, the same reference numerals throughout the various drawings denote the same or similar parts or elements. These drawings are not necessarily drawn to scale. It should be understood that these drawings depict only some embodiments according to this application and should not be construed as limiting the scope of this application.

[0013] Figure 1 This paper illustrates the structural framework of the cloud security system provided in an embodiment of this application.

[0014] Figure 2 A flowchart illustrating a file protection method applied to a client, provided by an embodiment of this application, is shown.

[0015] Figure 3 This illustration shows a schematic diagram of the creation and processing of eBPF and configuration information mapping tables in an embodiment of this application;

[0016] Figure 4 A schematic diagram of the storage file access strategy in an embodiment of this application is shown;

[0017] Figure 5 This illustration shows a schematic diagram of a security check performed by loading a file access policy in an embodiment of this application;

[0018] Figure 6 This illustrates another schematic diagram of security checks performed on loaded file access policies in an embodiment of this application;

[0019] Figure 7 This paper shows a structural framework diagram of a document protection device provided in an embodiment of this application;

[0020] Figure 8 A block diagram is shown for implementing the electronics in the embodiments of this application. Detailed Implementation

[0021] In the following description, only certain exemplary embodiments are briefly described. As those skilled in the art will recognize, the described embodiments can be modified in various ways without departing from the concept or scope of this application. Therefore, the drawings and description are considered to be exemplary in nature and not restrictive.

[0022] To facilitate understanding of the technical solutions of the embodiments of this application, the relevant technologies of the embodiments of this application are described below. The following relevant technologies are optional solutions and can be combined with the technical solutions of the embodiments of this application in any way, and all of them fall within the protection scope of the embodiments of this application.

[0023] The following terms will be used in the following text:

[0024] eBPF is a powerful network and performance analysis tool that is widely used in the Linux kernel.

[0025] Linux Security Modules (LSMs) are a framework in the Linux kernel used to support various computer security models.

[0026] Traditional file protection / anti-tampering solutions typically load file protection drivers into the kernel layer and monitor file operations. This approach carries significant risks due to its involvement with the kernel driver layer; vulnerabilities can lead to system crashes. Furthermore, the Linux kernel suffers from severe fragmentation, making kernel driver adaptation a major challenge.

[0027] The embodiments of this application aim to provide a file protection scheme suitable for cloud security systems, so as to increase the universality for multiple kernel versions and the security of operation.

[0028] Figure 1 The structural framework of the cloud security system provided in this application embodiment is shown, such as... Figure 1 As shown, the cloud security system may include a console 101, a server 102, and a client 103 connected by communication.

[0029] Console 101 can be used to configure corresponding file access policies based on received policy configuration conditions and send the configured file access policies to server 102. Console 101 can be a terminal device used by operations and maintenance personnel or administrators. These personnel can input policy configuration conditions through the terminal device according to specific needs, and the terminal device can then configure corresponding file access policies based on these conditions. When the input policy configuration conditions change, the file access policies also change accordingly. In some embodiments, operations and maintenance personnel or administrators can input the path to a core file through the terminal device. The terminal device can then set corresponding access permissions for that core file path as a file access policy. For example, for a game project, operations and maintenance personnel can input the path to the core game file through the terminal device, such as / opt / game / files, and the terminal device can set corresponding access permissions for that path as a file access policy.

[0030] Server 102 can interact with console 101, for example, it can receive file access policies configured through the console and send the received file access policies to the client. Server 102 can be a device of the service provider (such as a cloud vendor), such as at least one device such as a server, server cluster, or terminal device.

[0031] Client 103 can interact with server 102. For example, it can receive and store file access policies sent by server 102. In response to a user process's access request to a file in kernel space, client 103 can load the stored file access policy and perform a security check on the access. Client 103 can be a terminal device used by a user. The operating system of client 103 can be a Linux operating system, which includes user space and kernel space. User space is the runtime space for user programs, and kernel space is the runtime space for the Linux kernel. When a process runs in user space, it is in user mode; when a process runs in kernel space, it is in kernel mode.

[0032] For example, client 103 can be hardware, such as mobile phones, personal computers, tablets, wearable devices, and other electronic devices; it can also be an application (APP) or software module deployed on an electronic device. Console 101 and server 102 can be deployed on the same entity or multiple entities, which can be an application, service, instance, software-form functional module, virtual machine, container, or cloud server, or a hardware device or hardware chip with data processing capabilities.

[0033] It should be noted that the application scenarios or examples provided in the embodiments of this application are for ease of understanding, and the embodiments of this application do not specifically limit the application of the technical solutions. In addition, the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0034] The technical solution of this application and how it solves the aforementioned technical problems are described in detail below with specific embodiments. The listed specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0035] Figure 2 The flowchart shown is a file protection method applied to a client file security module according to an embodiment of this application. Figure 2 As shown, the method may include steps S201, S202 and S203.

[0036] Step S201: In response to a user process's request to access a file in the kernel space, load the file access policy based on eBPF.

[0037] The file access policy is received by the user-space security service module from the server and sent to the file security module, which then pre-stores it in the kernel space based on eBPF.

[0038] File access policies can include configuring permissions for user processes to access files in the kernel space. For example, for a certain file, only one user process may be allowed to access the file, while other user processes may be denied access. Access to a file may include operations such as editing or deleting the file.

[0039] Step S202: Perform a security check on the above access request of the user process based on the file access policy.

[0040] Step S203: Based on the result of the security check, allow or block the above access request of the user process.

[0041] When a user process requests access to a file in the kernel space, it can execute a system call (syscall) using the OPEN system command. This allows monitoring of the OPEN system calls of user processes. When the OPEN system call is detected, it indicates that a user process is requesting access to a file in the kernel space, meaning that there is an access request from a user process.

[0042] The file protection method provided in this application embodiment is based on eBPF to store and load file access strategies to achieve file protection / anti-tampering. eBPF does not need to load the kernel driver layer, so it does not need to be adapted to different kernel versions and can be directly applied to various kernel versions, which has strong universality. At the same time, because eBPF does not involve operations on the kernel driver layer, its security is also strong and will not cause the user's operating system to crash due to functional vulnerabilities of the cloud security system itself.

[0043] By combining the file protection method on the server side and the functions of the console, the file protection scheme provided in this application embodiment can dynamically configure, distribute and load file access policies, thereby dynamically processing (allowing or blocking) the access requests of user processes, effectively improving the timeliness of security checks based on file access policies. Over time, this file protection scheme can cover most user machines.

[0044] In an optional implementation, in step S201 above, loading a file access policy based on eBPF may include: storing the file access policy in the configuration information mapping table (BPF maps) of eBPF, and using eBPF to load the file access policy from the configuration information mapping table.

[0045] In one example, the file security module can use a subroutine of the eBPF pre-inserted into the kernel space to store the file access policy in the eBPF configuration information map (BPF maps), and then use the pre-inserted eBPF subroutine to load the file access policy stored in the above configuration information map.

[0046] eBPF subroutines can be pre-compiled in user space by the user-space security service module. These compiled eBPF subroutines can be inserted into kernel space via BPF system calls (bpf syscalls). The inserted eBPF subroutines can store file access policies in the eBPF configuration information map table. This configuration information map table typically uses key-value pairs for data storage, where the key can be a file access policy and the value can be the specific content of the file access policy. This creates key-value pairs with a mapping relationship, establishing a channel between kernel space and user space. This channel allows programs in kernel space and user space to share data in this configuration information map table, thus enabling data sharing and interaction between kernel space and user space.

[0047] The security service module in user space can be Cloud Shield. Cloud Shield can improve the security of data transmission between user space and kernel space, as well as between client and server.

[0048] In one optional implementation, the file security module is equipped with hook functions. For example, the file security module can be the aforementioned LSM, and the hook functions can be LSM hook functions (i.e., LSM Hooks). These hook functions can be called first, and then the file security module can be invoked through these hook functions. Correspondingly, loading file access policies from the configuration information mapping table using eBPF can include: when the hook function is called, loading the file access policy from the configuration information mapping table using eBPF. Based on the hook functions, the file security module can be flexibly controlled to implement its corresponding functions.

[0049] The file security module's actions of allowing or blocking access can be implemented by hook functions within the file security module. In some embodiments, when calling a hook function, the file path and process-related information, such as the PID (Process Identifier), can be passed to the hook function. After receiving the file path and process-related information, the hook function can perform corresponding operations on the access requests for that file path and process-related information according to the file access policy loaded by the file security module. For example, after performing a security check, the file security module can feed back the results of the security check to the attached hook function, and the hook function can perform corresponding allow or block operations based on the results of the security check.

[0050] In one optional implementation, loading a file access policy from a configuration information map using eBPF may include: loading the file access policy from the configuration information map using an eBPF subroutine. The eBPF subroutine may be pre-registered in a hook function and run during the hook function call; that is, the eBPF subroutine can run during the hook function call.

[0051] For hook functions that register eBPF subroutines, calling the hook function will run the eBPF subroutine, thus enabling the corresponding functions to be implemented based on the eBPF subroutine without affecting the kernel driver layer.

[0052] In one optional implementation, the creation and processing of the configuration information mapping table and eBPF include: the security service module compiles eBPF subroutines in user space, loads the compiled eBPF subroutines into kernel space based on BPF system calls, registers the loaded eBPF subroutines in kernel space into the hook functions, and creates a configuration information mapping table in kernel space based on the eBPF subroutines. When loading the eBPF subroutines into kernel space, the kernel space performs strict code verification on the eBPF subroutines to prevent unauthorized code from entering kernel space.

[0053] The security check can specifically include examining user process access requests for a file to determine if the request falls within the permissions specified by the file access policy. If the check shows the request is within the permissions, it passes the security check; otherwise, it fails. If the user process's access request passes the security check, the file security module allows it; if it fails, it blocks it. Based on the pass / fail status of the security check, the file security module can effectively determine whether a user process's access request is permitted, promptly blocking unauthorized requests to prevent them from adversely affecting the operating system's kernel space and effectively ensuring the security of the operating system's kernel space.

[0054] In an optional implementation, the file protection method described above may further include: transmitting an interception event to the security service module when a user process's access request fails the security check; the security service module then reports the interception event to the server. That is, when the check result indicates that the current user process's access request is outside the permission scope defined by the loaded file access policy, an interception event can be reported to the user space security service module, which in turn reports the interception event to the server. This allows the server to further process the interception event or provide further feedback to the console. Simultaneously, dynamic reporting of interception events can be achieved, improving the timeliness of reporting.

[0055] During the transmission of intercepted events to the security service module, eBPF can be used to store the intercepted events in a configuration information mapping table in the kernel space. In response to the security service module's read command, the intercepted event from this configuration information mapping table can be transmitted to the security service module. For example, after an intercepted event occurs, eBPF can be used to update the intercepted event in the fixed mapping key:events in the configuration information mapping table. The security service module can then read the content corresponding to key:events using a read command; this content represents the specific details of the intercepted event.

[0056] By using the configuration information mapping table, kernel space and user space can interact with each other, thereby enabling the reporting of intercepted events.

[0057] The following reference Figures 3-6 The principles of the file protection scheme provided in the embodiments of this application will be explained with some specific examples.

[0058] Figure 3This diagram illustrates a specific example of creating and processing eBPF and configuration information mapping tables. (See also...) Figure 3 The user-space cloud shield can run a core file process in user space based on BPF system commands. The core file process executes BPF system calls (bpf syscall) to load the eBPF subroutines compiled in user space into kernel space. The kernel space performs strict code verification on the eBPF subroutines to ensure that no illegal code will affect the normal operation of the kernel. After code verification, the eBPF subroutines are registered in LSM hook functions and BPF maps are created. The core file process can exchange data with the BPF maps through bpf syscall. For example, the user-space core file process can read data from the BPF maps through bpf syscall.

[0059] Figure 4 This diagram illustrates an eBPF-based storage file access policy after the eBPF and configuration information mapping table have been created and processed. (Refer to...) Figure 4 Operations / maintenance personnel / administrators access policies through dynamic configuration files in the console. Figure 4 (This process is not shown) and sent to the server. The server distributes the file access policy to the client through the cloud security system's distribution channel. After receiving the file access policy distributed by the server, the cloud shield in the client's user space sends the file access policy to the file security module and calls the LSM hook function to run the eBPF subroutine registered in it. Then, the file security module can call the eBPF subroutine to store the file access policy in the BPF maps in the kernel space.

[0060] Figure 5 This diagram illustrates how a file access policy is loaded and a security check is performed in response to a user process's request to access a file in kernel space. (Refer to...) Figure 5When a user process is detected executing the OPEN system call, it indicates that a user process is attempting to access a file in the kernel space, meaning there is an access request from a user process. At this point, the LSM hook function can be called to run the eBPF subroutine registered in that function, and the file security module can be invoked. The running eBPF subroutine can load the stored file access policy from BPF maps. The invoked file security module performs a security check on the current user process's access request based on the file access policy. If the access request passes the security check (Yes), the check result is returned to the LSM hook function, which then allows the access. If the access request fails the security check (No), the check result is returned to the LSM hook function, which then intercepts the access. Simultaneously, the interception event is reported to Cloud Shield via BPF maps and the BPF system call, and then reported to the server.

[0061] In some examples, such as Figure 6 As shown, when a user process is detected executing the OPEN system call, a pre-check can be performed. After the pre-check is completed, the LSM hook function is called. The pre-check includes inode lookup, error checking, and DAC (Discretionary Access Control) check.

[0062] Corresponding to the file protection method provided in the embodiments of this application, the embodiments of this application also provide a file protection device that can be applied to a client, such as... Figure 7 As shown, the device may include a security service module 701 deployed in user space and a file security module 702 deployed in kernel space.

[0063] The security service module 701 can be used to: receive file access policies sent by the server and send the file access policies to the file security module 702 in the kernel space.

[0064] The file security module 702 can be used to: respond to a user process's access request to a file in the kernel space, load a file access policy based on eBPF, perform a security check on the access request based on the file access policy, and allow or block the access request based on the result of the security check. The file access policy is pre-stored in the kernel space by the file security module based on eBPF.

[0065] In an alternative implementation, when loading a file access policy in kernel space based on eBPF, the file security module 702 can be used to store the file access policy in the configuration information mapping table of eBPF and use the eBPF to load the file access policy from the configuration information mapping table.

[0066] In one alternative implementation, the file security module 702 is equipped with hook functions, such as LSM hook functions. When loading file access policies from a configuration information map using eBPF, the file security module can be used to: load file access policies from a configuration information map using eBPF when a hook function is invoked.

[0067] In an alternative implementation, when loading file access policies from a configuration information map using eBPF, the file security module 702 can be used to: load file access policies from the configuration information map using eBPF subroutines. These eBPF subroutines are pre-registered in hook functions and run during the invocation of those hook functions.

[0068] In an optional implementation, when allowing or blocking access requests from user processes based on the results of security checks, the file security module 702 can be used to: allow the access request if it passes the security check; and block the access request if it fails the security check. In some embodiments, the file security module 702 can also be used to: transmit an interception event to the security service module if the access request fails the security check. For example, the file security module 702 can use eBPF to store the interception event in a configuration information mapping table in the kernel space, and in response to a read instruction from the security service module 701, transmit the interception event from the configuration information mapping table to the security service module 701, so that the security service module 701 can report the received interception event to the server.

[0069] The functions of each module in each device in the embodiments of this application can be found in the corresponding description in the above method, and they have corresponding beneficial effects, which will not be repeated here.

[0070] Figure 8 This is a block diagram of an electronic device used to implement embodiments of this application. For example... Figure 8 As shown, the electronic device includes a memory 801 and a processor 802. The memory 801 stores a computer program that can run on the processor 802. When the processor 802 executes the computer program, it implements any of the methods in the above embodiments. The number of memories 801 and processors 802 can be one or more. In a specific implementation, the electronic device may also include a communication interface 803 for communicating with external devices and performing data exchange and transmission. The electronic device can serve as any one of the console, server, and client in the embodiments of this application.

[0071] In practical implementation, if the memory 801, processor 802, and communication interface 803 are implemented independently, they can be interconnected via a bus to communicate with each other. This bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. This bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 8 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0072] Optionally, in a specific implementation, if the memory 801, the processor 802, and the communication interface 803 are integrated on a single chip, then the memory 801, the processor 802, and the communication interface 803 can communicate with each other through an internal interface.

[0073] This application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method provided in this application.

[0074] This application provides a computer program product, including a computer program that, when executed by a processor, implements the method provided in this application.

[0075] This application also provides a chip including a processor for calling and executing instructions stored in a memory, causing a communication device with the chip installed to perform the method provided in this application.

[0076] This application also provides a chip, including: an input interface, an output interface, a processor, and a memory. The input interface, output interface, processor, and memory are connected through an internal connection path. The processor is used to execute code in the memory. When the code is executed, the processor is used to execute the method provided in the application embodiment.

[0077] It should be understood that the aforementioned processor can be a Central Processing Unit (CPU), or other general-purpose processors, 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, discrete hardware components, etc. General-purpose processors can be microprocessors or any conventional processor. It is worth noting that the processor can be a processor supporting Advanced Reduced Instruction Set Machines (ARM) architecture.

[0078] Further, optionally, the aforementioned memory may include read-only memory and random access memory. The memory may be volatile memory or non-volatile memory, or may include both. Non-volatile memory may include read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory may include random access memory (RAM), which serves as an external cache. By way of example, but not limitation, many forms of RAM are available. Examples include Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDR SDRAM), Enhanced Synchronous DRAM (ESDRAM), Synchronous Link DRAM (SLDRAM), and Direct Rambus RAM (DR RAM).

[0079] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. A 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 according to 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 computer-readable storage medium or transferred from one computer-readable storage medium to another.

[0080] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of those different embodiments or examples.

[0081] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "a plurality of" means two or more, unless otherwise explicitly specified.

[0082] Any process or method described in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing a particular logical function or process. Furthermore, the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functionality involved.

[0083] The logic and / or steps described in the flowchart or otherwise herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus or device (such as a computer-based system, a processor-included system or other system that can fetch and execute instructions from, an instruction execution system, apparatus or device).

[0084] It should be understood that various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. All or part of the steps of the methods in the above embodiments can be implemented by a program instructing related hardware, the program being stored in a computer-readable storage medium, which, when executed, includes one or a combination of the steps of the method embodiments.

[0085] Furthermore, the functional units in the various embodiments of this application can be integrated into a processing module, or each unit can exist physically separately, or two or more units can be integrated into a module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. This storage medium can be a read-only memory, a disk, or an optical disk, etc.

[0086] The above description is merely an exemplary embodiment of this application, but the scope of protection of this application is not limited thereto. Any person skilled in the art can easily conceive of various variations or substitutions within the technical scope described in this application, and these should all be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A file protection method applied to a file security module on a client, wherein the client's operating system includes user space and kernel space, and the file security module is deployed in the kernel space, the method comprising: In response to a user process's access request to a file in the kernel space, a file access policy is loaded based on the extended Berkeley Packet Filter (eBPF). The file access policy is received from the server by the user space security service module and sent to the file security module, and is pre-stored in the kernel space by the file security module based on the eBPF. The access request is subjected to a security check based on the file access policy. The access request is allowed or blocked based on the results of the security check.

2. The document protection method according to claim 1, wherein, Loading the file access policy based on the eBPF includes: The file access policy is stored in the eBPF configuration information mapping table; The file access policy is loaded from the configuration information mapping table using the eBPF.

3. The document protection method according to claim 2, wherein, The file security module includes hook functions; the file access policy is loaded from the configuration information mapping table using eBPF, including: When the hook function is called, the file access policy is loaded from the configuration information mapping table using eBPF.

4. The document protection method according to claim 3, wherein, Loading the file access policy from the configuration information mapping table using the eBPF includes: The file access policy is loaded from the configuration information mapping table using the eBPF subroutine, wherein the subroutine is pre-registered in the hook function and runs during the hook function call.

5. The document protection method according to any one of claims 1-4, wherein, Based on the results of the security check, the access request is allowed or blocked, including: If the access request passes the security check, the access request is allowed. If the access request fails the security check, the access request is blocked.

6. The document protection method according to claim 5 further includes: If the access request fails the security check, an interception event is transmitted to the security service module; The interception event is reported to the server by the security service module.

7. The file protection method according to claim 6, transmitting the interception event to the security service module, includes: The intercepted events are stored in a configuration information mapping table in the kernel space using the eBPF. In response to the read command of the security service module, the intercepted events in the configuration information mapping table are transmitted to the security service module.

8. A file protection device applied to a client, wherein the client's operating system includes user space and kernel space, the device comprising: The security service module, deployed in the user space, is used to receive file access policies sent by the server and send the file access policies to the file security module in the kernel space. The file security module, deployed in the kernel space, is used to respond to a user process's access request to a file in the kernel space by loading the file access policy based on eBPF, performing a security check on the access request based on the file access policy, and allowing or blocking the access request based on the result of the security check; wherein, the file access policy is pre-stored by the file security module in the kernel space based on eBPF.

9. A cloud security system, comprising: The console is used to respond to received policy configuration conditions, configure the corresponding file access policies, and send the configured file access policies to the server. The server is connected to the console and is used to receive file access policies sent by the console and send the file access policies to the client. A client, communicating with the server, is used to execute the method according to any one of claims 1-7.

10. An electronic device comprising a memory, a processor, and a computer program stored on the memory, wherein the processor, when executing the computer program, implements the method of any one of claims 1-7.

11. A computer-readable storage medium storing a computer program that, when executed by a processor, implements the method of any one of claims 1-7.

12. A computer program product comprising a computer program that, when executed by a processor, implements the method according to any one of claims 1-7.

Images