IEEE TRANSACTIONS ON INFORMATION FORENSICS AND …2228 IEEE TRANSACTIONS ON INFORMATION FORENSICS...

IEEE TRANSACTIONS ON INFORMATION FORENSICS AND SECURITY, VOL. 11, NO. 10, OCTOBER 2016 2227

Rethinking Permission Enforcement Mechanismon Mobile Systems

Yuan Zhang, Min Yang, Guofei Gu, and Hao Chen

Abstract— To protect sensitive resources from unauthorizeduse, modern mobile systems, such as Android and iOS, designa permission-based access control model. However, currentmodel could not enforce fine-grained control over the dynamicpermission use contexts, causing two severe security problems.First, any code package in an application could use the grantedpermissions, inducing attackers to embed malicious payloadsinto benign apps. Second, the permissions granted to a benignapplication may be utilized by an attacker through vulnera-ble application interactions. Although ad hoc solutions havebeen proposed, none could systematically solve these two issueswithin a unified framework. This paper presents the first suchframework to provide context-sensitive permission enforcementthat regulates permission use policies according to system-wideapplication contexts, which cover both intra-application contextand inter-application context. We build a prototype system onAndroid, named FineDroid, to track such context during theapplication execution. To flexibly regulate the context-sensitivepermission rules, FineDroid features a policy framework thatcould express generic application contexts. We demonstrate thebenefits of FineDroid by instantiating several security extensionsbased on the policy framework, for three potential users: endusers, administrators, and developers. Furthermore, FineDroidis showed to introduce a minor overhead.

Index Terms— Permission enforcement, application context,policy framework.

I. INTRODUCTION

MODERN mobile systems such as Android, iOS designa permission-based access control model to protect

sensitive resources from unauthorized use. In this model,the accesses to protected resources without granted permis-sions would be denied by the permission enforcement system.

Manuscript received October 15, 2015; revised March 2, 2016 andMay 17, 2016; accepted May 26, 2016. Date of publication June 15, 2016;date of current version July 8, 2016. This work was supported in part by theNational Program on Key Basic Research under Grant 2015CB358800, in partby the Science and Technology Commission of Shanghai Municipality underGrant 13511504402, Grant 15511103003, and Grant 13JC1400800, and in partby the National Natural Science Foundation of China under Grant 61300027.The work of Y. Zhang was supported in part by the Shanghai SailingProgram under Grant 16YF1400800 and in part by the Shanghai ExcellentAcademic Leader Funds under Grant 16XD1400200. The associate editorcoordinating the review of this manuscript and approving it for publicationwas Prof. Tansu Alpcan. (Corresponding author: Min Yang.)

Y. Zhang and M. Yang are with the Shanghai Key Laboratory of DataScience, School of Computer Science, Fudan University, Shanghai 201203,China (e-mail: [email protected]; [email protected]).

G. Gu is with the Department of Computer Science and Engineer-ing, Texas A&M University, College Station, TX 77840 USA (e-mail:[email protected]).

H. Chen is with the Department of Computer Science, University ofCalifornia at Davis, Davis, CA 95616-5270 USA (e-mail: [email protected]).

Color versions of one or more of the figures in this paper are availableonline at http://ieeexplore.ieee.org.

Digital Object Identifier 10.1109/TIFS.2016.2581304

Since Android has been expanding its market share rapidlyas the most popular mobile platform [1], this paper mainlyfocuses on the permission model of Android. Ideally,the Android permission model should prevent malicious appli-cations from abusing sensitive resources. Actually, due tosome features of the Android ecosystem, malicious entitiescould easily abuse permissions, leading to the explosion ofAndroid malware [2] and the numerous reported applicationvulnerabilities [3], [4] in the past few years.

To better understand this problem, we first studythe characteristics of current Android applicationecosystem.

• SDK incorporation is quite popular in mobile app devel-opment. With these SDKs, third-party apps can invokeweb services to provide rich functionalities in an easierway, such as posting messages to Twitter, navigatingusing Google maps.

• Except Google Play, a lot of third-party applicationmarkets exist in the Android application ecosystem.Due to the lack of centralized management, an app couldbe repackaged, e.g., with an embedded advertisementlibrary for profit, and redistributed through third-partymarkets.

• Application interaction is a built-in feature in Androidprogramming model. It is quite effective to ease appli-cation development. For example, a lot of social appsencourage clients to upload portraits. Without applicationinteraction, the app needs to support photo shootingand editing which is quite professional and complex.Fortunately, with application interaction, the app coulddelegate these functionalities to professional apps.

From the above analysis, we can find that there are manyprincipals (such as incorporated SDKs, repacked payloads,deputy apps) that collaboratively participate in the function-alities of an app, while current application-level permissionenforcement cannot precisely control the fine-grained permis-sions that each principal can use. Specifically, we summarizethe limitations of current permission model from the followingtwo aspects.

• Intra-application Context Insensitive. In existing per-mission model, each application is treated as a separateprincipal, while the above analysis indicates that thethe application code may be contributed by multipleparties (app developers, SDK providers, repackaged pay-load, etc). Current permission enforcement mechanism islimited in simply applying a single security policy for theentire app.

1556-6013 © 2016 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission.See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.

2228 IEEE TRANSACTIONS ON INFORMATION FORENSICS AND SECURITY, VOL. 11, NO. 10, OCTOBER 2016

• Inter-application Context Insensitive. Although appli-cation interaction is a common characteristic of mobileapplications, it is transparent to the current coarse-grained permission enforcement mechanism, exposing anew attack surface, i.e., the permissions granted to avulnerable application may be abused by an attackerapplication via inter-application communication.

Given these problems, plenty of extensions have been pro-posed to refine the Android permission model. Dr. Androidand Mr. Hide framework [5] provides fine-grained seman-tics for serval permissions by adding a mediation layer.SEAndroid [6] hardens the permission enforcement system byintroducing SELinux extensions to the Android middleware.FlaskDroid [7] extends the scope of current permission systemby regulating resource accesses in Linux kernel and Androidframework together within a unified policy language. Context-aware permission models [8]–[11] are proposed to supportdifferent permission policies according to external contexts,such as location, time of the day. However, these worksstill could not address the two limitations described above.There are also some work dedicated to reduce the risk of inter-application communication [11]–[15] or to isolate untrustedcomponents inside an application [16]–[19]. However, nonecould achieve unified and flexible control according to thesystem-wide application context.

In this paper, we seek to fill the gap by bringing context-sensitive permission enforcement. We design a prototype,called FineDroid to provide fine-grained permission controlover the application context (in this paper, when we say con-text we mean the application execution context). For example,if app A is allowed to use SEND_SMS permission in thecontext C, when app A requests SEND_SMS permission inanother context C’, it would be treated as a different requestof SEND_SMS permission. In FineDroid, we consider both theintra-application context which represents the internal execu-tion context of an application, and the inter-application contextwhich reflects the IPC context of interacted applications. It isnon-trivial to track such context in Android. FineDroid designsseveral techniques to automatically track such contexts alongwith the application execution. To ease the administration ofpermission control policies, FineDroid also features a policyframework which is general enough to express the rules forhandling permission requests in a context-sensitive manner.

To demonstrate the benefits of FineDroid, we create twosecurity extensions for end-users, administrators and devel-opers. First, we provide end-users with in-context permissiongranting in which users could make permission granting deci-sions just for the occurrent application context. Second, sincepermission leak vulnerability [3], [4], [12], [20] is very com-mon and dangerous, we show how administrators could benefitfrom our system in transparently fixing these vulnerabilitieswithout modifying vulnerable applications. Last, we provideapplication developers with the ability of restricting untrustedthird-party SDK by declaring fine-grained permission specifi-cations in the manifest file. All these security extensions canbe easily built using policies.

We evaluate the effectiveness of our framework by mea-suring the effectiveness of the developed security extensions.

For end-users, we show that “for this context” permissiongranting is the most popular choice by users, and withoutsuch in-context granting option, users would have to handle13 times more permission prompts if they still want to makerational permission request decisions (details presented inSection VIII-A). For administrators, we show that FineDroidcan easily fix permission leak vulnerabilities with context-sensitive permission control policies, and the policies couldeven be automatically generated by a vulnerability detec-tor. For developers, we show that just several policies areenough to restrict the permissions that could be used byuntrusted SDKs. It is worth noting that our system is notlimited to support these two extensions. In addition, our systemis showed to introduce minor performance overhead (lessthan 2%).

In this paper, we make the following contributions.

• We propose context-sensitive permission enforcement todeal with severe security problems of mobile systems.Considering the characteristics of mobile applications,it is important and necessary to take the applicationcontext into account when regulating permission requests.

• We design a novel context tracking technique to trackintra-application context and inter-application contextduring the application execution.

• We design a new policy framework to flexibly andgenerally regulate permission requests with respect to thefine-grained application context.

• We demonstrate three security extensions based on thecontext-sensitive permission enforcement system, by justwriting policies and sometimes a small number of auxil-iary code.

• We evaluate the security benefits gained by the twosecurity extensions and report the performance overhead.

II. ANDROID BACKGROUND

The permission model of Android has been well describedin [21]. Here we introduce some most relevant background.

A. Application Process Model

By default, each Android application runs in an isolatedprocess with unique UID/GID. To boost the application cre-ation performance, each application process is spawned from aprocess incubator, named Zygote. When an application processis spawned, Zygote initializes the process as an AndroidRuntime instance which keeps a communication channelwith the Android system. Through this channel, the Androidsystem could manage the execution of every application.

B. Binder Interaction

Android designs the Binder IPC mechanism to facili-tate interactions among applications and system services.During startup, Android Runtime spawns a specificBinder thread to handle all Binder transactions routed to thisapplication. If one Binder thread is not enough to handlethese transactions timely, Android Runtime would auto-matically spawn new Binder threads. The Binder driver plays

ZHANG et al.: RETHINKING PERMISSION ENFORCEMENT MECHANISM ON MOBILE SYSTEMS 2229

Fig. 1. Architecture of Context-Sensitive Permission Enforcement Framework.

as a router that forwards transactions from clients to servers.During each transaction, the Binder driver also annotates somemeta-data such as the UID, PID of the client. Based on thetransaction meta-data, Android system services could get theclient identity and enforce permission checks.

C. Component Model

In Android programming model, apps are structured in com-ponents: Activity, Service, Broadcast Receiverand Content Provider [21]. Intent object is neededfor component interactions to describe the selection criteria forthe target component and invocation arguments. For an inter-action, an application needs to send an Intent to Androidsystem, and the Android system would check the meta-dataof the Intent object to determine the target component.After the target component is selected, the Android systemwould forward the Intent to the Android Runtimeof the target application through the communication chan-nel set up during the application startup. According to theIntent object, Android Runtime would instantiate thetarget component and invoke its corresponding interface forhandling.

III. THREAT MODEL

This paper considers a strong threat model in which anattacker aims to gain and abuse sensitive resources stealthily.More specifically, this paper assumes an attacker could launchall kinds of application-level attacks, while the Linux ker-nel and Android Runtime are secure (not compromised).For the stealthiness, we mean an attacker tries to hide itsidentity in using permissions from the permission enforcementsystem. We consider these two kinds of attacks.

A. Intra-Application Attack

To hide the behavior of abusing permissions, an attackercould inject malicious payloads into a benign appli-cation (either before installation or during runtime).There are several ways for an attacker to infect benign apps.First, an attacker could actively embeds malicious payloadsinto popular benign apps and redistributes the repackagedversion via third-party application markets. Second, an attackercould exploit code injection vulnerabilities (such as Man-in-the-Middle attack with dynamic class loading [22]) toinject malicious payloads. In addition, an attacker could also

publish malicious SDKs, passively waiting for developers toinclude [23].

B. Inter-Application Attack

The prevalent application interaction in the Android pro-gramming model may also be used by attackers to stealthilyuse permissions. This kind of attack has been verifiedin several forms, such as capability leak [3], [4], [12],component hijacking [20], content leak and pollution [24].In these attacks, the permission enforcement system wouldsee a permission request from a victim app which has alegitimate requirement for this privileged resource, while actu-ally this permission is originally requested and utilized by anattacker app.

Note that our threat model does not consider other kindsof attacks such as privacy stealing, root exploits and col-luding attacks, because they are not caused by the context-insensitive permission enforcement mechanism and have beenwell addressed by previous work [7], [15], [25], [26].

IV. APPROACH OVERVIEW

To defeat these attacks, we propose context-sensitive per-mission enforcement. The key idea is to construct a system-wide application context for each permission request and makegranting decisions based on this context. Since the permissionenforcement system could catch all the code packages and allthe apps that participate in the permission request, an attackercould no longer stealthily abuse permissions.

The system-wide application context is composed of twoparts: (1) Intra-application Context which represents theinternal execution flow of an application, and (2) Inter-application Context which reflects the interaction flow amongapplications and system services. With these two kinds of con-texts, our framework could accurately distinguish permissionrequests originated from different sources, thus achieving afine-grained control over permission usage.

The overall architecture of FineDroid is presentedin Figure 1. The rectangles filled with black color are newmodules introduced by FineDroid. The core of our frameworkis the Context Builder module, which automatically tracksthe application context along with the application execution.This module is placed in the Linux Kernel, so an attackercannot escape from the context tracking. We also provideContext API at the library layer for applications and the


Android framework to obtain the current application contextfrom the Context Builder module.

Based on Context API, we design a context-sensitive per-mission enforcement system. To flexibly set context-sensitivepermission control rules, FineDroid features a generic policylanguage. In FineDroid, all permission requests are interceptedby the Permission Manager module. To handle a permissionrequest, the Policy Manager module examines all the policesin the system, and then Permission Manager could make a per-mission decision according to the action (e.g. allow or deny)specified in the match policy. Besides, our policy language isextensible for introducing new permission handling actions.To support building security extensions atop the policy frame-work, Policy Manager provides open interfaces for policymanagement and extension.

Next, we will detail the design of FineDroid. The appli-cation context tracking technique is presented in Section V,and we describe the context-sensitive permission enforcementsystem in Section VI.

V. APPLICATION CONTEXT TRACKING

Application context is the cornerstone of FineDroid, whileit is not a primitive element yet in the Android system.Thus, we design Context Builder to automatically build thetwo kinds of application contexts. To prevent attackers fromhiding their identities in the application context, we placethe Context Builder in the Linux Kernel. However, the com-plexity of the Android programming model brings hugechallenges in propagating application context along with theapplication execution. To deal with these complexities, we fur-ther introduce several techniques for context propagating.Next, we elaborate these techniques.

A. Intra-Application Context BuilderIntra-application context is used to distinguish different

execution flows inside an app. In FineDroid, the functioncalling context is used to abstract the internal execution contextinside an app. However, it is too large to efficiently propagateand compare the complete calling context. Thus, we need toefficiently compute a birthmark for any given calling context.

1) PCC as Intra Context: We adopt a technique calledprobabilistic calling context (PCC) [27] to compute an inte-ger birthmark based on all the functions in the flow. PCCcan be efficiently calculated with a recursive expressionpcc = 3∗ pcc′ + cs where pcc′ is the PCC value of the callerand cs is a birthmark for the current call site. By applyingthis expression recursively from the leaf function on the stackto the root function, we could finally obtain a PCC valueas the birthmark for the whole calling context. Note thatPCC calculation is deterministic which means a given callingcontext would always get the same PCC value. As evaluated inmillions of unique calling contexts [27], PCC is efficient andaccurate for bug detection and intrusion detection in deployedsoftware. Thus, PCC is very suitable to represent the internalexecution context inside an app.

2) Call Site Birthmark: Since all Java code in an Androidapp is packed into a single DEX file, we use the relative offsetof a call site in the DEX file as the birthmark of the call

Fig. 2. Binder IPC Context Building.

site (cs value). While at the first glance this solution mayencounter problems with native code execution, it turns outthat this solution could still calculate a PCC value for the Javafunctions invoked before the native code because native codecould only be invoked from Java functions through Java NativeInterface. It is worth noting that our solution does not need tocalculate a PCC value for every function invocation. Instead,it just needs to compute PCC values for a small portion ofcalling contexts inside an application that may participate ina permission request, such as application interaction.

3) Implementation Issue: Since Java functions are executedin a dedicated Java stack by Dalvik virtual machine, ContextBuilder which lies in the Linux Kernel cannot recognize theuser-space Java stack. To solve this problem, we instrumentDalvik virtual machine to register the base address of Javastack to the kernel whenever a Java thread is spawned.Thus, when Context Builder needs to calculate the PCC valuefor the current context, it could traverse all the Java functionsin the execution flow by reconstructing the calling stack withthe base Java stack address.

B. Inter-Application Context Builder

Inter-application context reflects the IPC context amonginteracted applications. Since Binder IPC is the only way foran application to interact with other applications and systemservices, Context Builder extends Binder kernel module tokeep the whole IPC call chain for every IPC invocation.As showed in Figure 2, the extended Binder driver allocatesan array for each thread to record the application contextin handling Binder communication. During each Binder IPCinteraction, the driver would append caller’s identity intocaller’s application context, and propagate it to the calleeapplication as the callee’s application context. The caller’sidentity is composed of two parts: assigned UID of the callerapplication and PCC value for the intra-application contextinside the caller application when this interaction occurs.

C. Context Propagating

Due to some unique features of Android, the builtsystem-wide application context would be lost during normalexecution. Thus, FineDroid further retrofits the AndroidRuntime which manages the application execution to prop-agate application context during the following interactionbehaviors.

1) Component-Level Propagating: Component interactionis prevalent in Android apps. To initiate a component inter-action, an application (named as A ) first needs to send an


Fig. 3. Binder IPC Propagating Diagram in Component Interaction from App_A to App_B. (a) When App_B is started. (b) When App_B is not started.

Intent to the ActivitManagerService (referenced asAMS for short), then AMS would choose a target applica-tion (named as B ) and route the Intent to B. Figure 3 (a)illustrates this process. Since the invocations from A to AMSand from AMS to B are all proceeded with Binder IPC,app B would get the application context as [(uidA, pccA),(uidAM S , pccAM S)] when receiving this Intent. During thecomponent interaction, AMS plays as a mediator between thesender and the receiver. However, from the application contextpropagated to app B, AMS looks like a participator which iscontrary to its actual role.

The problem would be even worse when the target applica-tion B has not been launched at the time of Intent delivery.Figure 3 (b) illustrates this scenario. When app B is chosenas the callee of this component interaction and AMS finds thatapp B has not been started. AMS would delay the Intentrouting and notify Zygote (which is the application incubatorin Android) to spawn a new process for app B. When Bhas been started, it would notify AMS and AMS would sendthe delayed Intent to B. The problem is that the Intentdelivery from AMS to app B is performed in the context ofreceiving the start notification of app B, so the applicationcontext propagated to app B is [(uidB , pccB), (uidAM S ,pccAM S)]. This problem is caused by that the applicationcontext for sending the Intent from app A to AMS has notbeen recovered in delivering the Intent from AMS to app B.

To solve the two problems, we design Intent-based compo-nent interaction tracking. The basic idea is that, we instrumentAMS to annotate each Intent object with the sender’scontext, thus the context is propagated to the receiver togetherwith the Intent object. When Android Runtime in thereceiver application gets the Intent object from AMS, it firstrecovers the application context recorded in the Intentobject and then triggers the invocation of the target com-ponent. Thus, the target component can be executed withthe right application context. Note that the application con-text recovery in the receiver application is guaranteed byour instrumented Android Runtime, thus it could notbe escaped.

2) Thread-Level Propagating: In each AndroidRuntime, there is a main thread to handle the componentinteractions with the system and dispatch UI events(so this thread is also known as UI thread). To reduce thelatency of main thread in processing events, developersare advised to delegate time-consuming operationsto worker threads. Android designs Message [28],Handler [29], AsyncTask [30] interfaces for developersto facilitate such workload migration and synchronization.

However, since thread interaction is not proceeded via BinderIPC, the application context would be lost in the workerthread.

We design two countermeasures to propagate applicationcontexts among thread interactions. First, during thread cre-ation, we instrument the thread creation and initialization logicto propagate the application context of the creator threadto the new created thread and then recover the applicationcontext before the created thread is ready to run. Second, forthread interaction, we consider the message-based interactionmechanism in Android. Before a message is sent to a thread,the application context of the current thread is annotatedto the Message object. Then before the target thread handlesthe Message, its application context is restored accordingto the one encapsulated in the Message object. It is worthnoting that, our thread-level context tracking is transpar-ently performed by our instrumented Android Runtime.Thus, this kind of tracking is mandatory without relyingon any modification to the applications or cooperation withdevelopers.

3) Event-Level Propagating: Callbacks are commonly usedin Android to monitor system events. A typical use case is UIevent handling. However, the event-based programming modelalso brings problems to application context tracking, becausea callback may be executed in a future time by a threadwhich would have a different context to the one when thecallback is registered. To deal with this problem, FineDroidannotates each callback with the application context whenit is registered and recover the application context from thecallback before it is triggered for execution. From Androiddocumentation, we find more than 100 APIs that wouldregister callbacks. We instrument each API to embed theregistered callback into a wrapper which automaticallyrecords and recovers the context to/from the callback. Sinceonly Android APIs are instrumented, this technique is alsoenforced transparently to the app.

4) Compared With Scippa: Scippa [31] is a system toprovide IPC call-chains across application process. Similarto our context propagating technique, Scippa also extendsBinder driver and Android Runtime to propagate IPCcontext. However, it is limited in application to context-sensitive permission enforcement from the following aspects:

• First, Scippa does not build and propagate intra-application context during IPC interaction while it isquite important for preventing intra-applications attacksand inter-application attacks;

• Second, our system considers a more complicated com-ponent interaction model which covers two scenarios in


Fig. 4. Policy Language for FineDroid.

sending Intents (see Fig. 3) and effectively hiding thepresence of AMS in the IPC context;

• Third, our system proposes thread-level propagating andevent-level propagating to systematically propagate IPCcontext inside an application, while Scippa only supportscontext propagating during thread interaction .

VI. CONTEXT-SENSITIVE PERMISSION SYSTEM

Based on the constructed system-wide application context,permission requests in FineDroid could be handled separatelyaccording to the concrete application context. To ease the reg-ulation of permissions requests, FineDroid features a context-sensitive policy framework. Besides, FineDroid also collectsdetailed context information to facilitate expressive context-based policy writing.

A. Permission Manager

Permission Manager first needs to intercept all permis-sion requests. As introduced in [19] and [32], two kinds ofpermission requests are intercepted: KEPs (Kernel EnforcedPermissions) and AEPs (Android Enforced Permissions). Thetwo kinds of permission requests are intercepted differently.

1) KEP Interception: Since KEP is enforced by theUID/GID isolation mechanism in Linux Kernel [32],we instrument the related modules in the Linux Kernel tointercept all KEP permission requests. The permission requestis then redirected to Permission Manager in the Androidframework for handling.

2) AEP Interception: PermissionController service is a uni-fied point for permission checking in the Android framework.We instrument PermissionController service to redirect allpermission requests to the Permission Manager. Since the AEPpermission requests are preformed through Binder, PermissionManager could easily obtain the application contexts for theAEP permission requests with Context API.

To handle a permission request, Permission Manager firstqueries Policy Manager to select a policy which best matchesthe current application context. If no policy matches, Per-mission Manager would fall back to the original permissionenforcement mode. In the original mode, permission requestsare handled by querying the Permission Record (see Figure 1)to grant all the permissions declared in the application man-ifest file. When a matched policy is selected for the currentpermission request, Permission Manager just needs to followthe action (e.g. allow or deny) specified in the policy.

B. Policy Framework

FineDroid designs a declarative policy language to expressthe rules for handling permission requests in a context-sensitive manner. Figure 4 shows the structure of our policylanguage. Basically, a policy specifies the action 〈action〉 toperform when an app 〈app〉 requests a permission 〈permission〉

Fig. 5. Example of In-Context Permission Granting Interface.

under the application context of 〈context〉. To ease the expres-sion of application context, our policy is structured in XMLformat, with the following tags. (Sample policies can be foundin Figure 5 and Figure 7.)

• policy tag. It is the root tag for specifying a pol-icy. Three attributes are required to designate thehandling action (action attribute) when an app (appattribute) requests some permission (permission attribute).The expected application context for this policy canbe figured by either a context attribute or child tagsdescribed below.

• uid-selector tag. It describes the composition relationshipof several uid-context child tags. The selector attributeis mandatory to describe the composition relationshipamong the child tags. It supports 5 kinds of selectors:“contains”, “startwith”, “endwith”, “strictcontains” and“fullymatch”.

• uid-context tag. It describes context information for asingle application participated in the inter-applicationcommunication. The uid attribute is required to specifythe identity of the application. Package name can alsobe used as the identity of the application. If the value ofuid attribute begins with “∧”, it represents any applicationexcept the one specified by the uid attribute. The intra-application context of the application can be described byeither the pcc attribute using the exact PCC value of theapplication, or detailed function call context informationusing a child pcc-selector tag.

• pcc-selector tag. It describes the composition relationshipof several method-sig child tags. Just like uid-selectortag, it requires a selector attribute which also supports5 selectors.

• method-sig tag. It describes the signature for a methodinvoked in the calling context. Three attributes canbe used for description: className, methodName, andmethodProto.

• or, and, not tag. They describe the logic relationshipsamong child tags. They are used to depict complexcontexts which may be difficult to expressed only withuid-selector and pcc-selector. Meanwhile, these tags canbe nested together.

Besides, the policy language supports using “*” as the wildcard character in some attributes, such as context attribute inpolicy tag, pcc attribute in uid-context tag.


1) Policy Matching: To test whether a policy could match apermission request, Policy Manager first checks the requestedpermission and the requestor application. When both attributesmatch, Policy Manager further compares the application con-text. The application context matching is relatively slow,so we use a cache to remember the context matching results.If multiple policies are found to match, Policy Manager wouldselect the one that express the most fine-grained applicationcontext. Policy Manager also supports adding and removingpolicies to/from the system, as well as registering new actiontypes to extend the policy language. The next section will showhow these policies can be used to refine current permissionmodel.

C. Expressive Context-Based Policy Writing

To ease the writing of context-based policies, FineDroid col-lects the detailed context information during context building.The recorded context information enables writers to specifycontext policies in a more expressive manner.

1) Intra-Application Context Information: To supportdescribing uid-context with method signatures, FineDroidcollects the method signatures for all the Java methods in thecurrent intra-application context. Note that the detailed contextinformation is collected only when a new intra-applicationcontext (with a PCC value never see before in this app) isencountered. Since the detailed context information is keptin the file system, FineDroid using encryption to preventattackers from modifying the context information.

2) Application Identity Information: In Android, a uniqueUID/GID pair is selected during application installation torepresent as the identity of an app. However, UID/GID is notfriendly for users to understand. Instead, FineDroid supportsusing the package name of an app to describe the app. To mapa package name to UID/GID pair, FineDroid keeps all thepackage names of the application packages managed byPackageManagerService.

VII. SECURITY EXTENSIONS

To demonstrate the effectiveness of context-sensitive per-mission enforcement, we create three security extensions forend-users, administrators and developers. All these extensionsare built upon the interfaces exposed by Policy Manager,without modifying other FineDroid modules.

A. For End-User: In-Context Permission Granting

In the current Android permission model, an app needsto declare all requested permissions in a manifest file anda user should decide whether to grant all these permissionsat the installation time or to abort the installation. Recentuser studies have indicated that this grant-all-or-not-installpermission model could not help users make correct securitydecisions [33], [34]. To address this problem, Aurasium [35]repackages apps and provides time-of-use permission grantingfor Android but at the application level only.

A limitation of this solution is that a user may wish togrant the SEND_SMS permission only when she clicks the

Fig. 6. Sample Policies for In-Context Permission Granting. (a) Defaultpolicy (Grant for Once). (b) Grant for a Context. (c) Grant for All Contexts(Forever).

“Send” button but not in any other contexts of the application.Unfortunately, we are unaware of any existing techniquecapable of granting permissions based on contexts. FineDroidimproves application-level permissions by providing in-contextpermission granting, which allows the user to allow or denya permission for the current context. Figure 5 shows anin-context permission granting user interface, where the usercan choose to allow/deny a permission (1) always in thecurrent context, (2) always in all contexts, or (3) just once.Note that in-context permission granting still relies on usersto make rational allow/deny decisions, but we argue that itcould benefit users for the new flexibility in making decisions(see Section VIII-A).

We select 12 high-risk permissions, such as INTERNET,SEND_SMS, and READ_CONTACTS, to provide in-contextgranting when these permissions are requested. To support usergranting, we add a new action type prompt to the policylanguage. When Permission Manager performs a “prompt”action, it would invoke our registered callback to handlethis action. Our callback would prompt a dialog such asFigure 5 for users to make a granting decision.

To specify that the 12 high-risk permissions should behandled with “prompt” action, we register 12 default poli-cies to the system through the interface of Policy Manager.Figure 6 (a) shows a sample policy. When a user chooses togrant a permission for the current context, we add a policyto the system to specify that this permission is granted to theapp with current PCC value. Figure 6 (b) shows an example ofsuch in-context permission granting policy. Note that the PCCinteger value is used only by FineDroid to identify a contextand is transparent to the end user, who makes context-sensitivedecisions based only on the context in the application’s userinterface. When the application requests the same permissionin another scenario/context (which has a new PCC value),our system could still prompt users for permission granting.If users are quite confident about that an application shoulduse a permission forever, our system would add a policy asshowed in Figure 6 (c).

B. For Administrator: Fixing Permission Leak Vulnerability

In the Android programming model, if a public componentis not protected well, it may be misused to perform priv-ileged actions by an attacker application. As demonstrated


Fig. 7. Policy to fix SEND_SMS permission leak in SmsReceiver.

in [3], [4], and [20], many high-risk permissions, such asSEND_SMS, RECORD_AUDIO are found to be leaked in pre-installed apps and third-party apps. Next, we introduce howto use FineDroid to prevent permission leaks. Note that wedo not want to prevent all kinds of component hijackingvulnerabilities, such as information leaks.

1) Leak Causes: There are two possible cases for thepermission leak vulnerability. The first case is that someapplication-private components are mistakenly made publiclyaccessible. This may be caused by developer’s lack of securityawareness or insecure code generated by IDE. To fix such kindof leak, developers just need to mark these components asprivate ones in the manifest file. In Android, intra-applicationcomponent interaction and the inter-application componentinteraction share the same communication channel [36].Thus, a single component may be designed for two purposes:internal use and public use. The second case of permissionleak is that developers do not perform enough security checkswhen an internal component is for public use. However, thiscase is quite difficult to handle, due to two levels of securityrequirements in a single component.

2) Our Solution: By tracking system-wide applicationcontext, FineDroid could be used to fix permission leakvulnerability. With inter-application context, we could findwhether a component interaction is for internal use or forpublic use. With intra-application context, we could accuratelyspecify the vulnerable flow inside the application. Combin-ing intra-application context and inter-application contexttogether, we could make a policy to prevent a vulnerable flowfrom using permissions when it is invoked from an externalapplication. For example, the policy in Figure 7 denies theSEND_SMS permission request from the app com.android.mmswhen a foreign application participates in the interaction andthe internal execution state of com.android.mms matches avulnerable path (specified by the 〈pcc-selector〉 element).

The advantages of FineDroid in preventing permission leakvulnerabilities are that it requires no modification to thesystem nor the vulnerable applications and the policies arequite easy to write. In Section VIII-B, we would evaluatethe effectiveness of FineDroid in fixing real-world permissionleak vulnerabilities, and show that how the policies couldbe automatically generated by enhancing a permission leakvulnerability detector.

C. For Developer: Fine-Grained Permission Specification

An Android application may contain many third-party codepackages. For example, it is common for applications to embedan Ad library for fetching Ads, social network SDKs forpublishing events, payment SDKs for financial charge, analytic

Fig. 8. Original policy to incorporate Flurry Ads in Android Apps.

Fig. 9. Policy to prevent Flurry Ads from requesting location permission.

SDKs for marketing. However, in this case multiple third-party SDKs from different origins (potentially with differ-ent trust levels) will share the same privileges as the hostapplication, violating the principle of least privilege. Thus,a third-party SDK may abuse the permissions that granted tothe host application. For example, a popular Ad library wasfound to collect text messages, contacts and call logs [23].Unfortunately, developers have no way to restrict the permis-sions that are available to certain foreign packages.

1) Our Solution: By tracking intra-application context,FineDroid is capable of distinguishing the origins of permis-sion requests inside an application. Thus, we could build apermission sandbox inside an application where code packagesfrom different origins have different permission configurations.Based on the permission sandbox, developers could declarefine-grained permission specifications in the application man-ifest file to specify the permissions that could be used byeach third-party SDK. Figure 9 shows the format of thiskind of permission specification. The fine-grained permissionspecifications in the manifest file will be transformed toFineDroid policy by our enhanced PackageManagerService atthe install-time and added to the Policy Manager. Note thatapplication obfuscation [37] would not cause problems here,because developers could modify the manifest file after codeobfuscation.

2) Burden on Developers: To isolate third-party code pack-ages, developers need to specify fine-grained permission con-figurations in the manifest file, as showed in Figure 9. Actually,it would not place significant burden on developers, sincethey already need to configure permissions when incorporatingthird-part code packages. For example, consider a developerwho wishes to incorporate the Flurry SDK in her app. Flurry’sdocumentation requires her to declare four permissions in theapplication manifest, shown in Figure 8 [38]. If she usesFindDroid, then instead of declaring those permissions, shewould specify the policy in Figure 9. Finally, the developerneed to set fine-grained permissions only when she wishes torestrict the permissions of untrusted SDKs.

VIII. PROTOTYPE & EVALUATION

We implement a prototype of FineDroid on Android 4.1.1(Jelly Bean), running on both Google Nexus phones


(Samsung I9250) and emulators. We also implement thethree security extensions upon FineDroid. This section evalu-ates these extensions to demonstrate the effectiveness of ourcontext-sensitive permission enforcement framework, as wellas the performance overhead introduced by our framework.

A. In-Context Permission Granting

In-context permission granting provides flexible control overpermission usage. What option to choose in a permissiongranting decision is a tradeoff between security and usability.The “forever” option represents one end of the spectrumwith the maximum usability but possibly insufficient secu-rity (because the correct permission decisions might be dif-ferent in different contexts), while the “for once” optionrepresents the other end of the spectrum with the maximumsecurity but the worst usability (because the user has to answerevery permission question). The “for this context” option thatwe propose represents a middle ground.

However, how useful is it? How often is it more appropriatethan “for once” and “forever”? We conducted a user studyto find it out. In this study, we hired 10 volunteers in ouruniversity to participate. We selected 70 top Google Playapps (e.g., Cut the Rope, Firefox, BBC News, IKEA Catalog)from 21 different categories, and each participant chose asubset of these apps and ran them on FineDroid. The taskof the participating users was to thoroughly use the providedapps and to trigger as many features of the apps as possible.

1) Recommended Best-Practice Setting: To help users spec-ify policies using in-context permission granting withoutbringing in more risks, we recommend them the best-practicesetting. We first recommended them about the three optionsthat should choose when making granting decisions: (1) ifyou do not want the system to remember the decision, thenchoose “for once”, (2) if you do not want to handle therequest of this permission in the same current scenario/contextany more, then choose “for this context”, and (3) if you donot want to handle the request of this permission anytime inthis app, then choose “forever”. We then recommend them todeny a permission request “for once” when they are not surewhether to grant or not. If the denial of the permission requestdoes not come with decrease of service quality or applicationstability, we recommend them to deny the same permission“for this context”. We advice them to cautiously choose“forever” option. Since in-context permission granting pro-vides new flexibility in controlling application behaviors, ourrecommended policy setting is expected to help users gain abetter balance between security and usability.

Before the experiment, we gave them 5-minute trainingabout in-context permission granting. We introduced themabout the three options that could choose when making grant-ing decisions: (1) if you do not want the system to rememberthe decision, then choose “for once”, (2) if you do not wantto handle the request of this permission in the same currentscenario/context any more, then choose “for this context”,and (3) if you do not want to handle the request of thispermission anytime in this app, then choose “forever”.

2) Overall Usability Impact: In all, we collected 158 per-mission granting traces for 70 apps. On average, each trace

lasts about 12.3 minutes. Totally, users make 968 per-mission granting decisions. On average, users make about6.13 (968/158) permission decisions per app, which meansone decision for about 2 minutes. Thus, we can find that ournew in-context permission granting mechanism does not placesignificant burden for end-users.

3) Effectiveness: To study the benefits drawn by in-contextpermission granting, we assume that each permission deci-sion (allow or deny) that a user make is rational,1 i.e., nouser would intentionally allow a permission when it should bedenied, and vice versa. Specifically, we look into the followingquestions.

a) Q1 (How often is “for this context” chosen by users?):By examining the options chosen by users when making grant-ing decisions, we found the users made 590 “for this context”decisions, which is the mostly chosen option. Based on users’context-sensitive decisions, our system automatically handles37,666 permission requests without further bothering the users.It means 37666/(37666+590)=98.5% unnecessary permissionprompts are effectively eliminated within in-context permis-sion granting.

The above results, while encouraging, should be taken witha grain of salt, because users may not always choose the mostappropriate option when making decisions. It means that usersmay choose “for this context” option when “forever” wouldbe more appropriate. Since the “forever” option is not newintroduced by us, we should not attribute all the eliminated37,666 permission prompts to in-context permission granting.To investigate the benefits owing to in-context permissiongranting, we first need to judge when “for this context” optionis the most appropriate. However, manually judging would belaborious and subject to our biases. Finally, we find a way todeduce the cases when “for this context” option is the mostappropriate from users’ actual decisions (see Q2 and Q3).Thus, we could measure the benefits that owe to in-contextpermission granting from these cases (see Q4).

b) Q2 (How often is “for once” more appropriate than“for this context”?): In our study, users have made a totalof 72 choices of “for once” option in 50 contexts. However,no user has ever chosen both “allow for once” and “deny foronce” in the same permission request context of an app. Thisimplies that if these users had chosen “for this context” insteadof “for once”, they would have the same security effect butwould have avoided many permission prompts. This studyshows that “for once” option rarely, if ever, could be a moreappropriate choice than “for this context”.

c) Q3 (How often is “for this context” the most appro-priate choice?): When a user both allowed and denied thesame permission (with “for this context” option) but in dif-ferent application contexts in an app, it is reasonable to inferthat the “forever” option is inappropriate for this permissionin this app. Instead, “for this context” option is probablythe most appropriate choice in this case. For each user ineach app, our user study covered a total of 296 permissionsand 740 distinct permission request contexts. Among these

1Note that rational does not necessarily imply optimal, e.g., a user maychoose “for once” while actually “for this context” would be more appropriate.


permissions, 61 permissions have been both granted anddenied by the same user in different contexts of an app, fora total of 217 distinct permission request contexts. In otherwords, in these 217 (or 217/740=29.3%) permission requestcontexts, “for this context” is the most appropriate choice.

d) Q4 (Without “for this context” option, how manymore prompts would users need to handle?): In a time-of-use permission granting system where “for this context”option is unavailable, when a user is asked a permissionquestion in one of the above 217 permission contexts, the usercould choose either “for once” or “forever”. Note that the“forever” option would be inappropriate in the 217 contextsdiscussed above. As a result, rational users have to choose“for once” option, thus would have to handle more prompts.In the user study, for the 217 contexts above, the systemautomatically handles 12,678 permission requests based on theusers’ context-sensitive decisions. It implies that users wouldhave to handle 12678/968≈13 times more permission promptsif the “for this context” option is unavailable.

4) Longer-Term Usability Study: Since FineDroidremembers the user’s context-specific permission decisions,we expect that the user needs to repeat fewer permissiondecisions. To measure this improved usability in a longerterm, we chose five volunteers from the previous study toparticipate in a five-day study. We asked each participant tochoose her five most frequently used apps from the previousstudy so that they would be willing to spend more time onthese apps. During the study, just as in the previous study,our system recorded all the permission granting decisionsmade by the user and by FineDroid, respectively. In total wecollected 25 permission granting traces in 17 apps. The tracesshow that the participants made a total of only 27 permissiongranting decisions, all of which occurred in the first hour ofusing the app. By contrast, FineDroid automatically made93,817 permission granting decisions. This result corroborateswhat we observed during our previous shorter-term user study:that in-content permission granting significantly reduces thenumber of permission request prompts.

B. Fixing Permission Leak Vulnerability

We evaluate the effectiveness of FineDroid in fixing permis-sion leak vulnerabilities with two real-world vulnerabilities inAndroid AOSP apps: SEND_SMS leak [39] and WRITE_SMSleak [40]. These two vulnerabilities are both caused by theimproper protection of public components exposed in the Mmsapplication, which is the default message management app.

1) Vulnerability Analysis: There are two vulnerable com-ponents in the Mms application: SmsReceiverService which isa Service component and SmsReceiver which is a BroadcastReceiver component. Figure 10 illustrates the exploitablepaths in this application. SmsReceiverService is intended foronly internal use in the Mms application, while it is mis-takenly exported to the public. Through sending a well-designed Intent to SmsReceiverService, an attacker can drivethe Mms application to fake the receiving of arbitrary SMSmessages (WRITE_SMS leak, path a) or send arbitrary SMSmessages (SEND_SMS leak, path b). SmsReceiver is designed

Fig. 10. Permission leak paths in Mms application.

for both internal use and public use. However, the functionalityof sending arbitrary SMS messages which should only be usedby private components is not protected properly, causing it tobe exported to the public (SEND_SMS leak, path c).

2) Fixing the Vulnerability: Permission leak vulnerability istypically difficult to fix manually, because it requires enforc-ing multiple security requirements in a single component,such as SEND_SMS leak (path c in Figure 10) in SmsRe-ceiver. Besides, even if carefully fixed, it also requires there-distribution of the new application file. Based on Fine-Droid, we could easily prevent permission leaks by simplywriting policies to deny the permission request occurredin the exploitable path without modifying the application.Figure 7 shows an example of how to prevent SEND_SMS leak(path c in Figure 10) in SmsReceiver. Similarly, we could fixthe vulnerability of path a and b.

3) Effectiveness: We created three sample apps to exploiteach vulnerable path mentioned above. The sample appswere first tested in our FineDroid prototype with no policies.The result shows that all the three apps successfully exploitedthe vulnerabilities in the Mms app. Then we added threepolicies (as showed in Figure 7) to our prototype to fix thethree vulnerable paths. We also ran the same three sampleapps to attack Mms again. We found that our security policiessuccessfully prevented the permission re-delegation attacksthis time, demonstrating the effectiveness of FineDroid inenforcing fine-grained permission use policies.

4) Policy Generation: The policies to fix permission-leakvulnerabilities rely on the precise understanding of vulnerablepaths among component interactions. Thus the ideal scenariois to use together with an existing permission leakage vulner-ability detector (such as CHEX [20]). Once a vulnerable pathis detected, we can automatically generate a correspondingpolicy for FineDroid. Thus, the task of diagnosing vulnerableapplications and writing policies can be greatly simplified.To demonstrate the feasibility of automatic policy generationto be used together with any vulnerability detector, we chooseCHEX [20], a state-of-the-art tool in detecting permissionleak vulnerability, in our evaluation. However, the sourcecode of CHEX is not available, so we could not directlyenhance CHEX for policy generation. Instead, the authorsof CHEX provided us the output of CHEX in analyzing20 vulnerable applications, among which 10 applications arevulnerable to INTERNET permission leak. By parsing the out-put files, we successfully extracted 414 vulnerable paths with


detailed calling contexts. Based on the vulnerable paths (con-texts), the automatic policy generation is quite straightforward.As showed in Figure 7, the generated policies could deny thepermission request when the vulnerable path is exploited by aforeign application. Finally, for each vulnerable path detectedby CHEX, a policy is automatically generated to fix it.

C. Fine-Grained Permission Specification

We evaluate the effectiveness of FineDroid in providingfine-grained permission specification by restricting the priv-ileges of untrusted Ad libraries. In this experiment, we usean application named Stock Watch which embeds Flurry Adsfor fetching and displaying advertisements. For demonstrationpurpose, we assume Flurry Ads is not trusted by Stock Watchdevelopers, thus the developers want to restrict the permis-sions that could be used by Flurry Ads. Flurry Ads requestsACCESS_FINE_LOCATION permission during the execu-tion, and we assume the developers think this is quite sus-picious. With FineDroid, Stock Watch developers could easilyprohibit Flurry Ads from using ACCESS_FINE_LOCATIONpermission. As Figure 9 shows, they just need to declare a fine-grained permission specification in the manifest file. Duringthe installation, these specifications would be transformed topolicies that could be added to FineDroid. Because we do nothave the source code of the Stock Watch application, we mimicthe behavior of Stock Watch developers by repackaging theapplication file to replace the manifest file. By running the newapplication, we could find the ACCESS_FINE_LOCATIONpermission requests from Flurry Ads are all denied by Fine-Droid, and this does not affect the normal operation of theStock Watch application. Similar to Stock Watch, we alsotested another 20 applications to restrict the permissionsassigned to third-party libraries, including Google Ads, Tapjoy,Millennial Media. In all these cases, FineDroid provides strongenforcement of fine-grained permission specifications. We didencounter two cases that the applications crashed due to thedenial of some permissions requested from the Ads library.Instead of considering it as the fault of FineDroid, we arguethat developers of the Ads library should write more robustcode to handle more necessary exceptions in the future.

D. Performance Overhead

We have conducted several experiments to measure theperformance overhead caused by FineDroid. The experimentsare performed on Google Nexus phones.

1) Overall Performance: We first use three performancebenchmarks (CaffeineMark3, AnTuTu, and Linpack) to mea-sure the overall overhead introduced by FineDroid. The resultsshow that almost no noticeable performance overhead isobserved, with the worst overhead case at 1.99% in theLinpack benchmark.

2) Permission Request Handling Performance: Most over-head of FineDroid is introduced when handling permissionrequests. We implement a test app that performs 10,000 timesof permission requests to measure the average performance ofFineDroid in handling a single permission request. We com-pare the performance of unmodified Android with FineDroid

TABLE I

RESULTS ON HANDLING PERMISSION REQUESTS

TABLE II

RESULTS ON POLICY MATCHING

TABLE III

RESULTS ON CACHED POLICY MATCHING OPTIMIZATION

in two configurations. Context tracking is disabled in Fine-Droid w/o Context, where all overhead is caused by permis-sion interception. In FineDroid w/ Context, context trackingis switched on and no policy is installed on the system.Table I shows the results.

FineDroid introduces an overhead of 2.02 ms per requestin intercepting KEP permission requests, which is undoubt-edly higher than the case of unmodified Andorid becausein that case KEP request can be handled in the applicationprocess without communicating with Permission Manager inthe system process. The overhead introduced by further appli-cation context tracking is very minor (0.02 ms per request).For AEP permissions, the interception overhead is quite minorbecause AEP is originally enforced in the system process,while the context tracking overhead is more significant becauseit needs to build intra- and inter-application contexts in severalprocesses.

3) Policy Matching Performance: To test the overheadintroduced by the policy matching, we add policies to thesystem to grant the permissions requested by the test app.Each policy is written with the same structure as Figure 7.Table II shows the overhead of policy matching.

We also measure the performance of the aforementionedoptimization which caches previous policy matching results toreduce the overall matching overhead. From Table III, we canfind this optimization significantly reduces the total cost ofpolicy matching.

We believe the performance penalty introduced by Fine-Droid is acceptable because permission request (as well aspolicy matching) do not frequently occur in practice.

E. PCC Conflict Probability

Since PCC is probabilistic [27], two distinct intra-application contexts may have the same PCC value,which would degrade the effectiveness of our contexttracking technique. Thus, this section measures the probability


of PCC conflict. In the user study performed inSection VIII-A, our system recorded all the applicationexecution contexts with detailed calling context information.By analyzing the logs collected in the user study, we foundthere are 4.68 distinct permission request contexts on averagein the collected 158 permission granting traces, and thereare no conflict PCC values found in these contexts. Sinceour system only calculates PCC values in permission requestcontexts, the total number of PCC in an application should berelatively small. As evaluated in [27], a 32-bit PCC only hasfew conflicts for millions of unique contexts, thus we believethe adoption of PCC would hardly introduce context conflictsin our system.

IX. DISCUSSION

A. About FineDroid

To propagate application context, FineDroid relies onAndroid Runtime instance in each application to partic-ipate. Since Android Runtime is a user-space module inthe application process, currently FineDroid cannot guaranteeits integrity. Attackers may use Java Reflection to modifyAndroid Runtime’s private data structures. To preventsuch attacks, we instrument Reflection APIs to prevent manip-ulation of the private fields which are added by FineDroid tokeep application context. Because these fields are unique toFineDroid, this kind of instrumentation would not break otherlegitimate use of Reflection. Besides, adversaries may also usenative code to attack Android Runtime. Recent work onisolating native code in Android system [41], [42] could beincorporated to our system to prevent native code attack.

Undesirable data flows among multiple permission requestsare not considered in this paper. Actually, by providing fine-grained permission control to raise the bar for abusing permis-sions, FineDroid could also be used to prevent potential riskydata flows.

B. About In-Context Permission Granting

It is a long-running research problem about how to com-municate end-users with the application behavior to help themmake security decisions. However, making decisions is hard,helping users to make decisions is even harder. Permissiongranting mechanism itself could not tell users the correct deci-sion, but the way it interacts with end-users directly impactsthe security and usability. In installation-time permissiongranting, users are confused to make security decisions withoutknowing the permission usage. Thus, researchers proposedtime-of-use permission granting for Android, such Apex [43],Dr. Android and Mr. Hide [5]. In time-of-use permissiongranting, users could delay the granting decisions to runtime,at the exact time when application requests the permission.Compared with installation-time granting, time-of-use grantingcould provide better understanding of the risks of grantingdecisions. However, time-of-use granting would increase thenumber of granting decisions and interrupt the normal usageof the application. In-context permission granting proposedby this paper seems a better choice than time-of-use granting,because it not only allow users make decisions at runtime, but

TABLE IV

COMPARISON OF THREE PERMISSION GRANTING MECHANISMS

also avoid asking users the same permission granting ques-tions. The comparison among installation-time granting, time-of-use granting and in-context granting is depicted in Table IV.By providing users with a new way to interact with the per-mission granting mechanism, in-context permission grantingsignificantly advances this line of research, achieving a betterbalance between security and usability.

Although in-context permission granting is appealing, it stillneeds users to judge whether an app should gain a permis-sion or not. We do not claim that it could help users tomake probably more correct allow/deny decisions, but arguethe flexibility in making granting decisions could benefitusers. Actually, we expect this kind of permission grantingdecisions can be provided by a trusted party, such as GooglePlay or company IT administrators. The power of in-contextpermission granting lies in its flexibility in regulating permis-sion requests in a context-sensitive manner.

X. RELATED WORK

A. Permission System Extensions

Dr. Android and Mr. Hide [5] provides finer semantics forcoarse-grained permissions by rewriting privileged API invo-cations. SEAndroid [6] combines kernel-level MAC (SELinux)with several middleware MAC extensions to the Androidpermissions model, which could mitigate vulnerabilities inboth system and application layer. FlaskDroid [7] extendskernel-level MAC to bring mandatory access control for allresources in Linux Kernel and Android framework. Whilethese works refine or extend current permission system insome degree, they do not enforce fine-grained control overthe permission use context, which is the focus of FineDroid.

B. Permission Granting Extensions

Fratantonio et al. [44] explored the practicality of theadoption of finer-grained system for the Internet permissionby designing an automated system to extract all the domainsnames that an app need to access, and rewritten the apps torestrict the Internet access ability. Apparently, this solutionis limited and not generally applicable to other permissions.Aurasium [35] provides time-of-use permission granting forlegacy Android apps by automatically repackaging applica-tions to attach user-level sandboxing code. With well-designedDEX sandbox and native code sandbox, AppCage [42] alsosupports time-of-use permission granting, but it does notrequire application rewriting and can effectively defeat nativecode attack. Roesner et al. [45] introduced access controlgadgets (ACGs) which embed permission-granting semanticsin normal user actions. Apex [43] introduces partial permissiongranting at installation time and runtime constraints overpermission requests. Although these extensions improve the


original granting mechanism in some degree, they do not giveusers the ability to associate permission granting decisions tothe corresponding contexts, while it is an appealing featureprovided by the in-context permission granting.

C. Application Interaction Hardening

Felt et al. [12] proposed IPC inspection to prevent permis-sion re-delegation attacks by intersecting the permissions of allthe applications in the IPC call chain. However, this strategyis too rigid to allow intentional permission re-delegations.Quire [13] provides developers with new interfaces to acquireIPC call chain. Different from FineDroid, Quire relies onAIDL instrumentation to record the IPC call chain. However,the technique has several limitations: First, it could only trackthe IPC call chain during the invocation of AIDL-specifiedmethods, while some system interfaces are not specified usingAIDL such as AcvitityManagerService; Second, it isan opt-in option for developers to use these enhanced APIproxies, thus an attacker application can easily escape.

TrustDroid [14] divides apps into isolated trusted anduntrusted domains, without considering the communicationproblems inside a single domain. XManDroid [15] gener-ally mitigates application-level privilege escalation attacks byprohibiting any application communication if the permissionunion of the two apps may pose a security risk. Saint [11]secures the application communication by providing devel-opers with the ability to specify fine-grained requirementsabout the caller and callee. However, it could not improvethe permission enforcement mechanism during the applicationcommunication.

AppSealer [46] is a tool to automatically fix componenthijacking vulnerabilities by actively instrumenting vulnerableapps. Compared to AppSealer, our technique of fixing permis-sion leak vulnerabilities does not require heavy applicationrewriting which is error-prone and needs redistribution ofpatched apps.

D. Application Internal Isolation

To isolate in-app Ads, a separate process is introduced byAFrame [18], AdDroid [17] and AdSplit [16] for running Adslibraries. By intersecting the permissions that can be used bydifferent code packages in the same application, Compac [19]also provides fine-grained permission specification. However,without a systematic context tracking system and a genericpolicy framework, Compac could not flexibly handle permis-sion requests that cross multiple code packages. Comparedwith FineDroid, these frameworks could not flexibly regulatepermission use policies based on intra-application context.

E. Context-Aware Access Control

Recent works on context-aware access controlmodel [8]–[11] also regulate access control rules based oncontext information. Different from the notion in FineDroid,these works mostly consider the external application contextsuch as location, time of the day.

XI. CONCLUSION

This paper presents FineDroid, which brings context-sensitive permission enforcement to Android. By associatingeach permission request with its application context, FineDroidprovides a fine-grained permission control. The applicationcontext in FineDroid covers not only intra-application con-text, but also inter-application context. To automatically tracksuch application context, FineDroid designs a new seam-less context tracking technique. FineDroid also features apolicy framework to flexibly regulate context-sensitive per-mission rules. This paper further demonstrates the effective-ness of FineDroid by creating three security extensions uponFineDroid for end-users, administrators and application devel-opers. The performance evaluation shows that the overheadintroduced by FineDroid is minor.

REFERENCES

[1] Android Remains the Leader in the Smartphone Operating Sys-tem Market, accessed on Jun. 5, 2015. [Online]. Available:http://www.idc.com/getdoc.jsp?containerId=prUS24108913

[2] Sophos. Security Threat Report 2013, accessed on Jun. 5, 2015.[Online]. Available: http://www.sophos.com/en-us/security-news-trends/reports/security-threat-report/android-malware.aspx

[3] M. Grace, Y. Zhou, Z. Wang, and X. Jiang, “Systematic detection ofcapability leaks in stock Android smartphones,” in Proc. NDSS, 2012,p. 30.

[4] L. Wu, M. Grace, Y. Zhou, C. Wu, and X. Jiang, “The impact of vendorcustomizations on Android security,” in Proc. CCS, 2013, pp. 623–634.

[5] J. Jeon et al., “Dr. Android and mr. Hide: Fine-grained permissions inAndroid applications,” in Proc. SPSM, 2012, pp. 3–14.

[6] S. Smalley and R. Craig, “Security enhanced (SE) Android: Bringingflexible MAC to Android,” in Proc. NDSS, 2013, pp. 20–38.

[7] S. Bugiel, S. Heuser, and A.-R. Sadeghi, “Flexible and fine-grainedmandatory access control on Android for diverse security and privacypolicies,” in Proc. USENIX Secur., 2013, pp. 131–146.

[8] M. Conti, V. T. N. Nguyen, and B. Crispo, “CRePE: Context-relatedpolicy enforcement for Android,” in Proc. ISC, 2010, pp. 331–345.

[9] K. Singh, “Practical context-aware permission control for hybrid mobileapplications,” in Proc. RAID, 2013, pp. 307–327.

[10] F. Rohrer, Y. Zhang, L. Chitkushev, and T. Zlateva, “DR BACA:Dynamic role based access control for Android,” in Proc. ACSAC, 2013,pp. 299–308.

[11] M. Ongtang, S. McLaughlin, W. Enck, and P. McDaniel, “Semanticallyrich application-centric security in Android,” in Proc. ACSAC, 2009,pp. 340–349.

[12] A. P. Felt, H. J. Wang, A. Moshchuk, S. Hanna, and E. Chin, “Permissionre-delegation: Attacks and defenses,” in Proc. USENIX Secur., 2011,p. 22.

[13] M. Dietz, S. Shekhar, Y. Pisetsky, A. Shu, and D. S. Wallach, “QUIRE:Lightweight provenance for smart phone operating systems,” in Proc.USENIX Secur., 2011, p. 23.

[14] S. Bugiel, L. Davi, A. Dmitrienko, S. Heuser, A.-R. Sadeghi, andB. Shastry, “Practical and lightweight domain isolation on Android,”in Proc. SPSM, 2011, pp. 51–62.

[15] S. Bugiel, L. Davi, A. Dmitrienko, T. Fischer, A.-R. Sadeghi, andB. Shastry, “Towards taming privilege-escalation attacks on Android,”in Proc. NDSS, 2012, p. 29.

[16] S. Shekhar, M. Dietz, and D. S. Wallach, “AdSplit: Separating smart-phone advertising from applications,” in Proc. USENIX Secur., 2012,p. 28.

[17] P. Pearce, A. P. Felt, G. Nunez, and D. Wagner, “AdDroid: Privilege sep-aration for applications and advertisers in Android,” in Proc. AsiaCCS,2012, pp. 71–72.

[18] X. Zhang, A. Ahlawat, and W. Du, “AFrame: Isolating advertisementsfrom mobile applications in Android,” in Proc. ACSAC, 2013, pp. 9–18.

[19] Y. Wang, S. Hariharan, C. Zhao, J. Liu, and W. Du, “Compac: Enforcecomponent-level access control in Android,” in Proc. CODASPY, 2014,pp. 25–36.

[20] L. Lu, Z. Li, Z. Wu, W. Lee, and G. Jiang, “CHEX: Statically vettingAndroid apps for component hijacking vulnerabilities,” in Proc. CCS,2012, pp. 229–240.


[21] W. Enck, M. Ongtang, and P. McDaniel, “Understanding Androidsecurity,” IEEE Security Privacy, vol. 7, no. 1, pp. 50–57, Jan./Feb. 2009.

[22] S. Poeplau, Y. Fratantonio, A. Bianchi, C. Kruegel, and G. Vigna,“Execute this! Analyzing unsafe and malicious dynamic code loadingin Android applications,” in Proc. NDSS, 2014, pp. 23–26.

[23] Ad Vulna: A Vulnaggressive (Vulnerable & Aggressive) AdwareThreatening Millions, accessed on Jun. 5, 2015. [Online].Available: http://www.fireeye.com/blog/technical/2013/10/ad-vulna-a-vulnaggressive-vulnerable-aggressive-adware-threatening-millions.html

[24] Y. Zhou and X. Jiang, “Detecting passive content leaks and pollution inAndroid applications,” in Proc. NDSS, 2013, p. 5.

[25] W. Enck et al., “TaintDroid: An information-flow tracking system forrealtime privacy monitoring on smartphones,” in Proc. OSDI, 2010,pp. 393–407.

[26] P. Hornyack, S. Han, J. Jung, S. Schechter, and D. Wetherall, “Thesearen’t the droids you’re looking for: Retrofitting Android to protect datafrom imperious applications,” in Proc. CCS, 2011, pp. 639–652.

[27] M. D. Bond and K. S. McKinley, “Probabilistic calling context,” in Proc.OOPSLA, 2007, pp. 97–112.

[28] Android Message Class, accessed on Jun. 5, 2015. [Online]. Available:http://developer.android.com/reference/android/os/Message.html

[29] Android Handler Class, accessed on Jun. 5, 2015. [Online]. Available:http://developer.android.com/reference/android/os/Handler.html

[30] Android Asynctask Class, accessed on Jun. 5, 2015. [Online]. Available:http://developer.android.com/reference/android/os/AsyncTask.html

[31] M. Backes, S. Bugiel, and S. Gerling, “Scippa: System-centric IPCprovenance on Android,” in Proc. ACSAC, 2014, pp. 36–45.

[32] Y. Zhang et al., “Vetting undesirable behaviors in Android apps withpermission use analysis,” in Proc. CCS, 2013, pp. 611–622.

[33] P. G. Kelley, S. Consolvo, L. F. Cranor, J. Jung, N. Sadeh, andD. Wetherall, “A conundrum of permissions: Installing applications onan Android smartphone,” in Proc. USEC, 2012, pp. 68–79.

[34] A. P. Felt, E. Ha, S. Egelman, A. Haney, E. Chin, and D. Wagner,“Android permissions: User attention, comprehension, and behavior,” inProc. SOUPS, 2012, Art. no. 3.

[35] R. Xu, H. Saıdi, and R. Anderson, “Aurasium: Practical policy enforce-ment for Android applications,” in Proc. USENIX Secur., 2012, p. 27.

[36] E. Chin, A. P. Felt, K. Greenwood, and D. Wagner, “Analyzinginter-application communication in Android,” in Proc. MobiSys, 2011,pp. 239–252.

[37] Proguard, accessed on Jun. 5, 2015. [Online]. Available: http://developer.android.com/tools/help/proguard.html

[38] Documentation for Incorporating Flurry Android SDK,accessed on Jun. 5, 2015. [Online]. Available: https://developer.yahoo.com/flurry/docs/publisher/code/android/

[39] SEND_SMS Capability Leak in Android Open Source Project,accessed on Jun. 5, 2015. [Online]. Available: http://www.csc.ncsu.edu/faculty/jiang/send_sms_leak.html

[40] Smishing Vulnerability in Multiple Android Platforms, accessed onJun. 5, 2015. [Online]. Available: http://www.csc.ncsu.edu/faculty/jiang/smishing.html

[41] M. Sun and G. Tan, “NativeGuard: Protecting Android applications fromthird-party native libraries,” in Proc. WiSec, 2014, pp. 165–176.

[42] Y. Zhou, K. Patel, L. Wu, Z. Wang, and X. Jiang, “Hybrid user-levelsandboxing of third-party Android apps,” in Proc. ASIA CCS, 2015,pp. 9–30.

[43] M. Nauman, S. Khan, and X. Zhang, “Apex: Extending Android per-mission model and enforcement with user-defined runtime constraints,”in Proc. ASIACCS, 2010, pp. 328–332.

[44] Y. Fratantonio et al., “On the security and engineering implications offiner-grained access controls for Android developers and users,” in Proc.DIMVA, 2015, pp. 282–303.

[45] F. Roesner, T. Kohno, A. Moshchuk, B. Parno, H. J. Wang, andC. Cowan, “User-driven access control: Rethinking permission grantingin modern operating systems,” in Proc. SP, 2012, pp. 224–238.

[46] M. Zhang and H. Yin, “AppSealer: Automatic generation ofvulnerability-specific patches for preventing component hijackingattacks in Android applications,” in Proc. NDSS, 2014, p. 45.

Yuan Zhang received the B.Eng. degree fromNanjing University in 2009 and the Ph.D. degreefrom Fudan University in 2014. He is currently anAssistant Professor with the Software School, FudanUniversity. His research interests include systemsecurity and compiler techniques.

Min Yang received the B.Sc. and Ph.D. degreesin computer science from Fudan Universityin 2001 and 2006, respectively. He is currentlya Professor with the Software School, FudanUniversity. His research interests are in systemsoftware and security.

Guofei Gu received the Ph.D. degree in computerscience from the College of Computing, GeorgiaInstitute of Technology. He is currently an AssociateProfessor with the Department of Computer Sci-ence and Engineering, Texas A&M University. Hisresearch interests are in network and system security,social Web security, and cloud and software-definednetworking (SDN)/OpenFlow security.

Hao Chen received the B.S. and M.S. degrees fromSoutheast University and the Ph.D. degree from theComputer Science Division, University of Californiaat Berkeley. He is currently an Associate Professorwith the Department of Computer Science, Univer-sity of California at Davis. His primary interests arecomputer security and mobile computing.

IEEE TRANSACTIONS ON INFORMATION FORENSICS AND …2228 IEEE TRANSACTIONS ON INFORMATION FORENSICS...

Documents

Transcript of IEEE TRANSACTIONS ON INFORMATION FORENSICS AND …2228 IEEE TRANSACTIONS ON INFORMATION FORENSICS...