Android 7.0 SEAndroid app Permission Configuration Method

1. SEAndroid app classification

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

1) untrusted_app the third party app has no Android platform signature and no system authority

2) platform_app has an Android platform signature and does not have system permissions

3) system_app has android platform signature and system authority

Divided from above, authority level, theoretically: untrusted_app < platform_app < system_app

2. Definition of seapp_contexts

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 two parameters, user and seinfo.

For example:

user=system seinfo=platform, domain is system_app

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

3. user and seinfo decision mode

First of all, look at user. user can be understood as UID. For example, ps-Z results are as follows:

u:r:system_app:s0    system 2414 1172 com.android.keychain 
u:r:platform_app:s0   u0_a6  2439 1172 com.android.managedprovisioning 
u:r:untrusted_app:s0   u0_a8  2460 1172 com.android.onetimeinitializer 
u:r:system_app:s0    system 2480 1172 com.android.tv.settings 
u:r:untrusted_app:s0   u0_a27 2504 1172 com.android.email 
u:r:untrusted_app:s0   u0_a28 2523 1172 com.android.exchange 
u:r:untrusted_app:s0   u0_a7  2567 1172 com.android.musicfx 

The first column is SContext, and the second column is UID. As long as UID is system, it is basically system_app, and vice versa.

Other U0_XXX are either platform_app or untrusted_app

seinfo is determined by system/sepolicy/mac_permissions. xml 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, and others such as shared, seinfo is default.

For example, in the above results of ps-Z, OneTimeInitializer. apk is untrusted_app, ManagedProvisioning. apk is platform_app.

Look at Android. mk for these two app respectively

packages\ apps\ OneTimeInitializer\ Android. mk does not define LOCAL_CERTIFICATE, default is shared

packages\ apps\ ManagedProvisioning\ Android. mk has a definition LOCAL_CERTIFICATE: = platform

Because ManagedProvisioning. apk has an platform signature, seinfo is platform.

TvSettings is system_app, look at the corresponding parameters:

packages\ apps\ TvSettings\ Settings\ Android. mk Defined LOCAL_CERTIFICATE: = platform

packages\ apps\ TvSettings\ Settings\ AndroidManifest. xml Defined android: sharedUserId= "android.uid.system"

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

packages\ apps\ ManagedProvisioning\ AndroidManifest. xml does not define android: sharedUserId= "android. uid. system"

Therefore, although seinfo is platform, user is not system, so it is only platform_app, not system_app.

4. te file corresponding to app

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 by 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; 

Summary:

After the introduction of SEAndroid, app development needs to pay attention to which permissions are needed, and domain is determined according to configuration (shareuid and signature), thus determining the size of permissions.