SELinux security policy test method, electronic equipment, storage medium and product

Abstract

The invention relates to an SELinux security policy test method, electronic equipment, a storage medium and a product, and relates to the technical field of information security. According to the specific implementation scheme, in response to abnormal program operation, at least one access rejection log generated by SELinux on the basis of at least one access request of a program within the time period of abnormal program operation is obtained; activating the temporary SELinux, so that a temporary security policy in the temporary SELinux is updated for M times based on the at least one access denial log; testing the program after each update so as to enable the SELinux and the temporary SELinux to jointly process the access request of the program, and determining the running state of the program; and obtaining M groups of mapping relationships based on the mapping relationship between the temporary security policy updated each time and the operation state. The problem of abnormal program operation caused by auxiliary positioning can be solved, the technical threshold of debugging the Linux security policy by developers is reduced, and the time consumed for testing and verifying the problem is saved.

Description

Technical Field

[0001] The present disclosure relates to the field of information security technology, and in particular to a SELinux security policy testing method, electronic device, storage medium and product. Background Art

[0002] The traditional Linux operating system permission access control is the DAC (Discretionary Access Control) mode, which is to perform access control through users and groups. Security-Enhanced Linux (SELinux) is a security subsystem of Linux and belongs to the MAC (Mandatory Access Control) mode. Its core idea is to use policy configuration to control system resources such as processes and files in a more fine-grained manner than DAC, and the security level is also higher. Summary of the invention

[0003] In a first aspect, an embodiment of the present disclosure provides a method for testing a SELinux security policy, comprising: in response to a program running abnormality, obtaining at least one access denial log generated by SELinux based on at least one access request of the program during a period of program running abnormality;

[0004] Activate temporary SELinux so that a temporary security policy in the temporary SELinux is updated M times based on at least one access denial log, where M is an integer greater than 1;

[0005] Test the program after each update to allow SELinux and temporary SELinux to jointly process the program's access requests and determine the program's operating status;

[0006] Based on the mapping relationship between the temporary security policy and the running state after each update, M groups of mapping relationships are obtained, wherein at least one group of mapping relationships with a normal running state in the M groups of mapping relationships is used to reconfigure the security policy in SELinux.

[0007] In a second aspect, an embodiment of the present disclosure provides an electronic device, including a memory, a processor, and a computer program stored in the memory, wherein the processor implements any method of the embodiments of the present disclosure when executing the computer program.

[0008] In a third aspect, an embodiment of the present disclosure provides a computer-readable storage medium, in which a computer program is stored. When the computer program is executed by a processor, the method of any one of the embodiments of the present disclosure is implemented.

[0009] In a fourth aspect, an embodiment of the present disclosure provides a computer program product, including a computer program, which implements any method of the embodiments of the present disclosure when executed by a processor.

[0010] The above description is only an overview of the technical solution of the present disclosure. In order to more clearly understand the technical means of the present disclosure, it can be implemented in accordance with the contents of the specification. In order to make the above and other purposes, features and advantages of the present disclosure more obvious and easy to understand, the specific implementation methods of the present disclosure are listed below. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] The accompanying drawings are used to better understand the present solution and do not constitute a limitation of the present disclosure.

[0012] Figure 1 is a schematic diagram of an exemplary hardware structure according to an embodiment of the present disclosure;

[0013] Figure 2 is a schematic diagram of a process accessing resources according to an embodiment of the present disclosure;

[0014] Figure 3 is a logical schematic diagram of a method for testing a SELinux security policy according to an embodiment of the present disclosure;

[0015] Figure 4 It is a flowchart of a method for testing a SELinux security policy according to an embodiment of the present disclosure;

[0016] Figure 5 is a schematic diagram of an update test process of a temporary security policy according to an embodiment of the present disclosure;

[0017] Figure 6 is a schematic diagram of a test device for SELinux security policy according to an embodiment of the present disclosure;

[0018] Figure 7 is a block diagram of an electronic device for implementing an embodiment of the present disclosure. DETAILED DESCRIPTION

[0019] In the following, only some exemplary embodiments are briefly described. As those skilled in the art will appreciate, the described embodiments may be modified in various ways without departing from the concept or scope of the present disclosure. Therefore, the drawings and descriptions are considered to be exemplary in nature and not restrictive.

[0020] To facilitate understanding of the technical solutions of the embodiments of the present disclosure, the following describes the related technologies of the embodiments of the present disclosure. The following related technologies can be combined with the technical solutions of the embodiments of the present disclosure as optional solutions, and they all belong to the protection scope of the embodiments of the present disclosure.

[0021] 1. Security-Enhanced Linux:

[0022] SELinux for short, it is a security module of the Linux kernel. Linux also includes other security modules such as SMACK, AppArmor, TOMOYO, etc. These security modules are abstracted into a lightweight security access control framework Linux Security Modules (LSM). Linux Security Modules provide a calling interface for the system to call the above security modules such as SELinux to perform access control on user processes. SELinux is a mandatory access control (MAC) security system based on the domain-type model. Its principle is that any process that wants to do anything in the SELinux system must first configure permissions in the SELinux security policy file. If permissions are not configured in the SELinux security policy file, the process does not have permission for the operation. SELinux uses this mandatory access control method to ensure the security of processes and system resources. It allows each process to have its own operating area and grant minimal access rights.

[0023] Each subject in the SELinux system has a domain, and each object has a type. Among them, the subject mainly refers to various processes and threads in electronic devices. Objects mainly refer to various system resources used for communication, information sharing and storage in electronic devices, such as files, sockets, storage space, directories, shared memory, etc. Taking the electronic device as a mobile phone as an example, the system resources in the mobile phone can include stored system files, storage space, and storage directories of different storage spaces.

[0024] SELinux generally has the following three modes:

[0025] (1) Enforcing: Enforcing mode. This mode means that SELinux is running and has correctly started to restrict domain / type. If a subject process initiates an access request, it will compare whether the corresponding permissions are configured in the SELinux security policy file (including the comparison of security context or policy rules). If the comparison is successful, the subject's access behavior will be allowed; if the comparison fails, the subject's access behavior will be blocked and recorded.

[0026] (2) Permissive: This mode means that when SELinux is running, even if a subject process initiates an access request, but SELinux fails to perform a security context or policy rule comparison based on the access request, the access behavior of the subject process will not be blocked. It will only be recorded. This record can be used as a basis for judging the problem later.

[0027] (3) Disabled: Disabled mode, SELinux is not actually running.

[0028] 2. Access Vector Cache (AVC): It is used to record the access rules that have been calculated by the SELinux security server and provide a SELinux interface for the LSM hook.

[0029] The above is a brief introduction to the terms involved in the embodiments of the present disclosure, which will not be repeated later.

[0030] With the development of electronic devices (such as mobile phones, smart wearable devices, tablet computers, personal computers (PCs), desktop computers, laptops, large-screen devices, smart TVs, etc.), the security of electronic devices is becoming more and more important. The application of SELinux technology in the existing operating system platform has greatly improved the security of the operating system.

[0031] In some embodiments, the electronic device may be a device having Figure 1 The exemplary hardware structure of the exemplary mobile phone 100 shown in FIG. Figure 1 As shown, the mobile phone 100 may specifically include: a radio frequency (RF) circuit 110, a memory 120, an input unit 130, a display unit 140, a sensor 150, an audio circuit 160, a short-range wireless communication module 170, a processor 180, and a power supply 190. Those skilled in the art will appreciate that Figure 1 The structure of the mobile phone 100 shown in the figure does not constitute a limitation on the electronic device, and the electronic device may include more or fewer components than shown in the figure, or combine certain components, or arrange the components differently.

[0032] Combine the following Figure 1 The components of the mobile phone 100 are described in detail:

[0033] The RF circuit 110 can be used for receiving and sending signals during the process of sending and receiving information or making calls. In particular, after receiving the downlink information of the base station, it is sent to the processor 180 for processing; in addition, the data related to the uplink is sent to the base station. Generally, the RF circuit includes but is not limited to an antenna, at least one amplifier, a transceiver, a coupler, a low noise amplifier (Low Noise Amplifier, LNA), a duplexer, etc. In addition, the RF circuit 110 can also communicate with the network and other devices through wireless communication. The above-mentioned wireless communication can use any communication standard or protocol, and the wireless communication can include Global System For Mobile Communications (Global System For Mobile Communications, GSM), General Packet Radio Service (General Packet Radio Service, GPRS), Code Division Multiple Access (Code Division Multiple Access, CDMA), Wideband Code Division Multiple Access (Wideband Code Division Multiple Access, WCDMA), Time Division Code Division Multiple Access (Time-Division Code Division Multiple Access, TD-SCDMA), Long Term Evolution (Long Term Evolution, LTE), New Radio (New Radio, NR), GNSS, FM, low-orbit satellite connection and / or IR technology, etc. The GNSS may include a Global Positioning System (GPS), a Global Navigation Satellite System (GLONASS), a BeiDou Navigation Satellite System (BDS), a Quasi-Zenithsatellite System (QZSS) and / or a Satellite Based Augmentation System (SBAS), etc.

[0034] The memory 120 can be used to store software programs and modules. The processor 180 executes various functional applications and data processing of the mobile phone by running the software programs and modules stored in the memory 120. The memory 120 can mainly include a program storage area and a data storage area, wherein the program storage area can store an operating system, an application required for at least one function (such as a sound playback function, an image playback function, etc.), etc.; the data storage area can store data created according to the use of the mobile phone (such as pictures, audio data, phone books, etc.), etc. In addition, the memory 120 can include a high-speed random access memory, and can 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.

[0035] The input unit 130 can be used to receive input digital or character information, and to generate key signal input related to the user settings and function control of the mobile phone 100. Specifically, the input unit 130 may include a touch panel 131 and other input devices 132. The touch panel 131, also known as a touch screen, can collect the user's touch operation on or near it (such as the user's operation on the touch panel 131 or near the touch panel 131 using any suitable object or accessory such as a finger (such as a single finger or multiple fingers), a stylus, etc.), and drive the corresponding connection device according to a pre-set program. Optionally, the touch panel 131 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 180, and can receive and execute the command sent by the processor 180. In addition, the touch panel 131 can be implemented in various types such as resistive, capacitive, infrared, and surface acoustic wave. In addition to the touch panel 131, the input unit 130 may also include other input devices 132. Specifically, other input devices 132 may include but are not limited to one or more of a physical keyboard, function keys (such as volume control keys, switch keys, etc.), a trackball, a mouse, a joystick, etc.

[0036] The display unit 140 can be used to display information input by the user or information provided to the user and various menus of the mobile phone. The display unit 140 may include a display panel 141. Optionally, the display panel 141 may be configured in the form of a liquid crystal display (LCD), a light emitting diode (LED), an organic light emitting diode (OLED), an active-matrix organic light emitting diode (AMOLED), etc. Further, the touch panel 131 may cover the display panel 141. When the touch panel 131 detects a touch operation on or near it, it is transmitted to the processor 180 to determine the type of touch event. Subsequently, the processor 180 provides a corresponding visual output on the display panel 141 according to the type of touch event. Although in Figure 1 In the embodiment, the touch panel 131 and the display panel 141 are used as two independent components to realize the input and output functions of the mobile phone, but in some embodiments, the touch panel 131 and the display panel 141 can be integrated to realize the input and output functions of the mobile phone.

[0037] The mobile phone 100 may also include at least one sensor 150, such as a light sensor, a motion sensor, and other sensors. Specifically, the light sensor may include an ambient light sensor and a proximity sensor, wherein the ambient light sensor may adjust the brightness of the display panel 141 according to the brightness of the ambient light, and the proximity sensor may turn off the display panel 141 and / or the backlight when the mobile phone is moved to the ear. As a type of motion sensor, the accelerometer sensor can detect the magnitude of acceleration in all 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 horizontal and vertical screen switching, related games, magnetometer posture calibration), vibration recognition related functions (such as pedometer, tapping), etc.; as for other sensors that can be configured in the mobile phone, such as gyroscopes, barometers, hygrometers, thermometers, infrared sensors, etc., they will not be repeated here.

[0038] The audio circuit 160, the speaker 161, and the microphone 162 can provide an audio interface between the user and the mobile phone. The audio circuit 160 can transmit the received audio data to the speaker 161 after converting the received audio data into an electrical signal, which is converted into a sound signal for output; on the other hand, the microphone 162 converts the collected sound signal into an electrical signal, which is received by the audio circuit 160 and converted into audio data, and then the audio data is output to the processor 180 for processing, and then sent to another electronic device through the RF circuit 110, or the audio data is output to the memory 120 for further processing.

[0039] Communication technologies such as Wi-Fi, Bluetooth, Near Field Communication (NFC) and Ultra Wide Band (UWB) belong to short-range wireless transmission technologies. The mobile phone can help users send and receive emails, browse web pages and access streaming media through the short-range wireless module 170, which provides users with wireless broadband Internet access. The above-mentioned short-range wireless module 170 may include a Wi-Fi chip, a Bluetooth chip, an NFC chip and a UWB chip. Through the Wi-Fi chip, the mobile phone 100 can achieve the function of Wi-Fi Direct connection with other electronic devices, and can also make the mobile phone 100 work in an AP mode (Access Point mode) that can provide wireless access services and allow other wireless devices to access, or work in a STA mode (Station mode) that can connect to an AP but does not accept wireless devices to access, thereby establishing point-to-point communication between the mobile phone 100 and other Wi-Fi devices.

[0040] The processor 180 is the control center of the mobile phone. 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 120, and calling data stored in the memory 120, it executes various functions of the mobile phone and processes data, thereby monitoring the mobile phone as a whole. Optionally, the processor 180 may include one or more processing units; optionally, the processor 180 may include, for example, an application processor (Application Processor, AP), a modem processor, a graphics processor (Graphics Processing Unit, GPU), an image signal processor (Image Signal Processor, ISP), a controller, a video codec, a digital signal processor (Digital Signal Processor, DSP), a baseband processor, and / or a neural network processor (Neural-Network Processing Unit, NPU), etc. Among them, different processing units can be independent devices or integrated in one or more processors.

[0041] The mobile phone 100 also includes a power source 190 (such as a battery) for supplying power to various components. Preferably, the power source can be logically connected to the processor 180 through a power management system, so that the power management system can manage functions such as charging, discharging, and power consumption.

[0042] The mobile phone 100 may further include a camera. Optionally, the camera may be located at the front or rear of the mobile phone, which is not limited in the embodiments of the present disclosure.

[0043] See also Figure 2 As shown, it shows a schematic diagram of the process accessing resources. When a process in user space wants to request / access (for example, open) a resource (for example, a file), the kernel space will allow the process to find the inode corresponding to the resource (a structure used to store files in Linux), and then perform error checks (for example, check whether the resource exists, etc.) and traditional DAC checks (for example, check the comparison between the process id and the resource id, etc.) through the kernel interface. After the above two checks, the function that executes the request / access to a resource will call the LSM hook added by the Linux security module in the kernel. The LSM hook will call the callback function registered by SELinux in the Linux security module to perform SELinux permission checks on whether the process has the right to access the resource. If there is a relevant request / access rule for the process to the resource in AVC, the return result is allowed; if there is no corresponding request / access rule in AVC, the corresponding result will be written into AVC after querying the security policy file in the user space, and then the result will be returned.

[0044] It can be understood that when a Linux system or a system deeply customized based on the Linux system (such as an Android system based on the Linux kernel) runs a compiled program, when a process accesses system resources, the function that calls the system resources will call the LSM hook pre-written in the kernel by the Linux security module, and the LSM hook will call different security modules such as SELniux, SMACK, AppArmor, etc. The callback function registered in the Linux security module, so that the user can choose a suitable security module to load into the kernel, such as SELniux. Then, SELinux will query the access rules corresponding to SELinux (the SELinux security policy file can be a file in the Linux source code, which becomes the security policy in SELinux after being compiled into a binary security policy file and loaded into the kernel space, including at least one access rule). If the access rules corresponding to the behavior of the program are not queried in SELinux, that is, the SELinux security policy file does not configure the corresponding permissions for the behavior of the program, in this case, SELinux will reject the behavior and generate an access denial log accordingly.

[0045] Specifically, SELinux will query SELinux through the Access Vector Cache (AVC) to see if there is an access rule corresponding to the program's behavior. Therefore, access denial is also called AVC denial, and the denial information will be recorded in the system log file. This denial information is also called AVC alarm information, and the log that records the denial information is also the access denial log.

[0046] In Linux systems or deeply customized systems based on Linux systems, there are many SELinux access denial logs. For programs running in the system, some behaviors are denied and will not cause the program to fail to run normally (for example, some mobile phone APPs in Android systems request to obtain location information or read text messages, etc.), but there will be behaviors related to the normal operation of the program as expected. If they are denied, the program will run abnormally. If the developer finds that the program runs abnormally because the program's behavior is denied, it is necessary to configure the corresponding permissions for the denied behavior in the SELinux security policy, that is, to configure the corresponding access rules, so as to solve the problem of abnormal program operation.

[0047] However, due to the complexity of SELinux architecture and the certain threshold of related knowledge, it is difficult for developers outside the information security field to accurately locate the specific problem that causes the program to run abnormally from the access denial log (that is, which behavior or behaviors are denied, causing the program to run abnormally). Sometimes, they test and verify the problem by guessing and continuously adding access permission patterns. Each test requires recompiling the firmware to configure the security policy in SELinux, which takes a lot of time. Especially in non-test environments, if the configuration is wrong, it may bring security risks to the operating system.

[0048] In view of this, the present disclosure proposes a method for testing SELinux security policies. Figure 3 is a schematic diagram of the logical structure of an embodiment of the present disclosure, such as Figure 3 As shown, the method can configure an additional temporary SELinux in the Linux system, and activate the temporary SELinux when a program runs abnormally based on an access request processed by the SELinux program, so that the temporary SELinux can reprocess the access request denied by SELinux, and update and debug the temporary security policy in the temporary SELinux through the access denial log generated by SELinux denying program access, and finally obtain at least one temporary security policy that can enable the program to run normally.

[0049] These temporary security policies that enable the program to run normally can provide developers with references to help locate problems that cause program abnormalities. Developers can even choose one of these temporary security policies to configure in SELinux based on actual security needs, thereby solving the problem of SELinux processing program access requests causing program abnormalities. In addition, since the test of security policies is performed in temporary SELinux, there will be no security risks to the system due to configuration problems during the test.

[0050] Figure 4The following is a flow chart of a method for testing a SELinux security policy according to an embodiment of the present disclosure, including:

[0051] Step S410, in response to a program running exception, obtaining at least one access denial log generated by SELinux based on at least one access request of the program during a period of program running exception.

[0052] Here, when the compiled program runs in the Linux system, the Linux system will allow or deny the program's access requests based on the security policy in SELinux. If the security policy contains access rules corresponding to the behavior requested by the program, the access request will be allowed. If the security policy does not contain access rules corresponding to the behavior requested by the program, the access request will be denied, and the system will record the access request denial as an access denial log.

[0053] Since not all denied access requests will cause program abnormalities, and it is difficult for developers outside the information security field to identify the logs that are truly related to program abnormalities from a large number of access rejection logs, it is necessary to extract all access rejection logs during the period when program abnormalities occur and test and add corresponding access rules in the security policy based on these access rejection logs, and then determine the security policy configuration form that can enable the program to run normally.

[0054] Specifically, in step S410, at least one access denial log generated by SELinux based on at least one access request of the program during the period when the program runs abnormally is obtained, including: retrieving the system log during the period when the program runs abnormally; and filtering out at least one log containing a denial field in the system log as the access denial log.

[0055] For example, the content of an access denial log may be:

[0056] 12-3017:31:32.398W / InputReader(2557):type=1400audit(0.0:120070):avc:denied{read}for name="u:object_r:vendor_default_prop:s0"dev="tmpfs"ino=381scontext=u:r:system_server:s0tcontext=u:object_r:vendor_default_pro p:s0tclass=file permissive=0

[0057] Among them, "12-3017:31:32.398" is a timestamp, indicating the time of log recording, "type = 1400audit (0.0:120070): avc: denied {read}" indicates that SELinux has access control denial, avc indicates the log type, denied indicates the denial behavior of SELinux, dev indicates the device or file system where the target is located, and ino indicates the inode number of the target, which can be used to find the target file. Scontext (Source context) indicates the security context of the process that attempts to access the resource, which can also be understood as the subject label, Tcontext (Targetcontext) indicates the security context of the accessed resource, which can also be understood as the object label, and permissive = 0 indicates that SELinux is currently in enforcing mode, not permissive mode. The complete meaning of this access denial log is: the process (system_server) attempts to read a file with a security context of (vendor_default_prop), but this access behavior is denied due to the security policy of SELinux.

[0058] Here, we can use the timestamp, avc, and denied fields in the log to filter out the access denied logs during the period when the program ran abnormally.

[0059] Step S420: activating temporary SELinux so that the temporary security policy in the temporary SELinux is updated M times based on at least one access denial log, where M is an integer greater than 1.

[0060] Step S430, testing the program after each update, so that SELinux and temporary SELinux jointly process the access request of the program and determine the running status of the program.

[0061] Here, the present invention additionally configures a temporary SELinux in the Linux system. The temporary SELinux is in an inactivated state under normal circumstances. Only when the program runs abnormally and enters the test phase, the temporary SELinux is triggered to be activated, and the temporary security policy in the temporary SELinux is updated based on the access rejection log obtained in step S410, so that SELinux and the temporary SELinux jointly process the access request of the program. That is, when the system does not find the access rule corresponding to the current access request in the security policy of SELinux, it will further search for the access rule corresponding to the current access request in the temporary security policy of the temporary SELinux. If the access rule is found, the current access request will be allowed. If the access rule is not found in both SELinux and the temporary SELinux, the current access request will be rejected.

[0062] It can be understood that SELinux executes user process requests / access control through the system's native Linux security module, and temporary SELinux can execute user process requests / access control through another temporary Linux security module. See the previous description of this article that the Linux security module pre-writes the LSM hook in the kernel, and the temporary Linux security module may not pre-write the LSM hook into the kernel, and only establish a connection with the Linux security module. For example, the temporary SELinux in the temporary Linux security module provides a calling interface to the Linux security module, which enables the Linux security module to call the temporary SELinux to handle the program's access request. Based on this, after updating the temporary security policy in the temporary SELinux, the program can run normally when the temporary SELinux is activated, which means that if the temporary security policy in the temporary SELinux is added to the security policy of SELinux, the program can run normally when the temporary SELinux is not activated, that is, the updated temporary security policy can solve the problem of abnormal program operation.

[0063] It should be noted that the temporary security policy in temporary SELinux is actually a temporary file configured at the driver layer. The temporary file will be cleared after each system restart. That is, there are usually no configured access rules in temporary SELinux. Instead, only when temporary SELinux is activated, the generated rules that need to be tested will be written into temporary SELinux as a temporary security policy.

[0064] Specifically, in step S420, the temporary security policy in the temporary SELinux is updated M times based on at least one access denial log, including: generating M security policy files according to at least one access denial log, and the access rules contained in any security policy file are not completely the same as the access rules contained in any other security policy file; using the i-th security policy file among the M security policy files to update the temporary security policy in the temporary SELinux for the i-th time, where i is a positive integer less than M.

[0065] On this basis, in step S430, the program is tested after each update so that SELinux and temporary SELinux jointly process the program's access requests and determine the program's running status, including: triggering the program to rerun after the i-th update is completed, so that SELinux and temporary SELinux jointly process the program's access requests, determining and recording the program's running status after rerunning; after the recording is completed, triggering the use of the i+1th security policy file among the M security policy files to update the temporary security policy in the temporary SELinux for the i+1th time.

[0066] Here, each security policy file corresponds to an update of a temporary security policy. Ensuring that the access rules contained in each security policy file are not exactly the same can ensure that the temporary security policy after each update is different from the temporary security policy tested before, and fully test the running status of the program under different temporary security policies, so as to determine one or several security policy configuration forms that can enable the normal operation of the program.

[0067] Exemplarily, M security policy files are generated based on at least one access denial log, including: generating multiple candidate access rules based on the subject field and object field contained in the at least one access denial log, wherein each candidate access rule involves at least one subject field and / or at least one object field contained in the at least one access denial log; generating M security policy files based on different combinations of the multiple candidate access rules, wherein each security policy file includes at least one candidate access rule.

[0068] For example, the content of an access rule may be:

[0069] allow system_server vendor_default_pro:file{read}

[0070] This access rule indicates that the process (subject) with the source context (system_server) is allowed to perform a read operation on the file (object) with the target context (vendor_default_pro). Referring to the access denial log exemplified in the aforementioned step S410, the access denial log also records that a certain operation of the subject on the object was denied. A candidate access rule that allows the corresponding operation can be generated based on the recorded denial information, and the running status of the program when the candidate access rule is present in the temporary security policy can be tested.

[0071] Optionally, the generated temporary access rule may have only a subject or an object in addition to both a subject and an object. For example, the subject (system_server) may be directly set to permissive mode in SELinux. In this case, any operation of the subject will be allowed; or the object (vendor_default_pro) may be set to permissive mode. In this case, any operation of any other subject on the object will be allowed.

[0072] Here, M different security policy files can be formed based on different combinations of generated candidate access rules (the access rules contained in the same security policy file do not conflict with each other). Each security policy file can contain some of the same temporary access rules. It only needs to ensure that the temporary access rules contained in each security policy file are not exactly the same. In this way, the temporary security policies corresponding to each security policy file after each update will be different.

[0073] Step S440, based on the mapping relationship between the temporary security policy and the running state after each update, M groups of mapping relationships are obtained, wherein at least one group of mapping relationships with a normal running state in the M groups of mapping relationships is used to reconfigure the security policy in SELinux.

[0074] Here, each set of mapping relationships includes a temporary security policy and the running status of the program obtained by testing after the temporary security policy is configured in the temporary SELinux, so as to show developers in non-information security fields at least one security policy configuration method that can enable the normal operation of the program, for developers to refer to and configure the security policy in SELinux.

[0075] It is understandable that the core idea of ​​SELinux is to ensure information security by granting as few access rights as possible while ensuring the normal operation of each program in the system. Therefore, the security policy configuration method obtained through testing that enables the normal operation of the program is not necessarily a configuration method that fully meets the actual expectations of the developer. For example, in a temporary security policy that enables the normal operation of the program, process A is granted read and write permissions to file B, but in fact, process A only needs to be granted read permissions to file B for the program to run normally. Developers can configure the security policy in SELinux according to actual needs based on the temporary security policy obtained through testing that enables the normal operation of the program.

[0076] Exemplarily, if there are enough configuration forms of the temporary security policies tested in step S420 and step S430, a temporary security policy can also be directly determined as the actual configured security policy from the temporary security policies that enable the program to run normally. Specifically, after step S440, the following is further included:

[0077] At least one group of candidate mapping relationships with a normal operating state is determined from among the M groups of mapping relationships; temporary security policies in each candidate mapping relationship are extracted to obtain at least one candidate security policy; a security policy to be updated is determined from among the at least one candidate security policy, the security policy in SELinux is reconfigured using the security policy to be updated, and after the configuration is completed, the temporary SELinux is reset to an inactivated state so as to process access requests of a program based on the reconfigured SELinux.

[0078] Among them, the temporary security policy in the M group mapping relationship that enables the normal operation of the program can be first determined as the candidate security policy, and the security policy to be updated for reconfiguring SELinux can be determined according to actual needs in the candidate security policy to reconfigure SELinux, and after the configuration is completed, the temporary SELinux is reset to an inactivated state, thereby ending the test phase and restoring the normal operation of the system.

[0079] Since the temporary security policy tested previously works together with the security policy in SELinux to enable the normal operation of the program, the way to reconfigure SELinux is to write the access rules in the temporary security policy into SELinux. If the content defined by an original access rule in SELinux is overwritten by the access rule in the temporary security policy, the overwritten original access rule can be deleted accordingly. For example, the original access rule defines that process C has read permission for file D, while the access rule in the temporary security policy defines that process C has read and write permission for file D.

[0080] For example, in the absence of other functional requirements conflicts, based on the core idea of ​​SELinux, a candidate security policy with the least number of access rules can be determined from at least one candidate security policy as the security policy to be updated, so that the reconfigured SELinux can enable the program to run normally and ensure better security.

[0081] In some embodiments, activating temporary SELinux in step S420 includes: activating temporary SELinux in response to the running environment of the program being a test environment or a formal environment with an activation code.

[0082] Here, the test environment can be understood as the environment in which the current Linux system is used by developers to test compiled programs. The official environment with the activation code can be understood as the environment in which the maintenance personnel enter the activation code to test the cause of the program anomaly after the user reports a program anomaly while using the released official Linux system. The activation code is used to grant the officially released Linux system the permission to activate temporary SELinux.

[0083] By adopting the method of this embodiment, conditional restrictions can be imposed on the activation of temporary SELinux, so as to prevent users from mistakenly entering the test mode when using the officially released Linux system, thereby affecting normal use.

[0084] Figure 5 The update test process of the temporary security policy of an embodiment of the present disclosure is shown as follows: Figure 5 As shown, after each update of the temporary security policy in the temporary SELinux, the program is triggered to run again. After the program runs in the system, it will issue an access request. Based on the access request of the program, the Linux system will query the access rules to determine whether to allow or deny the access request.

[0085] Specifically, first, SELinux is queried to see whether an access rule corresponding to the access request is configured. If the system does not find an access rule corresponding to the current access request in the SELinux security policy, it will query whether the current system has a temporary SELinux activation code (the test environment comes with an activation code, and the activation code needs to be entered into the system in the released formal environment). If the current system has an activation code, the temporary security policy of temporary SELinux will be further queried for the access rule corresponding to the current access request. If the access rule is found, the current access request will be allowed. If the access rule is not found in either SELinux or temporary SELinux, the current access request will be rejected.

[0086] At the same time, the system will record the program's running status based on whether the access request is allowed or denied, and trigger the update of the temporary security policy in the temporary SELinux after recording, so as to continuously test the program's running status under different temporary security policies.

[0087] The above describes the specific settings and implementation methods of the embodiments of the present disclosure from different angles. By using the method provided in the above embodiments, a temporary SELinux is additionally configured in the Linux system, and the temporary SELinux is activated in the event of a program exception, so that the temporary SELinux can reprocess the access request rejected by SELinux, and the temporary security policy in the temporary SELinux is updated and tested. The relationship between the different security policy configuration methods and the program running status obtained can provide a reference for developers to assist in locating the problems that cause program running exceptions, reducing the technical threshold for developers to debug Linux security policies, and because the test of the security policy is carried out in the temporary SELinux, it is not necessary to recompile the firmware every time, which greatly saves the time spent on testing and verifying problems, and will not leave security risks for the system due to configuration problems during the test.

[0088] In addition, if the tested security policy configuration methods are rich enough, developers can also directly select the configuration method that meets the actual security needs from the security policy configuration methods that can enable the normal operation of the program to reconfigure the security policy in SELinux, thereby solving the problem of abnormal program operation.

[0089] As an implementation of the above methods, the embodiment of the present disclosure also provides a test device for SELinux security policy, which can be applied to electronic devices such as mobile phones, smart wearable devices, tablet computers, personal computers, desktop computers, laptops, large-screen devices, smart TVs, etc. The device may include:

[0090] The log acquisition module 610 is used for acquiring, in response to a program running abnormality, at least one access denial log generated by SELinux based on at least one access request of the program during a period of program running abnormality;

[0091] An activation module 620, configured to activate the temporary SELinux, so that the temporary security policy in the temporary SELinux is updated M times based on at least one access denial log, where M is an integer greater than 1;

[0092] A test module 630, for testing the program after each update, so that SELinux and temporary SELinux jointly process the access request of the program and determine the running status of the program;

[0093] The configuration module 640 is used to obtain M groups of mapping relationships based on the mapping relationship between the temporary security policy and the running state after each update, wherein at least one group of mapping relationships with a normal running state in the M groups of mapping relationships is used to reconfigure the security policy in SELinux.

[0094] Exemplarily, the activation module 620 is used to: generate M security policy files based on at least one access denial log, and the access rules contained in any security policy file are not completely the same as the access rules contained in any other security policy file; use the i-th security policy file among the M security policy files to update the temporary security policy in the temporary SELinux for the i-th time, where i is a positive integer less than M.

[0095] Exemplarily, the test module 630 is used to: trigger the program to re-run after the i-th update is completed, so that SELinux and temporary SELinux jointly handle the program's access request, determine and record the running status of the program after re-running; after the recording is completed, trigger the use of the i+1-th security policy file among the M security policy files to perform the i+1-th update of the temporary security policy in the temporary SELinux.

[0096] Exemplarily, the activation module 620 is also used to: generate multiple candidate access rules based on the subject field and object field contained in at least one access denial log, wherein each candidate access rule involves at least one subject field and / or at least one object field contained in at least one access denial log; and generate M security policy files based on different combinations of the multiple candidate access rules, wherein each security policy file includes at least one candidate access rule.

[0097] Exemplarily, the log acquisition module 610 is used to: retrieve the system logs in the period when the program runs abnormally; and filter out at least one log containing a deny field in the system logs as an access deny log.

[0098] Exemplarily, the activation module 620 is used to activate temporary SELinux in response to the running environment of the program being a test environment or a formal environment with an activation code.

[0099] Exemplarily, the configuration module 640 is used to determine at least one group of candidate mapping relationships with a normal operating status in M ​​groups of mapping relationships; extract the temporary security policy in each candidate mapping relationship to obtain at least one candidate security policy; determine the security policy to be updated in at least one candidate security policy, use the security policy to be updated to reconfigure the security policy in SELinux, and reset the temporary SELinux to an inactivated state after the configuration is completed, so as to process access requests based on the reconfigured SELinux handler.

[0100] Exemplarily, the configuration module 640 is further configured to determine, from at least one candidate security policy, a candidate security policy containing the least number of access rules as the security policy to be updated.

[0101] The functions of each unit, module or sub-module in each device of the embodiments of the present disclosure can refer to the corresponding description in the above method embodiments, and have corresponding beneficial effects, which will not be repeated here.

[0102] According to an embodiment of the present disclosure, the present disclosure also provides an electronic device, a computer-readable storage medium, and a computer program product.

[0103] Figure 7 FIG. 1 is a block diagram of an electronic device for implementing an embodiment of the present disclosure. Figure 7 As shown, the electronic device includes: a memory 701 and a processor 702. The memory 701 stores a computer program that can be run on the processor 702. When the processor 702 executes the computer program, the method in the above embodiment is implemented. The number of the memory 701 and the processor 702 can be at least one.

[0104] The electronic device also includes:

[0105] The communication interface 703 is used to communicate with external devices and perform data exchange transmission.

[0106] If the memory 701, the processor 702 and the communication interface 703 are implemented independently, the memory 701, the processor 702 and the communication interface 703 can be connected to each other through a bus and communicate with each other. The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus. The bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 7 Only one thick line is used in the diagram, but this does not mean that there is only one bus or only one type of bus.

[0107] Optionally, in a specific implementation, if the memory 701, the processor 702 and the communication interface 703 are integrated on a chip, the memory 701, the processor 702 and the communication interface 703 can communicate with each other through an internal interface.

[0108] The embodiment of the present disclosure also provides a chip, which includes a processor for calling and executing instructions stored in the memory from the memory, so that a communication device equipped with the chip executes the method provided by the embodiment of the present disclosure.

[0109] An embodiment of the present disclosure also provides a chip, including: an input interface, an output interface, a processor and a memory, wherein the input interface, the output interface, the processor and the memory are connected via an internal connection path, and the processor is used to execute the code in the memory. When the code is executed, the processor is used to execute the method provided by the embodiment of the present disclosure.

[0110] It should be understood that the processor may be a CPU, or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), FPGAs or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor, etc. It is worth noting that the processor may be a processor supporting the Advanced RISC Machines (ARM) architecture.

[0111] Further, optionally, the above-mentioned memory may include a read-only memory and a random access memory. The memory may be a volatile memory or a non-volatile memory, or may include both volatile and non-volatile memory. Among them, the non-volatile memory may include a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or a flash memory. The volatile memory may include a random access memory (RAM), which is used as an external cache. By way of exemplary but not limiting description, many forms of RAM are available. For example, static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM) and direct memory bus random access memory (DR RAM).

[0112] In the above embodiments, all or part of the embodiments may be implemented by software, hardware, firmware or any combination thereof. When implemented by software, all or part of the embodiments may be implemented in the form of a computer program product. The computer program product includes at least one computer instruction. When the computer program instruction is loaded and executed on a computer, all or part of the processes or functions according to the present disclosure are generated. The computer may be a general-purpose computer, a special-purpose computer, a computer network or other programmable device. The computer instruction may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium.

[0113] In the description of this specification, the description with reference to the terms "one embodiment", "some embodiments", "example", "specific example" or "some examples" etc. means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present disclosure. Moreover, the specific features, structures, materials or characteristics described may be combined in a suitable manner in any at least one embodiment or example. In addition, those skilled in the art may combine and combine different embodiments or examples described in this specification and the features of different embodiments or examples, unless they are contradictory.

[0114] In addition, the terms "first" and "second" are used for descriptive purposes only and should not be understood as indicating or implying relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of the features. In the description of the present disclosure, the meaning of "plurality" is two or more, unless otherwise clearly and specifically defined.

[0115] Any process or method described in the flow chart or otherwise described herein can be understood as a module, segment or portion of a code representing one or more executable instructions for implementing the steps of a specific logical function or process. And the scope of the preferred embodiments of the present disclosure includes other implementations, in which the functions may not be performed in the order shown or discussed, including in a substantially simultaneous manner or in a reverse order according to the functions involved.

[0116] The logic and / or steps described in the flowchart or otherwise described herein, for example, can be considered as an ordered list of executable instructions for implementing logical functions, which can be specifically implemented in any computer-readable medium for use by an instruction execution system, device or apparatus (such as a computer-based system, a system including a processor, or other system that can fetch instructions from an instruction execution system, device or apparatus and execute instructions), or used in combination with these instruction execution systems, devices or apparatuses.

[0117] It should be understood that the various parts of the present disclosure may be implemented with hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods may be implemented with software or firmware stored in a memory and executed by a suitable instruction execution system. All or part of the steps of the above embodiment method may be completed by instructing the relevant hardware through a program, which may be stored in a computer-readable storage medium, and when the program is executed, includes one or a combination of the steps of the method embodiment.

[0118] In addition, each functional unit in each embodiment of the present disclosure may be integrated into a processing module, or each unit may exist physically separately, or two or more units may be integrated into one module. The above-mentioned integrated module may be implemented in the form of hardware or in the form of a software functional module. If the above-mentioned integrated module is implemented in the form of a software functional module and sold or used as an independent product, it may also be stored in a computer-readable storage medium. The storage medium may be a read-only memory, a disk or an optical disk, etc.

[0119] The above is only an exemplary embodiment of the present disclosure, but the protection scope of the present disclosure is not limited thereto. Any technician familiar with the technical field can easily think of various changes or substitutions within the technical scope recorded in the present disclosure, which should be included in the protection scope of the present disclosure. Therefore, the protection scope of the present disclosure should be based on the protection scope of the claims.

Claims

1. A test method for SELinux security policy, include: In response to a program running exception, obtaining at least one access denial log generated by SELinux based on at least one access request of the program during a period of the program running exception; Activate temporary SELinux so that a temporary security policy in the temporary SELinux is updated M times based on the at least one access denial log, where M is an integer greater than 1; Testing the program after each update so that the SELinux and the temporary SELinux jointly process the access request of the program and determine the running status of the program; Based on the mapping relationship between the temporary security policy after each update and the running state, M groups of mapping relationships are obtained, wherein at least one group of mapping relationships with a normal running state in the M groups of mapping relationships is used to reconfigure the security policy in the SELinux.

2. The method according to claim 1, in, The temporary security policy in the temporary SELinux is updated M times based on the at least one access denial log, including: Generate M security policy files according to the at least one access denial log, wherein the access rules included in any security policy file are not completely the same as the access rules included in any other security policy files; The temporary security policy in the temporary SELinux is updated for the i-th time using the i-th security policy file among the M security policy files, where i is a positive integer less than M.

3. The method according to claim 2, in, After each update, the program is tested so that the SELinux and the temporary SELinux jointly process the access request of the program and determine the running status of the program, including: After the i-th update is completed, trigger the program to re-run, so that the SELinux and the temporary SELinux jointly process the access request of the program, and determine and record the running state of the program after re-running; After the recording is completed, the i+1th update of the temporary security policy in the temporary SELinux is triggered using the i+1th security policy file in the M security policy files.

4. The method according to claim 2, in, Generating M security policy files according to the at least one access rejection log includes: Generate a plurality of candidate access rules according to the subject field and the object field contained in the at least one access denial log, wherein each of the candidate access rules involves at least one subject field and / or at least one object field contained in the at least one access denial log; Based on different combinations of the plurality of candidate access rules, the M security policy files are generated, wherein each of the security policy files includes at least one of the candidate access rules.

5. The method according to claim 1, in, Acquiring at least one access denial log generated by SELinux based on at least one access request of the program during a period when the program runs abnormally, including: Retrieve the system logs for the period when the program runs abnormally; At least one log containing a rejection field is screened out from the system logs as the access rejection log.

6. The method according to any one of claims 1 to 5, in, Activate temporary SELinux, including: In response to the running environment of the program being a test environment or a formal environment with an activation code, the temporary SELinux is activated.

7. The method according to any one of claims 1 to 5, further comprising: include: Determining at least one group of candidate mapping relationships whose operating status is normal among the M groups of mapping relationships; Extracting the temporary security policy in each of the candidate mapping relationships to obtain at least one candidate security policy; The security policy to be updated is determined from the at least one candidate security policy, the security policy in the SELinux is reconfigured using the security policy to be updated, and after the configuration is completed, the temporary SELinux is reset to an inactive state, so as to process access requests of programs based on the reconfigured SELinux.

8. The method according to claim 7, in, Determining a security policy to be updated from the at least one candidate security policy includes: A candidate security policy including the least number of access rules is determined from the at least one candidate security policy as the security policy to be updated.

9. An electronic device comprising a memory, a processor and a computer program stored in the memory, wherein the processor implements the method according to any one of claims 1 to 9 when executing the computer program.

10. A computer-readable storage medium, wherein a computer program is stored in the computer-readable storage medium, and when the computer program is executed by a processor, the method according to any one of claims 1 to 9 is implemented.

11. A computer program product, comprising a computer program / instructions, which, when executed by a processor, implement the steps of the method according to claims 1 to 9.

Images