October 25th, 2010 By Owais



Smartphones, combining the mobility and personal nature of cell phones with the strengths of desktop computers, are fast becoming popular. Android is the first mass-produced consumer-market open source mobile platform that allows developers to easily create applications and users to readily install them. However, giving users the ability to install third-party applications poses serious security concerns. While the existing security mechanism in Android allows a mobile phone user to see which resources an application requires, he has no choice but to allow access to all the requested permissions if she wishes to use the applications. There is no way of granting some permissions and denying others. Moreover, there is no way of restricting the usage of resources based on runtime constraints such as the location of the device or the number of times a resource has been previously used. In this paper, we present a Selective Permission Mechanism for Android( a policy enforcement framework for Android that allows a user to selectively grant permissions to applications as well as impose constraints on the usage of resources. We also describe an extended package installer that allows the user to set these constraints through an easy-to-use interface.


 In this report we have discussed the existing drawbacks in Android architecture. We have highlighted the default permission sequence an application requests for gaining access to resources. Further key application framework classes are brought under discussing from where our selective permission mechanism is included in the existing android permission mechanism.


The increased capabilities and computational power of smartphones have enabled an increasing number of enterprises to deploy specialized services targeted towards these next-generation platforms. These services combine the mobility of traditional cell phones with the computational strengths of desktop systems to enable applications such as e-ticketing, e-prescribing, social networks, mobile healthcare and pervasive content creation and sharing systems. With the increase in use of open mobile architecture, security risks and attacks are also increasing on these devices. Moreover, due to the mobility features and personal nature of mobile devices, security and privacy concerns are more threatening on these platforms than on desktop systems.

 Existing Android permission Architecture

In Android base framework, PackageManagerService class serves as a central point for dealing with every APR, except the APRs generated by system process or any process that belongs to root user, which is resolved earlier in ActivityManagerService class. Root user processes are recognized through uid value “0” while system processes are identified by UID value “1000”.

 Initially, checkPermission() method of ApplicationContext class receive APR from caller application. ApplicationContext is a common implementation of Context API, which is an abstract class that allows access to application specific resources . The incoming request is then forwarded to ActivityManagerService class

Drawbacks of existing Architecture

  • Once application is installed the user can not change these permissions
    • The only way to revoke permissions from the application is to uninstall the application
  • Android’s existing security architecture does not provide a check on the usage of a resource
    • If an application is granted permission to access a resource e-g GPRS at install time, it will have unlimited access to it
  • Privacy Issues:    An application can easily violate users privacy e-g through access to GPS.

 Proposed Solution

  • To counter the drawbacks in the current security architecture we have proposed a comprehensive policy enforcement mechanism for the Android platform called Selective permission mechanism for Android(SPMA)
    • SMPA gives a mobile user several options for restricting the usage of phone resources by different applications
    • The user may grant some permissions and deny others at install time
    • SMPA also allows the user to impose runtime constraints on the usage of resources e.g. an application cannot send more than 10 SMS in a day. 

Modifications to Android Base Framework

 We have placed three new hooks and introduced two additional classes – PolicyEvaluator and PermissionManger, to enhance the current security policy enforcement mechanism of Android. First hook placed in PackageParser class populates the permission status and permission sequence repositories. Second hook positioned at PackageMangerService class forward every incoming APR to newly introduced PolicyEvaluator class. Finally, third hook in ApplicationContext, transfer session information to PolicyEvaluator. These modifications introduce two new features; runtime permission customization and runtime behavior monitoring in the Android platform.

Modification to incorporate customization of permissions

We have developed PermissionManager that enable user to customize application permissions. It provides a GUI, which displays a list of all applications installed on the device and their respective permissions requested by them at install time. GUI allows user to assign application mode either Restricted or UnRestricted.  In Restricted mode user can customize the permissions with the help of check box associated with each permission. The permission repository handles the process at back end. The Figure clearly states the application mode and shows that user has revoked the INTERNET permission from “SoundRecorder” application.


Runtime Behavior Monitoring

PolicyEvaluator class is responsible for runtime evaluation of applications. Every APR (application program resource) generated by any caller application is received by PackageManagerService class, where we have placed a hook that forwards every incoming APR to PolicyEvaluator class. It first checks the permission file to find out the mode of caller application. The APR generate by any unrestricted mode application is handled through traditional permission checking mechanism of Android . However, if APR is generated by any restricted mode application, then checkPermissionStatus() method of PolicyEvaluator is called. If user revoked the requested permission for that specific caller application using PermissionManager then APR is denied straight away. Otherwise, it further investigates the APR by calling evaluatePolicy() method. It first checks and update the history of caller application maintained into permission repository. The Sequence attribute of permission repository is associated with each permission tag. It records the sequence of permissions in a way they are exercised by caller application. Note that sequences are kept for every single session separately. Upon session termination, the value of sequence attribute is reset to zero. The Figure shows that AlarmClock application has exercised the CALL_PHONE permission first and then ACCESS_COARSE_LOCATION at second. The sequence attribute having value zero shows that the respective permission has not been exercised yet in current section.

After retrieving history profile from permission repository, EvaluatePolicy() compares the extracted permission sequences with the policies stored into policy repository . Each policy in the policy repository contains a set of permissions with a certain sequence which can be harmful for the user’s privacy or resources of the device. If a match is found, the system notifies user about the potential harmful APS. GUI prompt users with couple of ALLOW & DENY tabs, and a Check Box. The further execution of application is on user disposal by selecting ALLOW or vice versa, while user can also report to system about not to notify for this particular APS against this current caller application in future.

1 Responses to " easip-web3 "
Bahar Ali
October 27th, 2010

Great work, very comprehensive & Conceptual approach to the project work.
keep up the good work.

Leave a Reply