Method and apparatus for implementing process whitelist based on file extended attributes

Abstract

The present invention discloses a method and device for implementing a process whitelist based on file extended attributes. The whitelist list file is pre-encrypted and signed using encryption authentication technology. After the system boots and the file system is loaded, the whitelist list file is verified, decrypted, and the identity authentication of the whitelist list file is completed to ensure the security and reliability of the key information of the whitelist. The key information of the executable file in the whitelist list file is verified, and the corresponding file trusted extended attribute is set. Then, during the running process, when the application program is executed, only the file trusted extended attribute needs to be compared to quickly complete the verification. The present invention greatly improves the program startup efficiency on the premise of ensuring the security and reliability of the whitelist list file.

Description

Technical Field

[0001] The present invention relates to a method and device for implementing a process whitelist based on file extended attributes, belonging to the technical field of industrial information security. Background Art

[0002] The process whitelist technology can effectively resist malicious code attacks, and only the legitimate processes approved on the whitelist are allowed to run on the system. Currently, most whitelist implementation methods are to pre-collect a relatively complete process whitelist, save the key information such as the path and check value of its executable file, and then check against the whitelist based on the scanning results of the monitoring program to timely detect suspicious processes; or check the legitimacy of the program based on the whitelist every time the application program is started and executed, and intercept illegal processes at the initial stage of program execution.

[0003] Using the process whitelist can effectively control the running permissions of application programs and improve system security. The whitelist list file records the key information of the whitelist. If the whitelist list file is tampered with, the whitelist protection function will fail. Therefore, ensuring the security of the whitelist list file itself is the key to the whitelist technology to play its security protection function. In addition, the current legitimacy check of application programs based on the whitelist requires verifying and calculating the program and matching it with the whitelist every time the program is executed, which greatly affects the startup efficiency of legitimate programs.

[0004] In view of this, a new process whitelist implementation method is needed to ensure the security of the process whitelist list file itself and improve the process startup efficiency. Summary of the Invention

[0005] Objective: In order to overcome the deficiencies in the prior art, the present invention provides a method and device for implementing a process whitelist based on file extended attributes, proposes a fast verification method when a process starts, improves the process startup efficiency, and can ensure the security of the whitelist list file itself.

[0006] Technical Solution: To solve the above technical problems, the technical solution adopted by the present invention is:

[0007] In the first aspect, a method for implementing a process whitelist based on file extended attributes includes the following steps:

[0008] When the system in the device monitors that any executable file starts to execute, check whether the executable file exists in the whitelist list file.

[0009] When it is determined that the executable file exists, check whether the executable file has a file modification extended attribute.

[0010] If there is no file modification extended attribute, check whether the executable file has a file trusted extended attribute. If there is no file trusted extended attribute, send an instruction to the system to block the execution of the second executable file; if there is a file trusted extended attribute, send an instruction to the system to allow the executable file to be executed.

[0011] If there is a file modification extended attribute, obtain the absolute path of the executable file, read the content of the executable file through the absolute path and calculate the SM3 digest value, and then compare it with the absolute path and SM3 digest value of the executable file in the whitelist list file. If the comparison is consistent, add the file trusted extended attribute of the executable file and send an instruction to the system to allow the execution of the file; if the comparison is inconsistent, delete the file trusted extended attribute of the executable file and send an instruction to the system to block the execution of the executable file.

[0012] In a second aspect, a process whitelist implementation device based on file extended attributes includes the following modules:

[0013] System call monitoring module: When the system in the device monitors the start and execution of any executable file, check whether there is an executable file in the whitelist list file;

[0014] Whitelist implementation module, used to check whether the executable file has a file modification extended attribute when it is determined that there is an executable file; if there is no file modification extended attribute, check whether the executable file has a file trusted extended attribute. If there is no file trusted extended attribute, send an instruction to the system to block the execution of the executable file; if there is a file trusted extended attribute, send an instruction to the system to allow the executable file to be executed; if there is a file modification extended attribute, obtain the absolute path of the executable file, read the content of the executable file through the absolute path and calculate the SM3 digest value, and then compare it with the absolute path and SM3 digest value of the executable file in the whitelist list file. If the comparison is consistent, add the file trusted extended attribute of the executable file and send an instruction to the system to allow the execution of the file; if the comparison is inconsistent, delete the file trusted extended attribute of the executable file and send an instruction to the system to block the execution of the executable file.

[0015] As a preferred solution, the method for obtaining the whitelist list file includes the following steps:

[0016] When the device boots and the system runs, obtain the encrypted file and signature file of the whitelist list file, decrypt the encrypted file, and verify the signature of the signature file to obtain the whitelist list file.

[0017] As a preferred solution, the method for obtaining the file modification extended attribute in the executable file includes the following steps:

[0018] When the system in the device detects that the executable file in the whitelist list file has been modified, a file modification extended attribute is added to the executable file.

[0019] As a preferred solution, the method for obtaining the file trusted extended attribute in the executable file further includes the following steps:

[0020] Scan the executable files in the whitelist list file one by one. If there is a trust flag for the executable file in the whitelist list file, add a file trusted extended attribute to the executable file.

[0021] If there is no trust flag for the executable file in the whitelist list file, use the absolute path of the executable file in the whitelist list file to read the corresponding executable file content, calculate the SM3 digest value of the executable file, and compare it with the SM3 digest reference value. If the comparison is consistent, add a file trusted extended attribute to the executable file.

[0022] As a preferred solution, the method for obtaining the whitelist list file further includes:

[0023] If the encrypted file and signature file of the whitelist list file cannot be obtained, send an instruction to the system to prevent the device from running normally, and send an instruction to wait for the encrypted file and signature file of the whitelist list file to be redownloaded.

[0024] As a preferred solution, the method for obtaining the whitelist list file further includes:

[0025] If the verification or decryption of the encrypted file and signature file of the whitelist list file fails, send an instruction to the system to prevent the device from running normally, and send an instruction to wait for the encrypted file and signature file of the correct whitelist list file to be redownloaded.

[0026] As a preferred solution, the method for generating the encrypted file and signature file of the whitelist list file includes the following steps:

[0027] Perform SM3 digest calculation on the executable file, and write the absolute path of the executable file and the SM3 digest reference value into the whitelist list file;

[0028] Encrypt and sign the whitelist list file to generate the encrypted file and signature file of the whitelist list file.

[0029] As a preferred solution, the executable file includes: the executable file in the root file system, the user-defined executable file.

[0030] As a preferred solution, the method for there being a trust flag for the executable file in the whitelist list file includes the following steps:

[0031] If the executable file does not need to use the whitelist function, write the executable file that does not need to use the whitelist function into the whitelist list file, add a trust flag, and set the trust flag to 1.

[0032] As a preferred solution, the user-mode process is prohibited from calling the interface for modifying the file extension attributes to perform addition, modification, and deletion operations on the file modification extension attributes and file trusted extension attributes of the executable file.

[0033] Beneficial effects: A method and device for implementing a process whitelist based on file extension attributes provided by the present invention verify the key information of the executable file in the whitelist list file, and set corresponding file trusted extension attributes. Then, during the running process, when the application program is executed, only the file trusted extension attributes need to be compared to quickly complete the verification. Compared with the traditional whitelist method that must perform verification calculations every time the program is executed, the startup efficiency of the program is greatly improved.

[0034] In addition, the encryption authentication technology is used to encrypt and sign the whitelist list file in advance. After the system boots and the file system is loaded, the whitelist list file is verified and decrypted to complete the identity authentication of the whitelist list file, ensuring the security and reliability of the key information of the whitelist. And on the premise of ensuring the security and reliability of the whitelist list file, the executable file is verified. Description of the Drawings

[0035] Figure 1 It is a schematic diagram of the whitelist generation process of the present invention.

[0036] Figure 2 It is a schematic diagram of the whitelist configuration process of the present invention.

[0037] Figure 3 It is a schematic diagram of the whitelist verification process of the present invention. Detailed Embodiments

[0038] The following further describes the present invention with reference to specific embodiments.

[0039] Embodiment 1:

[0040] A method and device for implementing a process whitelist based on file extension attributes provided by the present invention, in the implementation process, first, a whitelist list file should be generated in the upper computer environment in advance and the whitelist list file should be encrypted and signed. The encrypted file and signature file of the generated whitelist list file are downloaded to the specified path of the file system on the device, so that when the device starts up next time, the whitelist list file can be parsed to configure the whitelist for the device.

[0041] After completing the above operations, turn on the device. At this time, the system starts to boot. After the file system is loaded as set, the system will first verify and decrypt the encrypted file and signature file of the whitelist list file to ensure the security and reliability of the whitelist list file itself, and then verify the key information of the executable files in the whitelist list file, and configure the corresponding file trusted extension attributes for the executable files according to the verification results. Thus, the configuration and deployment of the whitelist on the device are completed.

[0042] After that, during the operation of the device, if the system detects that the executable file in the whitelist is modified, it will configure the corresponding file modification extension attribute. During the operation of the device, when the application program is executed, it only needs to judge the file trusted extension attribute and file modification extension attribute of the executable file to quickly complete the whitelist verification function and realize the control of the execution of the application program.

[0043] As Figure 1 shown, the method for generating the whitelist list file is carried out according to the following steps:

[0044] Step A1: Calculate the SM3 digest of the executable files in the root file system in the upper computer, and write the absolute path of the executable file and the SM3 digest reference value into the whitelist list file.

[0045] Step A2: If there are user-defined executable files, calculate the SM3 digest of the user-defined executable files, and write the absolute path of the user-defined executable files and the SM3 digest reference value into the whitelist list file.

[0046] Step A3: If the executable file does not need to use the whitelist function, write the executable file that does not need to use the whitelist function into the whitelist list file, and add a trust flag, and set the trust flag to 1.

[0047] Step A4: Encrypt and sign the whitelist list file through the upper computer tool to generate the encrypted file and signature file of the whitelist list file.

[0048] Step A5: Download the encrypted file and signature file of the whitelist list file to the specified path of the file system on the device.

[0049] As Figure 2 shown, the whitelist configuration method is carried out according to the following steps:

[0050] Step B1: When the device is powered on and the system starts to boot, after the LSM hook function monitoring mechanism first detects that the file system has been loaded, check whether there are encrypted files and signature files of the whitelist list file in the specified path of the file system. If the encrypted file or signature file of the whitelist list file does not exist, prevent the device from running normally and wait for the user to re-download the encrypted file and signature file of the whitelist list file to the device; if the encrypted file and signature file of the whitelist list file exist, execute Step B2.

[0051] Step B2: Verify the signature and decrypt the encrypted file and signature file of the whitelist list file. If the signature verification or decryption fails, prevent the device from running normally and wait for the user to re-download the correct encrypted file and signature file of the whitelist list file to the device; if the signature verification and decryption are successful, parse the whitelist list file and execute Step B3.

[0052] Step B3: Delete the file modification extended attribute and file trust extended attribute of all executable files in the file system, so as to reset the whitelist configuration on the device to the initial state. Then scan the executable files in the whitelist list file one by one. If the trust flag of the executable file in the whitelist list file is 1, directly add the file trust extended attribute to the executable file; if there is no trust flag for the executable file in the whitelist list file, read the content of the corresponding executable file using the absolute path of the executable file in the whitelist list file, then calculate the SM3 digest value of the executable file, and compare it with the SM3 digest reference value. If the comparison is consistent, add the file trust extended attribute to the executable file; if the comparison is inconsistent, do not add the file trust extended attribute of the executable file. Thus, the configuration deployment of the whitelist on the device is completed.

[0053] As Figure 3 shown, the whitelist verification method is carried out according to the following steps:

[0054] Step C1: During the operation of the device, use the LSM hook function to monitor system calls at the operating system kernel layer. When it is detected that an executable file in the whitelist list file is modified, add the file modification extended attribute of the executable file. When it is detected that any executable file starts to execute, check whether the executable file exists in the whitelist list file. If it does not exist, prevent its execution; otherwise, execute Step C2.

[0055] Step C2: Check whether the executable file has a file modification extended attribute. If it does not have a file modification extended attribute, execute Step C3; if it has a file modification extended attribute, execute Step C4.

[0056] Step C3: Check whether the executable file has the file trusted extension attribute. If it does not have the file trusted extension attribute, block the program execution; if it has the file trusted extension attribute, allow the program to execute.

[0057] Step C4: Obtain the absolute path of the executable file, read the content of the executable file and calculate the SM3 digest value, and then compare it with the absolute path and SM3 digest value of the executable file in the whitelist list file. If the comparison is consistent, add the file trusted extension attribute of the file and allow the program to execute; if the comparison is inconsistent, delete the file trusted extension attribute of the file and block the program execution.

[0058] For the file modification extension attribute and file trusted extension attribute of the executable file, the user-mode process should be prohibited from calling the file extension attribute modification interface to perform addition, modification, and deletion operations on it.

[0059] Embodiment 2

[0060] An apparatus for implementing a process whitelist based on file extension attributes includes the following modules:

[0061] System call monitoring module: When the system in the apparatus monitors the startup and execution of any executable file, check whether there is an executable file in the whitelist list file;

[0062] Whitelist implementation module, used to check whether the executable file has the file modification extension attribute when it is determined that there is an executable file; if it does not have the file modification extension attribute, check whether the executable file has the file trusted extension attribute. If it does not have the file trusted extension attribute, send an instruction to the system to block the execution of the executable file; if it has the file trusted extension attribute, send an instruction to the system to allow the execution of the executable file; if it has the file modification extension attribute, obtain the absolute path of the executable file, read the content of the executable file through the absolute path and calculate the SM3 digest value, and then compare it with the absolute path and SM3 digest value of the executable file in the whitelist list file. If the comparison is consistent, add the file trusted extension attribute of the executable file and send an instruction to the system to allow the execution of the file; if the comparison is inconsistent, delete the file trusted extension attribute of the executable file and send an instruction to the system to block the execution of the executable file.

[0063] Preferably, the method for obtaining the whitelist list file includes the following steps:

[0064] When the device boots and the system runs, obtain the encrypted file and signature file of the whitelist list file, decrypt the encrypted file, and verify the signature of the signature file to obtain the whitelist list file.

[0065] Preferably, the method for obtaining the file modification extension attribute in the executable file includes the following steps:

[0066] When the system in the device detects that the executable file in the whitelist list file has been modified, a file modification extended attribute is added to the executable file.

[0067] Preferably, the method for obtaining the file trusted extended attribute in the executable file further includes the following steps:

[0068] Scan the executable files in the whitelist list file one by one. If there is a trust flag for the executable file in the whitelist list file, add a file trusted extended attribute to the executable file.

[0069] If there is no trust flag for the executable file in the whitelist list file, read the content of the corresponding executable file using the absolute path of the executable file in the whitelist list file, calculate the SM3 digest value of the executable file, and compare it with the SM3 digest reference value. If the comparison is consistent, add a file trusted extended attribute to the executable file.

[0070] Preferably, the method for obtaining the whitelist list file further includes:

[0071] If the encrypted file and signature file of the whitelist list file cannot be obtained, send an instruction to the system to prevent the device from running normally, and send an instruction to wait for the encrypted file and signature file of the whitelist list file to be redownloaded.

[0072] Preferably, the method for obtaining the whitelist list file further includes:

[0073] If the signature verification or decryption of the encrypted file and signature file of the whitelist list file fails, send an instruction to the system to prevent the device from running normally, and send an instruction to wait for the encrypted file and signature file of the correct whitelist list file to be redownloaded.

[0074] Preferably, the method for generating the encrypted file and signature file of the whitelist list file includes the following steps:

[0075] Perform SM3 digest calculation on the executable file, and write the absolute path of the executable file and the SM3 digest reference value into the whitelist list file;

[0076] Encrypt and sign the whitelist list file to generate the encrypted file and signature file of the whitelist list file.

[0077] Preferably, the executable file includes: executable files in the root file system, user-defined executable files.

[0078] Preferably, the method for having a trust flag for the executable file in the whitelist list file includes the following steps:

[0079] If the executable file does not need to use the whitelist function, write the executable file that does not need to use the whitelist function into the whitelist list file, add a trust flag, and set the trust flag to 1.

[0080] Preferably, the user-mode process is prohibited from calling the interface for modifying the file extension attributes to perform addition, modification, and deletion operations on the file modification extension attributes and file trusted extension attributes of the executable file.

[0081] Those skilled in the art should understand that the embodiments of the present application can be provided as a method, a system, or a computer program product. Therefore, the present application can adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware aspects. Moreover, the present application can adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0082] The present application is described with reference to the flowcharts and / or block diagrams of methods, apparatuses (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or block in the flowchart and / or block diagram, and the combination of processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to the processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing devices to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing devices generate a machine for implementing the functions specified in the process Figure 1 one process or multiple processes and / or blocks Figure 1 a device for the function specified in one block or multiple blocks.

[0083] These computer program instructions can also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer-readable memory generate a manufactured product including an instruction device, and the instruction device implements the functions specified in the process Figure 1 one process or multiple processes and / or blocks Figure 1 a function specified in one block or multiple blocks.

[0084] These computer program instructions can also be loaded onto a computer or other programmable data processing device, so that a series of operation steps are executed on the computer or other programmable device to generate a computer-implemented process, and thus the instructions executed on the computer or other programmable device provide steps for implementing the functions specified in the process Figure 1 one process or multiple processes and / or blocks Figure 1 a function specified in one block or multiple blocks.

[0085] The above are only the preferred embodiments of the present invention. It should be noted that for those of ordinary skill in the art, without departing from the principle of the present invention, several improvements and refinements can be made, and these improvements and refinements should also be regarded as the protection scope of the present invention.

Claims

1. A method for implementing a process whitelist based on file extended attributes, characterized in that: Including the following steps: When the system in the device monitors the startup and execution of any executable file, check whether the executable file exists in the whitelist list file; When it is determined that the executable file exists, check whether the executable file has a file modification extension attribute; If there is no file modification extension attribute, check whether the executable file has a file trust extension attribute. If there is no file trust extension attribute, send an instruction to the system to block the execution of the second executable file; if there is a file trust extension attribute, send an instruction to the system to allow the executable file to be executed; If there is a file modification extension attribute, obtain the absolute path of the executable file, read the content of the executable file through the absolute path and calculate the SM3 digest value, and then compare it with the absolute path and SM3 digest value of the executable file in the whitelist list file. If the comparison is consistent, add the file trust extension attribute of the executable file and send an instruction to the system to allow the execution of the file; if the comparison is inconsistent, delete the file trust extension attribute of the executable file and send an instruction to the system to block the execution of the executable file; The method for obtaining the whitelist list file includes the following steps: When the device powers on and the system runs, obtain the encrypted file and signature file of the whitelist list file, decrypt the encrypted file, and verify the signature of the signature file to obtain the whitelist list file.

2. The method for implementing a process whitelist based on file extended attributes according to claim 1, wherein: The method for obtaining the file modification extension attribute in the executable file includes the following steps: When the system in the device monitors that the executable file in the whitelist list file is modified, add a file modification extension attribute to the executable file.

3. The method for implementing a process whitelist based on file extended attributes according to claim 1, characterized in that: The method for obtaining the file trust extension attribute in the executable file further includes the following steps: Scan the executable files in the whitelist list file one by one. If there is a trust flag for the executable file in the whitelist list file, add a file trust extension attribute to the executable file; If there is no trust flag for the executable file in the whitelist list file, use the absolute path of the executable file in the whitelist list file to read the corresponding executable file content, calculate the SM3 digest value of the executable file, and compare it with the SM3 digest reference value. If the comparison is consistent, add a file trust extension attribute to the executable file.

4. A method for implementing a process whitelist based on file extended attributes according to claim 1, characterized in that: The method for obtaining the whitelist list file further includes: If the encrypted file and signature file of the whitelist list file cannot be obtained, send an instruction to the system to block the normal operation of the device and send an instruction to wait for the encrypted file and signature file of the whitelist list file to be redownloaded.

5. A method for implementing a process whitelist based on file extended attributes according to claim 1, characterized in that: The method for obtaining the whitelist list file further includes: If the verification or decryption of the encrypted file and signature file of the whitelist list file fails, send an instruction to the system to block the normal operation of the device and send an instruction to wait for the encrypted file and signature file of the correct whitelist list file to be redownloaded.

6. The method for implementing a process whitelist based on file extended attributes according to claim 1, characterized in that: The method for generating the encrypted file and signature file of the whitelist list file includes the following steps: Perform SM3 digest calculation on the executable file, and write the absolute path of the executable file and the SM3 digest reference value into the whitelist list file; Encrypt and sign the whitelist list file to generate the encrypted file and signature file of the whitelist list file.

7. A method for implementing a process whitelist based on file extended attributes according to claim 1, characterized in that: The executable files include: executable files in the root file system and user-defined executable files.

8. The method for implementing a process whitelist based on file extended attributes according to claim 2, wherein: A method for having a trust flag of an executable file in a whitelist list file includes the following steps: If the executable file does not need to use the whitelist function, write the executable file that does not need to use the whitelist function into the whitelist list file, add a trust flag, and set the trust flag to 1.

9. The method for implementing a process whitelist based on file extended attributes according to claim 1, characterized in that: Prohibit user-mode processes from calling the interface for modifying file extended attributes to perform addition, modification, and deletion operations on the file extended attributes and file trusted extended attributes of the executable file.

10. An apparatus for implementing a process whitelist based on file extended attributes, characterized in that: It includes the following modules: System call monitoring module: When the system in the device monitors the start and execution of any executable file, check whether the executable file exists in the whitelist list file; Whitelist implementation module, which is used to check whether the executable file has file modified extended attributes when it is determined that the executable file exists; If there is no file modified extended attribute, check whether the executable file has a file trusted extended attribute. If there is no file trusted extended attribute, send an instruction to the system to block the execution of the executable file; if there is a file trusted extended attribute, send an instruction to the system to allow the execution of the executable file; if there is a file modified extended attribute, obtain the absolute path of the executable file, read the content of the executable file through the absolute path and calculate the SM3 digest value, and then compare it with the absolute path and SM3 digest value of the executable file in the whitelist list file. If the comparison is consistent, add the file trusted extended attribute of the executable file and send an instruction to the system to allow the execution of this file; if the comparison is inconsistent, delete the file trusted extended attribute of the executable file and send an instruction to the system to block the execution of the executable file; A method for obtaining the whitelist list file includes the following steps: When the device powers on and the system runs, obtain the encrypted file and signature file of the whitelist list file, decrypt the encrypted file, verify the signature of the signature file, and obtain the whitelist list file.

Images