What are the benefits of the permission policy update on Android 8.0 and above? [closed]

Question

Android has slightly changed their permission policies on Android 8.0:

Prior to Android 8.0 (API level 26), if an app requested a permission at runtime and the permission was granted, the system also incorrectly granted the app the rest of the permissions that belonged to the same permission group, and that were registered in the manifest.

For apps targeting Android 8.0, this behavior has been corrected. The app is granted only the permissions it has explicitly requested. However, once the user grants a permission to the app, all subsequent requests for permissions in that permission group are automatically granted.

For example, suppose an app lists both READ_EXTERNAL_STORAGE and WRITE_EXTERNAL_STORAGE in its manifest. The app requests READ_EXTERNAL_STORAGE and the user grants it. If the app targets API level 25 or lower, the system also grants WRITE_EXTERNAL_STORAGE at the same time, because it belongs to the same STORAGE permission group and is also registered in the manifest. If the app targets Android 8.0 (API level 26), the system grants only READ_EXTERNAL_STORAGE at that time; however, if the app later requests WRITE_EXTERNAL_STORAGE, the system immediately grants that privilege without prompting the user.

What is the benefit of such change? It seems they achieve the same purpose. What could go wrong with the previous approach that the new one fixes?

Answer 1

What could go wrong with the previous approach that the new one fixes?

Well, you see, there was this bug...

Quoting the research paper, with emphasis added:

First, the adversary creates an app that includes in its manifest file a custom permission declaration with the protection level normal or signature and sets this custom permission to be a part of a system permission group (e.g., storage, camera etc.). Then, they update the definition of this custom permission so that the protection level is changed to dangerous and proceed to push an update to their app on the respective app market... The expectation is that since the custom permission is of level dangerous, the user will be prompted at runtime to make a decision on whether to grant or deny this permission in the runtime permission model. However, the malicious app automatically gets granted the permission. In addition, since the runtime permission model grants dangerous permissions on a group basis, the app also automatically obtains all the other requested dangerous permissions of the system permission group that the original permission belongs to. Same procedure can be followed to attack any system permissions group; hence, the adversary can silently obtain all system permissions simultaneously. Requesting dangerous permissions in the Android manifest constitutes no problems for the adversary, as permission requirements of an app are not directly presented to users at installation since Android 6.0. Hence, the user will be completely unaware that all these system permissions are granted to the app.

AFAICT, this Android 8.0 change was part of the mitigation strategy for this bug. This would only help a bit, and so I assume that other changes were made as well. However, given the nature of the bug presented in the paper and the nature of this Android 8.0, I have to assume that the two are at least somewhat related.