Android runtime permission for system apps

Question

Question about Android runtime permissions. AFAIK, android grant dangerous permission at runtime. I reset my phone, then adb pull /data/system/users/0/runtime-permissions.xml, I found android.ui.system has already granted many dangerous permissions. can anybody tell me how it does?

Anthropologist

there are some permissions which doesn't need to be granted Refer here for detail:- coderzpassion.com/android-new-runtime-permissions – Petrify

thanks Jagjit. this is part of runtime-permissions.xml, <shared-user name="android.uid.system"> <item name="android.permission.READ_CALENDAR" granted="true" flags="30" /> <item name="android.permission.READ_CALL_LOG" granted="true" flags="30" /> <item name="android.permission.ACCESS_FINE_LOCATION" granted="true" flags="30" /> <item name="android.permission.RECEIVE_WAP_PUSH" granted="true" flags="30" /> <item name="android.permission.RECEIVE_SMS" granted="true" flags="30" /> – Anthropologist

as you can see, these permissions are dangerous permissions, they should be granted at runtime. but they have been granted when first boot, it's confused. – Anthropologist

have you upgraded your device from 5 to 6 ? – Roby

My Device is Android 6.0.1. should it because system set default runtime permission for "android.uid.system" somewhere? because this is a special system uid. – Anthropologist

Answer 1

The mechanism to insert dangerous runtime permissions into the /data/system/users/0/runtime-permissions.xml file via a user-confirmed dialog applies only to third party applications, and is not relevant for built-in applications.

For built-in/system applications and framework components, all permissions are granted by default when a new user is created or when the device boots and a systemReady event is fired.

You can see the AndroidManifest.xml from AOSP, where all types of required permissions are written for system components.

For third party apps, when the user grants any runtime permission, it gets added into the file /data/system/users/0/runtime-permissions.xml. The permission gets removed from the file when the user revokes it from any third party app. In the case of a full factory reset, runtime permissions of all third party apps are removed, as /data/system/users/0/runtime-permissions.xml gets deleted (data partition wipe).

But even after a factory reset, /data/system/users/0/runtime-permissions.xml contains runtime permissions (even dangerous ones) for system apps, see the default permissions: runtime-permissions.xml.

And it happens because:

All the default permissions are granted from PackageManagerService, via these two methods:

newUserCreated() //this get called when new user is created   
systemReady() //this get called when device is booted

and the above methods internally invoke:

DefaultPermissionPolicy.grantDefaultPermissions();

Have a look at How DefaultPermissionPolicy triggers

And if you see DefaultPermissionPolicy's implementation, it contains all the relevant method to load all type of permissions for System components.

Specifically DefaultPermissionPolicy.grantDefaultPermissions() internally calls

grantPermissionsToSysComponentsAndPrivApps(userId); grantDefaultSystemHandlerPermissions(userId);

and it internally invokes grantRuntimePermissionsLPw(), which performs all the remaining work.

Hod

Thanks shridutt kothari. in the beginning, no runtime-permissions.xml, then PackageManagerService started and generate runtime-permissions.xml. in order to understand this more clearly, can you help to point where runtime permissions granted for android.uid.system, as seen in runtime-permissions.xml file. – Anthropologist

I found below code in RuntimePermissionPersistence class. but I havn't find where PermissionState for android.uid.system been set to granted. – Anthropologist

final int sharedUserCount = permissionsForSharedUser.size(); for (int i = 0; i < sharedUserCount; i++) { String packageName = permissionsForSharedUser.keyAt(i); List<PermissionState> permissionStates = permissionsForSharedUser.valueAt(i); serializer.startTag(null, TAG_SHARED_USER); serializer.attribute(null, ATTR_NAME, packageName); writePermissions(serializer, permissionStates); serializer.endTag(null, TAG_SHARED_USER); } – Anthropologist

And also, you can find "android.permission.WRITE_CALENDAR" defined in AndroidManifest.xml from AOSP, but can not find this permission for android.uid.system in default runtime-permissions.xml. this means not all the dangerous permission is pre-granted for android.uid.system. – Anthropologist

@Anthropologist i have updated answer to answer all your queries, have a look, it should be more than sufficient for identifying from where default system permission are coming after factory reset. – Hod

Thanks Shridutt, it's very useful for me. I looked into the source code, find this, private void grantPermissionsToSysComponentsAndPrivApps(int userId) { Log.i(TAG, "Granting permissions to platform components for user " + userId); but I can not find this log after device booted. – Anthropologist

I wrote an app, use android.permission.WRITE_CALENDAR runtime permission, and use android:persistent="true" in the manifest, then signed with system signature, at last I put this apk into priv-app dir, then reboot, but the required runtime permission "android.permission.WRITE_CALENDAR" didn't been granted automatically. from the AOSP, it should be granted automatically from grantPermissionsToSysComponentsAndPrivApps(userId); – Anthropologist

@Anthropologist it's not gonna work like you are expecting, grantPermissionsToSysComponentsAndPrivApps will only give permission to apps which are registered in Android framework's Manifest (androidxref.com/6.0.1_r10/xref/frameworks/base/core/res/…) – Hod

Already accepted this answer, thanks Shridutt. And I found grantDefaultPermissions only call onetime, because when next time reboot, system found defaultpermissions already granted, then this function won't be called again. – Anthropologist

can you help to answer another question? #37187261 – Anthropologist

@shridutt kothari, What do you mean by "register"? At which part the apps are registered? – Accession

Answer 2

Privileged Permission Allowlisting

Device manufacturers had little control over which signature|privileged permissions could be granted to privileged apps. Starting in Android 8.0, manufacturers must explicitly grant privileged permissions in the system configuration XML files in the /etc/permissions directory.

Android allow system apps present in these directories(system/product/vendor/oem/ | _ext) to whitelist their permissions via writing a XML file.

1. XML file content: <permissions> <privapp-permissions package="x.y.z"> <permission name="android.permission.PACKAGE_USAGE_STATS" /> </privapp-permissions> </permissions>

2. Android.bp file: prebuilt_etc { name: "x.y.z.xml", system_ext_specific: true, src: "x.y.z.xml", sub_dir: "permissions", }

3. Add 'x.y.z.xml' to PRODUCT_PACKAGES to make this part of final image (same as for an app)

4. On target: XML file can be found under 'partition/etc/permissions/priv-app'

5. PackageManager parse all the XML files and whitelist the permissions mentioned for the package name while install the app on boot.

Congruency