Method and device for ensuring safety of Selinux file

Abstract

The invention discloses a method and device for ensuring the security of a Selinux file, and the method comprises the steps: reading a signed security policy file from a file system of a user space when the security policy file needs to be updated; performing signature verification on the signed security policy file, and obtaining a new security policy; and after the signature verification is passed, the original security policy is unloaded, and then the new security policy is loaded to the Selinux kernel. By utilizing the scheme of the invention, the configuration information and the security policy of the Selinux can be ensured to be loaded and updated trustingly, and an attacker is prevented from bypassing security protection at a kernel level of an operating system by modifying a Selinux configuration file or a security policy file.

Description

Technical Field

[0001] The present invention relates to the field of Selinux security technology, and in particular to a method and device for ensuring the security of Selinux files. Background Art

[0002] Linux is a multi-user operating system with stable performance. The default access control under Linux is Discretionary Access Control (DAC), which is characterized by the resource owner being able to perform any operation (read, write, execute) on it. When a process is ready to operate a resource, the Linux kernel will compare the user identity (UID) and group identity (GID) of the process and resource. If the permissions allow, the corresponding operation can be performed. This method often brings some security issues. If a process runs as root, it means that it can operate any resource of the system without restriction.

[0003] SeLinux (Security-Enhanced Linux) is a mandatory access control (MAC) security system based on the domain-type model. It is designed as a kernel module and included in the Linux kernel, which enhances the security of the Linux system. SeLinux configuration files and security policy files play an important role in the security mechanism of SeLinux. However, if an attacker maliciously modifies the SeLinux configuration files and security policy files stored in the file system, such as adding some new policies, some malicious processes can access resources that were previously inaccessible, thereby causing information security issues. Malicious modification of configuration files can also cause information security issues, such as changing the Selinux enabled state in the configuration file to a disabled state. Summary of the invention

[0004] The embodiment of the present invention provides a method and device for ensuring the security of Selinux files, so as to ensure that the configuration information and security policy of Selinux are loaded and updated reliably, and prevent attackers from bypassing the security protection of the operating system kernel level by modifying the Selinux configuration file or the security policy file.

[0005] To this end, the embodiment of the present invention provides the following technical solutions:

[0006] On the one hand, an embodiment of the present invention provides a method for ensuring the security of a Selinux file, the method comprising:

[0007] When the security policy file needs to be updated, a new security policy file is obtained from the user space to the Selinux kernel space, wherein the new security policy file is a signed file;

[0008] Perform signature verification on the new security policy file in the Selinux kernel space;

[0009] After the signature verification is passed, the original security policy file is uninstalled, and then the new security policy file is loaded into the Selinux kernel.

[0010] Optionally, the method further comprises:

[0011] Obtain the new security policy file from the remote server and store the new security policy file in the file system;

[0012] The acquiring of a new security policy file from the user space to the Selinux kernel space includes: acquiring a new security policy file from the file system to the Selinux kernel space.

[0013] Optionally, the method further comprises:

[0014] Get the updated security policy file;

[0015] Performing a signing operation on the updated security policy file in a local trusted environment to obtain the new security policy file, and storing the signed security policy file in the file system;

[0016] The acquiring of a new security policy file from the user space to the Selinux kernel space includes: acquiring a new security policy file from the file system to the Selinux kernel space.

[0017] Optionally, the performing a signing operation on the updated security policy file includes: performing a signing operation on the updated security policy file using a signature algorithm.

[0018] Optionally, the signature algorithm includes any one of the following: a message authentication code algorithm, an asymmetric algorithm.

[0019] Optionally, the binary data structure of the signed security policy file includes: a header data structure, security policy binary data, and a signature data structure; the header data structure includes auxiliary information; and the signature data structure includes key information.

[0020] Optionally, the method further comprises:

[0021] Generate a signed Selinux configuration file and / or a signed initial security policy file in a secure environment;

[0022] During the startup of the Selinux kernel, read and verify the signature of the Selinux configuration file, and after the verification is passed, load the Selinux configuration file; and / or

[0023] According to the configuration information of the Selinux configuration file, the initial security policy file is read and verified, and after the verification is passed, the initial security policy file is loaded.

[0024] On the other hand, an embodiment of the present invention further provides a device for ensuring the security of Selinux files, the device comprising: a signature verification module and a security service module arranged in the Selinux kernel space;

[0025] The signature verification module is used to obtain a new security policy file from the user space to the Selinux kernel space when the security policy file needs to be updated, and the new security policy file is a signed file; and perform signature verification on the new security policy file in the Selinux kernel space;

[0026] The security service module is used to unload the original security policy file after the signature verification module passes the signature verification, and then load the new security policy file into the Selinux kernel.

[0027] Optionally, the device further comprises:

[0028] A file storage module, used for acquiring the new security policy file from a remote server and storing the new security policy file in a file system;

[0029] The signature verification module obtains a new security policy file from the file system to the Selinux kernel space.

[0030] Optionally, the device further comprises:

[0031] A signature module is used to obtain an updated security policy file, perform a signature operation on the updated security policy file in a local trusted environment, obtain the new security policy file, and store the signed security policy file in the file system;

[0032] The signature verification module obtains a new security policy file from the file system to the Selinux kernel space.

[0033] Optionally, the device further comprises:

[0034] An initial file generation module, used to generate a signed Selinux configuration file and / or a signed initial security policy file in a secure environment;

[0035] The signature verification module is also used to read and verify the signature of the Selinux configuration file during the startup process of the Selinux kernel, and load the Selinux configuration file after the verification is passed; and / or read and verify the initial security policy file according to the configuration information of the Selinux configuration file, and load the initial security policy file after the verification is passed.

[0036] Optionally, the function of the signature verification module is implemented by any one of the following methods: software, software and an encryption and decryption coprocessor in a programmable system-on-chip, software and a programmable logic array.

[0037] On the other hand, an embodiment of the present invention further provides a computer-readable storage medium on which a computer program is stored. When the computer program is executed by a processor, the steps of the method for ensuring the security of Selinux files described above are executed.

[0038] On the other hand, an embodiment of the present invention further provides a terminal device, comprising a memory and a processor, wherein the memory stores a computer program that can be run on the processor, and is characterized in that the processor executes the steps of the method for ensuring the security of Selinux files when running the computer program.

[0039] The method and device for ensuring the security of Selinux files provided by the embodiment of the present invention, when the security policy file needs to be updated, obtains a new security policy file from the user space to the Selinux kernel space; performs signature verification on the new security policy file in the Selinux kernel space; after the signature verification passes, uninstalls the original security policy file, and then updates the security policy file, that is, loads the new security policy file into the Selinux kernel. By performing signature verification on the updated security policy file, attackers cannot modify the security policy file by using the root authority, thereby ensuring the security policy of Selinux.

[0040] Furthermore, by adding signature information to the Selinux configuration file and / or the initial security policy file, during the Selinux kernel startup process, by verifying the signature of the Selinux configuration file and / or the initial security policy file, it is ensured that the Selinux configuration file and / or the initial security policy file can be loaded in a trustworthy manner, effectively preventing attackers from bypassing the security protection at the kernel level of the operating system by modifying the Selinux configuration file or the security policy file, thereby ensuring the security of information in Selinux. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] Figure 1 This is a basic hardware architecture diagram of the existing PSOC operation;

[0042] Figure 2 It is a schematic diagram of the processing system structure of the existing PSOC;

[0043] Figure 3 This is the flowchart of the existing PSOC secure boot;

[0044] Figure 4 It is a schematic diagram of the operation process of a user-mode application on a SeLinux kernel space file in the prior art;

[0045] Figure 5 It is a schematic diagram of the core components of SeLinux in the prior art;

[0046] Figure 6 This is a flow chart of a method for ensuring Selinux file security provided by an embodiment of the present invention;

[0047] Figure 7 is a schematic diagram of a binary data structure of a signed security policy file in an embodiment of the present invention;

[0048] Figure 8 It is a flowchart of loading a Selinux configuration file and a security policy file when the Selinux kernel is started in an embodiment of the present invention;

[0049] Fig. 9 It is a schematic diagram of the process of loading Selinux configuration files and initial security policy files using the method of the present invention;

[0050] Fig.10 It is a schematic diagram of the process of loading the updated security policy in the Selinux kernel using the method of the present invention;

[0051] Fig.11 The present invention is a schematic diagram of a structure of a device for ensuring the security of Selinux files provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0052] The principle and spirit of the present invention will be described below with reference to the exemplary embodiments shown in the accompanying drawings. It should be understood that these embodiments are described only to enable those skilled in the art to better understand and implement the present invention, and are not intended to limit the scope of the present invention in any way.

[0053] Programmable SoC (PSOC) is a heterogeneous system-on-chip that integrates the software programmability of a CPU processor with the hardware programmability of an FPGA (Field-Programmable Gate Array). The basic hardware architecture of PSOC is as follows: Figure 1 shown.

[0054] Reference Figure 1 The PSOC chip has two relatively independent programmable areas, namely the processing system area and the programmable logic area. Among them, the processing system area mainly provides software programming capabilities, and the programmable logic area mainly provides hardware programming capabilities (the programmable logic area is the field-programmable gate array (FPGA), which needs to be programmed through a bitstream file). PSOC exchanges data with the off-chip double data rate synchronous dynamic random-access memory (DDR), non-volatile memory, and other peripherals through a communication interface. The boot program, FPGA bitstream file (bitstream) and operating system firmware are generally stored in an off-chip non-volatile memory (such as flash memory, secure digital (SD) card and other storage devices). When the chip is powered on, the boot program, FPGA bitstream file, and operating system will be loaded into the on-chip memory or DDR memory in turn. Generally, a small part of the boot program will be loaded into the on-chip memory (such as the first-level boot program), the bitstream file will generally be loaded into the programmable logic area, and the rest of the firmware (such as the second-level boot program, operating system kernel, root file system, user application resources, etc.) will be loaded into the DDR memory and then executed.

[0055] like Figure 2 As shown in the figure, the processing system of PSOC is mainly composed of application processor core (AP core), static random access memory (Static Random-Access Memory, SRAM), encryption coprocessor (Crypto Coprocessor), dynamic random access memory interface (DDR PYH), one-time programmable memory (eFuse), on-chip read-only memory and other communication and display interfaces (such as queued serial peripheral interface (Queued Serial Peripheral Interface, QSPI), high-definition multimedia interface (High Definition Multimedia Interface, HDMI), etc. The various components are connected through the system bus to complete data exchange.

[0056] The application processor core is responsible for code execution. After the PSOC is powered on, it will first execute the code on the read-only memory (ROM) and open up the corresponding stack space on the on-chip static random access memory (SRAM). The code in the ROM will complete the initialization of the peripheral interface and complete some security-related configuration and preparation work based on certain information bits in the eFuse, such as determining whether the current chip needs to execute the secure boot process. If it is currently in secure boot mode, the chip needs to complete the initialization of the encryption and decryption coprocessor and the key processing in the eFuse. Then the ROM code will read the first-level boot loader from the off-chip memory through the peripheral interface and verify whether the signature of the boot loader is legal. After the verification is passed, the corresponding operation will be performed according to whether the boot loader is encrypted. If it is encrypted, it is necessary to perform the decryption operation of the boot loader and then jump to the boot loader for execution. The signature verification process is generally implemented using an asymmetric cryptographic algorithm, such as RSA, elliptic curve cryptography, etc., that is, the signature information of the boot loader or other firmware is verified using the public key of the algorithm to prevent the execution of untrusted code. In order to ensure the credibility of the algorithm public key, the HASH summary value of the public key or the root public key is generally saved in the eFuse, and the legitimacy of the public key is verified before verification to prevent the threat of the public key being replaced.

[0057] Figure 3 The existing PSOC secure boot process is shown as follows:

[0058] 1. The code in the ROM first verifies the legitimacy of the public key in the eFuse, and uses the public key to verify the legitimacy of the first-level boot loader. If it is legitimate, the first-level boot loader is loaded and run;

[0059] 2. If the developer needs to configure a bitstream file to the programmable logic area, the first-level boot loader first needs to verify the legitimacy of the bitstream file, and if it is legitimate, load the bitstream file and configuration;

[0060] 3. After the bitstream file is loaded and configured, the legitimacy of the second-level boot loader is verified. If it is legal, the second-level boot loader is loaded and run;

[0061] 4. The second-level boot loader verifies the legitimacy of the Linux kernel program. If it is legitimate, it loads and runs the Linux kernel program;

[0062] 5. The Linux kernel program loads the image file and verifies it. After the verification passes, the application is loaded.

[0063] Through the above PSOC secure boot process, the credibility of the operating system kernel is guaranteed.

[0064] SeLinux is a specific implementation of Mandatory Access Control (MAC), which enhances the security of Linux systems. The characteristic of MAC mechanism is that the resource owner cannot decide who can access the resource. The specific decision on whether to access the resource is based on SeLinux policy, which is composed of a series of access rules.

[0065] A simple example is shown in Figure 4. If a user-mode application wants to operate (including reading, writing, and executing) a file in a directory, the process will access the resource file through the system call interface. At this time, the kernel-mode code will perform a series of checks on the legitimacy of the system call, such as error checks and DAC checks. The SeLinux kernel uses the Linux security module to hook the kernel's system call, that is, Figure 4 The LSM Hook in the process queries the SeLinux security policy based on the process execution context and resource context before execution, and decides whether to allow the operation on the file based on the security policy, that is, to allow or deny the operation.

[0066] The core components of SeLinux are Figure 5 As shown, the core component 50 mainly includes: a process (Subject) 51, a target object manager (Object Manager) 52, a security service (Security Server) 53, a security policy 54, and an access vector cache (Access Vector Cache) 55: wherein:

[0067] The appearance of process 51 can trigger the processing of a target object (such as reading a file);

[0068] The target object management 52 knows the operation request for a resource and can perform the operation;

[0069] Security service 53 will complete the confirmation of the legitimacy of the operation request according to the security policy;

[0070] Security policy 54 is a set of security rules written in SeLinux policy language;

[0071] The function of the access vector cache 55 is to cache some rules to improve system performance.

[0072] All of the above components exist in the SeLinux kernel space.

[0073] During the startup of the Linux kernel with SELinux enabled, the kernel needs to complete the relevant security configuration of Selinux by reading the configuration file saved in the file system, and then read the security policy file into the kernel based on the relevant configuration information, and complete the parsing of the security policy data structure.

[0074] Configuration files include global configuration files, policy configuration files, policy storage configuration files, Selinux kernel configuration files, etc. These configuration files are generally saved in the file system of the Linux operating system, such as / etc / selinux / targeted, / etc / selinux / mls, etc.

[0075] Security policy files generally refer to resource access policies written in the Selinux policy language. These files cannot be parsed directly by the kernel. They generally need to be preprocessed by the policy parsing, compilation, and compression modules to be converted into binary data before they can be loaded and parsed by the Selinux kernel (these binary data are also saved in the file system and loaded into the kernel space during kernel startup, and then used by the security service module). The storage location of the security policy file is determined by the configuration information in the configuration file.

[0076] When Selinux has completed initialization and started running smoothly, legitimate users can still update the rules in the Selinux kernel in real time by modifying the security policy file. The updated security policy file will also be parsed, compiled, and compressed by the preprocessing module to generate an updated binary policy data file. At this time, the Selinux kernel will first uninstall the original security policy, and then load the updated binary security policy file into the kernel to implement the security policy update.

[0077] Selinux configuration files and security policy files play an important role in the security mechanism of Selinux. However, if an attacker maliciously modifies the Selinux configuration files and security policy files stored on the file system, such as adding some new policies, some malicious processes can access resources that were previously inaccessible, thus causing information security issues. Malicious modification of configuration files can also cause information security issues, such as changing the Selinux enabled state in the configuration file to a disabled state.

[0078] To this end, the embodiment of the present invention provides a method and device for ensuring the security of Selinux files, adding a signature verification function module in the SeLinux kernel code framework to ensure that the files and data structures loaded by SeLinux have not been tampered with, thereby ensuring that the Selinux configuration files and security policy files are reliably loaded and updated.

[0079] like Figure 6 FIG. 1 is a flow chart of a method for ensuring Selinux file security provided by an embodiment of the present invention, comprising the following steps:

[0080] Step 601, when the security policy file needs to be updated, a new security policy file is obtained from the user space to the Selinux kernel space, and the new security policy file is a signed file.

[0081] After the Selinux kernel has completed startup and is running smoothly, legitimate users can still use the corresponding interface to update the security policy in the kernel. At this time, the updated security policy data file is required to be a correctly signed file. When the Selinux kernel receives an operation request to update the security policy, the signature verification module in the Selinux kernel can obtain the signed security policy file and verify its signature. It should be noted that the operation request to update the security policy is usually initiated by a user process, and the user process will trigger the Selinux kernel to execute the security policy update process.

[0082] In a non-limiting embodiment, the new security policy file can be a security policy file that has completed a signature operation on an updated security policy file on a remote server, that is, the signed security policy file can be directly obtained from the remote server and stored in the file system of the user space.

[0083] Accordingly, the Selinux kernel obtains a new security policy file from the file system to the Selinux kernel space.

[0084] In another non-limiting embodiment, a new security policy file may be generated locally on the target device. Specifically, an updated security policy file is obtained locally on the target device, and a signing operation is performed on the updated security policy file in a local trusted environment such as TEE (Trusted Execution Environment) or a security module to obtain the signed security policy file, and the signed security policy file is stored in the file system.

[0085] Accordingly, the Selinux kernel obtains a new security policy file from the file system to the Selinux kernel space. It should be noted that the signing environment needs to be a trusted environment. In addition, after completing the signing operation, the private key file and cached data on the device need to be cleared in time to prevent the leakage of private key information.

[0086] In specific applications, the updated security policy file can be signed using a signature algorithm. The signature algorithm may include, but is not limited to, any of the following: a message authentication code (MAC) algorithm such as CBC-MAC based on a symmetric encryption and decryption algorithm and HMAC based on a HASH operation, an asymmetric algorithm such as an RSA algorithm and an ECC (Elliptic Curves Cryptography, elliptic curve cryptography algorithm, etc.

[0087] The binary data structure of the signed security policy file is as follows: Figure 7 As shown, it includes: header data structure, security policy binary data, and signature data structure. Among them:

[0088] The header data structure includes auxiliary information, such as an indication of the signature mode, algorithm parameters, signature data position offset, security policy binary data length, etc.

[0089] The signature data structure includes key information, mainly including the public key information used for the signature, the master public key information, the public key parameters, the signature information, the summary value, the check value and other data.

[0090] Step 602: Perform signature verification on the new security policy file in the Selinux kernel space.

[0091] Specifically, the signature verification module of the kernel can verify the signature of the updated security policy data to verify its legitimacy. The verification process can perform corresponding verification operations according to the signature algorithm used, which is not limited in the embodiment of the present invention.

[0092] Step 603, after the signature verification is passed, the original security policy file is uninstalled, and then the new security policy file is loaded into the Selinux kernel.

[0093] It should be noted that after the security policy is updated, the data cached in the access vector cache (AVC) may be further cleared, and finally the loading and parsing of the new security policy data are completed.

[0094] Figure 6The method for ensuring the security of Selinux files in the illustrated embodiment is to read the signed security policy file from the file system of the user space when the security policy file needs to be updated; perform signature verification on the signed security policy file and obtain a new security policy; after the signature verification passes, uninstall the original security policy and then load the new security policy into the Selinux kernel. By performing signature verification on the updated security policy file, attackers cannot modify the security policy file by using root privileges, thereby ensuring the security policy of Selinux.

[0095] Considering that if an attacker maliciously modifies the SElinux configuration file and / or policy file stored on the file system in a malicious manner, it will also cause information security issues. For this reason, in another non-limiting embodiment of the method of the present invention, it may further include a signature verification process for the Selinux configuration file and / or the signed initial security policy file when the SELinux configuration is initialized and / or when the SELinux security policy is loaded.

[0096] like Figure 8 As shown, it is a flowchart of loading the Selinux configuration file and the security policy file when the Selinux kernel is started in an embodiment of the present invention, including the following steps:

[0097] Step 801, generating a signed Selinux configuration file and / or a signed initial security policy file in a secure environment;

[0098] The signature algorithm used when generating the signed Selinux configuration file and the signed initial security policy file can be selected as needed, and should be consistent with the signature algorithm used when the security policy file is updated.

[0099] Step 802, during the Selinux kernel startup process, read and verify the signature of the Selinux configuration file, and after the verification is passed, load the Selinux configuration file; and / or

[0100] Step 803: read and verify the initial security policy file according to the configuration information of the Selinux configuration file, and load the initial security policy file after the verification is passed.

[0101] The signature verification of Selinux configuration files and initial security policy files can also be completed by the signature verification module mentioned above. Since the signature verification module is part of the kernel program, the PSOC's secure boot process can well ensure the correctness and integrity of the signature verification module function, ensure that the execution logic will not be maliciously modified, and the signature verification process will not be maliciously bypassed.

[0102] It should be noted that, in actual applications, the signature verification module can be implemented in a variety of ways, such as: pure software implementation, or software combined with an encryption and decryption coprocessor implementation. If the signature verification algorithm is not supported by the encryption and decryption coprocessor, it can also be implemented through software code combined with the logic of the programmable logic area of ​​​​the PSOC, for example, by downloading the bitstream file of the signature verification algorithm module to the programmable logic area to achieve the signature verification function.

[0103] pass Figure 8 The process shown can ensure that the SELinux configuration file and the initial security policy file are loaded correctly.

[0104] In order to further clearly describe the present invention, Fig. 9 and Fig.10 The process of loading the Selinux configuration file and the initial security policy file in the Selinux kernel and updating the security policy file after the Selinux kernel is running are respectively shown.

[0105] Reference Fig. 9 During the startup of the Linux kernel with SeLinux enabled, the kernel reads the SeLinux configuration file stored in the file system through the libselinux API (an API that can be used by SeLinux applications to view or set the security context of processes and files and obtain security policy decisions). The signature verification module in the kernel verifies the signature. After the verification passes, the kernel completes the relevant security configuration of Selinux, and then reads the initial security policy file into the kernel based on the relevant configuration information. The signature verification module verifies the signature of the initial security policy file. After the verification passes, the security policy data is loaded.

[0106] SeLinux configuration files include global configuration files, policy configuration files, policy storage configuration files, SELinux kernel configuration files, etc. These configuration files are generally saved in the file system of the Linux operating system and are signed files.

[0107] Security policy files cannot be parsed directly by the kernel. They need to be preprocessed into binary data by the policy parsing, compilation, and compression modules before they can be loaded and parsed by the Selinux kernel (these binary data will be saved in the file system and loaded into the kernel space during the kernel startup process. The data in the binary file will then be parsed into some data structures in the kernel for subsequent use by the security service module). The storage location of the policy file is determined by the configuration information in the configuration file. Similarly, the initial policy file is also a signed file.

[0108] Through the above process, the legitimacy of the loaded SeLinux configuration file and the initial security policy file can be effectively guaranteed, thereby ensuring the security of the information in the SeLinux kernel.

[0109] Reference Fig.10 When Selinux completes initialization and starts running smoothly, legitimate users can still update the rules in the Selinux kernel in real time by modifying the policy file. The updated security policy file will also be parsed, compiled, and compressed by the preprocessing module to generate an updated binary policy data file. In the scheme of the present invention, it is required that the updated security policy data file is correctly signed data. The signed security policy data can be sent to the target device through remote update, or generated locally on the target device, which is not limited.

[0110] When the kernel receives an operation request to update the security policy, the kernel's signature verification module will first verify the signature of the updated security policy data to verify its legitimacy. If the verification is correct, it is necessary to unload the original security policy data in the kernel, load the updated binary policy file into the kernel, and clear the cached data in the AVC, thereby achieving the purpose of updating the security policy and effectively ensuring the legitimacy of the new security policy.

[0111] Accordingly, an embodiment of the present invention also provides a device for ensuring the security of Selinux files, such as Fig.11 Shown is a structural schematic diagram of the device.

[0112] The device 110 for ensuring the security of Selinux files includes: a signature verification module 111 and a security service module 112 arranged in the Selinux kernel space.

[0113] The signature verification module 111 is used to obtain a new security policy file from the user space to the Selinux kernel space when the security policy file needs to be updated, and the new security policy file is a signed file; and perform signature verification on the new security policy file in the Selinux kernel space;

[0114] The security service module 112 is used to unload the original security policy file after the signature verification module passes the signature verification, and then load the new security policy file into the Selinux kernel.

[0115] In a non-limiting embodiment, the device 110 may further include: a file storage module (not shown), configured to obtain the new security policy file from a remote server and store the new security policy file in the file system.

[0116] Accordingly, the signature verification module 111 may obtain a new security policy file from the file system to the Selinux kernel space.

[0117] In another non-limiting embodiment, the device 110 may also include: a signature module (not shown), used to obtain an updated security policy file, sign the updated security policy file in a local trusted environment to obtain the new security policy file, and store the new security policy file in the file system.

[0118] Accordingly, the signature verification module 111 may obtain a new security policy file from the file system to the Selinux kernel space.

[0119] In another non-limiting embodiment, the device 110 may further include: an initial file generation module (not shown) for generating a signed Selinux configuration file and / or a signed initial security policy file in a secure environment.

[0120] Accordingly, in this embodiment, the signature verification module 111 is also used to read and verify the signature of the Selinux configuration file during the Selinux kernel startup process, and load the Selinux configuration file after the verification is passed; and / or read and verify the initial security policy file according to the configuration information of the Selinux configuration file, and load the initial security policy file after the verification is passed.

[0121] In practical applications, the functions of the signature verification module 111 are implemented in any of the following ways: software, software and an encryption and decryption coprocessor in a programmable system-on-chip, software and a programmable logic array.

[0122] For other related descriptions about the above-mentioned device 110 for ensuring the security of Selinux files, reference may be made to the related descriptions in the aforementioned embodiments, which will not be repeated here.

[0123] In a specific implementation, each module / unit included in each device or product described in the above embodiments may be a software module / unit or a hardware module / unit, or may be partly a software module / unit and partly a hardware module / unit.

[0124] For example, for each device or product applied to or integrated in a chip, each module / unit contained therein may be implemented in the form of hardware such as circuits, or at least some of the modules / units may be implemented in the form of software programs, which run on a processor integrated inside the chip, and the remaining (if any) modules / units may be implemented in the form of hardware such as circuits; for each device or product applied to or integrated in a chip module, each module / unit contained therein may be implemented in the form of hardware such as circuits, and different modules / units may be located in the same component (such as a chip, circuit module, etc.) or different components of the chip module, or at least some of the modules / units may be implemented in the form of software programs. The element can be implemented in the form of a software program, which runs on a processor integrated inside the chip module, and the remaining (if any) modules / units can be implemented in the form of hardware such as circuits; for various devices and products applied to or integrated in the terminal, the various modules / units contained therein can be implemented in the form of hardware such as circuits, and different modules / units can be located in the same component (for example, chip, circuit module, etc.) or in different components in the terminal, or, at least some modules / units can be implemented in the form of a software program, which runs on a processor integrated inside the terminal, and the remaining (if any) modules / units can be implemented in the form of hardware such as circuits.

[0125] The embodiment of the present invention further discloses a storage medium, which is a computer-readable storage medium and stores a computer program. When the computer program is run, it can execute Figure 6 or Figure 8 The steps of the method shown in . The storage medium may include a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, etc. The storage medium may also include a non-volatile memory (non-volatile) or a non-transitory memory, etc.

[0126] The embodiment of the present invention further discloses a terminal device, including a memory and a processor, wherein the memory stores a computer program that can be run on the processor, and the processor executes a program when running the computer program. Figure 6 or Figure 8 The steps of the method shown in .

[0127] It should be understood that the term "and / or" in this article is only a description of the association relationship of the associated objects, indicating that there can be three relationships. For example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone. In addition, the character " / " in this article indicates that the associated objects before and after are in an "or" relationship.

[0128] The above embodiments may be implemented in whole or in part by software, hardware, firmware or any other combination thereof. When implemented using software, the above embodiments may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer programs are loaded or executed on a computer, the processes or functions described in the embodiments of the present application are generated in whole or in part. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions may be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium, for example, the computer instructions may be transmitted from one website site, computer, server or data center to another website site, computer, server or data center by wired or wireless means.

[0129] In the several embodiments provided by the present invention, it should be understood that the disclosed methods and devices can be implemented in other ways. For example, the device embodiments described above are only schematic; for example, the division of the units is only a logical function division, and there may be other division methods in actual implementation; for example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0130] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0131] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may be physically included separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of hardware plus software functional units.

[0132] The above-mentioned integrated unit implemented in the form of a software functional unit can be stored in a computer-readable storage medium. The above-mentioned software functional unit is stored in a storage medium, including a number of instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) to perform some steps of the method described in each embodiment of the present application.

[0133] Although the present invention is disclosed as above, the present invention is not limited thereto. Any person skilled in the art can make various changes and modifications without departing from the spirit and scope of the present invention. Therefore, the protection scope of the present invention shall be subject to the scope defined by the claims.

Claims

1. A method for ensuring the security of Selinux files, characterized in that: The method comprises: When the security policy file needs to be updated, a new security policy file is obtained from the user space to the Selinux kernel space, wherein the new security policy file is a signed file; Perform signature verification on the new security policy file in the Selinux kernel space; After the signature verification is passed, the original security policy file is uninstalled, and then the new security policy file is loaded into the Selinux kernel.

2. The method according to claim 1, characterized in that The method further comprises: Obtain the new security policy file from the remote server and store the new security policy file in the file system; The acquiring of a new security policy file from the user space to the Selinux kernel space includes: acquiring a new security policy file from the file system to the Selinux kernel space.

3. The method according to claim 1, characterized in that The method further comprises: Get the updated security policy file; Performing a signing operation on the updated security policy file in a local trusted environment to obtain the new security policy file, and storing the signed security policy file in the file system; The acquiring of a new security policy file from the user space to the Selinux kernel space includes: acquiring a new security policy file from the file system to the Selinux kernel space.

4. The method according to claim 3, characterized in that The signing operation on the updated security policy file includes: The updated security policy file is signed using a signature algorithm.

5. The method according to claim 4, characterized in that The signature algorithm includes any one of the following: a message authentication code algorithm, an asymmetric algorithm.

6. The method according to claim 2, characterized in that The binary data structure of the signed security policy file includes: a header data structure, security policy binary data, and a signature data structure; the header data structure includes auxiliary information; and the signature data structure includes key information.

7. The method according to any one of claims 1 to 6, characterized in that: The method further comprises: Generate a signed Selinux configuration file and / or a signed initial security policy file in a secure environment; During the startup of the Selinux kernel, read and verify the signature of the Selinux configuration file, and after the verification is passed, load the Selinux configuration file; and / or According to the configuration information of the Selinux configuration file, the initial security policy file is read and verified, and after the verification is passed, the initial security policy file is loaded.

8. A device for ensuring the security of Selinux files, characterized in that: The device comprises: a signature verification module and a security service module arranged in the Selinux kernel space; The signature verification module is used to obtain a new security policy file from the user space to the Selinux kernel space when the security policy file needs to be updated, and the new security policy file is a signed file; and perform signature verification on the new security policy file in the Selinux kernel space; The security service module is used to unload the original security policy file after the signature verification module passes the signature verification, and then load the new security policy file into the Selinux kernel.

9. The device according to claim 8, characterized in that The device also includes: A file storage module, used for acquiring the new security policy file from a remote server and storing the new security policy file in a file system; The signature verification module obtains a new security policy file from the file system to the Selinux kernel space.

10. The device according to claim 8, characterized in that The device also includes: A signature module is used to obtain an updated security policy file, perform a signature operation on the updated security policy file in a local trusted environment, obtain the new security policy file, and store the signed security policy file in the file system; The signature verification module obtains a new security policy file from the file system to the Selinux kernel space.

11. The device according to claim 8, characterized in that The device also includes: An initial file generation module, used to generate a signed Selinux configuration file and / or a signed initial security policy file in a secure environment; The signature verification module is also used to read and verify the signature of the Selinux configuration file during the startup process of the Selinux kernel, and load the Selinux configuration file after the verification is passed; and / or read and verify the initial security policy file according to the configuration information of the Selinux configuration file, and load the initial security policy file after the verification is passed.

12. The device according to any one of claims 8 to 11, characterized in that The function of the signature verification module is implemented by any one of the following methods: software, software and an encryption and decryption coprocessor in a programmable system-on-chip, software and a programmable logic array.

13. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method for ensuring the security of Selinux files as claimed in any one of claims 1 to 7 are executed.

14. A terminal device, comprising a memory and a processor, wherein the memory stores a computer program that can be run on the processor, characterized in that: When the processor runs the computer program, the processor executes the steps of the method for ensuring the security of Selinux files as described in any one of claims 1 to 7.

Images