Permissions history

[ao-anssi]

As a user I would have liked to see if I forgot to remove a permission I gave to an app, or if an app was given a permission without my knowing (noticing) it. To do so I think that it may be useful to have a sort of history of granted/revoked permissions. The difference with the privacy dashboard is that it would show the grant of permissions potentially before they are used.

If you think that it would be useful I have implemented a small modification of aosp 12 that provides this functionnality with a little companion system app to display the permissions granting/revocation history.

[flawedworld]

Hi @ao-anssi we would be interested to evaluate this and adapt your changes. Please link the app/changes here when possible.

[ao-anssi]

Hello, Here are the links to the branch "permission_history" :

• https://github.com/ao-anssi/platform_system_sepolicy/tree/permission_history
• https://github.com/ao-anssi/platform_frameworks_base/tree/permission_history
• https://github.com/ao-anssi/platform_packages_apps_securityconfhistory/tree/permission_history
• https://github.com/ao-anssi/platform_build/tree/permission_history

NB : the code still contains some debug lines.

[ghost]

Hi @ao-anssi I'm trying to get this code building on AOSP 12.1 (GrapheneOS is now on Android 12.1) and your changes in frameworks/base is causing a very strange error that I don't know what to do about.

Here is the error: https://gist.github.com/Zanthed/931786cb114692b29e9ba1d810e78b92

I'm trying to figure it out, but would you have any ideas?

There's some code that's causing a memory leak because I have 25GB of memory, a 60GB swapfile, and 10 vCPUs so it is not because of memory but I don't know what.

[ghost]

I also believe we would like to rather integrate this menu into Settings -> Privacy -> Privacy Dashboard instead of bundling a companion app. It also makes more sense as permission usage history is already documented there and we can just add a button for it. Especially since it is a privileged app and we want to avoid bundling extra privileged apps as much as we can.

I have not taken a look at the companion app, but as far as I can tell it's just to read the results so we can most likely get this integrated into a separate area in Privacy Dashboard.

[ao-anssi]

Hello,

Thank you very much trying to integrate the patch I sent you. I am sorry for the error at compilation (I tried it on Android 12), I will look at it as soon as possible and tell you. It's fine for me if you put the display of permission history in the Privacy Dashboard (yes the app simply read the history). Here is I short video of the companion app

https://user-images.githubusercontent.com/100346278/158147930-8c65ab60-8578-4794-b523-453ed26676fb.mp4

[ao-anssi]

regarding the compilation issue I wouldn't be surprised if the problem was in the generation of the exposed api, for example the generation of the files like : frameworks/base/core/api/current.txt (removed.txt etc) . In android 12 they are updated by the command :

m api-stubs-docs-non-updatable-update-current-api

I tell you for the 12.1

[ao-anssi]

Hi I rebuilt from scratch the 12.1+the patches, it compiled without errors (the only difference with the 12 is that I made little changes to sepolicy because of the version 32 in 12.1, the 12 was in 31, but I think you did the same). Could you try the compilation with an empty "out" ?

[ghost]

Hi @ao-anssi it was actually a build error in my environment. I apologize. But yes thank you for verifying your code builds.

Two questions:

Is the companion app necessary to put it into Privacy Dashboard?

And is the Sqlite database necessary to have? I believe it's just for the companion app.

[ao-anssi]

Hi,

The sqlite database is were the service listening for the permission events store them, if you prefer you can use an other way to store them.

Sorry but I haven't understood your question "Is the companion app necessary to put it into Privacy Dashboard?"

[ao-anssi]

Actually the patch is quite basic and made of two services :

• a SecurityConfigurationHistoryService : listening to the PermissionManagerService and writing permission granting or revocation event to the database (with hooks in the functions : grantRuntimePermission, revokeRuntimePermission
• a SecurityConfigurationHistoryReaderService : used by applications to read the database

A SecurityConfigurationHistoryManager is defined that allows applications to use the SecurityConfigurationHistoryReaderService (for example it is used by the companion app). A hook is set in the UserController to start the recording, at the end of boot, by calling startRecording on SecurityConfigurationHistoryService to prevent the saving of permissions given by the system at boot time. The choice of having two services was driven by the need to hide the functions allowing to write into the database. I hope the debug lines I have left are not too confusing, I thought they may help in case of integration problem.

[ghost]

Thanks for the explanation. Will let you know if I have any more questions!