File verification method, device and system based on extended attributes

Abstract

This invention provides a file verification technology based on extended attributes. The technology includes: reading the extended attributes of the file to be verified; defining a data structure for the extended attributes; creating extended attribute nodes for the file to be verified based on the data structure, and setting the extended attribute name and value in the extended attribute nodes; checking the security of the file to be verified against a whitelist; calculating a first verification value for the file to be verified, and reading the nodes in the file to be verified that store security attributes; and comparing the first verification value with the nodes that store security attributes. This invention utilizes extended attributes to achieve more flexible and efficient file verification.

Description

Technical Field

[0001] This invention relates to the field of computer security technology, and in particular to a file verification technology based on extended attributes. Background Technology

[0002] With the development of internet technology, many advanced computer and information technologies have emerged. At the same time, new types of malware have also brought new threats to governments, businesses, and individuals. Malware may illegally tamper with the code or data of programs (especially system files) or implant malicious code, thus threatening system security and potentially causing significant losses to users. Checking the uniqueness and integrity of system files before executing a program can effectively prevent damage caused by malware.

[0003] Taking the startup and operation of a Linux system as an example, Linux uses files as the basic unit of operation. In existing Linux systems, encrypted strings are used to describe the status of system files. The verification method for system files mainly involves traversing a list storing basic file information to obtain the corresponding status values ​​for comparison and verification. Specifically, the aforementioned system files are all stored in fixed paths and have fixed file types. In this case, the system can only verify values ​​stored at specific addresses and only specific file statuses. More specifically, Linux systems use the IMA / EVM kernel module by default for security verification. The extended attribute names of this kernel module are fixed and cannot be changed (e.g., security.ima and security.evm).

[0004] As can be seen, the above methods lack flexibility in file verification. They cannot be extended to include files other than system files, such as user's private data files, software files, and shared data files. Furthermore, because they use a list-based approach to store and retrieve status information, the existing methods have low verification efficiency and can only provide conclusions of completeness or incompleteness, uniqueness or non-uniqueness, without evaluating the degree of completeness. Summary of the Invention

[0005] This invention provides a file verification method, apparatus, and system based on extended attributes to solve the problems of low verification efficiency, inflexible status description, and inability to quantitatively evaluate the integrity of files in the prior art.

[0006] To achieve the above objectives, the present invention employs the following technical solution: a file verification method based on extended attributes, the method comprising: S1: reading the extended attributes of the file to be verified, the extended attributes including at least the name and timestamp information of the file to be verified; if reading fails, proceeding to step S2; if reading succeeds, proceeding to step S4; S2: defining a data structure for the extended attributes and proceeding to step S3, the data structure including at least an extended attribute name and an extended attribute value corresponding to the extended attribute name; S3: creating an extended attribute node for the file to be verified according to the data structure, and setting the extended attribute name and the extended attribute value of the file to be verified in the extended attribute node, and proceeding to step S4; In the above steps, the extended attribute nodes include at least a first extended attribute node and a second extended attribute node, which respectively store the name and timestamp of the file to be verified; S4: Check the name and timestamp of the file to be verified according to the whitelist to determine whether the file to be verified is secure; if secure, proceed to step S5; if insecure, report an error and / or terminate the process; S5: Calculate the first verification value of the file to be verified and read the extended attribute node of the file to be verified that stores security attributes, and proceed to step S6; S6: Compare the first verification value with the value of the extended attribute node that stores security attributes; if they are the same, determine that the file to be verified is secure; if they are different, determine that the file to be verified is insecure, report an error and / or terminate the process.

[0007] In a preferred embodiment, in step S4, checking the name and timestamp of the file to be verified according to the whitelist to determine whether the file to be verified is secure includes: S41: determining whether the file to be verified is in the whitelist based on the name information of the file to be verified; if yes, proceed to step S42; if no, report an error and / or terminate the process; S42: determining whether the file to be verified is the latest version based on the timestamp information of the file to be verified; if yes, it is determined to be secure; if no, report an error and / or terminate the process.

[0008] In a preferred embodiment, step S4 further includes: S43: if secure, obtain the storage path of the file to be verified and check if the storage path exists; if it exists, execute step S5; if it does not exist, report an error and / or terminate the process.

[0009] In a preferred embodiment, in step S5, calculating the first verification value of the file to be verified includes: S51: obtaining the full text and / or digest of the file to be verified according to the path, and calculating the first verification value of the full text and / or digest of the file to be verified; the first verification value is a value calculated according to the encryption algorithm.

[0010] In a preferred embodiment, the file to be verified includes a third extended attribute node; step S6 further includes: S61: modifying the extended attribute value of the third extended attribute node according to the verification result of the file or the type of the error.

[0011] To achieve the above objectives, another technical solution adopted by the present invention is: a file verification device based on extended attributes, the device comprising at least: a data reading module for reading the extended attributes of the file to be verified; a data definition module for defining the data structure of the extended attributes; a data storage module for creating extended attribute nodes of the file to be verified according to the data structure, and setting the extended attribute name and extended attribute value in the extended attribute nodes; and a data verification module for checking the file to be verified according to a whitelist to determine whether the file to be verified is secure, and calculating and comparing a first verification value of the file to be verified.

[0012] In a preferred embodiment, the data reading module is used to obtain the storage path of the file to be verified; the data verification module is used to determine whether the file to be verified is in the whitelist based on the name information of the file to be verified, to determine whether the file to be verified is the latest version based on the timestamp information of the file to be verified, and to check whether the storage path exists.

[0013] In a preferred embodiment, the data reading module is used to obtain the full text and / or summary of the file to be verified according to the path; the data verification module is used to calculate the first verification value of the full text and / or summary of the file to be verified.

[0014] In a preferred embodiment, the data storage module is used to modify the extended attribute value of the extended attribute node according to the file verification result or the type of error.

[0015] To achieve the above objectives, another technical solution adopted by the present invention is: a file verification system based on extended attributes, the system including at least a processor for implementing the method described in any of the above embodiments.

[0016] Compared with the prior art, the advantages of the present invention are: (1) The present invention uses the extended attributes of the file to describe the file status. It adds or customizes new extended attributes and redesigns the corresponding software logic based on the added extended attributes to meet the business logic of user-mode programs and kernel-mode functions; (2) The present invention can directly read the extended attribute name and key value information of the file to be verified. There is no traversal operation. The running efficiency is almost unaffected by the number of system files. The efficiency will not decrease with the increase of the number of files. Attached Figure Description

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

[0018] Figure 1 The following is a flowchart illustrating a file verification method based on extended attributes, provided by an embodiment of the present invention. Detailed Implementation

[0019] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0020] It should be noted that the terms "first" and "second" used in this invention are used to distinguish between two entities or parameters with the same name but different names. It is clear that "first" and "second" are only for the convenience of expression and should not be construed as limiting the invention. Subsequent embodiments will not elaborate on this point.

[0021] During operating system startup and runtime, it is necessary to at least verify the uniqueness and integrity of system files. To improve system security, this invention further enables the management and verification of various file types, including but not limited to executable files, loadable files, library files, and text files. Furthermore, user file usage is random; users may place files in arbitrary locations, meaning file paths may be randomly distributed throughout the file system.

[0022] Based on this, the preferred embodiment of the present invention for implementing the above technical solution involves reading or writing relevant information about a file through its extended attributes, and using this as the basis for verification. In specific applications, adjustments can be made according to the actual technical path adopted, thereby achieving the aforementioned technical solution more flexibly.

[0023] Example 1

[0024] like Figure 1As shown, this embodiment provides a file verification method based on extended attributes. Taking the native file subsystem of the Linux operating system as an example, this embodiment uses the extended attributes of file nodes to customize related logic and perform security hardening. Unlike the original verification mechanism of the Linux operating system kernel, the extended attribute name added in this embodiment can be any name, and the corresponding key-value pair can also be any string information. Specifically, it includes the following steps.

[0025] S1: Read the extended attributes of the file to be verified. The extended attributes include at least the name and timestamp information of the file to be verified.

[0026] Specifically, in this embodiment, the security of a file is first determined based on its name and timestamp information, which can be stored in the extended attributes of the file to be verified. More specifically, if reading the name and timestamp information of the file to be verified fails, step S2 is executed; if reading the name and timestamp information of the file to be verified is successful, step S4 is executed.

[0027] In an optional embodiment, when a file is created, additional extended attribute nodes for name and time can be added, and the corresponding name and timestamp information can be stored. If these are not stored, or if the stored names or data structures are inconsistent, the read will fail. In this case, additional extended attribute nodes are added and set according to the current information of the file to be verified (i.e., steps S2-S3 below), so that information can be obtained and judged in the next verification of the file to be verified.

[0028] S2: Define the data structure for the extended attribute. The data structure must include at least the extended attribute name and the extended attribute value corresponding to the extended attribute name.

[0029] Specifically, based on the file content to be verified, define the names of the extended attributes and the data content to be stored, and then execute step S3. During file verification, the specific meaning of the file can be verified based on the extended attribute names and values, including but not limited to verifying file uniqueness, integrity, or other different meanings.

[0030] In an optional embodiment, extended attributes are a functional mechanism of the file system, similar to a linked list. Users can add a new node as needed, customize its name, and store file information. This newly added extended attribute name and the stored information data are then used in the verification process. For example, the data structure `security.wlist = taged` can be used to represent the security status of a file, where "taged" can be any value.

[0031] In an optional embodiment, the extended attributes can be defined using file-based inode nodes. This approach is versatile and efficient, meeting the relevant business requirements of both user space and kernel space.

[0032] S3: Create extended attribute nodes for the file to be verified based on the data structure, and set the extended attribute name and extended attribute value of the file to be verified in the extended attribute nodes.

[0033] Specifically, based on the data structure defined in step S2, an extended attribute node is created in the extended attributes of the file to be verified, and step S4 is executed. The extended attribute node includes at least a first extended attribute node and a second extended attribute node, which are used to store the name and timestamp of the file to be verified, respectively.

[0034] In an optional embodiment, taking a Linux system as an example, the Setattr function can be used to create the extended attribute node of the file to be verified. The data structure of this node is set according to predefined rules, such as the data structure defined in step S2, and will not be changed or redefined. In an optional embodiment, the writing function of the extended attribute node can be implemented by calling the system's API, for example, writing the name string and the numeric string to the storage bits corresponding to the innode node of the file to be verified.

[0035] S4: Check the name and timestamp of the file to be verified according to the whitelist to determine whether the file to be verified is safe; if safe, proceed to step S5; if not safe, report an error and / or end the process.

[0036] Specifically, in this invention, the whitelist refers to a list of files that the system allows to be executed. This embodiment checks whether the file to be verified matches the information in the whitelist to determine whether executing the file is safe.

[0037] In an optional embodiment, the step of checking the file to be verified may include: S41 determining whether the file to be verified is in the whitelist based on its name information; if yes, proceeding to step S42; otherwise, reporting an error and / or ending the process; S42 determining whether the file to be verified is the latest version based on its timestamp information; if yes, it is deemed safe; otherwise, reporting an error and / or ending the process. In an optional embodiment, in addition to the aforementioned file name and timestamp, other file attributes can also be used for checking, including but not limited to the file's creator, version number, etc.

[0038] In an optional embodiment, the process may further include step S43: if secure, obtain the storage path of the file to be verified and check if the storage path exists; if it exists, execute step S5; if it does not exist, report an error and / or terminate the process.

[0039] S5: Calculate the first verification value of the file to be verified, and read the node in the file to be verified that stores the security attribute, and execute step S6.

[0040] Specifically, the first verification value in this step can be used to verify the uniqueness, integrity, or other custom attributes of the file to be verified.

[0041] In an optional embodiment, taking integrity as an example, calculating the first verification value of the file to be verified includes S51 obtaining the full text and / or digest of the file to be verified according to the path, and calculating the first verification value of the full text and / or digest of the file to be verified; the first verification value is a value calculated according to the encryption algorithm. In an optional embodiment, the encryption algorithm can be selected from various national cryptographic algorithms, such as SM1, SM2, SM3 and SM4, etc.

[0042] S6: Compare the first verification value with the node storing the security attribute. If they are the same, the file to be verified is determined to be secure; if they are different, the file to be verified is determined to be insecure, and an error is reported and / or the process ends.

[0043] Specifically, the first verification value calculated in step S5 is compared with the corresponding value stored in the extended attribute node of the file to be verified. If the comparison results are the same, the file to be verified is determined to be safe; if the comparison results are different, the file to be verified is determined to be unsafe, and an error is reported and / or the process ends.

[0044] In an optional embodiment, this step further includes, in step S61, modifying the extended attribute value of the third extended attribute node based on the file's verification result or the type of error. The verification result can be secure or insecure, and the error type can be any error reported in steps S1 to S6. The system can determine whether the file is secure based on this extended attribute, or determine the error type of the file to be verified based on the error information, thereby further determining whether to execute the file.

[0045] This embodiment describes a relatively complete file verification method. In practical applications, verification can be performed based on the type of file to be verified, such as file name, type, and verification value. Based on this, depending on security requirements, some or all of the verification values ​​can be selected for file verification, thereby achieving integrity verification.

[0046] Example 2

[0047] Existing operating systems only allow extended attribute names like `security.ima` or `security.evm`, and the stored keys can only be specific encrypted strings calculated by existing encryption functions. Therefore, this embodiment uses the Linux system's original API function `Setattr` to explain the business logic for data structures, data reading, and writing. Based on this, the present invention can achieve highly customizable technical effects.

[0048] Specifically, this embodiment uses the execution mechanism of native functions in the operating system's executable file (exe) as an example. In this embodiment, due to the executable file's execution mechanism, when the executable file runs, the system will read the extended attribute names and key-value information of the file's Inode structure in real time.

[0049] More specifically, when a user creates the executable file ` / bin / test.sh`, the system calls the `Setattr` function or an equivalent function to create an extended attribute node for the file based on a predefined data structure. For example, it creates a node named "security.binary" and sets the value of `security.binary` to 2. In an optional embodiment, the string "security.binary" can indicate that the file is an executable file, and the value "2" can indicate that the file has a priority level of 2 and is in a verified state.

[0050] In an optional embodiment, when the / bin / test.sh executable file is run, the corresponding module of the system will automatically read the extended attribute string "security.binary=2" of the file, verify it, consider it to meet the security requirements, and run it immediately. The verification method can be as described in Embodiment 1, and will not be described in detail in this embodiment.

[0051] Furthermore, the `Setattr` native function can be used to create an extended attribute node for the file, "security.verify=tag". In an optional embodiment, "security.verify" represents the name of the newly added extended attribute node, and the string "tag" represents the specific key-value pair. In an optional embodiment, when it is necessary to indicate multiple pieces of information such as the file path not being changed and the file content not being changed, the tag key-value pair can be specifically set to "tag=2". In an optional embodiment, the system automatically reads the string "tag=2" when the file is run, indicating that the file path and file content have not been changed, and the file can run normally. Specifically, it can be set as follows: when security.verify=1, it indicates that the file path has not been changed and the file content has not been changed; when security.verify=2, it indicates that the file path has been changed but the file content has not been changed; when security.verify=3, it indicates that the file content has been changed.

[0052] This embodiment is based on the operating system's native EXE function execution mechanism, reading the extended attribute names and key-value information of the corresponding file's inode structure in real time. There is no traversal operation, so the impact on execution efficiency is minimal. Because the newly added extended attributes can store various numerical information, users can customize operations. After implementing the corresponding string encryption and decryption functions, the security level and functionality are equivalent to existing security levels.

[0053] Example 3

[0054] The present invention adopts a modular design to implement the methods of Embodiment 1 and Embodiment 2, as well as any optional embodiment thereof.

[0055] Specifically, this embodiment includes a data reading module for reading the extended attributes of the file to be verified; a data definition module for defining the data structure of the extended attributes; a data storage module for creating extended attribute nodes of the file to be verified according to the data structure, and setting the extended attribute name and extended attribute value in the extended attribute nodes; and a data verification module for checking the file to be verified according to a whitelist to determine whether the file to be verified is safe, and calculating and comparing the first verification value of the file to be verified.

[0056] In an optional embodiment, the data reading module is used to obtain the storage path of the file to be verified; the data verification module is used to determine whether the file to be verified is in the whitelist based on the name information of the file to be verified, to determine whether the file to be verified is the latest version based on the timestamp information of the file to be verified, and to check whether the storage path exists.

[0057] In an optional embodiment, the data reading module is used to obtain the full text and / or summary of the file to be verified according to the path; the data verification module is used to calculate a first verification value for the full text and / or summary of the file to be verified. In an optional embodiment, the data storage module is used to modify the extended attribute values ​​of the extended attribute nodes according to the verification result or error type of the file.

[0058] Example 4

[0059] The present invention also includes a file verification system based on extended attributes, the system including at least a processor, capable of implementing the methods of Embodiment 1 and Embodiment 2 above, and any optional embodiment therein.

[0060] The foregoing has provided a detailed description of the file verification method, apparatus, and system based on extended attributes provided by the present invention. Specific examples have been used to illustrate the principles and implementation methods of the present invention. The above description of the implementation is only for the purpose of helping to understand the method and core ideas of the present invention. At the same time, for those skilled in the art, based on the ideas of the present invention, there will be changes in the specific implementation methods and application scope. Modifications and improvements to the present invention are possible without exceeding the concept and scope defined by the appended claims. Therefore, the content of this specification should not be construed as a limitation of the present invention.

Claims

1. A file verification method based on extended attributes, used in the native file subsystem of the Linux operating system, characterized in that, The method includes: Step S1: Read the extended attributes of the file to be verified, which include at least the name and timestamp information of the file to be verified; if reading fails, proceed to step S2; if reading succeeds, proceed to step S4. Step S2: Define the data structure of extended attributes based on the file's Inode node, and execute step S3. The data structure includes at least the extended attribute name and the extended attribute value corresponding to the extended attribute name. Step S3: The Setattr function creates an extended attribute node for the file to be verified, and the system API is used to write the name string and numeric string to the storage location corresponding to the Inode node of the file to be verified. Then, step S4 is executed. The extended attribute node includes at least a first extended attribute node and a second extended attribute node, which respectively store the name and timestamp of the file to be verified. Step S4: Check the name and timestamp of the file to be verified according to the whitelist to determine whether the file to be verified is safe; if safe, proceed to step S5; if not safe, report an error and / or terminate the process; where the whitelist refers to the list of files that the system allows to be executed. In step S4, the step of checking the name and timestamp of the file to be verified according to the whitelist to determine whether the file to be verified is secure includes: Step S41: Determine whether the file to be verified is in the whitelist based on the name information of the file to be verified. If yes, proceed to step S42; otherwise, report an error and / or end the process. Step S42: Determine whether the file to be verified is the latest version based on the timestamp information of the file to be verified. If yes, it is considered safe; otherwise, report an error and / or end the process. Step S5: Calculate the first verification value of the file to be verified. The first verification value is a value obtained by calculating according to the encryption algorithm. Read the extended attribute node of the file to be verified that stores security attributes and execute step S6. Step S6: Compare the first verification value with the value of the extended attribute node storing the security attribute. If they are the same, the file to be verified is determined to be secure; if they are different, the file to be verified is determined to be insecure, and an error is reported and / or the process ends. The file to be verified also includes a third extended attribute node; step S6 further includes: Step S61: Modify the extended attribute value of the third extended attribute node according to the verification result of the file or the type of error.

2. The method according to claim 1, characterized in that, Step S4 further includes: Step S43: If safe, obtain the storage path of the file to be verified and check if the storage path exists; if it exists, proceed to step S5; if it does not exist, report an error and / or terminate the process.

3. The method according to claim 2, characterized in that, In step S5, calculating the first verification value of the document to be verified includes: Step S51: Obtain the full text and / or digest of the file to be verified according to the path, and calculate the first verification value of the full text and / or digest of the file to be verified; the first verification value is a value calculated according to the encryption algorithm.

4. A file verification device based on extended attributes, used in the native file subsystem of the Linux operating system, wherein the file verification device is used to implement the file verification method based on extended attributes as described in any one of claims 1-3, characterized in that, The device includes at least: The data reading module is used to read the extended attributes of the file to be verified; the data reading module is also used to obtain the storage path of the file to be verified. The data definition module is used to define data structures with extended attributes based on file-based Inode nodes; The data storage module is used to create extended attribute nodes of the file to be verified by the Setattr function, and write the name string and the numeric string to the storage bits corresponding to the Inode node of the file to be verified by calling the extended attribute node writing function implemented by the system API. The data verification module is used to check the file to be verified according to the whitelist to determine whether the file to be verified is safe, and to calculate and compare the first verification value of the file to be verified, wherein the whitelist refers to the list of files that the system allows to be executed; the data verification module is used to determine whether the file to be verified is in the whitelist according to the name information of the file to be verified, to determine whether the file to be verified is the latest version according to the timestamp information of the file to be verified, and to check whether the storage path exists; The data storage module is used to modify the extended attribute values ​​of the extended attribute node according to the file verification result or the type of error.

5. The apparatus according to claim 4, characterized in that, The data reading module is used to obtain the full text and / or summary of the file to be verified according to the path; the data verification module is used to calculate the first verification value of the full text and / or summary of the file to be verified.

6. A file verification system based on extended attributes, characterized in that, The system includes at least a processor for implementing the method according to any one of claims 1-3.

Images