SoFunction
Updated on 2025-04-04

Android 7.0 SEAndroid app permission configuration method

App Classification

SELinux (or SEAndroid) divides apps into three main types (depending on user, there are other domain types):

1) untrusted_app Third-party app, no Android platform signature, no system permissions

2) platform_app has Android platform signature, no system permissions

3) system_app has Android platform signature and system permissions

From the above, the permission level is divided, theoretically: untrusted_app < ​​platform_app < ​​system_app

2.seapp_contexts definition

system/sepolicy/seapp_contexts

isSystemServer=true domain=system_server 
user=system seinfo=platform domain=system_app type=system_app_data_file 
user=bluetooth seinfo=platform domain=bluetooth type=bluetooth_data_file 
user=nfc seinfo=platform domain=nfc type=nfc_data_file 
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=_isolated domain=isolated_app levelFrom=user 
user=_app seinfo=platform domain=platform_app type=app_data_file levelFrom=user 
user=_app domain=untrusted_app type=app_data_file levelFrom=user 

As can be seen from the above, domain and type are determined by the two parameters of user and seinfo.

for example:

user=system seinfo=platform, domain is system_app

user=_app, can be untrusted_app or platform_app, if seinfo=platform, it is platform_app.

and seinfo judgment method

First look at user. User can be understood as UID. For example, the result of ps -Z is as follows:

u:r:system_app:s0    system 2414 1172  
u:r:platform_app:s0   u0_a6  2439 1172  
u:r:untrusted_app:s0   u0_a8  2460 1172  
u:r:system_app:s0    system 2480 1172  
u:r:untrusted_app:s0   u0_a27 2504 1172  
u:r:untrusted_app:s0   u0_a28 2523 1172  
u:r:untrusted_app:s0   u0_a7  2567 1172  

The first column is SContext, and the second column is UID. As long as the UID is system, it is basically system_app, and the other way around.

Other U0_XXX either belong to platform_app or untrusted_app

seinfo is determined by system/sepolicy/mac_permissions.xml, and the content is as follows:

<!-- Platform dev key in AOSP --> 
<signer signature="@PLATFORM" > 
 <seinfo value="platform" /> 
</signer> 
 
<!-- All other keys --> 
<default> 
 <seinfo value="default" /> 
</default> 

That is, if the signature is platform, seinfo is platform, others such as shared, etc., seinfo is default.

For example, in the above results of ps -Z, it is untrusted_app and platform_app.

Check out these two apps separately

packages\apps\OneTimeInitializer\ LOCAL_CERTIFICATE is not defined, the default is shared

packages\apps\ManagedProvisioning\ has been defined LOCAL_CERTIFICATE := platform

Because there is a platform signature, seinfo is platform.

TvSettings is system_app, check the corresponding parameters:

packages\apps\TvSettings\Settings\LOCAL_CERTIFICATE := platform

packages\apps\TvSettings\Settings\ has defined android:sharedUserId=""

TvSettings user is system, seinfo is platform, so it is system_app

packages\apps\ManagedProvisioning\ android:sharedUserId="" is not defined

So although ManagedProvisioning is a platform, the user is not a system, so it is just a platform_app, not a system_app.

The corresponding te file

system_app -> system/sepolicy/system_app.te

untrusted_app -> system/sepolicy/untrusted_app.te

platform_app -> system/sepolicy/platform_app.te

The corresponding permissions are given through the allow statement, for example, only system_app can set prop:

# Write to properties 
unix_socket_connect(system_app, property, init) 
allow system_app debug_prop:property_service set; 
allow system_app net_radio_prop:property_service set; 
allow system_app system_radio_prop:property_service set; 
auditallow system_app net_radio_prop:property_service set; 
auditallow system_app system_radio_prop:property_service set; 
allow system_app system_prop:property_service set; 
allow system_app ctl_bugreport_prop:property_service set; 
allow system_app logd_prop:property_service set; 

Summarize:

After introducing SEAndroid, app development needs to pay attention to what permissions are needed, and determine the domain based on configuration (shareuid and signature), thereby determining the permission size.

The above article on Android 7.0 SEAndroid app permission configuration is all the content I share with you. I hope you can give you a reference and I hope you can support me more.