Method, device, terminal equipment and storage medium for disabling selinux

Abstract

Embodiments of the present application disclose a method and device for prohibiting the closing of SELinux, terminal equipment and storage medium, which are used for preventing the closing of SELinux in the listed terminal equipment products, and eliminating the situation that SELinux is closed. The method comprises the following steps: detecting whether the value of android.verifiedbootstate in the kernel start parameter cmdline is equal to orange; if the value is not equal to orange, determining that the terminal equipment is in an unlocked state, obtaining the structure body selinux_state of a register and a parameter new_value; and in the case that the parameter new_value is equal to 0, assigning 1 to enforce in the structure body selinux_state, so as to open SELinux.

Description

Technical Field

[0001] This application relates to the field of terminal device technology, and in particular to a method, apparatus, terminal device, and storage medium for disabling SELinux. Background Technology

[0002] While Linux's native SELinux permissions provide very strict access control for ordinary applications and the system, it cannot distinguish or defend against malicious privilege escalation or exploitation to disable SELinux. Summary of the Invention

[0003] This application provides a method, apparatus, terminal device, and storage medium for preventing SELinux from being disabled, thereby preventing SELinux from being disabled in commercially available terminal device products.

[0004] This application provides a method for disabling SELinux, the method being applied to a terminal device, the method comprising:

[0005] The system checks whether the value of android.verifiedbootstate in the kernel boot parameter cmdline is equal to orange. If it is not equal to orange, the terminal device is determined to be in an unlocked state. The system then obtains the structure selinux_state and the parameter new_value from the register. If the parameter new_value is equal to 0, the system sets the value of enforce in the structure selinux_state to 1 to enable SELinux.

[0006] A second aspect of this application provides an apparatus for disabling SELinux, the apparatus being applied to a terminal device, the apparatus comprising:

[0007] The processing module is used to detect whether the value of android.verifiedbootstate in the kernel boot parameter cmdline is equal to orange; if it is not equal to orange, it determines that the terminal device is in an unlocked state, obtains the structure selinux_state and parameter new_value from the register; if the parameter new_value is equal to 0, it assigns the value of enforce in the structure selinux_state to 1 so that SELinux is enabled.

[0008] A third aspect of this application provides a terminal device, which may include:

[0009] Memory containing executable program code;

[0010] A processor coupled to the memory;

[0011] The processor is used to execute the method described in the first aspect of this application.

[0012] In another aspect, embodiments of this application provide a computer-readable storage medium including instructions that, when executed on a processor, cause the processor to perform the method described in the first aspect of this application.

[0013] Another aspect of this application discloses a computer program product that, when run on a computer, causes the computer to execute the method described in the first aspect of this application.

[0014] Another aspect of this application discloses an application publishing platform for publishing computer program products, wherein when the computer program product is run on a computer, the computer executes the method described in the first aspect of this application.

[0015] As can be seen from the above technical solutions, the embodiments of this application have the following advantages:

[0016] In this embodiment, the value of `android.verifiedbootstate` in the kernel boot parameter `cmdline` is checked to see if it equals `orange`. If it does not equal `orange`, the terminal device is determined to be in a locked state. The `selinux_state` structure and the parameter `new_value` in the register are obtained. If the parameter `new_value` equals 0, the `enforce` value in the `selinux_state` structure is set to 1 to enable SELinux. This is used in commercially available terminal device products to prevent SELinux from being disabled by determining that the terminal device is in a locked state and setting the `enforce` value in the `selinux_state` structure to 1 when the parameter `new_value` equals 0. Attached Figure Description

[0017] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the description of the embodiments and the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application, and other drawings can be obtained based on these drawings.

[0018] Figure 1A This is a schematic diagram of the overall structure of SELinux;

[0019] Figure 1BThis is a basic access flowchart for SELinux;

[0020] Figure 1C A schematic diagram of the SELinux core components;

[0021] Figure 2 This is a schematic diagram of one embodiment of the method for disabling SELinux in this application.

[0022] Figure 3 This is a schematic diagram of another embodiment of the method for disabling SELinux in this application;

[0023] Figure 4 This is a schematic diagram of a device for disabling SELinux in an embodiment of this application;

[0024] Figure 5 This is a schematic diagram of one embodiment of the terminal device in this application;

[0025] Figure 6 This is a schematic diagram of another embodiment of the terminal device in this application. Detailed Implementation

[0026] This application provides a method, apparatus, terminal device, and storage medium for preventing SELinux from being disabled, thereby preventing SELinux from being disabled in commercially available terminal device products.

[0027] To enable those skilled in the art to better understand the present application, the technical solutions of the embodiments of the present application will be described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. All embodiments based on the present application should fall within the scope of protection of the present application.

[0028] Terminal devices have developed rapidly in recent years, with various manufacturers launching customized versions. Simultaneously, with the promotion and use of cloud computing and the Internet of Things, terminal devices are increasingly integrated into people's daily lives, making their security requirements ever stronger. Although major manufacturers are improving their security defense and vulnerability mitigation capabilities, related privilege escalation incidents continue to occur frequently.

[0029] SELinux is a mandatory access control (MAC) security model inherent in Linux. MAC's effect is very simple and effective: any process wanting to do anything within the SELinux system must first be granted the necessary permissions in the security policy configuration file. Any behavior without the pre-defined SELinux permissions will be blocked by the SELinux policy. Whether SELinux can be bypassed is a crucial factor in the attack and defense against vulnerabilities in Linux / AOSP (Android Open Source Project). Many security policies disable SELinux as their first action after privilege escalation, such as by writing 0 using the `setenforce` tool.

[0030] SELinux is a typical implementation of mandatory access control (MAC). It generates a security context for each object in the system, and each object's access to system resources is subject to security context review. The review rules include type enforcement, multi-level security review, and role-based access control (RBAC).

[0031] SELinux is built on top of the Linux Security Module (LSM). The Linux Security Module is a lightweight, general-purpose access control framework suitable for implementing various access control models as kernel-loadable modules. Users can choose the appropriate security module to load into the kernel according to their needs.

[0032] like Figure 1A The image shown is a schematic diagram of the overall structure of SELinux. SELinux consists of five basic components:

[0033] (1) An auxiliary module for handling the file system, namely SELinuxFS;

[0034] (2) Hooks settings for integrated Linux security modules;

[0035] (3) Security Policy Database (SPD);

[0036] (4) Security Label Verification Module;

[0037] (5) Access Vector Cache (AVC) to improve verification speed.

[0038] like Figure 1B The diagram shows the basic access flow of SELinux. When a process accesses a resource via a system call, it first performs basic checks upon entering the kernel; if an exception is found, it returns directly. The Linux kernel's Discretionary Access Control (DAC) then reviews the access; if an exception is found, it returns directly. The relevant hooks in the Linux kernel modules are called, connecting to SELinux hooks for MAC verification; if an exception is found, it returns directly. The actual system resource is accessed. Finally, the process returns to user space and reports the result.

[0039] SELinux and SEAndroid: Android is built on the standard Linux Kernel, so it can naturally enable SELinux. However, such security services are rarely enabled on general mobile platforms. In order to further enhance the security of Android, Google has been preparing for a long time and has now fully enabled SELinux in Android 5.0(L) and has deeply integrated SELinux to form SEAndroid.

[0040] The impact of SELinux on Android is as follows:

[0041] Superuser privileges (Root) are strictly limited, greatly improving the previous situation where Root users were "lawless"; SELinux protection reduces the risk of attacks on critical system processes, and ordinary processes will not have permission to directly connect to critical system processes; the application (APP) sandbox mechanism is further strengthened to ensure that APPs are unlikely to perform abnormal or attack behaviors; it will change the history of APPs having their permissions locked once installed, and dynamic adjustment of APP permissions will become possible.

[0042] The following is a brief explanation of DAC and MAC:

[0043] DAC stands for Discretionary Access Control, meaning the system only provides basic authentication, and the complete access control is controlled by the developer.

[0044] MAC stands for Mandatory Access Control, which means that the system strictly restricts every access request, and the specific restriction policy is given by the developer.

[0045] (1) Linux DAC

[0046] Linux DAC employs a very simple strategy, dividing resource visitors into three categories: Owner, Group, and Other. Different access permissions are set for these three categories of visitors. These access permissions are further divided into read, write, and execute.

[0047] Visitors are typically processes with their own uid / gid. Access is determined by matching the uid / gid with file permissions.

[0048] Root privileges are divided into many Root Capabilities based on different application scenarios. If there is a CAP_DAC_OVERRIDE option, the Linux DAC restriction can be bypassed directly.

[0049] Linux DAC has significant shortcomings, one major one being the "lawless" nature of root privileges. Root users can do almost anything, and once an intruder gains root access, they have complete control of the system. Furthermore, every process by default has full permissions for its corresponding user, allowing it to modify or delete all files and resources belonging to that user. Clearly, this makes it difficult to prevent malware.

[0050] (2) Linux MAC

[0051] To address the shortcomings of DAC (Access Control List), Linux MAC (Macro Access Control) requires the system to check every access request, and each access to a file resource requires specific verification. This specific verification is performed according to predefined policies. In the Linux kernel, all MAC mechanisms are built on top of Linux Security Modules (LSM), including SELinux, Apparmor, Smack, and TOMOYO Linux. SELinux has now become the de facto industry standard.

[0052] For Linux DAC, MAC can significantly compensate for its shortcomings. Firstly, it restricts root privileges; even with root privileges, if MAC verification fails, the user cannot actually perform the relevant operations. Secondly, it provides more comprehensive and granular control over each permission, restricting user access to resources.

[0053] like Figure 1C The diagram shown illustrates the core components of SELinux. These core components include the Subject, Object Manager, Access Vector Cache, and Security Server, with the Security Server comprising Security Policy.

[0054] Subject usually refers to the object that triggers the access behavior, which is usually a process in Linux;

[0055] The Object Manager is an object access manager, which can know which resources the Subject needs to access and trigger the verification mechanism.

[0056] A security server is used to verify whether a subject can truly access an object, and this verification mechanism is based on a predefined security policy.

[0057] Security Policy is a language for describing SELinux policies;

[0058] Access Vector Cache (AVC) is an access cache used to record past access verification information in order to improve efficiency and speed up processing.

[0059] In existing Linux terminal devices, there are two ways to disable SELinux:

[0060] (1) Setenforce

[0061] SELinux can be disabled using `setenforce 0`; however, `setenforce` itself has permission restrictions: it can only be executed with root privileges (ordinary devices do not have root privileges).

[0062] (2) sys / fs / selinux / enforce

[0063] This path is the control switch for SELinux. The essence of Setenforce is to write a value to this node (0: represents turning off SELinux, 1 represents enabling SELinux). Its permissions are also restricted, allowing only root privileges to write to it.

[0064] While Linux's native SELinux permissions provide very strict access control for ordinary applications and the system, it cannot distinguish or defend against malicious privilege escalation or exploitation to disable SELinux.

[0065] For original equipment manufacturers (OEMs), normal terminal devices do not have root privileges after being released to the market (to ensure stable system operation and prevent accidental tampering that could affect device use). Therefore, there should be no operation to disable SELinux. This solution is therefore proposed to strengthen the security of the SELinux disabling policy.

[0066] This application proposes and implements a "security policy that prevents SELinux from being disabled", which is pre-configured in terminal devices, integrated into the kernel hardening, implemented based on the Kretprobe framework, and mounted and works as a kernel module.

[0067] The terminal equipment in this application may be referred to as user equipment (UE), mobile station (MS), mobile terminal, smart terminal, etc. The terminal equipment can communicate with one or more core networks via a radio access network (RAN). For example, the terminal equipment can be a mobile phone (or "cellular" phone), a computer with a mobile terminal, etc. The terminal equipment can also be portable, pocket-sized, handheld, computer-embedded, or vehicle-mounted mobile devices, as well as terminal equipment in future NR networks. They exchange voice or data with the radio access network. Regarding the terminal equipment: In this application, the terminal equipment may also include relays and base stations capable of data communication; however, this application will use the general term UE for description.

[0068] In the embodiments of this application, the terminal device may be a mobile phone, a tablet computer, a computer with wireless transceiver capabilities, a virtual reality (VR) terminal device, an augmented reality (AR) terminal device, a wireless terminal device in industrial control, a wireless terminal device in self-driving, a wireless terminal device in remote medical care, a wireless terminal device in a smart grid, a wireless terminal device in transportation safety, a wireless terminal device in a smart city, or a wireless terminal device in a smart home, etc.

[0069] By way of example and not limitation, in this embodiment, the terminal device can also be a wearable device. Wearable devices, also known as wearable smart devices, are a general term for devices that utilize wearable technology to intelligently design and develop everyday wearables, such as glasses, gloves, watches, clothing, and shoes. Wearable devices are portable devices that are worn directly on the body or integrated into the user's clothing or accessories. Wearable devices are not merely hardware devices, but also achieve powerful functions through software support, data interaction, and cloud interaction. Broadly speaking, wearable smart devices include those that are feature-rich, large in size, and can achieve complete or partial functions without relying on a smartphone, such as smartwatches or smart glasses, as well as those that focus on a specific type of application function and require the use of other devices such as smartphones, such as various smart bracelets and smart jewelry for vital sign monitoring.

[0070] The technical solution of this application will be further described below by way of embodiments, such as... Figure 2 The diagram shown is an embodiment of a method for disabling SELinux in this application, which may include:

[0071] 201. Check if the value of android.verifiedbootstate in the kernel boot parameter cmdline is equal to orange.

[0072] For example, the terminal device detects whether the value of android.verifiedbootstate in the kernel boot parameter cmdline is equal to orange (yellow).

[0073] Understandably, Android Verified Boot (AVB) verifies the integrity of the software running on a user's device. It typically begins with a read-only portion of the device firmware, which loads code and executes it only after verifying, via password, that the code is authorized and that there are no known security vulnerabilities.

[0074] Upon startup, the system first checks the device's boot status. Device status indicates the degree of freedom allowed to flash software onto the device and whether verification is enforced. Device statuses are locked and unlocked. A locked device prevents new software from being flashed, while an unlocked device allows modifications. This is why unlocking the device is necessary before rooting.

[0075] When a terminal device powers on, the bootloader first checks whether the device is locked or unlocked. If the device is unlocked, the bootloader displays a warning to the user and then continues booting, even if the loaded operating system fails verification. The bootloader communicates the boot-time verification state to Android via kernel command options. It sets the `androidboot.verifiedstate` option to one of the following values, indicating that boot verification issues are categorized as follows:

[0076] Green: The device is locked and not using a user-configurable root of trust;

[0077] Yellow: The device is locked and uses a user-configurable root of trust. This is a warning screen for locked devices with a custom root of trust.

[0078] Orange: Warning screen for unlocked devices;

[0079] Red (EIO): Warning screen for dm-verity corruption;

[0080] Red (Operating System Not Found): No valid operating system was found.

[0081] In the fastboot code, the `cat / proc / cmdline` command searches for `androidboot.verifiedbootstate = orange`. In `system / core / fs_mgr / libfs_avb`, `IsDeviceUnlocked` is provided, returning the unlocked state.

[0082] 202. If it is not equal to orange, then the terminal device is determined to be in an unlocked state, and the register structure selinux_state and parameter new_value are obtained.

[0083] Optionally, obtaining the register structure selinux_state and parameter new_value may include: retrieving the structure selinux_state from regs[0] and the parameter new_value from regs[1] in the pt_regs register.

[0084] It should be noted that, based on the analysis of the Linux source code, the function call flow of SELinux when it is shut down (combining the two shutdown methods in the existing schemes) can be found in code snippets (1) and (2), as follows:

[0085] Code snippet (1):

[0086]

[0087] Code snippet (2):

[0088] Expand the sel_write_enforce() function:

[0089]

[0090] For example, referring to the function call method of selinux_status_update_setenforce (code snippet-2), the first parameter of this system call is the selinux_state structure state. According to the source code analysis, it can be seen that the new_value input by the user will be updated in the selinux_state structure state and applied to the system. Therefore, the technical solution of this application retrieves the first selinux_state structure from regs[0] of the pt_regs register and retrieves the second parameter new_value from regs[1].

[0091] 203. When the parameter new_value is equal to 0, the enforce value in the selinux_state structure is set to 1 so that SELinux is enabled.

[0092] For example, it is determined whether the parameter new_value is equal to 0, that is, whether the user space should disable SELinux. If the parameter new_value is equal to 0, that is, SELinux should be disabled, the terminal device assigns the value of enforce in the structure selinux_state to 1, so that SELinux is enabled, that is, SELinux is disabled.

[0093] This can also be understood as forcibly re-enabling SELinux by resetting the enforce value in the selinux_state structure to 1; thus causing the previous attempt to set the enforce value in the selinux_state structure to 0 to fail and restore it to 1.

[0094] Optionally, the terminal device may be running a Linux system.

[0095] Optionally, the terminal device is an AOSP (Android Open Source Project) terminal device with a Linux system.

[0096] That is, the technical solution of this application is not only applicable to AOSP terminal devices, but also applicable to terminal devices of any commercial Linux system.

[0097] In this embodiment, the value of `android.verifiedbootstate` in the kernel boot parameter `cmdline` is checked to see if it equals `orange`. If it does not equal `orange`, the terminal device is determined to be in a locked state. The `selinux_state` structure and the parameter `new_value` in the register are obtained. If the parameter `new_value` equals 0, the `enforce` value in the `selinux_state` structure is set to 1 to enable SELinux. This is used in commercially available terminal device products to prevent SELinux from being disabled by determining that the terminal device is in a locked state and setting the `enforce` value in the `selinux_state` structure to 1 when the parameter `new_value` equals 0.

[0098] This application, while meeting GKI 2.0 requirements, requires no modification to the kernel source code and conforms to current AOSP requirements and development trends. Furthermore, it utilizes SELinux's necessary path checks for disabling certain processes by examining characters entered by the user in user space for the `enforce` node; if such actions are detected, they are intercepted and recorded.

[0099] like Figure 3The diagram shown illustrates another embodiment of the method for disabling SELinux in this application, which may include:

[0100] 301. Use register_kretprobe to register a pre_handler hook point with the selinux_status_update_setenforce function for monitoring.

[0101] For example, the terminal device uses register_kretprobe to register a pre_handler hook point with the selinux_status_update_setenforce function for monitoring.

[0102] 302. Check if the value of android.verifiedbootstate in the kernel boot parameter cmdline is equal to orange.

[0103] Optionally, detecting whether the value of android.verifiedbootstate in the kernel boot parameter cmdline is equal to orange may include: detecting whether the value of android.verifiedbootstate in the kernel boot parameter cmdline is equal to orange through the hook point.

[0104] For example, a terminal device can determine whether it is in an unlocked state by detecting whether the value of android.verifiedbootstate in the kernel boot parameter cmdline is equal to orange.

[0105] 303. If it is not equal to orange, then the terminal device is determined to be in an unlocked state, and the register structure selinux_state and parameter new_value are obtained.

[0106] Optionally, obtaining the register structure selinux_state and parameter new_value may include: retrieving the structure selinux_state from regs[0] and the parameter new_value from regs[1] in the pt_regs register.

[0107] 304. If the value is equal to orange, then the terminal device is determined to be unlocked, and the check is stopped.

[0108] For example, if the value of `android.verifiedbootstate` is not `orange`, it indicates that the terminal device is in a locked state (locked), and the `selinux_state` structure and the parameter `new_value` in the register are retrieved. If the value of `android.verifiedbootstate` is `orange`, it indicates that the terminal device is in an unlocked state (unlocked), and the current check is terminated. This is because an unlocked state indicates that the terminal device is no longer trusted, so protection is no longer provided.

[0109] 305. If the parameter new_value is equal to 0, set the value of enforce in the structure selinux_state to 1 so that SELinux is enabled.

[0110] 306. If the parameter new_value is not equal to 0, determine that SELinux is enabled and stop the check.

[0111] For example, the terminal device determines whether the parameter new_value is equal to 0 (to confirm whether the user space should disable SELinux). If the parameter new_value is equal to 0, it means that the user space should disable SELinux, and the enforce value in the selinux_state structure is set to 1 to enable SELinux. If the parameter new_value is not equal to 0, it is determined that the user space should not disable SELinux, that is, SELinux is enabled, so the check stops.

[0112] Optionally, determining that SELinux is enabled and stopping the check when the parameter new_value is not equal to 0 may include: determining that SELinux is enabled and stopping the check when the parameter new_value is equal to 1.

[0113] For example, if the parameter new_value equals 1, it is determined that the user space is not disabling SELinux, i.e., SELinux is enabled, so the check stops.

[0114] Optionally, the method may further include: when a security event is detected at the kernel layer, transmitting the event information of the security event to the user layer; and through the user layer, reporting the event information to the backend server.

[0115] For example, the terminal device saves key data of security events, such as process permissions and process names, and uploads them to kevent for data tracking.

[0116] Optionally, the step of transmitting the event information of the security event to the user layer when a security event is detected in the kernel layer includes: transmitting the event information of the security event to the data reporting module of the kernel layer when a security event is detected in the kernel layer; transmitting the event information to a preset reporting channel between the kernel layer and the user layer through the data reporting module; the event information includes an event type; and obtaining the event information from the preset reporting channel through a user process in the user layer.

[0117] Optionally, reporting the event information to the backend server through the user layer includes: performing reporting processing on the event information according to the event type of the event information through the user process, so as to report the event information to the backend server.

[0118] Optionally, the step of performing the reporting process on the event information according to the event type through the user process may include: parsing the event type from the event information through the user process; when the event type is an execution type, saving the event information in a preset linked list through the user process; and saving the event information in the preset linked list to a local log according to a preset time interval; when the event type is a privilege escalation type, obtaining the application package name corresponding to the event information through the user process, saving the application package name and the event information to the local log, and displaying a pop-up on the terminal device interface through the user process; when the event type is a mount type, saving the event information to the local log; and reporting the local log to the backend server through a data acquisition service for analysis and processing by the backend server.

[0119] (1) When the event type is execution type, the event information is saved in the preset linked list through the user process; and the event information in the preset linked list is saved to the local log according to the preset time interval.

[0120] In this embodiment, when the event type is execution type, it indicates a security issue arising in the kernel layer where the security context of the executable file does not correspond. The terminal device calls the user-layer's save module through the user process to save the event information in a preset linked list. The save module's functionality is also implemented during the user-layer's initialization phase.

[0121] In this embodiment of the application, since the executable file is run many times when the terminal device is working normally, the execution type security events will occur more frequently. Therefore, in order to avoid frequent writing operations to the local log, the terminal device will first save the event information in a preset linked list. Every preset time interval, or when the preset linked list storage space is full, or when other event types of security events occur, such as mounting type security events, the event information in the preset linked list will be transferred to the local log for saving, so that the local log can be uploaded to the backend server later.

[0122] (2) When the event type is privilege escalation type, the application package name corresponding to the event information is obtained through the user process, the application package name and event information are saved to the local log, and a pop-up is displayed on the terminal device interface through the user process.

[0123] In this embodiment of the application, when the event type is privilege escalation, it indicates that a system call instruction has illegally obtained the highest system privileges. This type of security event has a high security risk. The terminal device will further obtain the application package name corresponding to the event information through the user process, that is, the application name that initiated the system call instruction. Then, through the storage module, the application package name and the corresponding event information are stored together in the local log.

[0124] In this embodiment, the application package name corresponding to the privilege escalation event information indicates a malicious program that may be attempting to illegally obtain the highest system privileges. The terminal device saves the application package name and event information together for subsequent uploading to the backend server, where such malicious programs can be traced.

[0125] In this embodiment of the application, since privilege escalation type security events pose a high security risk, the terminal device will further call the pop-up module responsible for interface display in the user layer through the user process to display a pop-up prompt on the terminal device interface to warn the user that a high-risk program is currently accessing the system's highest privileges.

[0126] (3) When the event type is mount type, the event information is saved to the local log.

[0127] In this embodiment of the application, when the event type is mount type, it indicates that a partition mount instruction has illegally tampered with the read and write permissions of the preset system partition. The terminal device saves the event information of the mount type in the local log through the storage module.

[0128] In this embodiment, the value of `android.verifiedbootstate` in the kernel boot parameter `cmdline` is checked to see if it equals `orange`. If it does not equal `orange`, the terminal device is determined to be in a locked state, and the register structure `selinux_state` and parameter `new_value` are obtained. If `new_value` equals 0, the `enforce` value in the `selinux_state` structure is set to 1 to enable SELinux. This is used in commercially available terminal devices to prevent SELinux from being disabled by determining that the terminal device is in a locked state and setting `enforce` to 1 in the `selinux_state` structure when `new_value` equals 0. This application complies with GKI 2.0 requirements and is implemented entirely in .ko file format. It does not compromise kernel integrity and is applicable to all Android manufacturers. By checking the necessary path for SELinux disabling and examining the characters entered by the user in the `enforce` node, it confirms whether the user has disabled the SELinux. If so, it is intercepted and recorded. This will prevent SELinux from being disabled in commercially available terminal products; any attempt to disable SELinux will be blocked and recorded.

[0129] like Figure 4 The diagram shown is a schematic of a device for disabling SELinux in an embodiment of this application, which may include:

[0130] Processing module 401 is used to detect whether the value of android.verifiedbootstate in the kernel boot parameter cmdline is equal to orange; if it is not equal to orange, it determines that the terminal device is in an unlocked state, obtains the structure selinux_state and parameter new_value of the register; if the parameter new_value is equal to 0, it assigns the value of enforce in the structure selinux_state to 1 so that SELinux is enabled.

[0131] Optionally, the processing module 401 is also used to register a pre_handler hook point with the selinux_status_update_setenforce function using register_kretprobe for monitoring; and to detect whether the value of android.verifiedbootstate in the kernel boot parameter cmdline is equal to orange through the hook point.

[0132] Optionally, the processing module 401 is specifically used to retrieve the structure selinux_state from regs[0] in the pt_regs register and the parameter new_value from regs[1].

[0133] Optionally, the processing module 401 is further configured to transmit the event information of the security event to the user layer when a security event is detected in the kernel layer; and report the event information to the background server through the user layer.

[0134] Optionally, the processing module 401 is also used to determine that the terminal device is in an unlocked state and stop the check if the value is equal to orange.

[0135] Optionally, the processing module 401 is also configured to determine that SELinux is enabled and stop checking if the new_value is equal to 1.

[0136] Optionally, the terminal device may be running a Linux system.

[0137] like Figure 5 The diagram shown is a schematic representation of an embodiment of the terminal device described in this application, including, as follows: Figure 4 The device shown is one that prevents SELinux from being disabled.

[0138] like Figure 6 The diagram shown is a schematic representation of another embodiment of the terminal device in this application, which may include:

[0139] Figure 6 This diagram illustrates a partial structural representation of a mobile phone related to the terminal device provided in this embodiment. (Reference) Figure 6 The mobile phone includes components such as a radio frequency (RF) circuit 610, a memory 620, an input unit 630, a display unit 640, a sensor 650, an audio circuit 660, a wireless fidelity (Wi-Fi) module 670, a processor 680, and a power supply 690. Those skilled in the art will understand that... Figure 6 The mobile phone structure shown does not constitute a limitation on the mobile phone and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0140] The following is combined Figure 6 A detailed introduction to each component of a mobile phone:

[0141] RF circuit 610 can be used for receiving and transmitting signals during information transmission or calls. Specifically, it receives downlink information from the base station and processes it with processor 680; additionally, it transmits uplink data to the base station. Typically, RF circuit 610 includes, but is not limited to, an antenna, at least one amplifier, a transceiver, a coupler, a low-noise amplifier (LNA), a duplexer, etc. Furthermore, RF circuit 610 can also communicate wirelessly with networks and other devices. The aforementioned wireless communication can use any communication standard or protocol, including but not limited to Global System for Mobile Communications (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.

[0142] The memory 620 can be used to store software programs and modules. The processor 680 executes various functions and data processing of the mobile phone by running the software programs and modules stored in the memory 620. The memory 620 may mainly include a program storage area and a data storage area. The program storage area may store the operating system, applications required for at least one function (such as sound playback function, image playback function, etc.), etc.; the data storage area may store data created according to the use of the mobile phone (such as audio data, phonebook, etc.). In addition, the memory 620 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device.

[0143] The input unit 630 can be used to receive input numerical or character information, and to generate key signal inputs related to user settings and function control of the mobile phone. Specifically, the input unit 630 may include a touch panel 631 and other input devices 632. The touch panel 631, also known as a touch screen, can collect touch operations performed by the user on or near it (such as operations performed by the user using a finger, stylus, or any suitable object or accessory on or near the touch panel 631), and drive the corresponding connection devices according to a pre-set program. Optionally, the touch panel 631 may include two parts: a touch detection device and a touch controller. The touch detection device detects the user's touch position and the signal generated by the touch operation, and transmits the signal to the touch controller; the touch controller receives touch information from the touch detection device, converts it into touch point coordinates, sends it to the processor 680, and can receive and execute commands sent by the processor 680. In addition, the touch panel 631 can be implemented using various types such as resistive, capacitive, infrared, and surface acoustic wave. In addition to the touch panel 631, the input unit 630 may also include other input devices 632. Specifically, other input devices 632 may include, but are not limited to, one or more of the following: physical keyboard, function keys (such as volume control buttons, power buttons, etc.), trackball, mouse, joystick, etc.

[0144] The display unit 640 can be used to display information input by the user or information provided to the user, as well as various menus of the mobile phone. The display unit 640 may include a display panel 641, which may optionally be configured as a liquid crystal display (LCD), organic light-emitting diode (OLED), or similar display. Furthermore, a touch panel 631 may cover the display panel 641. When the touch panel 631 detects a touch operation on or near it, it transmits the information to the processor 680 to determine the type of touch event. Subsequently, the processor 680 provides corresponding visual output on the display panel 641 based on the type of touch event. Although in Figure 6 In this embodiment, the touch panel 631 and the display panel 641 are two separate components to realize the input and output functions of the mobile phone. However, in some embodiments, the touch panel 631 and the display panel 641 can be integrated to realize the input and output functions of the mobile phone.

[0145] The mobile phone may also include at least one sensor 650, 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. The ambient light sensor can adjust the brightness of the display panel 641 according to the ambient light level, and the proximity sensor can turn off the display panel 641 and / or backlight when the phone is moved to the ear. As a type of motion sensor, an accelerometer sensor can detect the magnitude of acceleration in various directions (generally three axes). When stationary, it can detect the magnitude and direction of gravity, and can be used for applications that recognize the phone's posture (such as landscape / portrait switching, related games, magnetometer posture calibration), vibration recognition-related functions (such as pedometer, taps), etc. Other sensors that may be configured in the mobile phone, such as gyroscopes, barometers, hygrometers, thermometers, and infrared sensors, will not be described in detail here.

[0146] Audio circuit 660, speaker 661, and microphone 662 provide an audio interface between the user and the mobile phone. Audio circuit 660 converts received audio data into electrical signals and transmits them to speaker 661, where speaker 661 converts them into sound signals for output. On the other hand, microphone 662 converts collected sound signals into electrical signals, which are received by audio circuit 660, converted into audio data, and then output to processor 680 for processing. The audio data is then transmitted via RF circuit 610 to, for example, another mobile phone, or output to memory 620 for further processing.

[0147] Wi-Fi is a short-range wireless transmission technology. Through the Wi-Fi module 670, mobile phones can help users send and receive emails, browse web pages, and access streaming media, providing users with wireless broadband internet access. Although Figure 6 The Wi-Fi module 670 is shown, but it is understood that it is not a necessary component of the mobile phone and can be omitted as needed without changing the nature of the application.

[0148] The processor 680 is the control center of the mobile phone, connecting various parts of the phone through various interfaces and lines. It executes software programs and / or modules stored in the memory 620, and calls data stored in the memory 620 to perform various functions and process data, thereby providing overall monitoring of the phone. Optionally, the processor 680 may include one or more processing units; preferably, the processor 680 may integrate an application processor and a modem processor, wherein the application processor mainly handles the operating system, user interface, and applications, and the modem processor mainly handles wireless communication. It is understood that the modem processor may also not be integrated into the processor 680.

[0149] The mobile phone also includes a power supply 690 (such as a battery) that supplies power to various components. Preferably, the power supply can be logically connected to the processor 680 through a power management system, thereby enabling functions such as charging, discharging, and power consumption management through the power management system.

[0150] Although not shown, mobile phones may also include a camera, Bluetooth module, etc., which will not be described in detail here.

[0151] In this embodiment, the processor 680 is used to detect whether the value of android.verifiedbootstate in the kernel boot parameter cmdline is equal to orange; if it is not equal to orange, it determines that the terminal device is in an unlocked state, obtains the register structure selinux_state and parameter new_value; if the parameter new_value is equal to 0, it assigns the value of enforce in the structure selinux_state to 1 so that SELinux is enabled.

[0152] Optionally, the processor 680 is also used to register a pre_handler hook point with the selinux_status_update_setenforce function using register_kretprobe for monitoring; through the hook point, it detects whether the value of android.verifiedbootstate in the kernel boot parameter cmdline is equal to orange.

[0153] Optionally, processor 680 is used to retrieve the structure selinux_state from regs[0] in the pt_regs register and the parameter new_value from regs[1].

[0154] Optionally, the processor 680 is further configured to, when a security event is detected at the kernel layer, transmit the event information of the security event to the user layer; and through the user layer, report the event information to the background server.

[0155] Optionally, the processor 680 is also configured to determine that the terminal device is unlocked and stop the check if the value is equal to orange.

[0156] Optionally, the processor 680 is also configured to determine that SELinux is enabled and stop checking if the new_value is equal to 1.

[0157] Optionally, the terminal device may be running a Linux system.

[0158] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of the present invention are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can store or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state disk (SSD)).

[0159] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0160] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection between apparatuses or units through some interfaces, and may be electrical, mechanical, or other forms.

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

[0162] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0163] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0164] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A method of disabling SELinux shutdown, characterized by, The method is applied to a terminal device without Root authority after leaving factory, is based on a Kretprobe framework, and comprises the following steps: registering a pre_handler hook point of a selinux_status_update_setenforce function for monitoring by using register_kretprobe; detecting, through the hook point, whether an android.verifiedbootstate value in a kernel start parameter cmdline is equal to orange; if not equal to orange, determining that the terminal device is in an unlocked state, and obtaining a structure selinux_state of a register and a parameter new_value; in a case where the parameter new_value is equal to 0, assigning enforce in the structure selinux_state to 1, so as to turn on SELinux.

2. The method of claim 1, wherein, The obtaining of the structure selinux_state of the register and the parameter new_value comprises the following steps: obtaining the structure selinux_state from regs[0] of a pt_regs register and the parameter new_value from regs[1].

3. The method according to claim 1 or 2, characterized in that, The method further comprises the following steps: when detecting that a security event occurs in a kernel layer, transmitting event information of the security event to a user layer; reporting, by the user layer, the event information to a background server.

4. The method according to claim 1 or 2, characterized in that, The method further comprises the following steps: if equal to orange, determining that the terminal device is in an unlocked state, and stopping checking.

5. The method according to claim 1 or 2, characterized in that, The method further comprises the following steps: in a case where the new_value is equal to 1, determining that SELinux is in an on state, and stopping checking.

6. The method of claim 1 or 2, wherein, The system of the terminal device is a Linux system.

7. An apparatus for disabling SELinux, the apparatus comprising: The device is applied to a terminal device without Root authority after leaving factory, is based on a Kretprobe framework, and comprises the following steps: a processing module, configured to register a pre_handler hook point of a selinux_status_update_setenforce function for monitoring by using register_kretprobe, detect, through the hook point, whether an android.verifiedbootstate value in a kernel start parameter cmdline is equal to orange, determine that the terminal device is in an unlocked state if not equal to orange, and obtain a structure selinux_state of a register and a parameter new_value, and assign enforce in the structure selinux_state to 1 in a case where the parameter new_value is equal to 0, so as to turn on SELinux.

8. A terminal device, comprising: comprise the following: a memory storing executable program codes; a processor coupled with the memory; the processor is configured to execute the method in any one of claims 1-6.

9. A computer-readable storage medium comprising instructions which, when executed on a processor, cause the processor to carry out the method of any one of claims 1-6.

Images