Method and terminal for updating SELinux security policy

Abstract

The present application relates to the field of operating system technology, and in particular to a method and terminal for updating SELinux security policy. The embodiment of the present application discloses a method for updating SELinux security policy, comprising the following steps: a terminal receives a security policy file sent by a server. After receiving the security policy file, the terminal performs the following steps while remaining powered on: storing the security policy file in a preset storage space, reading the security policy file from the preset storage space and writing it into a memory, and the terminal loading the security policy file in the memory. The present application is applied in the process of updating system files at a terminal.

Description

Technical Field

[0001] The present application relates to the technical field of operating systems, and in particular to a method and a terminal for updating a SELinux security policy. Background Art

[0002] With the popularity of smart terminals such as smart phones, the security of smart terminals is becoming more and more important. The application of SELinux (Security-Enhanced Linux) technology in the existing operating system platform has greatly improved the security of the operating system. Taking the application of SELinux technology in the Android system as an example, SELinux technology formulates a security policy file, which specifies the access rights of different processes when accessing system resources, so that different processes have different access rights, ensuring that the process can smoothly perform its basic functions and prevent system resources from being maliciously used. Minimizing the access rights of each process while ensuring the function of each process can ensure the maximum security of the system. The permissions outside the normal business of the process are a security risk to the entire system. To modify the access rights of the process, the security policy file can only be modified and updated to the terminal. The existing update method is: modify the security policy file, recompile and generate a system upgrade patch package, and then push the generated system upgrade patch package to the smart terminal through the wireless software upgrade (Over-the-air programming, OTA) method, and then the smart terminal uses the system upgrade patch package to upgrade the system to update the security file. When updating the security policy file by upgrading the system, the smart terminal needs to be restarted, which will cause the current service to be interrupted. When the system upgrade patch package is large, the repair time is long. Summary of the invention

[0003] The present application discloses a method and terminal for updating SELinux security policy, which is invented to solve the problems in the prior art that when the security policy file is updated by system upgrade, the terminal restarts, causing the current service to be interrupted, and when the system upgrade patch package is large, the repair time is long.

[0004] In a first aspect, a method for updating SELinux security policy is provided, which is applied to a terminal, comprising: the terminal receives a security policy file sent by a server, and after receiving the security policy file, the terminal performs the following steps while remaining powered on: storing the security policy file to a preset storage space; reading the security policy file from the preset storage space and writing it into a memory; and loading the security policy file in the memory.

[0005] The above method provided by the embodiment of the present application can realize the update of the security policy file formulated by SELinux technology. By adopting the update method provided by the embodiment of the present application, the terminal does not need to be restarted, and the service currently running on the terminal will not be interrupted. In addition, after receiving the security policy file sent by the server, the terminal can automatically run the update method provided by the embodiment of the present application in the background, and since only the security policy file is updated, the process of refreshing the partition is omitted, and the update speed is fast. Therefore, the updated security policy file can take effect in a timely and rapid manner.

[0006] In one possible design, before the terminal reads the security policy file from the preset storage space and writes it into the memory, the method further includes: the terminal performing a security and / or integrity check on the security policy file stored in the preset storage space.

[0007] In a possible design, the terminal stores the security policy file to a preset storage space, including: the terminal stores the security policy file to a preset storage space through a first service or process. The terminal reads the security policy file from the preset storage space and writes it into the memory, including: the terminal modifies the value of the preset attribute value from a first value to a second value through the first service or process. When it is detected that the value of the preset attribute value changes from the first value to the second value, the terminal reads the security policy file from the preset storage space through a second service or process and writes it into the memory. The terminal loads the security policy file in the memory, including: the terminal loads the security policy file in the memory through the second service or process.

[0008] In a possible design of the first aspect, when the terminal is powered off and shut down, the value of the preset attribute value changes from the second value to the first value. When the terminal is restarted, the method also includes: in the kernel startup phase, the terminal changes the value of the preset attribute value from the first value to the second value so that the second service or process detects that the value of the preset attribute value is changed from the first value to the second value, and then reads the security policy file from the preset storage space and writes it into the memory.

[0009] In a possible design of the first aspect, the first service or process is an update_sepolicy service, the second service or process is an init process, and the preset attribute value is a SELinux.reload_policy attribute value.

[0010] In a possible design of the first aspect, the terminal stores the security policy file to a preset storage space; reads the security policy file from the preset storage space and writes it into a memory; and loads the security policy file in the memory, including: the terminal stores the security policy file to a preset storage space through a preset service or process; reads the security policy file from the preset storage space and writes it into a memory; and loads the security policy file in the memory.

[0011] In a possible design of the first aspect, the preset service or process is an init process.

[0012] In a possible design of the first aspect, the preset storage space is a preset writable partition of the terminal.

[0013] In a second aspect, a terminal is provided, comprising: a receiving unit, configured to receive a security policy file sent by a server; a processing unit, configured to write the security policy file into a first storage unit while the terminal remains powered on; the processing unit is further configured to read the security policy file from the first storage unit and write it into a second storage unit; wherein the second storage unit is a memory; and the processing unit is further configured to load the security policy file in the second storage unit.

[0014] In a possible design of the second aspect, the processing unit is further used to perform security and / or integrity verification on the security policy file stored in the first storage unit.

[0015] In a possible design of the second aspect, the processing unit is further configured to store the security policy file in the first storage unit through a first service or process; modify the value of the preset attribute value from the first value to the second value through the first service or process. When it is detected that the value of the preset attribute value changes from the first value to the second value, read the security policy file from the first storage unit and write it into the second storage unit through a second service or process; and load the security policy file in the second storage unit through the second service or process.

[0016] In a possible design of the second aspect, when the terminal is powered off and shut down, the value of the preset attribute value changes from the second value to the first value. Then, when the terminal is restarted, the processing unit is further used to: during the kernel startup phase, change the value of the preset attribute value from the first value to the second value so that after the second service or process detects that the value of the preset attribute value is changed from the first value to the second value, read the security policy file from the first storage unit and write it into the second storage unit.

[0017] In a possible design of the second aspect, the first service or process is an update_sepolicy service, the second service or process is an init process, and the preset attribute value is a SELinux.reload_policy attribute value.

[0018] In a possible design of the second aspect, the processing unit is also used to: store the security policy file to the first storage unit through a preset service or process; read the security policy file from the first storage unit and write it into the second storage unit; and load the security policy file in the second storage unit.

[0019] In a possible design of the second aspect, the preset service or process is an init process.

[0020] In a possible design of the second aspect, the first storage unit is a preset writable partition of the terminal.

[0021] According to a third aspect, a terminal is provided, comprising: a communication interface, a processor, a memory and a bus, the memory comprising a first memory and a second memory, the second memory being an internal memory; the memory stores program code, and when the program code is executed by the processor, the terminal performs the following steps: the communication interface is used to receive a security policy file sent by a server; the processor is used to write the security policy file to the first memory while keeping the computer powered on; the security policy file is read from the first memory and written to the second memory; and the security policy file in the second memory is loaded.

[0022] In a possible design of the third aspect, the processor is further used to perform security and / or integrity verification on the security policy file stored in the first memory.

[0023] In a possible design of the third aspect, the processor is also used to store the security policy file to the first memory through a first service or process; to modify the value of the preset attribute value from a first value to a second value through the first service or process; when it is detected that the value of the preset attribute value changes from the first value to the second value, to read the security policy file from the first memory and write it to the second memory through a second service or process; and to load the security policy file in the second memory through the second service or process.

[0024] In a possible design of the third aspect, when the terminal is powered off and shut down, the value of the preset attribute value changes from the second value to the first value. Then, when the terminal is restarted, the processor is further used to: during the kernel startup phase, change the value of the preset attribute value from the first value to the second value so that after the second service or process detects that the value of the preset attribute value is changed from the first value to the second value, read the security policy file from the first memory and write it into the second memory.

[0025] In a possible design of the third aspect, the first service or process is an update_sepolicy service, the second service or process is an init process, and the preset attribute value is a SELinux.reload_policy attribute value.

[0026] In a possible design of the third aspect, the processor is also used to: store the security policy file to the first memory through a preset service or process; read the security policy file from the first memory and write it to the second memory; and load the security policy file in the second memory.

[0027] In a possible design of the third aspect, the preset service or process is an init process.

[0028] In a possible design of the third aspect, the first memory is a preset writable partition of the terminal.

[0029] In a fourth aspect, a computer-readable storage medium is provided, wherein instructions are stored in the computer-readable storage medium. When the instructions are executed on a terminal, the terminal executes the method for updating the SELinux security policy described in the first aspect.

[0030] In a fifth aspect, a computer program product comprising instructions is provided, and when the computer program product is run on a terminal, the terminal executes the method for updating the SELinux security policy described in the first aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0031] Figure 1A A flowchart of a method for updating SELinux security policy in the prior art;

[0032] Figure 1B For application on terminal Figure 1A A schematic diagram of the interface of the method shown;

[0033] Figure 2 A schematic diagram of the structure of a mobile phone;

[0034] Figure 3A flowchart of a method for updating SELinux security policy provided in an embodiment of the present application;

[0035] Figure 4A A flowchart of another method for updating SELinux security policy provided in an embodiment of the present application;

[0036] Figure 4B A flowchart of another method for updating SELinux security policy provided in an embodiment of the present application;

[0037] Figure 5 For application on terminal Figure 3 or Figure 4A or Figure 4B The interface diagram of the method;

[0038] Figure 6 A schematic diagram of the structure of a terminal provided in an embodiment of the present application. DETAILED DESCRIPTION

[0039] SELinux technology has formulated many permission policies, so that the access subject has only the minimum access rights to the access object, thereby improving the security of the system. Among them, the access subject mainly refers to various processes and threads in the terminal. The access object mainly refers to various system resources used for communication, information sharing and storage in the terminal, such as files, sockets, storage space, directories, shared memory, etc. Taking a mobile phone as an example, the system resources in the mobile phone include system files stored in the mobile phone, the storage space of the mobile phone, and the storage directories of different storage spaces.

[0040] The permission policy defined by SELinux can be expressed in the following form: rule_name source_type target_type:object_class perm_set.

[0041] Among them, rule_name is used to indicate the type of the permission policy, which may be allow (allow) or prohibit (forbid). source_type indicates the access subject, which is generally the name of a process or thread; target_type:object_class indicates the access object, and perm_set indicates the operations that the access subject is allowed to perform on the access object (when rule_name is allow) or the operations that the access subject is prohibited to perform on the access object (when rule_name is prohibit). object_class may be file, indicating a normal file; or dir, representing a directory; or fd, indicating a file descriptor. When object_class is file, perm_set may be read (read), write (write), create (create) and other operations.

[0042] For example, a permission policy is: allow netd proc:file write. In this policy, allow means that the rule is an "allow rule", netd means that the access subject is the netd process, proc:file means that the access object is a common file in the proc directory, and write means that the executable operation defined by the rule for proc:file is write. Therefore, the meaning of this permission policy is to allow the netd process to access common files in the proc resource and perform write operations on them.

[0043] SELinux has three optional modes in specific applications: (1) disabled mode, which means that SELinux is completely ineffective. (2) permissive mode, which means that when a policy violation occurs, only logs are recorded and no prohibition is made. (3) enforcing mode, which means that when a policy violation occurs, logs are recorded and access is prohibited. Currently, SELinux will take full effect on Android L and later versions and the enforcing mode is turned on by default. In this mode, when an application violates the permission policy, it will not be able to obtain resources, which will cause some functions to become abnormal or invalid. When SELinux technology is applied to the Android platform, this SELinux technology can also be called SEAndroid.

[0044] When the access rights of an application are too large or too small, the above-mentioned permission policy formulated by SELinux needs to be modified. For example: the access rights set for application process A are to allow application process A to access or modify system resource 1, but the actual business of application process A does not need to access system resource 1 at all. If there is a vulnerability in application process A, then the above-mentioned permissions granted to application process A may cause system resource 1 to be tampered with, etc., resulting in security vulnerabilities in the terminal. In the above application scenario, the terminal needs to modify the permission policy formulated by SELinux, for example: modify the access rights of application process A to system resource 1, etc. At present, when mobile phones and other terminals leave the factory, security policy files and other files are generated into an image file and the image file is written to a read-only partition. When the security policy file needs to be modified, the system is usually upgraded by OTA upgrade (that is, the partition used to store security policy files is updated) to update the security policy file. OTA upgrade refers to the technology of upgrading the system or application by downloading the upgrade package on the remote server through the wireless network. It is currently Commonly used software upgrade methods for the system.

[0045] refer to Figure 1A The storage area of ​​the mobile phone 10 includes two parts: Double Data Rate (DDR) 101 and Embedded Multi Media Card (EMMC) / Universal Flash Storage (UFS) 102. Among them, DDR 101 is equivalent to the "memory" of the mobile phone, and EMMC / UFS 102 is equivalent to the "hard disk" of the mobile phone. Figure 1A exemplarily shows a partition of EMMC / UFS102, including Firstbootloader partition, Second bootloader partition, misc partition, boot partition, recovery partition, cache partition, modem partition, system partition, data partition, sdcard partition, etc.

[0046] Among them, the First bootloader partition, the Second bootloader partition and the boot partition store applications related to the mobile phone startup, which are used to start the mobile phone. Specifically, the First bootloader partition mainly performs hardware detection. After determining that the hardware can work normally, the files in the Second bootloader partition are copied to the DDR to start the startup operation. The Second bootloader partition will perform some hardware initialization, obtain the memory size, and then start from the content contained in the boot partition. The cache partition is generally used to store temporary caches generated by the mobile phone system. The misc partition is used to store some temporary files of the flag type, and the recovery partition generally writes a system software with a restore function, which can rewrite or clean up the existing system. The modem partition is used to store baseband-related files, such as files related to long-term evolution (LTE) communication of the mobile phone. The system partition is generally used to store system files. This partition is generally read-only by default, that is, the system files stored in this partition cannot be modified. The data partition is generally used to store user data, such as various Android installation packages (Android Package, APK) data. The sdcard partition is used to mount a secure digital memory card (Secure Digital Memory Card, SD). When the phone is turned on, the data stored in EMMC / UFS102 will be loaded into DDR101.

[0047] It should be noted that the above partition division is only an exemplary division. In actual applications, there may be other division forms, which may include more or fewer partitions.

[0048] also, Figure 1A In the example, the storage space of the mobile phone includes DDR and EMMC / UFS. In other implementations, the storage space of the mobile phone may also include: static random access memory (SRAM) storage area, Nand / Nor Flash storage area, synchronous dynamic random access memory (SDRAM) storage area and peripheral address space. Among them, the SRAM storage area is equivalent to the "memory" of the mobile phone, and the Nand / Nor Flash storage area is the "hard disk" of the mobile phone. All system data of the mobile phone is stored in Nand / Nor Flash, and Nand / Nor Flash can be divided into the above partitions.

[0049] Take the partition storing the security policy file as the boot partition as an example. Figure 1A The current OTA upgrade method is as follows: the server 20 recompiles and creates an upgrade package, such as an OTA differential package, and then sends the upgrade package to the mobile phone 10. After receiving the upgrade package, the mobile phone 10 first downloads it to the local (which can be understood as writing it to the storage space of the mobile phone, such as writing it to a writable partition, which is generally the DATA partition for Android). After the user agrees to the upgrade, it needs to be refreshed from the writable partition to the boot partition. The process of refreshing the boot partition requires Restart and start The system software stored in the recovery partition enters the recovery mode (also known as the upgrade mode) for execution. The working modes of the mobile phone 10 include the normal mode and the recovery mode. The recovery mode is different from the normal startup mode of the mobile phone 10. The mobile phone 10 needs to be restarted to enter the recovery mode. After refreshing the boot partition, the content in the boot partition will only be loaded into the memory when the mobile phone 10 is turned on. Therefore, the mobile phone needs to be restarted again to reload the content in the refreshed boot partition. At this point, the updated security policy file takes effect.

[0050] refer to Figure 1B From the user's visible perspective, the upgrade process after the mobile phone 10 receives the updated upgrade package includes: the mobile phone displays an interface (1), and the interface (1) displays a prompt message prompting the user to upgrade. When the mobile phone detects that the user confirms the upgrade operation 110, the mobile phone restarts to enter the recovery mode, and the mobile phone displays an interface (2). The interface (2) displays a progress indicator, such as presenting the upgrade progress in the form of a progress bar 120. This process is essentially a process of refreshing the boot partition. When the upgrade is completed, the mobile phone displays an interface (3). The interface (3) displays a prompt message that the upgrade is complete, and prompts the user to restart. When the user is detected to perform a restart operation 130, the mobile phone restarts again to load the refreshed boot partition and displays the power-on interface shown in interface (4).

[0051] It can be seen that when the current OTA upgrade method is used to update the security policy file, the mobile phone needs to be restarted twice. This method will cause the current service to be interrupted, and when the system upgrade patch package is large, the repair time is long, and there is even a risk of repair failure that the phone cannot be started normally when the upgrade fails.

[0052] In order to solve the above problems, the embodiments of the present application provide a method for updating SELinux security policy, which can be applied to any terminal with an operating system that applies SELinux technology, such as mobile phones, wearable devices, augmented reality (AR) and virtual reality (VR) devices, tablet computers, personal digital assistants (PDA), and vehicle-mounted terminals. Of course, in the following embodiments, there is no restriction on the specific form of the terminal.

[0053] Take the terminal as a mobile phone as an example. Figure 2 As shown, the terminal 200 includes: a communication interface 210, a memory 220, an input unit 230, one or more sensors 240, a processor 250, a power supply 260, a display unit 270, an audio circuit 280 and other components. Those skilled in the art will understand that Figure 2 The terminal structure shown in the figure does not constitute a limitation on the terminal, and may include more or less components than shown in the figure, or combine certain components, or arrange the components differently.

[0054] The functional components of the terminal 200 are introduced below:

[0055] Among them, the communication interface 210 is used for the terminal 200 to communicate with other devices. The communication interface 210 can be specifically implemented as a radio frequency (RF) circuit, which is used for receiving and sending signals during information transmission or calls. In particular, after receiving the downlink information of the base station, it is processed by the processor 250; in addition, the uplink data is sent to the base station. Usually, the RF circuit is not limited to an antenna, at least one amplifier, a transceiver, a coupler, a low noise amplifier (LNA), a duplexer, etc. In addition, the RF circuit can also communicate with the network and other devices through wireless communication. The wireless communication can use any communication standard or protocol, including but not limited to the global system of mobile communication (GSM), general packet radio service (GPRS), code division multiple access (CDMA), wideband code division multiple access (WCDMA), long term evolution (LTE), email, short messaging service (SMS), etc.

[0056] The memory 220 can be used to store software programs and modules. The processor 250 executes various functional applications and data processing of the terminal 200 by running the software programs and modules stored in the memory 220. The memory 220 may mainly include a program storage area and a data storage area, wherein the program storage area may store an operating system, an application program (Application, APP) required for at least one function, such as a sound playback function, an image playback function, etc.; the data storage area may store data created according to the use of the terminal 200 (such as audio data, image data, phone book, etc.). Of course, the memory may also include a first memory and a second memory, wherein the first memory is the "external memory" of the terminal, for example Figure 1A The EMMC / UFS shown in the figure, the second memory is the "memory" of the memory, for example Figure 1A In addition, the memory 220 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, or other volatile solid-state storage devices.

[0057] The input unit 230 can be used to receive digital or character information input by the user, and to generate key signal input related to the user settings and function control of the terminal 200. Specifically, the input unit 230 may include a touch screen 231 and other input devices 232. The touch screen 231, also known as a touch panel, can collect the user's touch operation on or near it (such as the user's operation on or near the touch screen 231 using any suitable object or accessory such as a finger, a stylus, etc.), and drive the corresponding connection device according to a pre-set program. Optionally, the touch screen 231 may include two parts: a touch detection device and a touch controller. Among them, the touch detection device detects the user's touch orientation, detects the signal brought by the touch operation, and transmits the signal to the touch controller; the touch controller receives the touch information from the touch detection device, converts it into the touch point coordinates, and then sends it to the processor 250, and can receive and execute the command sent by the processor 250. In addition, the touch screen 231 can be implemented in various types such as resistive, capacitive, infrared, and surface acoustic waves. In addition to the touch screen 231, the input unit 230 may also include other input devices 232. Specifically, other input devices 232 may include, but are not limited to, one or more of a physical keyboard, function keys (such as a volume control button, a power switch button, etc.), a trackball, a mouse, a joystick, and the like.

[0058] The sensor 240 includes a sensor for biometric identification, such as a fingerprint identification sensor, a face identification sensor, and an iris identification sensor. Taking the fingerprint identification sensor as an example, the fingerprint identification sensor can collect the fingerprint information of the user and report the collected fingerprint information to the processor 250, and the processor 250 identifies the user according to the fingerprint information.

[0059] Sensor 240 also includes a gravity sensor, which can detect the magnitude of the acceleration of the mobile phone in various directions (generally three axes), and can detect the magnitude and direction of gravity when stationary. It can be used for applications that identify the posture of the mobile phone (such as switching between horizontal and vertical screens, related games, magnetometer posture calibration), vibration recognition related functions (such as pedometer, tapping), etc.

[0060] The terminal 200 may also include other sensors, such as a light sensor. Specifically, the light sensor may include an ambient light sensor and a proximity light sensor. Among them, the ambient light sensor can adjust the brightness of the display panel 231 according to the brightness of the ambient light; the proximity light sensor can detect whether there is an object approaching or touching the mobile phone, and can turn off the display panel 231 and / or the backlight when the terminal 200 is moved to the ear. The terminal 200 may also be configured with other sensors such as a gyroscope, a barometer, a hygrometer, a thermometer, an infrared sensor, etc., which will not be repeated here.

[0061] The display unit 270 may be used to display information input by the user or information provided to the user and various menus of the terminal 200. The display unit 270 may include a display panel 271. Optionally, the display panel 271 may be configured in the form of a liquid crystal display (LCD), an organic light-emitting diode (OLED), etc. Further, the touch screen 231 may cover the display panel 271. When the touch screen 231 detects a touch operation on or near it, it is transmitted to the processor 250 to determine the type of touch event. Subsequently, the processor 250 provides a corresponding visual output on the display panel 271 according to the type of touch event. Although in Figure 2 In the embodiment, the touch screen 231 and the display panel 271 are used as two independent components to implement the input and output functions of the terminal 200, but in some embodiments, the touch screen 231 and the display panel 271 can be integrated to implement the input and output functions of the terminal 200.

[0062] The audio circuit 280, the speaker 281, and the microphone 282 can provide an audio interface between the user and the terminal 200. The audio circuit 280 can transmit the received audio data to the speaker 281 after converting the received audio data into an electrical signal, which is converted into a sound signal for output by the speaker 281; on the other hand, the microphone 282 converts the collected sound signal into an electrical signal, which is received by the audio circuit 280 and converted into audio data, and then the audio data is output to the RF circuit 210 to be sent to, for example, another mobile phone, or the audio data is output to the memory 220 for further processing.

[0063] The processor 250 is the control center of the terminal 200. It uses various interfaces and lines to connect various parts of the entire mobile phone. By running or executing software programs and / or modules stored in the memory 220, and calling data stored in the memory 220, it executes various functions of the terminal 200 and processes data, thereby monitoring the mobile phone as a whole. Optionally, the processor 250 may include one or more processing units; optionally, the processor 250 may integrate an application processor and a modem processor, wherein the application processor mainly processes the operating system, user interface and application programs, etc., and the modem processor mainly processes wireless communications. It is understandable that the above-mentioned modem processor may not be integrated into the processor 250.

[0064] The terminal 200 also includes a power supply 260 (such as a battery) for supplying power to various components. Optionally, the power supply can be logically connected to the processor 250 through a power management system, thereby implementing functions such as charging, discharging, and power consumption management through the power management system.

[0065] Although not shown, the terminal 200 may further include an antenna, a Wireless-Fidelity (WiFi) module, a Near Field Communication (NFC) module, a Bluetooth module, a speaker, an accelerometer, a gyroscope, and the like.

[0066] The following methods provided in the embodiments of the present application can be applied to Figure 2 Various terminals including mobile phones shown.

[0067] refer to Figure 3 The present application embodiment provides a method for updating a SELinux security policy, comprising the following steps:

[0068] 301. The terminal receives a security policy file sent by the server.

[0069] The security policy file is a common file. It can be seen that compared with the prior art in which the server pushes the image file containing the security policy file to the terminal, in the embodiment of the present application, the server only needs to push the security policy file to the terminal. The server side does not need to generate an upgrade package such as an OTA differential package.

[0070] 302. The terminal stores the security policy file in a preset storage space while the terminal remains powered on.

[0071] The preset storage space is a storage space in the terminal other than the memory. Optionally, a writable partition of the terminal, for example, Figure 1A The Data partition in .

[0072] This process can be regarded as the process of the terminal downloading the security policy file.

[0073] 303. The terminal performs a validity and integrity check on the security policy file stored in the preset storage space.

[0074] In one implementation, the server generates a digital signature to encrypt the security policy file, and pushes the encrypted security policy file to the terminal. The terminal verifies the digital signature of the security policy file to implement security and / or integrity verification. The specific implementation of security and / or integrity verification of files can refer to the prior art and will not be repeated here.

[0075] It should be noted that step 303 is an optional step, and the terminal may directly execute step 304 after executing step 302.

[0076] 304. The terminal reads the security policy file from the preset storage space and writes it into a memory.

[0077] The memory is a storage space for temporarily storing data in the terminal, that is, a storage space for cached data in the terminal, for example: Figure 1A The DDR101 described in . It can also be a synchronous dynamic random access memory (Synchronous Dynamic Random Access Memory, SDRAM) and the like.

[0078] 305. The terminal loads the security policy file in the memory.

[0079] It should be noted that while the terminal supports the method for updating the SELinux security policy shown in steps 301 to 305 provided in the embodiment of the present application, it is still compatible with the existing method of updating the security policy file using OTA upgrade. In practical applications, the method provided in the embodiment of the present application is mainly used in the scenario of updating the security policy file formulated by SELinux technology. The method of updating using OTA upgrade can be used for all types of updates and is a universal update method.

[0080] The above method provided by the embodiment of the present application can realize the update of the security policy file formulated by SELinux technology. By adopting the update method provided by the embodiment of the present application, the terminal does not need to be restarted, and the service currently running on the terminal will not be interrupted. In addition, after receiving the security policy file sent by the server, the terminal can automatically run the update method provided by the embodiment of the present application in the background, and since only the security policy file is updated, the process of refreshing the partition is omitted, and the update speed is fast. Therefore, the updated security policy file can take effect in a timely and rapid manner.

[0081] refer to Figure 4A In one implementation, the above steps 302 to 305 can be completed by the interaction of terminal-specific services or processes, wherein one process or service is used to download the updated security policy file, and another process or service is used to load the downloaded security policy file. For example, it can be completed by the interaction of the update_sepolicy service and the init process.

[0082] The specific implementation of the above process by the interaction between the update_sepolicy service and the init process includes the following steps:

[0083] 401. The update_sepolicy service stores the security policy file in a preset directory of a preset writable partition of the terminal.

[0084] For example, the default writable partition is the data partition, and the default directory can be a directory under the data partition, such as / data / security / sepolicy.bin.

[0085] This step 401 can be regarded as a process in which the update_sepolicy service downloads a security policy file.

[0086] 402. The update_sepolicy service performs security and integrity verification on the security policy file.

[0087] The update_sepolicy service is a newly created service in the embodiment of the present application, which is used to download the security policy file to be updated from the remote server and perform integrity verification.

[0088] Of course, in order to support the update_sepolicy service to execute step 402, the update_sepolicy service needs to have read and write permissions on the directory storing the security policy file. For example, if the security policy file is stored in the / data / security / sepolicy.bin directory, the update_sepolicy service needs to have read and write permissions on the files in the directory.

[0089] Therefore, a prerequisite for the update_sepolicy service in the embodiment of the present application is that the write permission to the directory / data / security / for this service is configured when the terminal leaves the factory.

[0090] The specific implementation of security and integrity verification of the security policy file can refer to the existing technology and will not be repeated here.

[0091] After the verification is passed, the following step 403 is executed.

[0092] 403. The update_sepolicy service sets the attribute value SELinux.reload_policy to 1.

[0093] The SELinux.reload_policy attribute value is used to trigger the init process to reload the security policy file. The initial value of this attribute value is 0. After the update_sepolicy service verifies the security verification policy file, it will set this attribute value to 1. When the init process monitors that the attribute value is set to 1, the init process will try to reload the security policy file. For details, please refer to step 404.

[0094] Optionally, the update_sepolicy service may also set other customized attribute values. When the attribute value is a preset value, the init process is also triggered to execute the following step 404.

[0095] 404. The init process reads the security policy file from the preset directory of the preset writable partition, writes the security policy file into the memory, and then loads the security policy file.

[0096] Optionally, when executing step 404, the init process may perform security and integrity verification on the security policy file again, and then load the security policy file after the verification passes.

[0097] The init process is an existing process and the first user-mode process of the system, which is used to load other subsequent system processes. Its specific implementation can refer to the existing technology and will not be repeated here.

[0098] Of course, in order to support the init process to execute step 404, the improvement of the init process in the embodiment of the present application is: modifying the loading policy file of the init process to the path specified by the embodiment of the present application for storing the security policy file, such as / data / security / sepolicy.bin.

[0099] It can be seen that in Figure 4A In the implementation shown, the download, security and integrity check of the security policy file are performed by the update_sepolicy service. The loading of the security policy file is completed by the init process, and the init process performs a secondary check on the file.

[0100] Considering that after the terminal is restarted, the security policy file in the image file in the read-only partition (such as the boot partition) will be loaded by default according to the existing process at startup, when the phone is turned on again, after the kernel starts the init.rc script, the attribute value SELinux.reload_policy attribute value must be set to 1 in the post-fs-dat stage to trigger the init process to re-read the security policy file located in the preset directory of the preset writable partition to load the security policy file, thereby overwriting the security policy file read from the boot partition.

[0101] refer to Figure 4B In another implementation, the above steps 302 to 305 may be completed by a specific service or process of the terminal, such as the update_sepolicy service.

[0102] The specific implementation of the process shown in steps 302 to 305 by the update_sepolicy service includes the following steps:

[0103] 410. The update_sepolicy service stores the security policy file in a preset directory of a preset writable partition of the terminal.

[0104] 420. The update_sepolicy service performs security and integrity verification on the security policy file.

[0105] The specific implementation of step 410 and step 420 may refer to the aforementioned step 401 and step 402, which will not be described in detail here.

[0106] After the verification is passed, the update_sepolicy service executes the following step 430.

[0107] 430. After verification, the update_sepolicy service reads the security policy file from the preset directory of the preset writable partition, writes it into the memory, and then loads the security policy file.

[0108] exist Figure 4B In the implementation shown, the downloading of the security policy file, the security and integrity verification, and the loading of the downloaded security policy file are all performed by the update_sepolicy service, so there is no need to set the attribute value of SELinux.reload_policy.

[0109] Considering that the image file in the read-only partition will be loaded when the terminal restarts, the image file also contains the security policy file. Figure 4B The method shown modifies the policy for loading the security policy file at startup so that the update_sepolicy service directly reads and loads the security policy file located in the preset writable partition.

[0110] In addition, in one implementation, the above method provided in the embodiment of the present application automatically runs in the background without the user's awareness. Figure 5 As shown in interface (1), when a user is chatting with the WeChat application, after receiving the updated security policy file sent by the server, A prompt box 502 is displayed floating on the interface 501, and the interface 502 displays a prompt message to remind the user that there is currently an updateable security file on the mobile phone. When the mobile phone detects that the user confirms the update operation 503, the mobile phone background executes the method provided in the embodiment of the present application to update the security policy file, and the mobile phone displays the interface (2). The update progress of the security file is displayed with a reduced progress bar 504 in the upper right corner of the interface (2). When the update is completed, as shown in the interface (3), a prompt box 505 pops up on the WeChat interface 501 to remind the user that the security policy file has been updated. Of course, ringing, vibration, voice and other methods can also be used to remind the user that the update is complete. When the confirmation operation 506 performed by the user is detected, the mobile phone only displays Figure 5 The WeChat interface 501 is shown in (4).

[0111] It is understandable that the terminal described in the present application includes hardware structures and / or software modules corresponding to the execution of each function in order to realize the above functions. Those skilled in the art should easily realize that, in combination with the units and algorithm steps of each example described in the embodiments disclosed in the present application, the present application can be implemented in the form of hardware or a combination of hardware and computer software. Whether a function is executed in the form of hardware or computer software driving hardware depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of the present application.

[0112] The embodiment of the present application can divide the functional modules of the terminal according to the above method example. For example, each functional module can be divided according to each function, or two or more functions can be integrated into one processing module. The above integrated module can be implemented in the form of hardware or in the form of software functional modules. It should be noted that the division of modules in the embodiment of the present application is schematic and is only a logical function division. There may be other division methods in actual implementation.

[0113] refer to Figure 6 The embodiment of the present application discloses a terminal 600, including: a receiving unit 601, a processing unit 602, and a storage unit 603, wherein the storage unit 603 specifically includes a first storage unit 6031 and a second storage unit 6032.

[0114] The receiving unit 601 is used to receive a security policy file sent by a server. The processing unit 602 is used to write the security policy file into the first storage unit 6031 while the computer is powered on. The processing unit 602 is also used to read the security policy file from the first storage unit 6031 and write it into the second storage unit 6032. The processing unit 602 is also used to load the security policy file in the second storage unit 6032.

[0115] Optionally, the processing unit 602 is further configured to perform security and / or integrity verification on the security policy file stored in the first storage unit 6031 .

[0116] Optionally, the processing unit 602 is also used to store the security policy file to the first storage unit 6031 through a first service or process; to modify the value of a preset attribute value from a first value to a second value through the first service or process; when it is detected that the value of the preset attribute value changes from the first value to the second value, to read the security policy file from the first storage unit 6031 and write it to the second storage unit 6032 through a second service or process; and to load the security policy file in the second storage unit 6032 through the second service or process.

[0117] Optionally, when the terminal is powered off and shut down, the value of the preset attribute value changes from the second value to the first value. Then when the terminal is restarted, the processing unit 602 is also used to: during the kernel startup phase, change the value of the preset attribute value from the first value to the second value so that the second service or process detects that the value of the preset attribute value is changed from the first value to the second value, and then reads the security policy file from the first storage unit 6031 and writes it into the second storage unit 6032.

[0118] Optionally, the first service or process is an update_sepolicy service, the second service or process is an init process, and the preset attribute value is a SELinux.reload_policy attribute value.

[0119] Optionally, the processing unit 602 is also used to: store the security policy file to the first storage unit 6031 through a preset service or process; read the security policy file from the first storage unit 6031 and write it to the second storage unit 6032; and load the security policy file in the second storage unit 6032.

[0120] Optionally, the preset service or process is an init process. The first storage unit 6031 is a preset writable partition of the terminal.

[0121] The receiving unit 601 may be composed of Figure 2 The processing unit 602 may be implemented by the communication interface 210 of the terminal 200. Figure 2 The storage unit 603 may be implemented by the processor 250 of the terminal 200. Figure 2 The memory 220 of the terminal 200 is shown implemented.

[0122] The above-mentioned terminal provided by the embodiment of the present application can realize the update of the security policy file formulated by SELinux technology. By adopting the update method provided by the embodiment of the present application, the terminal does not need to be restarted, and the service currently running on the terminal will not be interrupted. In addition, after receiving the security policy file sent by the server, the terminal can automatically run the update method provided by the embodiment of the present application in the background, and since only the security policy file is updated, the process of refreshing the partition is omitted, and the update speed is fast. Therefore, the updated security policy file can take effect in a timely and rapid manner.

[0123] An embodiment of the present application further provides a computer-readable storage medium, in which instructions are stored. When the instructions are executed on a terminal, the terminal executes the methods described in the above method embodiments.

[0124] An embodiment of the present application further provides a computer program product comprising instructions, and when the computer program product is run on a terminal, the terminal executes the methods described in the above method embodiments.

[0125] The steps of the method or algorithm described in conjunction with the disclosure of the present application can be implemented in a hardware manner, or can be implemented by a processor executing software instructions. The software instructions can be composed of corresponding software modules, and the software modules can be stored in a random access memory (Random Access Memory, RAM), a flash memory, a read-only memory (ReadOnly Memory, ROM), an erasable programmable read-only memory (Erasable Programmable ROM, EPROM), an electrically erasable programmable read-only memory (Electrically EPROM, EEPROM), a register, a hard disk, a mobile hard disk, a read-only compact disk (CD-ROM) or any other form of storage medium known in the art. An exemplary storage medium is coupled to a processor so that the processor can read information from the storage medium and can write information to the storage medium. Of course, the storage medium can also be a component of the processor. The processor and the storage medium can be located in an ASIC.

[0126] Those skilled in the art should be aware that in one or more of the above examples, the functions described in this application can be implemented using hardware, software, firmware, or any combination thereof. When implemented using software, these functions can be stored in a computer-readable medium or transmitted as one or more instructions or codes on a computer-readable medium. Computer-readable media include computer storage media and communication media, wherein communication media include any media that facilitates the transmission of a computer program from one place to another. The storage medium can be any available medium that a general or special-purpose computer can access.

[0127] The specific implementation methods described above further illustrate the purpose, technical solutions and beneficial effects of the present application in detail. It should be understood that the above description is only the specific implementation methods of the present application and is not intended to limit the scope of protection of the present application. Any modifications, equivalent substitutions, improvements, etc. made on the basis of the technical solutions of the present application should be included in the scope of protection of the present application.

Claims

1. A method for updating SELinux security policy, characterized in that: Applied to terminals, including: The terminal receives a security policy file sent by the server; After receiving the security policy file, the terminal performs the following steps while remaining powered on: The terminal stores the security policy file in a preset storage space; The terminal modifies the value of the preset attribute value from the first value to the second value; When it is detected that the value of the preset attribute value changes from the first value to the second value, the terminal reads the security policy file from the preset storage space and writes it into the memory through a second service or process; The terminal loads the security policy file in the memory through a second service or process.

2. The method according to claim 1, characterized in that Before the terminal reads the security policy file from the preset storage space and writes it into the memory, the method further includes: The terminal performs a security and / or integrity check on the security policy file stored in the preset storage space.

3. The method according to claim 1 or 2, characterized in that: The terminal storing the security policy file in a preset storage space includes: the terminal storing the security policy file in the preset storage space through a first service or process; The terminal modifies the value of the preset attribute value from the first value to the second value, including: the terminal modifies the value of the preset attribute value from the first value to the second value through the first service or process.

4. The method according to claim 3, characterized in that When the terminal is powered off and shut down, the value of the preset attribute value changes from the second value to the first value, and when the terminal is restarted, the method further includes: During the kernel startup phase, the terminal modifies the value of the preset attribute value from a first value to a second value so that the second service or process detects that the value of the preset attribute value is modified from the first value to the second value, and then reads the security policy file from the preset storage space and writes it into the memory.

5. The method according to claim 3, characterized in that: The first service or process is an update_sepolicy service, the second service or process is an init process, and the preset attribute value is a SELinux.reload_policy attribute value.

6. The method according to claim 1 or 2, characterized in that: The terminal stores the security policy file in a preset storage space, including: The terminal stores the security policy file in a preset storage space through a preset service or process.

7. The method according to claim 6, characterized in that The preset service or process is the init process.

8. The method according to claim 1 or 2, characterized in that: The preset storage space is a preset writable partition of the terminal.

9. An electronic device, characterized in that: The electronic device includes a memory and one or more processors; the memory and the processor are coupled; the memory is used to store computer program code, and the computer program code includes computer instructions. When the processor executes the computer instructions, the one or more processors execute the method described in any one of claims 1-8.

10. A computer-readable storage medium, wherein instructions are stored in the computer-readable storage medium, characterized in that: When the instruction is executed on a terminal, the terminal is caused to execute the method for updating SELinux security policy according to any one of claims 1 to 8.

Images