Android has the capacity to defined shared applications. In this article, we briefly introduce this concept, the consequences on your privacy and then detail how Protektoid can help you with that.
Presentation of the concept
Short technical note
Applications of a same development company can be grouped and rely on one system user, defined by its UID. Two applications can then automatically share their data, both on the file system and runtime. To do this, development companies rely on the Android Concept of SharedUserId.
Two applications A and B with the same SharedUserId and developed by the same company also share other informations, such as security details and permissions.
Before Marshmallow, this permission sharing was displayed on the application information, system level, for each of them. This is not the case since Marshmallow (at least not until today, July 12, 2017).
Consequences on your privacy
As far as we are concerned, we believe this can have major impacts:
- it is not easy to know, after install, if two applications were built and signed by the same company, unless you rely on specific security apps
- information displayed by the system are not 100% trustworthy anymore and it thus not easy to know which application can do what
- most of the security applications just ignore this concept of shared permissions
An example: if application A asks for Internet access and B asks for Contacts, both A and B can send your contact details to a remote third party on Internet. Howerver, A only displays Internet permission and B only displays the Contact one.
How to display inherited permissions on Protektoid?
The activation of the inherited permission display is done at the Setting level of Protektoid. You only need to open Settings page and scroll down up to "Advanced Settings". If "Show inherited permissions" says "OFF", just click on "OFF" and it will become "ON".
As we believe this concept is critical, we decided to enable it by default.
How to control inherited permissions on Protektoid?
After activating the display of inherited permissions, you will now be able to see them directly on the page of each application that do have such permissions. If we go back to our example, opening application A on Protektoid will show you that A can access Contact thanks to the application B.
The following picture illustrates a concrete case we encountered.
Of course, the next question is "what next ?"
At the time of writing, Android does not support the capacity to disable permissions gained by inheritance. However, Protektoid let you
- flag an inherited permission as undesired
- know from which application(s) an inherited permission is gained, in order to eventually disable it directly (such as disabling Contact from B to prevent A from having access to your contacts)
Side notes, during on our talk at the French NDH XV event (Nuit du Hack 2017)
If you want more details about our talk at the French NDH XV event, please check the Nuit Du Hack website, https://nuitduhack.com/en, or reach us out! The video of our talk shall be on-line soon, as for the slides. We talked about, among others and with different technical explanations, how permissions are implemented on the Android Open Source Project (AOSP) and the market status.
Conference slides are also available on https://lab.protektoid.com/public/assets/ndh2017.pdf.
When considering Android, it is important to know that the choice made to not display inherited permissions has various consequences on the trust regarding information displayed by the system, data available to third parties, such as security applications, etc. Only our deep analysis of the AOSP let us detect, understand and build an algorithm to detect and retrieve these inherited permissions.
When considering the current status of the security applications, it is important to know that no other application but Protektoid offers you such a clear and complete understanding about which applications can do what, why, and how to review and configure them, may these permissions be grouped, enabled or disabled inherited or not!