Permissions are one of the essential features in Android’s security design. Simply put, permissions define the behaviour of your Android device, or any computer system. They ask questions such as, what kind of App is this? Should a newly installed App be allowed to access the camera? Then follow up by informing the user and asking that person to explicitly allow or deny the App they presumably installed to make use of the camera. This complex system provides for the privacy of the user, and by restricting applications to specific permissions they are granted the overall security of the mobile device.
“A central design point of the Android security architecture is that no app, by default, has permission to perform any operations that would adversely impact other apps, the operating system, or the user.” - Android documentation
Check out this YouTube video on Managing Android Permissions.
How was this goal achieved? By building off the already complex structure of Linux permissions. Let's take a quick look at how basic Linux permissions work, and then discuss how Google expanded on that model. In Linux there are several basic permissions: Read, write, and execute. Each of these represents an elevated level of access to the Linux system, with the ability to read data being the lowest level and the ability to read, write, and execute on Apps and services being the highest. These three levels are supplemented by user access permissions, which define how much a user or group of users can modify the system. Each user and each group of users can be granted different levels of authority to make system-affecting decisions. Administrators naturally receive full authority, while other users and groups can be allotted less authority depending on their relationship to the system in question, for example they may be guests with no strong authority, or normal users with just enough authority to modify their own user experience and use permitted Apps.
Android takes these basic permissions which provide a moderate level of abstraction and expands them all to encompass and isolate as much of the system as possible. Every App and service installed on an Android device runs as its own user, with associated Apps and services belonging to a common group. This expansion of the user and group identity permissions allows the Android system to treat every App installed as an individual case, inform the person using the device of what that App is requesting permission to use, and receive explicit consent from that human being to do so. In CopperheadOS, we go the extra mile to lock down the permission scheme further.
That brings us to the next question: How does the Android system decide which permissions need to be granted by a person? By separating permissions into threat categories, the system knows that any component which contains, transmits or records user data is a dangerous permission. Any permission in this category requires human interaction for modification. Some of the components or features which fall into this category are:
- Camera, microphone and speakers.
- Network and phone
- Touch input.
- Any device specific components such as sensor packages for motion or temperature, step counters.
- The internal file system in which user data is stored.
Applications which bypass the Play Stores defenses are often malicious insofar as they cast a wide net over permission access without obvious or real requirements for the permissions requested. While Google is actively working on thwarting this threat, Android users should be cautious on the permissions required by each application and should map those requirements to the application’s function. A camera filter App asking for phone permissions should raise suspicions. Best practice would have the permission be denied. If the application doesn’t work because a suspicious permission isn’t granted then it’s probably a better idea to avoid the application, or a review of the applications history should be done. Having a user’s data siphoned off to unknowable parties is not worth the trade-off for convenience. Not all permission requests are malicious. Applications must ask for permission from a user. Often Android application developers will attempt to lessen troubleshooting problems by requesting more permissions than strictly necessary. It’s best to make sure users consistently curate their list of applications to avoid malware slipping through their scrutiny.
There is another category of permissions in the Android system provided to Accessibility services, designed to facilitate use of devices by persons with special needs. These permissions transcend the dangerous category as they have been given deep access to the Android system in order to provide necessary functions. For that reason, accessibility services make a very attractive target for malware. Accessibility services are granted access to overwrite the screen, simulate touch input and much more. This deep access can and is often abused by malware to achieve device administration privileges, install more malware, leak user data, and worse. It is very important that any Accessibility services installed on an Android system are sourced from only the most trustworthy sources, and should only be installed if necessary. Any App you may install which wants to run as an Accessibility service should be regarded as deeply suspicious. We recommend that Android users routinely review and curate their installed apps and especially scrutinize those with Accessibility Services access.