Android Application - Quanzhi T507 security policy

Platform: T507
System: Android 10.0
T507 Android system version is Android 10.0, and SELinux is enabled by default. SELinux based on MAC access control model can better protect our Android system, such as limiting the access rights of system services and controlling the access of applications to data and system logs, which reduces the impact of malware and prevents the impact on system security caused by code defects.
In terms of system security, SELinux is the God of protection, but in terms of software development, SELinux is a tie, which is a double-edged sword.

For example, when we develop applications or increase some permissions of system services, we must follow SELinux rules and set corresponding security policies for our applications, otherwise our applications do not have the permission to access data or devices.
Let's start with the MAC access control model and briefly sort out the T507 Android security policy and the methods to customize the T507 Android security policy.

Access control model, DAC, MAC

Access control refers to controlling access to a resource in a computer or network. Without it, everyone can access any resource. With access control, users must pass identification, authentication and authorization before obtaining actual access resources or operations.

DAC: Discretionary Access Control
The system identifies the user and determines the operation permissions of the user according to the permission settings of the operated object, such as read, write and exec.
The user with the permission of this object can assign the permission to other users, which is called "discretional".
The defect is that the permission control is relatively decentralized and inconvenient to manage. For example, it is impossible to simply set unified permissions for a group of files to a specified group of users.

Mandatory access control (MAC: Mandatory Access Control)
Mac is born to make up for the problem that DAC permission control is too decentralized. In the MAC model, the administrator manages access control. Administrators make policies that users cannot change. The policy defines which principal can access which object. This access control model can increase the security level because it is policy based and any operation that is not explicitly authorized cannot be performed. Mac is developed and implemented in systems that pay most attention to confidentiality, such as military systems. The subject is clearly marked, and the object is classified, or security level.

SElinux based on MAC

Reference link:

Usually, the software must run as the Root user account to write data to the original block device. In the traditional Linux environment based on DAC, if the Root user is invaded, the attacker can use the user identity to write data to each raw block device.
Since Android 4.3, SELinux has provided mandatory access control (MAC) protection for the traditional discretionary access control (DAC) environment. As part of the Android security model, Android uses security enhanced Linux (SELinux) to enforce mandatory access control (MAC) for all processes, even processes running with Root / super user privileges (Linux functions).
For example, you can use SELinux to label these devices so that processes assigned Root permissions can only write data to the devices specified in the relevant policies. As a result, the process cannot overwrite data and system settings outside a specific raw block device.
With SELinux, Android can better protect and restrict system services, control access to application data and system logs, reduce the impact of malware, and protect users from possible defects in the code on mobile devices.

The version of T507 Android system is Android10, and SELinux is enabled by default. Even if you obtain the root permission of the system, you can only write data to the devices specified in the relevant policies, so as to better protect and limit the system services and ensure the security of the system and data.

Labels, rules, and domains

SELinux relies on tags to match actions and policies. Labels are used to determine what is allowed. Sockets, files, and processes are labeled in SELinux. SELinux needs to refer to two points when making decisions: one is the label assigned to these objects, and the other is the strategy to define how these objects interact.

In SELinux, the tag takes the form of user:role:type:mls_level, where type is the main component of the access decision and can be modified by other components that make up the label. Objects are mapped to classes, and different access types to each class are represented by permissions.

Policy rules are in the following form: allow domains types:classes permissions;, Of which:

Domain - The label of a process or group of processes. It is also called domain type because it only refers to the type of process.
Type - The label of an object (for example, a file, socket) or a group of objects.
Class - The type of object (for example, file, socket) to access.
Permission - The operation to perform (for example, read, write).

Policy configuration source file

This is a device independent configuration and cannot be modified for devices in general
This is a device specific configuration based on BOARD_SEPOLICY_* Variable to select the policy configuration of the corresponding platform.

Taking T507 as an example, the path of T507 policy file is as follows:

OKT507-android-source/android$ ls device/softwinner/common/sepolicy/
private  vendor

Type Enforcement (TE) profile

The. Te file saves the domain, type definitions and rules of the corresponding object. Typically, there is a. Te file for each domain, such as installd.te. The device and file types are declared in device.te and file.te. Some files (such as domain.te, app.te) store sharing rules.

Take T507 as an example, T507 system_ The TE file path of app is as follows:


Label profile

1,file_contexts: file security context
2,property_contexts: attribute security context
Taking T507 as an example, the path of T507 security context file is as follows:


Seoandroid app category

SELinux (or seoandroid) divides app s into three main types (there are other domain types according to different user s):

1)untrusted_app is a third-party app without Android platform signature and system permission
2)platform_ The app is signed by the android platform and does not have system permission
3)system_ The app has android platform signature and system permission

Divided from the above, permission level, theoretically: untrusted_ app < platform_ app < system_ app

domain and type of APP

View seapp_ In the context file, the domain and type of the APP are determined by the user and seinfo parameters

isSystemServer=true domain=system_server_startup

user=_app seinfo=platform domain=traceur_app type=app_data_file levelFrom=all
user=system seinfo=platform domain=system_app type=system_app_data_file
user=bluetooth seinfo=platform domain=bluetooth type=bluetooth_data_file
user=network_stack seinfo=network_stack domain=network_stack levelFrom=all type=radio_data_file
user=nfc seinfo=platform domain=nfc type=nfc_data_file
user=secure_element seinfo=platform domain=secure_element levelFrom=all
user=radio seinfo=platform domain=radio type=radio_data_file
user=shared_relro domain=shared_relro
user=shell seinfo=platform domain=shell type=shell_data_file
user=webview_zygote seinfo=webview_zygote domain=webview_zygote
user=_isolated domain=isolated_app levelFrom=all
user=_app seinfo=app_zygote domain=app_zygote levelFrom=all
user=_app seinfo=media domain=mediaprovider type=app_data_file levelFrom=user
user=_app seinfo=platform domain=platform_app type=app_data_file levelFrom=user
user=_app isEphemeralApp=true domain=ephemeral_app type=app_data_file levelFrom=all
user=_app isPrivApp=true domain=priv_app type=privapp_data_file levelFrom=user
user=_app minTargetSdkVersion=29 domain=untrusted_app type=app_data_file levelFrom=all
user=_app minTargetSdkVersion=28 domain=untrusted_app_27 type=app_data_file levelFrom=all
user=_app minTargetSdkVersion=26 domain=untrusted_app_27 type=app_data_file levelFrom=user
user=_app domain=untrusted_app_25 type=app_data_file levelFrom=user
user=_app minTargetSdkVersion=28 fromRunAs=true domain=runas_app levelFrom=all
user=_app fromRunAs=true domain=runas_app levelFrom=user


Reference link:

User can be understood as UID. Android UID and Linux UID are two different things. Linux UID is used to distinguish users in multi-user operating system, while Android UID is used for system permission management.
The article in the reference link is very clear about the generation of uid.


Different signatures create the corresponding selinux context.

 have platform Signature, so seinfo yes platform. 


Reference documents

You can view the default signature file provided in the Android source code build/target/product/security / directory. There may be differences between different platforms:
T507 provides six signature files with different permissions: media, networkstack, platform, shared, testkey and verity.

Take T507 as an example to view the currently running application information:

console:/ # ps -Z
u:r:system_app:s0              system       15712  1861 1050628 110868 SyS_epoll_wait      0 S
u:r:untrusted_app_27:s0:c512,c768 u0_a62    30259  1861 1052120 114132 SyS_epoll_wait      0 S com.forlinx.changelogo

The UID(user) of the two currently running apps,, is system and has a platform signature. Its domain and type are system_app.

com.forlinx.changelogo does not set the default setting for UID, and its UID is u0_a62, and the signature file is not set. Its domain and type are untrusted_app.

T507 custom security policy

For the above two running apps, we add additional permissions to these two apps, and the corresponding TE configuration files are system_app.te,untrusted_app.te, the corresponding path is:


Take as an example. We add the execution permission of the can device:

OKT507-android-source/android$ vi device/softwinner/common/sepolicy/vendor/system_app.te

allow system_app vendor_shell_exec:file { getattr open read execute execute_no_trans };
allow system_app shell_exec:file { getattr open read execute execute_no_trans };
allow system_app shell:file { getattr open read execute execute_no_trans };

Analyze in the form of policy rule configuration (allow domains types:classes permissions):
domains: system_app
types: vendor_shell_exec
classes: file
permissions: getattr open read execute execute_no_trans

neverallow failures

Sometimes the permissions we added are not allowed by the default configuration of the system. For example, the permissions we added to to execute scripts are reported as follows:

libsepol.report_failure: neverallow on line 9 of system/sepolicy/private/system_app.te (or line 41463 of policy.conf) violated by allow system_app shell:file { read open };
libsepol.report_failure: neverallow on line 22 of system/sepolicy/private/shell.te (or line 40025 of policy.conf) violated by allow system_app shell:file { read open };
libsepol.check_assertions: 2 neverallow failures occurred

The default security policy path of the system is system/sepolicy /. According to the error prompt, we can modify the default configuration and modify system/sepolicy/private/system_app.te and system/sepolicy/private/shell.te to complete the authorization.

The above is the context of Android security policy and the method of customizing security policy under Android system of T507 platform.

Tags: Android

Posted on Thu, 02 Dec 2021 23:58:17 -0500 by brauchi