Android provides third-party applications with an extensive permission API that includes access to phone hardware, settings, and user data. Access to privacy- and security-relevant parts of
the API is controlled with an install-time application permission system. In this article an overlook methodology and study is conducted regarding Android applications to determine whether Android developers follow least privilege with their permission requests. We have try to put results of a brief Android application system investigate to highlight the causes of over privilege and find evidence that developers are trying to follow least privilege but sometimes fail due to insufficient Google Android API documentation.
Google Android’s to some extent unrestricted application market and its declaration as open source have made it a popular platform for third-party mobile applications. According to statistics of 2011, the Android Market includes more applications than the Apple App Store . Android supports third party development with an extensive API that provides applications with access to phone hardware (e.g., the camera,sensors e.t.c), WiFi and cellular networks, user data, and phone settings.
Access to privacy- and security-relevant parts of Android’s Developer API is controlled by an install-time application permission system. Each application must declare upfront what permissions it requires, and the user is noticed during installation about what permissions it will receive. If a user does not want to grant a permission to an application, he or she can cancel the installation process.
Install-time permissions can provide users with control over their privacy and reduce the impact of bugs and vulnerabilities in applications. However, an install-time permission system is ineffective if developers routinely request more permissions than they require. Over privileged applications expose users to unnecessary permission warnings and increase the impact of a bug or vulnerability.
Android provides developer documentation, but its permission information is limited. The lack of reliable permission information may cause developer error. The documentation lists permission requirements for only 78 methods, whereas in an independent testing conducted by UC Berkeley there is a revelation of permission requirements for 1259 methods. This leads to the developer confusion and can result in over privileged application , because developer to make application work correctly adds unnecessary application permissions.
Android Permissions Classification
Permissions may be required when interacting with the system API, databases, and the message-passing system. Each application runs in a process with a low-privilege user ID, and applications can access only their own files by default. Each application runs in its own virtual machine. As User data is stored in Content Providers, and permissions are required to perform operations on some system Content Providers. For example, applications must have permission for READ_CONTACTS in order to execute READ queries on the Contacts Content Provider. Applications may or may not need permissions to receive Intents (i.e. messages) from the Android OS . Intents notify applications of events, such as a change in network connectivity, and some Intents sent by the system are delivered only to applications with appropriate permissions. Furthermore, permissions are also required to send Intents that mimic the contents of system Intents.
if we classify the permissions according to there threat level , we can generally categorized them into mainly three levels
- Normal Application Permissions
In normal application permissions a protection in terms of access is given to the API calls that could not harm the user. for example the ability to change user’s smart phone’s background picture by using SET_WALLPAPER.
- Dangerous Application Permissions
The permissions fall in this category can result in conducting the harmful events for the user. Like gathering of private information from contacts or various application credentials data , spending of money by sending msgs or making calls.
- Signature/System based Application Permissions
These permissions control access to privileges that are deemed as most dangerous. These permissions are some what difficult to obtain. Like the ability of application to control the backup process or deletion of application packages. Signature permissions are allowed only for the applications that are digitally signed with the device manufacturer’s certificate or installed in a special system folder.These restrictions essentially limit Signature/System permissions requests by other applications.
Applications can also define their own permissions for the purpose of self-protection.
Android Permission Enforcement Details
Inside Android Application Programming Interface
Now Let us take a look at the Android permission enforcement details.The Android API framework is mainly composed of 02- two parts:
one is a library that resides in each application’s virtual machine and second is an implementation of the API that runs in the system processes .
The API library runs with the same permissions as the application it accompanies, whereas the API implementation in the system process has no restrictions. The library provides the mechanism for interacting with the API implementation. API calls that read or change global phone state are proxied by the library to the API implementation in the system process.
API calls are handled in three steps:
- The application invokes the public API in the library.
- the library invokes a private interface(RPC stub), also in the library.
- the RPC stub initiates an RPC request with the system process that asks a system service to perform the desired operation.
It can be understandable by an example like if an application calls ClipboardManager.getText(), the call will be relayed to IClipboard$Stub$Proxy, which proxies the call to the system process’s ClipboardService.
Use of Java reflections
An android application can use Java reflection to access all of the Android API library’s hidden and private classes, methods, and fields. Some private interfaces do not have any corresponding public API; however, applications can still invoke them using reflection. These non-public library methods are intended for use by Google applications or the framework itself, and developers are advised against using them because they may change or disappear between releases. Nonetheless, some applications use them. Java code running in the system process is in a separate virtual machine and therefore immune to reflection.
read more in part-2 : Android Permissions a Careful concern, keep reading at inteliworld.com