Modeling and Enhancing
Android’s Permission System
Elli Fragkaki, Lujo Bauer, Limin Jia, and David SwaseyCarnegie Mellon University, Pittsburgh, PA, USA
Abstract. Several works have recently shown that Android’s security architecture cannot prevent many undesired behaviors that compromise the integrity of applications and the privacy of their data. This paper makes two main contributions to the body of research on Android se-curity: first, it develops a formal framework for analyzing Android-style security mechanisms; and, second, it describes the design and imple-mentation of Sorbet, an enforcement system that enables developers to use permissions to specify secrecy and integrity policies. Our formal framework is composed of an abstract model with several specific instan-tiations. The model enables us to formally define some desired security properties, which we can prove hold onSorbetbut not on Android. We implementSorbeton top of Android 2.3.7, test it on a Nexus S phone, and demonstrate its usefulness through a case study.
1
Introduction
Recent years have witnessed an explosion in the use of mobile computing thanks to the proliferation of feature-rich smartphones, and associated app stores and easy-to-install applications. Smartphones have powerful hardware, with many useful sensors (e.g., GPS, camera, microphone, accelerometer) exposed via rich APIs, and enough computing power to run complex applications. Applications take advantage of these rich APIs to perform convenient and useful, but poten-tially privacy-sensitive tasks such as accessing address-book or location infor-mation; accessing online banking and medical accounts; and controlling home security systems. App stores make it easy for users to install and run applica-tions, while providing few guarantees about their provenance or behavior.
To protect sensitive resources from applications, and applications from each other, Android and other mobile OSes implement security mechanisms such as permission systems and strong isolation between applications. These mecha-nisms, however, have in practice proved insufficient, with an increasing number of malicious applications starting to target smartphones [15, 23, 16].
A number of works have investigated these weaknesses from various per-spectives, including demonstrating how applications can communicate through covert channels [24, 18], developing tools to detect information leaks [8, 5, 14], and implementing more powerful protection mechanisms (e.g., [22, 20, 7, 2]).
This paper adds to the body of research on Android security in two main ways: first, by developing a formal framework for analyzing Android-style se-curity mechanisms, including defining properties desired of those, and verifying
whether these properties hold; and, second, by designing and implementing an enforcement system that provides application developers with simple language constructs to specify flexible secrecy and integrity policies, and provably exhibits desirable security properties. To remain practically relevant, we constrain our en-forcement system, which we callSorbet, to be easily retrofittable into Android’s current architecture. The design and implementation of Sorbetimproves exist-ing Android permission system in the followexist-ing aspects: (1) we formally state the properties that we wish our new mechanisms to achieve, and formally prove that our system design supports them; (2) we enhance Android’s permission system to support coarse-grained secrecy and integrity policies; and (3) we provide more flexible support for fine-grained and scope-limited delegation of permissions. Formal analysis. One of our main goals is to improve our understanding of the security properties that we desire of Android-like permission systems, and to verify that specific systems are capable of specifying and enforcing desired properties. We pursue this goal by building a generalized, abstract model of the Android permission system, and stating a set of desirable properties in terms of the model. We then develop instantiations of this model both for the current Android permission system and for Sorbet. Based on this formal account, we study the properties of the current system; our investigation reveals both design and implementation flaws, which guide the design ofSorbet. We also prove that
Sorbet’s design is sufficient to support the properties that we have defined. Coarse-grained secrecy and integrity policies.Sorbet’s key innovation is coarse-grained mechanisms that allow developers to protect their applications against privilege escalation and undesired information flows (e.g., [6, 8]). Android’s per-mission system only prevents applications that do not have the correct permis-sions from directly calling a protected component. This is inadequate to protect against a malicious application that reaches a protected component indirectly, via a chain of calls to innocent applications. To protect against such attacks, we enrich Android’s permission system with the ability to specify information-flow constraints and explicit declassification permissions, and implement a light-weight calling-context tracking and checking mechanism. A key challenge here is to supportlocal specification ofglobal properties.
Flexible and fine-grained delegation.Run-time delegation of URI permissions is a key feature in Android, and allows applications to use third-party components (e.g., a viewer activity) to manipulate content that those components normally would not be permitted to access. On examination, we discovered that Android’s implementation of permission delegation is plagued by a number of flaws and questionable design decisions.Sorbetsupports more flexible and principled per-mission delegation and revocation, and allows developers to specify constraints that limit the lifespan and redelegation scope of the delegated permissions. De-veloping a mechanism that correctly enforces lifetime and scope constraints turns out to be unexpectedly tricky, due to redelegation and the dynamic nature of Android applications and components, including application installation and uninstallation, and instantiation and termination of components.
Contributions and Roadmap This paper makes the following contributions: – We develop a formal model that generalizes Android-style permissions (§2.2). We show how Android’s current permission system can be represented as an instantiation of our abstract model (§2.3).
– Building on this model, we define a set of security properties that one may desire of Android-style permission systems (§3.1). We show that Android currently obeys some of the desired security properties, but not others, and expose several design inconsistencies and implementation flaws (§3.2). – We describe Sorbet, a set of improvements to Android’s permission
sys-tem that supports developer-specified coarse-grained information-flow and privilege-escalation policies. We formalizeSorbetas an instantiation of our model and show that it better supports the desired security properties (§4). – Finally, we implementSorbet on top of Android 2.3.7, test it on a Nexus
S phone, and demonstrate several new scenarios that it enables (§5).
2
Preliminaries
We first review the Android architecture as it pertains to permissions (§2.1). We then develop an abstract model of Android-style permission systems (§2.2), and an instantiation of it that captures details of Android’s implementation (§2.3).
2.1 Android Overview
Android is a Linux-based open-source OS designed for smartphones. Android ap-plications are written in Java and compiled to Dalvik bytecode. Each application is executed in a separate Dalvik Virtual Machine (DVM) instance.
Android applications are composed of four types of components:
Activities define the user interface. Only one activity interacts with the user at a time. Users typically interact with a sequence of activities to perform a task. Services run in the background and have no user interface. Unlike activities, services remain active regardless of which application is in the foreground. Broadcast receivers listen for system-wide broadcasts, and inform other applica-tion components upon the receipt of a broadcast.
Content providers store data and are the main way to share data between appli-cations. Each provider exposes a public URI that uniquely identifies its data set. Components and applications can access or update the data via SQL queries.
Activities, services, and broadcast receivers communicate viaintents, asyn-chronous messages that deliver data and, if needed, cause a new instance of the recipient component to be created. The OS mediates both cross- and intra-application communications via intents. The recipient of an intent can be spec-ified explicitly by its package and class name, or implicitly via the action the intent attempts to initiate. We will often write that a componentcalls another component in lieu of explaining that the communication is via an intent.
Static Constructs
Components C ::=Ccode|Cdata
Code Components Ccode ::= (name,A, ϕckCallee, ϕckCaller,Pdecl,Preq,Pgrnt)
Data Components Cdata ::= (name, ϕckCaller,Pdecl)
Component Groups Cb ::= (name, ϕckCallee, ϕckCaller,Pdecl,Preq,Pgrnt,{C1,· · ·,Cn})
Run-time Constructs
Run-time Instances Ins ::=iC|iCb
Comp Instances iC ::= (namer,C,Pgrnt)
Comp Group Instances iCb ::= (namer,Cb,Pgrnt,{iC1,· · ·,iCn})
Principals Prin ::=Ins|user Targets Tgt ::=Ins|C|Cb
Events E ::=x= E1;E2|calliC1iC2I|returniC1iC2I |resolveiC ϕ
| grantPrin Tgt P F |revokePrin ({Tgt1,· · ·,Tgtn})P
| checkguardiC Tgtϕ|exitIns|installPrinCb|uninstallPrinCb
Fig. 1.Syntax of permission model
Android uses(application) permissions to protect components and sensitive APIs. Permissions are strings (e.g.,android.permission.INTERNET) defined by the system or declared by applications. A component or API protected by a permis-sion can be accessed only by applications that hold this permispermis-sion. Applications acquire (application) permissions only at install time, with the user’s consent.
Additionally, content providers can use URI permissions to grant ad-hoc access to specific pieces of data that they control (records, tables, or databases). URI permissions can be dynamically granted and revoked.
2.2 Abstract Model
To be able to formally state the properties desired of a permissions architecture, we develop an abstract, formal model of Android-style permissions systems. The model comprises: (1) static elements, which are the code and data we want to protect; (2) run-time elements, such as system events and component instances; and (3) a transition system that captures the behavior of the protection mecha-nisms. The model is more general than Android’s implementation as its purpose is to encompass a wider design space of permission systems, including previously suggested extensions (e.g., [22]). We only sketch the model here; see our technical report [13] for details. Fig. 1 shows the model’s static and run-time elements. Static constructs Following Android, applications in our model are built from components. We distinguish betweencode components (Ccode) anddata
compo-nents (Cdata). Code components—activities, services, and broadcast receivers—
may act both as callers and as callees; data components—content providers—are passive and only receive calls. A code component is comprised of a name (name), the actionsAto which the component is willing to respond, permissions (Pdecl,
Preq, andPgrnt), and guards (ϕckCallee,ϕckCaller).
In Android, calls to a component are guarded by a permission check. We gen-eralize this check to an abstract guard modeled by a boolean functionϕckCaller.
the calling context and returnstrueor false. A second general guard,ϕckCallee,
specifies when outgoing calls should be allowed.
We distinguish between permissions that are declared (Pdecl), requested from
the user (Preq), and granted (Pgrnt). This allows us to model behaviors such as
dynamic delegation of permissions.
We model applications,Cb, as a set of components ({C1,· · ·,Cn}) with guards
and permissions that apply to all. This is consistent with Android, where per-missions are typically declared, requested, and granted at the application level, but individual components can protect themselves with additional permissions. Run-time constructs It is important to distinguish static components from run-time instances, and run-time instances from each other. A static component
C may have multiple run-time instances iC, composed of a unique identifier (e.g., pointer),namer, and the permissionsPgrnt granted to this instance. We
similarly model run-time component groupsiCb(e.g., a running application). PrincipalsPrin are entities that can grant and revoke permissions: run-time components and component groups, and the user (i.e., human who installs ap-plications). Targets Tgt are the objects of such operations, and can be either run-time or static components or component groups.
Abstracting detail, we focus on system events that concern permissions, such as component communication via intents (calliC1 iC2 I), and granting (grant)
and revoking permissions (revoke). We discuss these further in §2.3 and §4.1 when we focus on the Android andSorbetinstantiation of the abstract model. Transition system We capture the dynamics of the model as a transition system. We model a system state Σ as a tuple composed of a set of entities (run-time and static) and auxiliary data structures Aux. We write E to denote a sequence of events to be processed by the system. We assume that each event is associated with a unique event IDn. The evolution of the system is a series of transitions (Σ;E−→o Σ0;E0), whereo records whether the evaluation of eventn is successful (o=ok(n)) or fails (o=fail(n)). Evaluation of acallevent will fail, for example, if the appropriate guards don’t evaluate totrue. A trace, denoted byT, is a sequence of transitions:Σ0;E0
o1
−→Σ1;E1· · · ok
−→Σk;Ek.
The specific rules in the transition system depend on the concrete implemen-tations being modeled. Here we show the rule schema for a successfulcallevent. The call succeeds only if both guards evaluate totrue.
call-t(Σ;E, n::calliC1iC2I)
ok(n)
−→ (Σ0;E) whereΣ0=updateCall(Σ,calliC1 iC2 I)
ifiC2.ϕckCaller(Σ,iC1) =trueandiC1.ϕckCallee(Σ,iC2) =true
A parallel rule, call-f, specifies that a call fails if either guard returnsfalse. 2.3 Android Model
We instantiate our abstract model to describe the key behaviors of Android’s permission system1. This has helped us to identify flaws in its implementation
1 When we refer to Android, we mean version 2.3.7, which was the newest version
available while we were carrying out our investigation. The behaviors we describe generally hold in 4.0 as well.
and peculiarities in its design. We omit a full description, but show example instantiations of guards (ϕuri
P ) and transition rules for granting permissions. Guards The guardϕuriP checks whether a component has the URI permissions specified inP.ϕuriP can be used asϕckCaller whenPis the set of URI permissions
protecting a component.
We first define functions to look up the permissions associated with a run-time component from the current state. FunctiongrantedByUsrPerm(iC, Σ) re-turns permissions granted at install time, and functionURIPerm(iC, Σ) returns the URI permissions dynamically granted to iC; URIPerm in turn relies on a data structure M to track the URI permissions granted to each application. Then, we defineϕuri
P as follows.
ϕuri
P ,f(iC, Σ) =P ⊆grantedByUsrPerm(iC, Σ)∪URIPerm(iC, Σ) Granting permissions URI permissions can be granted temporarily, via an intent, or permanently, viagrantUriPermission. We model the former as:
grantiC1iC2P Ftmp;calliC1 iC2 I.
Here, iC1grants permissionP with flagFtmp toiC2 before transferring control
to iC2. Granting permanently we model as grant iC1Cb P Fprm. Flags Ftmp
and Fprm constrain the lifetime of the delegation of P and the scope of its
potential redelegation by iC2. Mirroring Android, the lifetime of permissions
granted withFtmp is confined to the lifetime of the recipient (iC2) of the grant
operation. When granting withFprm, the recipient will have the permission until
the system reboots or the permission is revoked. Neither flag restricts the scope of redelegation. The following rule shows howgrant currently works in Android.
(Σ;E, n::grantiC1 iC2 P Ftmp) ok(n)
−→ (Σ0;E) ifϕuri{P}(iC1, Σ) =true
whereΣ0=updateGrant(Σ,iC1,iC2, P,Ftmp)
Granting succeeds only if the granter has permissionP. Afterwards,updateGrant updates state, by recording inMthat the enclosing application ofiC2now has
permissionP with flag Ftmp, and that the instanceiC2 hasP inPgrnt.
The rule for granting with Fprm (omitted here) differs only in its update
function: M records that nowCb has permission P with the flag Fprm. These
rules make explicit that Android does not distinguish betweenFtmp and Fprm
when deciding whether a component can grant permissions. This causes problems when components redelegate permissions, as we discuss in§3.2.
3
Security Properties
We define several properties that one might desire of an Android-style security architecture (§3.1) and investigate whether they currently hold (§3.2).
3.1 Specifying Desired Security Properties
We formulate the properties desired of Android’s security architecture based on the resources that need protection. These are typically interfaces that allow
access to functionality that could cause harm or inconvenience (e.g., sending expensive text messages) and to sensitive data that should not leave the posses-sion of components that legitimately require it (e.g., financial information in a banking application; location information). We abstractly define access-control properties that specify when and how a protected interface can be called and information-flow properties that specify when and what information can flow to or from a component. We also investigate lower-level, functional-correctness properties concerning granting and revoking permissions, since these directly affect the access-control and information-flow properties.
Local properties The following two properties state that the immediate restrictions specified by a component on its callers or callees are always obeyed.
Property1. (Local callee protection) If a componentA is called by another component B, thenA’s guardϕckCallee evaluates totrue.
Property2. (Local caller protection) If a componentAcalls another
compo-nentB, thenA’s guardϕckCaller evaluates totrue.
It is easy to show that Prop. 1 and 2 hold on any instantiation that includes rules likecall-tandcall-f(see§2.2).
Delegation and revocation properties
Property3. (Delegation) A componentA has a permission P if A owns P,
or there is a delegation chain from a component B to A such that A satisfies the scope and lifetime constraints imposed by every component on the chain, and that every component on the chain also has P.
Intuitively, Prop. 3 ensures that the use of a redelegated permission is con-fined by the lifetime and scope constraints specified by the original granter. For instance, if an email component gives to a viewer component the URI permission
P for displaying an attachment, two sensible constraints are thatP is confined to a specific instance of the viewer, and that the viewer cannot redelegateP.
Property4. (Revocation) If A revokesP from B, then there is a delegation
chain from A toB, orAowns P.
This is a basic correctness property for revocation. Allowing arbitrary com-ponents to revoke permissions is likely to be disruptive; hence, only the owner or granter should be allowed to revoke a permission.
Global properties The next two properties are simplified noninterference. We customize the general notion that secret inputs cannot affect public outputs and tainted inputs cannot affect endorsed outputs to fit the permission-based Android model.
Property5. (Privilege escalation) Given any component B protected by
per-missionP, and any componentA that does not have that permission, ifSAB is
a system that contains A and B (and other components), and SB is the same
system withoutA, then a call chain ending withB exists inSAB if and only if it
exists in SB. Additional call chains ending withB may exist inSAB if explicitly
In other words, with respect to accessingB, a system with unprivileged compo-nentAshould behave the same as a system withoutA. The only exception is if additional policy explicitly allowsA to affectB. Without such exceptions, this property would likely be too restrictive.
For example, letB be the interface, guarded by permissionP, for rebooting the phone. Suppose that component C hasP (which allows it to call B), and a public interface, such that any calls to that interface will cause C to call B. Then, a componentAthat does not haveP can indirectly causeB to be invoked by callingC.C’s indiscriminate invocation ofB is an example of the confused-deputy problem. Since a trace culminating in that invocation ofB cannot exist in a system withoutA, Prop. 5 prohibits this behavior.
In the other direction, we may want to prevent sensitive information from being leaked, which permission systems typically cannot specify directly. We leverage permissions to state an undesired information flow as follows. Suppose that permission P1 guards the source of some information and permission P2
guards the sink. Then, an undesired information flow can be specified as a call chain from a component that uses P1 to a component that uses P2. A system
that has no undesired information flows should then obey the following property.
Property6. (Information flow) Given an undesired information flow from a
component Aguarded by P1 to a component B guarded by P2, a call chain that
ends with B exists in a system withA if and only if the same call chain exists in a system without A. Additional call chains ending with B may exist in the system withA only if explicitly allowed by policy.
Without a more expressive policy specification language, these properties cannot be specified precisely.
3.2 Analyzing Android Permissions
We investigated the extent to which Android’s current permission system, as represented by our model, supports the properties defined in§3.1.
Local properties hold Android’s permission system implements thecall-t
and call-f rules, and the guards specified by the components are checked at run time; hence, Prop. 1 and 2 hold. However, Prop. 2 holds trivially, because callers cannot state useful guards on callees.
Delegation and revocation properties do not hold Prop. 3 requires that a permission does not outlive the lifespan specified by its granter. Android’s implementation, however, does not distinguish between Ftmp and Fprm when
deciding whether a component can grant permissions. This violates Prop. 3 and causes several bugs (see our companion technical report [13]), e.g., a component that gained temporary permission can redelegate the permission permanently, including to itself.
Android’srevokeURIPermissionrevokes a URI permission from all components to which it was dynamically granted, and can be called by any component that was granted the permission at install time. This violates Prop. 4, which requires
that a componentAcan revoke only from entities to which it granted permission (unless A owns the permission). Such violations can easily cause confusion, as unrelated applications can revoke each other’s permissions.
Global properties do not hold Previous work has pointed out that An-droid suffers from privilege-escalation flaws (e.g., [6]); i.e., Prop. 5 does not hold. Prop. 6 also does not hold, as Android does not have a mechanism for prevent-ing, or even specifyprevent-ing, undesired information flows. An application can access any component for which it has the permission to do so, regardless of whether it had previously accessed protected information. Previous work has shown that this results in various specific undesired information flows [24, 18, 8].
Examining Android in light of these properties also revealed several design and implementation bugs, which we reported to Google. These include the ability of components that received a temporary permission to redelegate that permission permanently, and improper bookkeeping of granted permissions during applica-tion uninstallaapplica-tion and installaapplica-tion that can lead to privilege escalaapplica-tion. These flaws are discussed in more detail in our companion technical report [13].
4
Sorbet: Android Permissions++
Motivated by the properties of §3.1, we develop Sorbet, an improved permis-sion system that supports (1) developer-defined policies to mitigate undesired information flows and privilege-escalation attacks; and (2) well-behaved permis-sion delegation and revocation. Our goals were to enable developers and users to specify richer policies on their applications without dramatically altering An-droid, and to construct an enforcement system that is provably well behaved.
Some of the mechanisms we use have been discussed previously [10, 22, 14, 7]; we integrate these and other ideas into a system that we can formally show satisfies interesting security properties and enables new use cases.
4.1 New Features in Sorbet
Coarse-grained information-flow protection Sorbetextends Android’s permission labels to make them suitable for specifying coarse-grained information-flow policies, and enforces such policies at component and application bound-aries. By reusing permission labels, this approach requires little new syntax.
InSorbet, a component A guarded by P1 (e.g., the contacts permission)
can specify (in the application manifest) information-flow policies of the form disallow-flow(P1, P2). This indicates that any component Bthat made use of P1
to accessAcannot (including transitively) use permissionP2. A component can
also request at install time the permission allow-declassify(P1, P2) to declassify
sensitive information, i.e., to escape the restriction imposed bydisallow-flow(P1, P2).
Our mechanism can be used by programmers to strengthen their own code by separating trusted information that should remain internal to an applica-tion from untrusted flows that may be communicated to the outside, thereby decreasing the chance of the application being misused by malicious ones. The mechanism can also be used to defend against malicious applications or devel-opers, by specifying policies that should hold between applications.
Coarse-grained privilege-escalation protection To mitigate the confused-deputy problem, Sorbet tracks the permissions of all components on the call stack. When a component A is called, and A is protected by permission P,
Sorbetchecks if every component on the call stack hasP. However, this is too
restrictive for practical use; e.g., an email app, which needs to use theINTERNET
permission to send email, could do so only when started by applications that have theINTERNETpermission. To address this,Sorbet allows components to request a privileged permission ˆP. When a componentBhas the permission ˆP, it is permitted to callAeven when other components on its call stack do not have
P. ˆP is similar to theenable privilegeoperation in Java stack inspection. Other works have also tracked the call stack for similar purposes (e.g., [7]);Sorbet’s novelty here is in allowing developers to specify policies, and in enabling proofs that this and other design features allow the system to exhibit desired properties.
Flag Recipient Redelegation scope Lifetime
Fcomp activity no redelegation activity exit Ftask activity activities in the same task activity exit FappTmp activity activities in the same app activity exit FallTmp activity any component activity exit Fapp app no redelegation app uninstall Fall app unrestricted app uninstall
Fig. 2.Flags for constraining delegation. Columns show the recip-ient scope, the scoping constraints of redelegation, and the lifetime of the granted permission.
As with information flow, Sorbet protects against privilege escala-tion at both component level and application level. To account for An-droid’s inability to com-pletely mediate commu-nication (e.g., via pub-lic static fields) between components within an
application, the policy enforced at the application level assumes that compo-nent boundaries within an application are not respected.
Principled redelegation and revocation Sorbetalso addresses Android’s problems with indiscriminate redelegation. The challenge here is to design a (cor-rect) mechanism to allow programmers to predictably control delegation lifetime and redelegation scope. Building on Android’s notion of temporary and persis-tent permissions, we enable thegrantoperation to precisely convey the intended scope of the recipient (a component or an application), the scope of redelega-tion (none, components in the same task, components in the same applicaredelega-tion, and unrestricted), and the lifetime of the permission (until the recipient activ-ity exits, or is uninstalled). For simplicactiv-ity, we converge on six combinations of these constraints (summarized in Fig. 2), which the programmer can specify via flags passed as arguments to grant. The enforcement mechanism enforces the transitive properties that the constraints implicitly require.
Sorbetallows a componentAto revoke a permissionP from componentB
only ifA granted P to B (or Aowns P). In other words, the act of delegating creates a new link in a delegation chain, and revocation removes that link.
4.2 Implementation of Improvements in Abstract Model
We now briefly describe Sorbetas an instantiation of the abstract model. We focus on mechanisms for enforcing information flow, and briefly discuss privilege escalation. Delegation and revocation are discussed in our technical report [13]. Information-flow protection To enforce information-flow policies specified bydisallow-flow(P1, P2) andallow-declassify(P1, P2), we augment the model with
an auxiliary data structureN, which keeps track of information-flow constraints. More concretely, N maps a component instance iC to the set of information-flow constraints that includes all such policies specified by components in the call chain before and includingiC.
We define forbidP(N,iC) to return the set of permissions that are for-bidden from being used by constraints in N(iC). For instance, if N(iC) = {disallow-flow(P1, P2)}, then forbidP returns {P2}. FunctionguardP(Σ,iC)
re-turns the set of permissions that guards the calls to componentiC. A successful call between components in the same group can now be defined as follows.
call-t(Σ;E, n::calliC1 iC2 I)
ok(n)
−→ (updateCall(Σ,calliC1 iC2 I);E)
ifiC2.ϕckCaller(Σ,iC1) =trueandiC1.ϕckCallee(Σ,iC2) =true
andguardP(Σ,iC2)∩forbidP(N,iC1) =∅
The last line is the added check for information-flow policies. The call succeeds only if the permission required to access the callee is not forbidden by the policy. If the call succeeds, information will flow from the caller to the callee, and straints need to be similarly propagated. In addition, the callee has its own con-straints that need to be incorporated inN. For this, we define two new functions. updFlow(N,iC,Fl) returns a new mapping N0, whereN0(iC) = N(iC)∪Fl. updDeclassify(N,iC,allow-declassify(P1, P2)) returns a new mapping N0, which
removesdisallow-flow(P1, P2) fromN foriC. Hence, after a declassification
per-missionallow-declassify(P1, P2) is encountered, the constraint that forbade access
to components guarded by P2 is lifted. E.g., if the user explicitly allows access
to the Internet after private data is read, then this will be allowed.
We define function flowP(Σ,iC) to return the set of information-flow con-straints that guard the calls to iC, and getDeclassify(iC) to return the set of declassification permissions of iC. The function updateCall first computes N0 = updFlow(N,iC
2, flowP(Σ,iC1)), then N00 = updFlow(N0,iC2,N(iC1)),
and finallyN000=updDeclassify(N00,iC
2,getDeclassify(iC2)).
Android does not mediate all communications between components within the same application (e.g., via shared static fields). Sorbet conservatively as-sumes that components within an application have communicated, and treats cross-application calls differently. We write NA(iC) to be the union of sets
of information-flow constraints N(iC0), for each iC0 that is in the same ap-plication as iC. We define forbidPA(N,iC) = NA(iC). We define function
guardPA(Σ,iC) to return the set of permissions that guards the calls to all components in the same application as component iC. In the rule for cross-application calls, NA takes the place of N, and guardPA takes the place of
guardP. This means that if any component in an application has accessed private data protected by disallow-flow(P1, P2), then no component in that application
can use permissionP2. The update function similarly accumulates all constraints
in the entire application, rather than just one component.
Returns are treated similarly to calls, with the caller and callee designations switched. We omit the definitions here for space reasons.
Privilege-escalation protection To prevent privilege escalation, we use aux-iliary tree-like data structures to keep track of the full call history. We define a call forestTS as a list of call treesT, as follows:
Call ForestTS::= [T1,· · ·,Tn] Call TreeT ::= (TS,(iC,P))
We use MTS to denote a mapping from run-time components to call forests.
Each call tree represents a call chain, and the root of the tree is the last com-ponent on the call chain. The child of the root is a call forest, which is a list of call chains, each representing a past call chain to the root component. If com-ponent A (which has permissions PA) calls B (with permissions PB), and C
(with permissionsPC) also callsB, andB has only one run-time instance, then
MTS(B) = [([ ],(A, PA)),([ ],(C, PC))]. In other words, each call tree in the call
forestMTS(B) records the full context of the call stack. IfB now callsD, the
call tree ([([ ],(A, PA)),([ ],(C, PC))],(B, PB)) will be stored inMTS(D).
A call from component A to component B is allowed only when for any permission P that guards the access to B, either A has ˆP; or A has P and for every call chain recorded in MTS(A), either (1) all the components have
permissionP; or (2) there exists a componentC that has permission ˆP, and all the components in the call stack afterC have P.
As with information flow, the rule for cross-application calls assumes that all components within an application have communicated with each other.
4.3 Properties
We prove Sorbet obeys Prop. 1–6. Here we show only the more concrete re-statements of Prop. 5 and 6 made possible bySorbet’s new policy statements (disallow-flow,allow-declassify, and ˆP). For brevity, details and proof sketches are relegated to our companion technical report [13].
We first define an indirect call chain.
Definition1. (Indirect call chain) Given components A and B, there exists
an indirect call chainfromA toB if there exist 1. componentsD1,· · ·, Dk; and
2. call chains fromA toD1, fromD1 toD2,· · ·, and fromDk toB.
We say that a componentA can influenceanother componentB if there is an indirect call chain from A to B. For example, A can affect the behavior of
B (i.e., the intents that B sends) if either (1) A is part of a call chain to B, or (2)Aappears in a call chain to some component D, and this chain shares a component with a different call chain toB. The shared component carries A’s influence toB.
Property5*. (Privilege escalation (2)) Given a component B protected by permission P, and a component A that does not have P and belongs to a dif-ferent application thanB, ifSAB is a system that containsAandB (and other
components), and SB is the same system without A, then a (possibly indirect)
call chain that ends in B exists inSAB if and only if it exists inSB. Additional
(possibly indirect) call chains may exist in SAB only if each such chain has a
common suffix with a (possibly indirect) call chain fromAtoB, and there exists a component between A and B that has permission Pˆ; or there is a component
B0 between A and B, the path between B and B0 contains components of the same application, andB0 is not protected by permissionP but communicated to
B via unmonitored channels.
Property6*. (Information flow (2)) Suppose a component A is guarded by
permissionP1 and an information-flow policy disallow-flow(P1, P2), and a
com-ponentB is guarded byP2, andAandB belong to different applications. Then,
a (possibly indirect) call chain that ends with B, in a system with A, exists if and only if the same call chain exists in a system withoutA. Additional (possibly indirect) call chains may exist in the system withAonly if each such chain has a common suffix with a (possibly indirect) call chain fromAtoB, and there exists a component betweenA andB that has permission allow-declassify(P1, P2).
5
Implementing and Evaluating Sorbet
We implemented Sorbet on top of Android 2.3.7. This section describes the most salient implementation details, including the syntactic additions for ex-pressingSorbet’s policies, and a case study that illustratesSorbet’s features. Syntactic additions We extended Android’s manifest file syntax to support information-flow and integrity policies. The component protected by P1 can
specifydisallow-flow(P1, P2) by addingandroid:forbiddenPermissions=["P2"]to
the permissions by which this component is protected. allow-declassify(P1, P2)
is specified as<declassified-info source=["P1"] destination=["P2"]/>. A
per-mission is labeled as privileged ˆP by the addition of a “privileged” attribute to its declaration: <uses-permission android:name="P" android:privileged="true"/>. Implementation overview Sorbet’s keystone is a reference monitor built on top of Android’s ActivityManager (Fig. 3). ActivityManager already medi-ates inter-component communication, which includes preventing calls that are illegal by Android’s policy; Sorbet modifies it so that mediation of relevant calls is handled bySorbet instead of by the legacy parts of ActivityManager. Enforcing Sorbet’s policies also requires additional bookkeeping, including of instance data (e.g., to recognize that a particular application has accessed a re-source protected by a “forbidden” permission), and richer static policy specified
in application manifests. Hence, a significant component ofSorbet’s implemen-tation is the data structures that implement this bookkeeping. The bookkeeping includes keeping track of individual files accessed by applications; for enforce-ment purposes, these are treated as components.
!""#$ &'()*+',$ !""%$ !-.+/01$ 23435',$ 6),7'0$ &'8','4-'$ 2)4/0),$ 93-:35'$23435',$ ;3+3$!9<$ =',4'*$ <4(034-'$ >303$ !""#$ !""%$ 6),7'0$603.-$ >303$ !4?,)/?$9',@($
Fig. 3. Sorbet architecture: additions to Android are shaded; arrows indicate inter-actions between system components. The most challenging part in
im-plementing Sorbet was to identify not just which application invoked a protected resource (which Android typically already does) but which spe-cific component instance was respon-sible for the call; we accomplished this by enhancing Android’s IPC data structures to carry more information about the caller. Another challenge was to capture operations not me-diated by ActivityManager, such as opening a socket or a file. Android enforces permission-based policies on such operations by Linux-level checks based on the (Linux) group ID of the calling application; applications are assigned group IDs at installation time by the package manager. To me-diate access to these operations, we
used TOMOYO Linux [21], a set of Linux kernel patches that replaces scat-tered, ad-hoc access-control checks with centralized ones.2We further extended TOMOYO Linux so that access attempts for which policy was enforced at Linux level (e.g., to open a socket or a file) trigger a call toSorbet’s reference monitor. This also allowsSorbetto mediate security-relevant behaviors implemented in native code that may be included in Android applications.
Case study To testSorbetand illustrate its usefulness, we used it to imple-ment several policies; some that can be impleimple-mented (sometimes partially) by previously proposed mechanisms (e.g., [2, 7]), and some that requireSorbet’s features. Our main case study involves four applications: a file manager for stor-ing and manipulatstor-ing private files (e.g., a diary or list of account numbers); a text editor; an encryption application; and an email application. The high-level policy we focus on is to prevent private files from being leaked on the Internet, but to allow them to be manipulated by various applications at the user’s be-hest (e.g., by using the private file manager to launch an editor). Private files are kept in a content provider implemented by the file manager, and protected by separate permissions that allow read and write access. Applications can access private files only when dynamically delegated the appropriate permissions by the file manager. We next describe several specific scenarios (summarized in Fig. 4) that examine variants of this policy and show how they could be implemented.
2
Scenario Private FileManager Editor Encryption
App Email App PE IF
1 Private files cannot be sent over the network
a protected by
R/W perms – – – – –
b protected by
R/W permsuse Internet use Internet use Internet X – c
protected by R/W perms forbid Internet
use Internet use Internet use Internet – X
2 Private files sent over network only via email
a protected by
R/W permsuse Internet use Internet useInternet\ X – b
protected by R/W perms forbid Internet
use Internet use Internet
use Internet declassify
R/W→Internet – X
3 Private files sent over network only via email and if encrypted
protected by R/W perms forbid Internet use Internet use Internet declassify R/W→Internet useInternet\ X X
Fig. 4.Three scenarios from our case study. Columns indicate the permissions assigned to each application, and whether enforcement is via protection from privilege escalation (PE), or information flow prevention (IF).
Scenario 1. We start from a base case in which private files must not be sent over the network (Fig. 4, Scenario 1). In Android, the only way to prevent one of these applications from leaking files to the network is to avoid granting any of the applications the Internet permission (Scenario 1a). In Sorbet, this policy can be enforced by either the mechanism that prevents privilege escalation or the one that prevents undesired information flows. In the first case, all other applications can be granted the Internet permission, but will no longer be able to use it if the file manager, which does not have this permission, is on the call stack (Scenario 1b). In the second case, the file manager declares the Internet permission as forbidden, with the same effect (Scenario 1c).
Scenario 2.We now extend the desired policy to allow only the email client to send a private file (an activity that the user explicitly initiates), while other ap-plications can use the Internet for other purposes. This cannot be implemented in stock Android, but can still be done with either ofSorbet’s protection mech-anisms. For enforcement via the privilege-escalation mechanism, the email app must declare and be granted the privileged version of the Internet permission. To enforce the same policy viaSorbet’s information-flow mechanism, the file manager would declare the Internet permission as forbidden (as in Scenario 1), and the email would declare the permission to declassify from R/W to Internet. Scenario 3.Finally, we extend the policy from Scenario 2 to allow emailing pri-vate files only if they are encrypted. Enforcing this without limiting reasonable uses of the email app requires both the information-flow and privilege-escalation mechanisms. As in Scenario 2a, the email app is given the privileged Internet permission, so that it can send email even if indirectly invoked by the file man-ager, which does not have the Internet permission. In addition, the file manager declares the Internet permission forbidden, and the encryption app is allowed to
declassify. Now, the only path to emailing private files is via the encryption app, which is trusted to invoke the email app only with encrypted data.
The last scenario shows thatSorbetallows easy specification of useful poli-cies significantly beyond what Android offers. Our case study used minimally modified off-the-shelf applications: Open Manager v2.1.8, Qute Text Editor v0.1, Android Privacy Guard v1.0.9, Email v2.3.4. We modified manifest files, added sending functionality to some, and added a content provider to Open Manager.
Sorbet’s overhead was sufficiently small to be unobservable by the user.3
6
Related Work
Researchers have analyzed the security of Android’s permission system [5, 10], developed analysis tools for Android applications [11], and proposed new pro-tection mechanisms (e.g., [20, 22]). Many works studied Android’s attack surface (e.g., [19]), including covert channels [24], DoS [1] and web attacks [17], and unauthorized application repackaging [27].
Several works have pointed out flaws in Android’s permission system. One weakness is the lack of global properties: Android’s permission system does not prevent privilege escalation or information leakage. Davi et al. [6] and Felt et al. [12] have studied privilege-escalation attacks in detail. Bugiel et al. devel-oped a system that monitors interactions between applications at run time and mitigates a wide range of privilege-escalation attacks [2]. Our mechanism has many similarities, but we focus on allowing developers to specify policies on a per-application basis, and emphasize formal analysis of mechanisms. Dietz et al. proposed a framework, Quire, for provenance tracking to mitigate the confused deputy problem [7]. Our goals overlap, butSorbetdiffers in several ways: We do not track full provenance information, but instead focus on flexible, application-level policy specification based on permissions; we rely on the Android runtime for bookkeeping, rather than using digital signatures. We also support declas-sification, and formally investigate Sorbet’s properties. Another approach to mitigating application collusion is through domain isolation. Bugiel et al. as-signed trust levels to applications, allowing them to communicate only if they are at the same level [3]. They focus on defining policy for a set of applications at the same trust level, whereas we let applications define policy individually.
Several works have investigated privacy leaks in Android [8, 24, 4, 9]. We pro-vide a formal framework that allows such flaws to be seen as violations of desired security properties. Projects such as TaintDroid [8] and AppFence [14] aim to automatically detect and prevent dangerous information leaks. Our work is in several ways complementary. TaintDroid and AppFence operate at a much finer granularity, tracking tainting at the level of variables, and enforce fixed policies. In contrast, our enforcement is at the component level, and allows developers
3
We ran microbenchmarks, but, as common in this setting, the small changes—and sometimes improvements—in latency were dwarfed by the variances between runs.
to specify policies, including, e.g., declassification, which is key to enabling ap-plications that have legitimate reason to send tainted data to operate. We also formally prove that our design enforces desired high-level security properties.
Systems such as Saint [22] and Apex [20] also improve Android’s permission system, e.g., by protecting callers with guards that consider context beyond just permissions, while staying generally close to the original design. We focus on deeper revisions to the permission model and enforcing transitive properties.
Formal analysis of Android-related security issues has received less attention. Shin et al. [25] developed a formal model in order to verify functional correctness properties of Android, which revealed a flaw in the naming scheme for permis-sions and a possible attack [26]. In contrast, our work develops a more abstract model suitable for reasoning about extensions to Android’s permission system.
7
Conclusion
This paper develops a framework for formally analyzing Android-style permis-sion systems, and shows how to enhance Android’s permispermis-sion system to support rich policies while maintaining convenient, application-centric policy specifica-tion. We have proved the design of our enforcement system satisfies a set of secu-rity properties, showed its feasibility by implementing and running it on a Nexus S phone, and demonstrated its usefulness through a case study. In doing so, we discover that Android’s inability to provide strong isolation between components constrains the expressiveness of our system and complicates its implementation. Our system successfully provides both application- and component-level protec-tions, but it would need to resort to application-level protection less often if Android’s component-level abstractions were more robust.
Acknowledgments This research was supported by NSF grants 0917047 and 1018211; by CyLab at Carnegie Mellon under grants DAAD19-02-1-0389 and W911NF-09-1-0273 from the Army Research Office; and by a gift from KDDI R&D Laboratories Inc.
References
1. A. Armando, A. Merlo, M.M., Verderame, L.: Would you mind forking this process? A denial of service attack on Android (and some countermeasures). In: Proc. IFIP SEC (2012)
2. Bugiel, S., Davi, L., Dmitrienko, A., Fischer, T., Sadeghi, A.R., Shastry, B.: To-wards taming privilege-escalation attacks on Android. In: Proc. NDSS (2012) 3. Bugiel, S., Davi, L., Dmitrienko, A., Heuser, S., Sadeghi, A.R., Shastry, B.:
Prac-tical and lightweight domain isolation on Android. In: Proc. SPSM (2011) 4. Chaudhuri, A.: Language-based security on Android. In: PLAS Workshop (2009) 5. Chin, E., Felt, A.P., Greenwood, K., Wagner, D.: Analyzing inter-application
6. Davi, L., Dmitrienko, A., Sadeghi, A.R., Winandy, M.: Privilege escalation attacks on Android. In: Proc. ISC (2010)
7. Dietz, M., Shekhar, S., Pisetsky, Y., Shu, A., Wallach, D.S.: Quire: Lightweight provenance for smart phone operating systems. In: Proc. USENIX Security (2011) 8. Enck, W., Gilbert, P., gon Chun, B., Cox, L.P., Jung, J., McDaniel, P., Sheth, A.N.: TaintDroid: An information-flow tracking system for realtime privacy monitoring on smartphones. In: Proc. USENIX OSDI (2010)
9. Enck, W., Octeau, D., McDaniel, P., Chaudhuri, S.: A study of Android application security. In: Proc. USENIX Security (2011)
10. Enck, W., Ongtang, M., McDaniel, P.D.: On lightweight mobile phone application certification. In: Proc. CCS (2009)
11. Felt, A.P., Chin, E., Hanna, S., Song, D., Wagner, D.: Android permissions demys-tified. In: Proc. CCS (2011)
12. Felt, A.P., Wang, H., Moshchuk, A., Hanna, S., Chin, E.: Permission re-delegation: Attacks and defenses. In: Proc. USENIX Security (2011)
13. Fragkaki, E., Bauer, L., Jia, L.: Modeling and enhancing Android’s permission sys-tem. Tech. Rep. CMU-CyLab-11-020, CyLab, Carnegie Mellon University (2011) 14. Hornyack, P., Han, S., Jung, J., Schechter, S., Wetherall, D.: These aren’t the
droids you’re looking for: Retrofitting Android to protect data from imperious applications. In: Proc. CCS (2011)
15. Lineberry, A., Richardson, D.L., Wyatt, T.: These aren’t the permissions you’re looking for. www.defcon.org/images/defcon-18/dc-18-presentations/ Lineberry/DEFCON-18-Lineberry-Not-The-Permissions-You-Are-Looking-For. pdf(2010), [accessed 10-Apr-2012]
16. Loftus, J.: DefCon dings reveal Google product security risks. gizmodo.com/
5828478(2011), [accessed 10-Apr-2012]
17. Luo, T., Hao, H., Du, W., Wang, Y., Yin, H.: Attacks on WebView in the Android system. In: Proc. ACSAC (2011)
18. Marforio, C., Francillon, A., ˇCapkun, S.: Application collusion attack on the permission-based security model and its implications for modern smartphone sys-tems. Tech. Rep. 724, ETH Zurich (2011)
19. Mylonas, A., Dritsas, S., Tsoumas, B., Gritzalis, D.: Smartphone security evalua-tion – The malware attack case. In: Proc. SECRYPT (2011)
20. Nauman, M., Khan, S., Zhang, X.: Apex: extending Android permission model and enforcement with user-defined runtime constraints. In: Proc. ASIACCS (2010) 21. NTT Data Corporation: TOMOYO Linux.tomoyo.sourceforge.jp/(2012),
[ac-cessed 10-Apr-2012]
22. Ongtang, M., McLaughlin, S.E., Enck, W., McDaniel, P.D.: Semantically rich application-centric security in Android. In: Proc. ACSAC (2009)
23. Passeri, P.: One year of Android malware (full list).hackmageddon.com/2011/08/
11/one-year-of-android-malware-full-list/(2011), [accessed 20-Jun-2012]
24. Schlegel, R., Zhang, K., Zhou, X., Intwala, M., Kapadia, A., Wang, X.: Sound-comber: A stealthy and context-aware sound Trojan for smartphones. In: Proc. NDSS (2011)
25. Shin, W., Kiyomoto, S., Fukushima, K., Tanaka, T.: A formal model to analyze the permission authorization and enforcement in the Android framework. In: Proc. SocialCom/PASSAT (2010)
26. Shin, W., Kwak, S., Kiyomoto, S., Fukushima, K., Tanaka, T.: A small but non-negligible flaw in the Android permission scheme. In: Proc. POLICY (2010) 27. Zhou, W., Zhou, Y., Jiang, X., Ning, P.: Detecting repackaged smartphone
