9

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?

Shridutt Kothari
  • 7,326
  • 3
  • 41
  • 61
user1890874
  • 283
  • 1
  • 2
  • 9

2 Answers2

25

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.

user2891462
  • 3,033
  • 2
  • 32
  • 60
Shridutt Kothari
  • 7,326
  • 3
  • 41
  • 61
  • 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. – user1890874 May 10 '16 at 08:26
  • I found below code in RuntimePermissionPersistence class. but I havn't find where PermissionState for android.uid.system been set to granted. – user1890874 May 10 '16 at 08:32
  • final int sharedUserCount = permissionsForSharedUser.size(); for (int i = 0; i < sharedUserCount; i++) { String packageName = permissionsForSharedUser.keyAt(i); List 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); } – user1890874 May 10 '16 at 08:32
  • 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. – user1890874 May 10 '16 at 08:44
  • @user1890874 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. – Shridutt Kothari May 10 '16 at 13:55
  • 1
    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. – user1890874 May 11 '16 at 09:45
  • 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); – user1890874 May 11 '16 at 09:49
  • @user1890874 it's not gonna work like you are expecting, grantPermissionsToSysComponentsAndPrivApps will only give permission to apps which are registered in Android framework's Manifest (http://androidxref.com/6.0.1_r10/xref/frameworks/base/core/res/AndroidManifest.xml) – Shridutt Kothari May 11 '16 at 12:45
  • 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. – user1890874 May 11 '16 at 13:42
  • 1
    can you help to answer another question? http://stackoverflow.com/questions/37186761/check-android-process-groups – user1890874 May 12 '16 at 12:29
  • @shridutt kothari, What do you mean by "register"? At which part the apps are registered? – Cengiz Kandemir Jun 05 '18 at 10:53
0

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.

Shailendra Yadav
  • 1,822
  • 1
  • 12
  • 16