ASM: A Programmable Interface for Extending Android Security Stephan Heuser, Intel CRI-SC at Technische Universität Darmstadt; Adwait Nadkarni and William Enck, North Carolina State University; Ahmad-Reza Sadeghi, Technische Universität Darmstadt and Center for Advanced Security Research Darmstadt (CASED) https://www.usenix.org/conference/usenixsecurity14/technical-sessions/presentation/heuser
This paper is included in the Proceedings of the 23rd USENIX Security Symposium. August 20–22, 2014 • San Diego, CA ISBN 978-1-931971-15-7
Open access to the Proceedings of the 23rd USENIX Security Symposium is sponsored by USENIX ASM: A Programmable Interface for Extending Android Security
* Stephan Heuser∗ Adwait Nadkarni [email protected] [email protected] Intel CRI-SC at TU Darmstadt North Carolina State University William Enck Ahmad-Reza Sadeghi [email protected] [email protected] North Carolina State University TU Darmstadt / CASED
Abstract such as “get location,” “take picture,” and “search ad- dress book.” The availability of these semantically rich Android, iOS, and Windows 8 are changing the applica- OS APIs vastly simplifies application development, and tion architecture of consumer operating systems. These has led to an explosive growth in the number and diver- new architectures required OS designers to rethink secu- sity of available applications. rity and access control. While the new security archi- These functional changes caused OS designers to re- tectures improve on traditional desktop and server OS think security. The new application abstractions both en- designs, they lack sufficient protection semantics for dif- able and necessitate assigning each user application to a ferent classes of OS customers (e.g., consumer, enter- unique protection domain, rather than executing all user prise, and government). The Android OS in particular applications with the user’s ambient authority (the norm has seen over a dozen research proposals for security in traditional OSes such as Windows and UNIX). By de- enhancements. This paper seeks to promote OS secu- fault, each application’s protection domain is small, often rity extensibility in the Android OS. We propose the An- containing only the OS APIs deemed not to be security droid Security Modules (ASM) framework, which pro- sensitive and the files it creates. The application must be vides a programmable interface for defining new refer- granted capabilities to access the full set of semantically ence monitors for Android. We drive the ASM design by rich OS APIs. This security model provides a better ap- studying the authorization hook requirements of recent proximation of least privilege, which limits both the im- security enhancement proposals and identify that new pact of an exploited application, as well as the authority OSes such as Android require new types of authorization granted to a Trojan. However, how and when to grant hooks (e.g., replacing data). We describe the design and these privileges has been the topic of much debate [16]. implementation of ASM and demonstrate its utility by For the last several years, the security research com- developing reference monitors called ASM apps. Finally, munity has contributed significant discourse on the right ASM is not only beneficial for security researchers. If security architecture for these new operating systems. adopted by Google, we envision ASM enabling in-the- Android has been the focus of this discourse, mostly due field security enhancement of Android devices without to its open source foundation, widespread popularity for requiring root access, a significant limitation of existing mobile devices, and the emergence of malware targeting bring-your-own-device solutions. it. In the relatively short period of time since the An- droid platform’s initial release in 2008, there have been 1 Introduction more than a dozen proposals for new Android security architectures [15, 24, 14, 23, 10, 7, 8, 37, 6, 19, 18, 12, Consumer operating systems are changing. Android, 9, 22, 29]. As we discuss in this paper, while these secu- iOS, and Windows 8 place a high priority on the user- rity architecture proposals have very diverse motivations, application experience. They provide new abstractions their implementations often share hook placements and for developing user-applications: applications fill the enforcement mechanisms. screen; they have complex lifecycles that respond to The primary goal of this paper is to promote OS secu- user and system events; and they use semantically rich rity extensibility [33] in the Android platform. History OS provided application programming interfaces (APIs) has shown that simply providing type enforcement, in- formation flow control, or capabilities does not meet the
∗These authors contributed equally to this work. demands of all potential OS customers (e.g., consumers,
USENIX Association 23rd USENIX Security Symposium 1005 enterprise, government). Therefore, an extensible OS se- need to change, eliminating the need to port each re- curity interface must be programmable [33]. In short, we search project to new versions. ASM can provide even seek to accomplish for Android what the LSM [34] and greater benefit if it is adopted into the Android Open TrustedBSD [32] frameworks have provided for Linux Source Project (AOSP): ASM apps can be added without and BSD, respectively. What makes this task interesting source code modification. Ultimately, we envision an in- and meaningful to the research community is the pro- terface that allows enterprise IT and researchers to load cess of determining the correct semantics of authoriza- ASM apps on production phones without root access. tion hooks for this new OS architecture. The remainder of this paper proceeds as follows. Sec- In this paper, we propose the Android Security Mod- tion 2 provides a short background on Android. Section 3 ules (ASM) framework, which provides a set of autho- defines high level goals that underlie the ASM design. rization hooks to build reference monitors for Android Section 4 surveys recent work enhancing Android secu- security. We survey over a dozen recent Android secu- rity and identifies a common set of authorization hook se- rity architecture proposals to identify the hook seman- mantics. Section 5 describes the ASM design. Section 6 tics required of ASM. Of particular note, we identify the evaluates the utility and performance of ASM. Section 7 need to (1) replace data values in OS APIs, and (2) allow highlights related work on OS security extensibility. Sec- third-party applications to define new ASM hooks. We tion 8 concludes. design and implement an open source version of ASM within Android version 4.4 and empirically demonstrate negligible overhead when no security module is loaded. 2 Background ASM fulfills a strong need in the research community. It The Android OS is based on a Linux kernel, but pro- provides researchers a standardized interface for security vides a substantially different application abstraction architectures and will potentially lead to field enhance- than found in traditional Linux desktop and server dis- ment of devices without modifying the system firmware tributions. Android applications are written in Java and (e.g., BYOD), if adopted by Google. compiled into a special DEX bytecode that executes in This paper makes the following contributions: Android’s Dalvik virtual machine. Applications may op- We identify the authorization hook semantics re- tionally contain native code components. Application • quired for new operating systems such as Android. functionality is divided into components. Android de- The Android OS is responsible for enforcing more fines four types of components: activity, service, broad- than just UNIX system calls. Android includes se- cast receiver, and content provider. The application’s mantically rich OS APIs and new application lifecy- user interface is composed of a set of activity compo- cle abstractions that must be included in OS access nents. Service components act as daemons, providing control. We also identify the need for authorization background processing. Broadcast receiver components hooks to replace data values and for third-party ap- handle asynchronous messages. Content provider com- plications to introduce new authorization hooks. ponents are per-application data servers that are queried by other applications. We design and implement the extensible Android Se- • Application components communicate with one an- curity Modules (ASM) framework. ASM brings OS other using Binder interprocess communication (IPC). security extensibility to Android. It allows mul- Binder provides message passing (called parcels) and tiple simultaneous ASM apps to enforce security thread management. In addition to data values, parcels requirements while minimizing performance over- can pass references to other binder objects as well as file head based on the required authorization hooks. descriptors. When an application holds a reference to a service component binder object, it can execute remote We implement two example ASM apps to demon- • procedure calls (RPCs) for any methods defined by that strate the utility of the ASM framework. ASM al- service. Most of Android’s semantically rich OS APIs lowed the fast development of useful example ASM are implemented as RPCs to OS defined service com- apps with functionalities similar to MockDroid [6] ponents. The OS also defines several content provider and password protected apps. components (e.g., address book) that are queried using Finally, we envision multiple ways in which ASM can special RPC methods. It should be noted that while de- benefit the security community. ASM currently provides velopers are encouraged to use Binder IPC, Android also great value to researchers with the ability to modify the supports standard Linux IPC mechanisms, for example source code of a device. It provides a modular interface domain sockets or pipes. to define callbacks for a set of authorization hooks that Applications often interface with Binder indirectly us- provide mediation of important protection events. As the ing intent messages. The intent message abstraction is Android OS changes, only the ASM hook placements used for communication between activity and broadcast
1006 23rd USENIX Security Symposium USENIX Association receiver components, as well as starting service compo- G2 Ensure existing security guarantees. Android nents. Intent messages can be addressed to implicit ac- provides sandboxing guarantees to application tion strings that are resolved by the Activity Manager providers. Allowing third-parties to extend An- Service (AMS). Intent messages and action strings al- droid’s security framework potentially breaks those low end users and OEMs to customize the applications guarantees. Therefore, ASM’s reference moni- used to perform tasks. The AMS resolves the desired tor interface hooks should only make enforcement target application and component, starting a new process more restrictive (e.g., fewer permissions or less file or thread if necessary. system access). Note that by only allowing more Android enforces component security requirements restrictive enforcement, we lose expressibility (e.g., using permissions (i.e., text strings that represent capa- for capability models). bilities). Android defines a set of core permissions for G3 Protect kernel integrity. As an explicit extension to protecting OS resources and applications, but third-party Goal G2, we must maintain kernel integrity. Some application developers can define new permissions that authorization modules will require hooks within the are enforced using the same mechanisms as OS permis- Linux kernel. We cannot provide the LSM inter- sions. Permissions are granted to applications on install face to third-parties without some controls. We ex- and stored in the Package Manager Service (PMS). An- plore several methods of exposing this functionality droid places authorization hooks (implemented as a fam- in Section 5.4.5. ily of checkPermission() methods) in the AMS as well as OS service component RPC methods. checkPermis- G4 Multiple authorization modules. While there have sion() is called along with the process identifier (PID) of been proposals for supporting multiple LSMs [27], the caller and the appropriate permission string. Calling official support for multiple authorization modules checkPermission() invokes an RPC in the PMS, which re- in Linux has not been adopted at the time of writing. turns granted if the caller’s PID belongs to an application We see benefit in allowing multiple ASM modules that is granted the permission, and throws a security ex- (e.g., personal and enterprise) and seek to design ception if it is denied. However, not all permissions are support for multiple authorization modules into the enforced using checkPermission(). Permissions that con- design of ASM. Achieving multiple authorization trol access to low-level capabilities are mapped to Linux modules requires carefully designing the architec- group identifiers (GIDs). Such capabilities include open- ture to address potential conflicts. ing network sockets and accessing the SDcard storage. G5 Minimize resource overhead. When no authoriza- For these permissions, corresponding GIDs are assigned tion module is loaded, ASM should have negligi- to applications at installation time, and the kernel pro- ble impact on system resources (e.g., CPU perfor- vides enforcement. mance, energy consumption). Furthermore, given the wide variety of authorization hook semantics, 3 Design Goals we recognize that not all authorization modules will A secure operating system requires a reference moni- require all hooks. Since some hooks have more tor [2]. Ideally, a reference monitor provides three guar- overhead than others, we seek to design ASM such antees: complete mediation, tamperpoofness, and ver- that different hooks can be enabled and disabled to ifiability. We seek to provide a foundation for build- minimize overhead. ing reference monitors in Android. As with LSM [34], the ASM only provides the reference monitor interface Threat Model: ASM assumes that the base Android OS hooks upon which authorization modules are built. Fur- and services are trusted. That is, our trusted comput- thermore, similar to the initial design of LSM, our ASM ing base (TCB) includes the Linux kernel, the AMS, the design manually places hooks throughout Android. PMS, and all OS service and content provider compo- We seek to design a programmable interface for build- nents. We assume that third-party applications have com- ing new security enhancements to the Android platform. plete control over their process address spaces. That is, Our design is guided by the following goals. any authorization hooks placed in framework code that executes within the third-party application’s process is G1 Generic authorization expressibility. We seek to untrusted. Finally, since third-party applications can in- provide the reference monitor interface hooks nec- clude their own authorization hooks, they must be trusted essary to develop both prior and future security to mediate the protection events they define. enhancements for Android. Not all authorization modules will use all hooks, and hooks may need 4 Authorization Hook Semantics to be placed at different levels to obtain sufficient The underlying motivation of ASM is to provide a pro- enforcement semantics. grammable interface to extend Android security. Re-
USENIX Association 23rd USENIX Security Symposium 1007 Table 1: Classification of authorization hook semantics required by Android security enhancements Android Package Sensors / Fake System Content File Network Third Party System ICC Manager Phone Info Data Providers Access Access Extension MockDroid [6] XManDroid [7] TrustDroid [8] FlaskDroid [9] CRePE [10] Quire [12] TaintDroid [14] Kirin [15] IPC Inspection [18] AppFence [19] Aquifer [22] APEX [23] Saint [24] SEAndroid [29] TISSA [37] cently, Google adopted the UNIX-level portion of the The Package Manager Service (PMS) is also frequently SEAndroid [29] project into AOSP. However, Android modified to customize application permissions. Per- security is significantly more complex than simply medi- missions are also occasionally customized by modify- ating UNIX system calls. Nearly all application commu- ing the interfaces to device sensors and system content nication occurs through Binder IPC, which from a UNIX providers containing privacy sensitive information (e.g., perspective is an ioctl to /dev/binder. Mediating the address book). Several proposals also require authoriza- higher level application communication has been the fo- tion hooks for file and network access, which are en- cus of most Android security research. The goal of this forced in the Linux kernel. section is to explore these different proposals to identify The table also denotes two areas that are nonstandard a common set of authorization hooks semantics. That is, for OS reference monitors. The first hook semantics is we seek to satisfy Goal G1 by surveying existing propos- the use of fake data. That is, instead of simply allowing als to enhance Android security. or denying a protected operation, the hook must mod- Academic and industry researchers have proposed ify the value that is returned. This third option is of- many different security enhancements to the Android ten essential to protecting user privacy while maintain- OS. These enhancements have a wide range of mo- ing usability. For example, the geographic coordinates tivations. For example, Kirin [15] places constraints of the north pole, or maybe a coarse city coordinates can on permissions of applications being installed. Frame- be substituted for the devices actual location. Replacing works such as Saint [24], XManDroid [7] and Trust- unique identifiers (e.g. IMEI or IMSI) to combat adver- Droid [8] focus on mediating communication between tising tracking is a further example. The second interest- components in different applications. FlaskDroid [9] and ing hook semantics is the inclusion of third-party hooks. the aforementioned SEAndroid [29] project also medi- That is, a third-party application wishes the OS reference ate component interaction as a part of their enforcement. monitor to help enforce its security goals. Aquifer [22] enforces information flow control policies Finally, TaintDroid [14] and AppFence [19] use fine- that follow the user’s UI workflow. IPC Inspection [18] grained taint tracking. They modify Android’s Dalvik and Quire [12] track Android intent messages through a environment to track information within a process. How- chain of applications to prevent privilege escalation at- ever, dynamic taint tracking has false negatives, which tacks. TaintDroid [14] and AppFence [19] dynamically may lead to access control circumvention. It also in- track privacy sensitive information as it is used within curs more performance overhead than may be tolerable an application. APEX [23] and CRePE [10] provide for some environments. In this work, we only consider fine-grained permissions. TISSA [37], MockDroid [6], mediation at the process level. Therefore, TaintDroid and AppFence [19] allow fine-grained policies as well as and AppFence cannot be built on top of ASM. However, allow the substitution of fake information into Android this does not preclude researchers from combining Taint- APIs. While these proposals have diverse motivations, Droid with ASM. many share authorization hook semantics. Table 1 classifies this prior work by authorization hook 5 ASM Design semantics. Nearly all of the proposals modify Android’s The authorization hooks identified in the previous sec- Activity Manager Service (AMS) to provide additional tion describe semantically what to mediate, but not how constraints on Inter-Component Communication (ICC). to mediate it. Existing Android security enhancements
1008 23rd USENIX Security Symposium USENIX Association Access Control Callback ASM App Registration: An ASM app must register it- ASM Hook self with the ASM Bridge after it is installed. The time ASM apps Other 3rd of registration depends on logic in the specific ASM app. ASM 1 ASM 2 ... party apps Applications For example, the ASM app could register itself automat- System Services Activity System Content ically after install, or it could provide a user interface to (e.g. telephony, Manager Service Providers enable and disable it. When the ASM Bridge receives the location) Android OS registration, it updates its persistent configuration. To ac- ASM Bridge tivate the ASM app, the device must reboot. We require a Linux Kernel reboot to ensure ASM apps receive all protection events ASM LSM since boot, which may impact their protection state. Figure 1: ASM framework architecture Hook Registration: The ASM app service component is define hooks in different ways, not all of which provide started by ASM during the boot process. At this time, the correct or complete mediation. ASM provides a refer- ASM app registers for reference monitor interface hooks ence monitor interface for building new reference moni- for which it wishes to receive callbacks. Different hooks tors. By doing so, ASM allows reference monitor devel- incur different overheads. ASM only enables a reference opers to focus on their novel security enhancements and monitor hook if it is registered by an ASM app. There- not on placing hooks correctly. It also allows separate fore, ASM app developers should only register for the scrutiny of authorization hook placement that benefits all hooks required for complete mediation. Finally, if the reference monitors built on top of ASM. ASM registers for hooks defined by a third-party appli- Figure 1 shows the ASM framework architecture. Ref- cation (Section 5.4.4), the application developer and the erence monitors are implemented as ASM apps. Each ASM app developer must agree on naming conventions. ASM app registers for a unique set of authorization Handling Hook Callbacks: Once an ASM app regis- hooks, specifying a callback for each. When a protected ters for a reference monitor interface hook, it will re- operation occurs, ASM automatically invokes the call- ceive a callback whenever the corresponding protection back in the ASM app. The ASM reference monitor inter- event occurs. The information provided in the callback is face is contained within the ASM Bridge. In addition to hook-specific. The ASM app returns the access control managing ASM apps, the ASM Bridge receives protec- decision to the ASM Bridge. As discussed in Section 5.3, tion events from authorization hooks placed throughout some hooks allow the callback to replace data values. the Android OS. Since Android places functionality in Finally, similar to registration for third-party hooks, the multiple userspace processes, authorization hooks only ASM app developer must coordinate with the application notify the ASM Bridge if the hook is explicitly enabled. developer for information passed to the callback. ASM also supports authorization hooks within the Linux Registration Protection: Reference monitors are highly kernel. To achieve kernel authorization, a special ASM privileged. While ASM does not allow an ASM LSM performs upcalls to the ASM Bridge, again only app to override existing Android security protections doing so for hooks explicitly enabled. (Goal G2), ASM must still protect the ability to re- This section details the design of the ASM framework. ceive callbacks. ASM protects callbacks using An- We use the following terminology. A protection event droid’s existing permission model. It defines two permis- is an OS event requiring access control. Authorization sions: REGISTER ASM and REGISTER ASM MODIFY. hooks are placed throughout the Android OS, which in- The ASM Bridge ensures that an ASM app has the voke a callback in the ASM Bridge. The ASM Bridge de- REGISTER ASM permission during both ASM app reg- fines reference monitor interface hooks, for which ASM istration and hook registration. Finally, since replacing apps register hook callbacks. Finally, we frequently refer data values in an access control callback has greater se- to the ASM framework as a whole simply as ASM. curity implications, the ASM Bridge ensures the ASM app has the REGISTER ASM MODIFY permission if it 5.1 ASM Apps registers for a hook that allows data modification. This Reference monitors are built as ASM apps. They are allows easy ASM app inspection to identify its abilities. developed using the same conventions as other Android ASM App Deployment: How the ASM permissions are applications. The core part of an ASM app is a service granted has a significant impact on the practical security component that implements the reference monitor hook of devices. Previous studies [17] have demonstrated that interface provided by ASM. There are three main func- end users frequently do not read or understand Android’s tionalities that must be provided within this service. Fi- install time permissions. Therefore, malware may at- nally, the registration interface itself is protected by An- tempt to exploit user comprehension of permissions and droid permissions. gain ASM app privileges. To some extent, this threat is
USENIX Association 23rd USENIX Security Symposium 1009 mitigated by our goal to ensure existing security guaran- 1 2 tees (Goal G2). Different ASM app deployment mod- hook_1 hook_1 ASM 1 els can also mitigate malware. In the use case where re- allow/deny searchers change AOSP source code, these permissions ASM 4 Bridge 3 can be bound to the firmware signing key, thereby only allow/deny hook_1_mod allowing the researchers’ ASM apps to be granted ac- + modied data ASM 2 modied data cess. In the case where ASM is deployed on production devices, ASM could follow the security model used by 1. ASM Bridge receives a callback. 2. The normal hook is invoked. device administration API. That is, a secure setting that 3. The modied data hook (i.e. mod) is invoked. is only modifiable by users would enable whether ASM 4. ASM Bridge returns the result for the initial callback. apps can be used. An alternative is to use a model simi- Figure 2: ASM Hook Invocation lar to Android’s “Unknown sources” setting for installing to the protection event. If the ASM app callback imple- applications. That is, unless a secure user setting is se- mentation is buggy, the authorization hook may stall exe- lected, only Google certified ASM apps can be installed. cution. Therefore, ASM has the ability to set timeouts on callback execution. If a timeout occurs, the ASM Bridge 5.2 ASM Bridge conservatively assumes access is denied. The ASM Bridge 1) provides the reference monitor in- Master Policy: ASM supports multiple simultaneous terface, and 2) coordinates protection events that occur in ASM apps (Goal G4). This goal is motivated by multi- authorization hooks placed throughout the Android OS, stakeholder scenarios, e.g. users, administrators, and as well as third-party applications. As discussed in Sec- device manufacturers installing ASM apps on a device. tion 5.1, ASM apps notify the ASM Bridge of their exis- When more than one ASM app is active, a reconciliation tence via an ASM app registration followed by individ- strategy is required to handle potential conflicts between ual hook registrations. We now discuss several reference access control decisions. The correct conflict resolution monitor interface considerations. strategy is highly use-case specific. Therefore, providing Per-Hook Activation: All reference monitor interface a general solution is infeasible [9]. hooks are deactivated by default. Each authorization ASM addresses this problem using a master policy hook maintains an activation state variable that deter- that defines policy conflict reconciliation. For our im- mines whether or not the ASM Bridge is notified of plementation and evaluation, we use a consensus strat- protection events. This approach eliminates unneces- egy. That is, all active ASM apps must grant an access sary IPC and therefore improves performance (Goal G5) control decision for the action to be allowed. Similar to when no ASM app requires a specific hook. Likewise, FlaskDroid [9], the master policy can be easily modified this approach allows ASM to achieve negligible over- to support other conflict resolution strategies [26, 21]. heard when no ASM apps are loaded (see Section 6.2). For example, a priority-based resolution policy hierar- When an ASM app registers a callback for a deacti- chically orders ASM apps, and a voting policy allows an vated hook, the ASM Bridge activates the hook by noti- action if a specified threshold of ASM apps grant it. fying the corresponding authorization hook implemen- tation. ASM maintains a list of active hooks in each 5.3 Callbacks Modifying Data OS component (e.g., OS service component, OS con- Before discussing the reference monitor interface hooks tent provider component). When a protection event oc- provided by ASM, we must describe one last concept. curs, the OS component creates an access control bundle While most ASM apps require a simple allow/deny ac- that is sent to the ASM Bridge. When the ASM Bridge cess control interface, some may benefit from the abil- receives the access control bundle for a hook, it is for- ity to modify data values. For example, MockDroid [6] warded to each ASM app that registered for the hook. modifies values (e.g., IMEI, location) returned by OS Similarly, the ASM LSM in the kernel (Section 5.4.5) APIs before they are sent to applications. ASM supports maintains a separate activation state variable per hook data modifications by providing a special hook type. and performs an upcall for each protection event. Each reference monitor interface hook that poten- Callback Timeouts: The ASM Bridge is notified of pro- tially requires data replacement is split into two vari- tection events via synchronous communication. Autho- ants: 1) normal, which allows the corresponding call- rization hooks in userspace communicate with the ASM back to simply allow or deny the event, and 2) modify, Bridge using Binder IPC, and the ASM LSM uses syn- which allows the corresponding callback to modify the chronous upcalls, as described in Section 5.4.5. The value returned by the OS API or content provider, in ad- ASM Bridge then uses synchronous Binder IPC to in- dition to specifying allow or deny. As mentioned in Sec- voke all ASM app callbacks for the hook corresponding tion 5.1, modifying data has a greater security sensitivity,
1010 23rd USENIX Security Symposium USENIX Association 1 // Callback received by the ASM Bridge: 1 // Callback received by the ASM Bridge: 2 int start_act(inout Intent intent, in String 2 int resolveActivity_mod(inout List
USENIX Association 23rd USENIX Security Symposium 1011 5.4.2 OS Service Hooks 1 // Callback received by the ASM Bridge: 2 int appOpsQuery(int opcode, int callingUid, String Lifecycle hooks include mediation for inter-component packageName); 3 // Here, opcode = OP_SEND_SMS communication using intent messages. However, ASM 4 // Callback to individual ASMs: apps also require mediation for OS APIs providing func- 5 int sendSms(int callingUid, String packageName); tionality such as getting the geographic location and tak- Listing 3: AppOps Hook for Sending SMS ing pictures. Android implements this functionality in different service components designated as system ser- 1 // Callback received by the ASM Bridge: 2 int getDeviceId(int callingUid, out String[] vices, e.g., location and telephony services. device_ids); ASM uses Android’s AppOps subsystem to place the 3 // Callback to individual ASMs (Modify data): 4 int getDeviceId_mod(int callingUid, out String[] authorization hooks for many OS service hooks. AppOps device_ids); is a very recent addition to AOSP. While there have been Listing 4: getDeviceId Hook several popular media stories of hobbyist developers us- ing AppOps to control per-application permissions, Ap- turn deny or allow. If the return value is allow, the ASM pOps remains largely undocumented and is not yet avail- app can also place a custom value in the first index of able for public use. Based on our code inspection, Ap- the device ids array. This value will be sent to the pOps appears to be an effort by Google to provide more Android application that invoked getDeviceId(), in- flexible control of permission related events. Conceptu- stead of the real device ID. ally, AppOps is an Android security enhancement and could be implemented as an ASM app. We discuss Ap- 5.4.3 Content Provider Hooks pOps as an ASM app further in Section 7. The ASM authorization hooks for services use the Ap- Content provider components are daemons that provide a pOps syntax. AppOps defines opcodes for different op- relational database interface for sharing information with erations, e.g., OP READ CONTACTS or OP SEND SMS. other applications. The ASM Bridge receives callbacks To identify the application performing an operation, the from the OS content provider components (e.g., Calen- Linux uid and the package name of the application are dar, Contacts, and Telephony). Separate hooks are re- used. ASM uses a single authorization hook in AppOps quired for the insert, update, delete and query functions. to call the ASM Bridge. The ASM Bridge decodes the Authorization hooks for insert, update and delete must opcode and translates it into an ASM hook. be invoked before the action is performed, to preserve AppOps supports graceful enforcement. That is, it the integrity of the provider’s data. In contrast, the query returns empty data instead of throwing a Security Ex- function’s hook is invoked after the execution, to allow ception wherever possible (e.g., in Cursors). As a re- filtering of the returned data. sult, apps do not crash when they are denied access The content provider query RPC returns a database to resources. On the other hand, AppOps does not Cursor object. The Cursor object not a parcelable type, allow data values to be modified at runtime. There- and therefore the entire query response is not returned to fore, ASM adds specific data modification hooks. We the caller in a single Binder message. Therefore, ASM also needed to extend AppOps with several hooks for apps cannot filter the query. To account for this, we ex- privacy sensitive operations (e.g., getDeviceId(), tract the Cursor contents into a parcelable ASMCursor onLocationChanged()). We now discuss two wrapper around a CursorWindow object to include in the examples, including both regular AppOps hooks and callback to the ASM Bridge. ASM’s data modification hooks. The following example demonstrates the query inter- Example 3: Listing 3 shows the callback proto- face. ASM only provides normal (i.e., no data modifica- type for the AppOps hook for sending an SMS tion) hooks for insert, delete, and update. (OP SEND SMS). The ASM Bridge receives the generic Example 5: Listing 5 shows the callback prototypes appOpsQuery() callback and translates the opcode for the CallLogProvider OS content provider. The to the sendSms() hook. ASM apps registered for the ASM Bridge receives the original query and the result sendSms() hook receive a callback whenever an SMS wrapped in an ASMCursor. The callback is split into message is sent. normal and modify hook variants. ASM apps that regis- Example 4: Listing 4 shows the data modification call- ter for the normal hook get read access to the query and back prototype for the getDeviceId() OS API call the result. ASM apps registered for the data modify hook in the PhoneSubInfo (i.e., telephony) service. The ASM can also modify the ASMCursor object. Both the hooks Bridge receives a callback from the authorization hook return allow and deny decisions via the return value. and executes the getDeviceId mod() callback in Finally, we note that this use of a CursorWindow ob- ASM apps. ASM apps receiving this callback can re- ject to copy the entire content provider query response
1012 23rd USENIX Security Symposium USENIX Association 1 // Callback received by the ASM Bridge: other ASM authorization hooks, third-party hooks are 2 int callLogQuery(inout ASMCursor cursor, in Uri uri, only activated when an ASM app registers for it. in String[] projection, in String selection, in String[] selectionArgs, in String sortOrder, int ASM apps receive hook callbacks for all of their regis- callingUid, int callingPid); tered third-party hooks via a single interface (technically 3 // Callback to individual ASMs (No modify data): 4 int callLogQuery(in ASMCursor cursor, in Uri uri, in two callbacks, as in Listing 6). Within this callback, String[] projection, in String selection, in String[] ASM apps must identify the third-party hook by name selectionArgs, in String sortOrder, int callingUid, int callingPid); and must interpret the data in the Bundle based on the 5 // Callback to individual ASMs (Modify data): third-party application’s specification. We assume that 6 int callLogQuery_mod(inout ASMCursor cTemp, in Uri uri, in String[] projection, in String selection, in ASM apps that register for third-party hooks are aware String[] selectionArgs, in String sortOrder, int of the absolute hook name and the contained attributes. callingUid, int callingPid); The ASM app returns allow, deny, or allow along with a Listing 5: CallLogProvider query hook modification of the Bundle (for data modification hooks).
1 // Callbacks received by the ASM Bridge: Finally, the third-party application developer must im- 2 int hook_handler(in String name, in Bundle b); plement a special service component to receive hook 3 int hook_handler_mod(in String name, inout Bundle b); 4 // Callback to individual ASMs (No modify data): activation and deactivation callbacks from the ASM 5 int hook_handler(in String name, in Bundle b); Bridge. The ASM Bridge sends messages to this service 6 // Callback to individual ASMs (Modify data): 7 int hook_handler_mod(in String name, inout Bundle b); to update the status of a hook. Third-party application developers must follow the message codes exposed by Listing 6: Third Party Hooks ASM for proper hook management.
into the ASM hook may lead to additional overhead 5.4.5 LSM Hooks when query responses are large. This is because Android uses a lazy retrieval of Cursor contents, only transferring ASM apps sometimes require mediation of UNIX-level portions of the response over Binder IPC as needed. One objects such as files and network sockets. ASM can- way to improve ASM query performance is to intercept not define authorization hooks for such objects in the the actual data access via Binder to modify data, rather userspace portion of the Android OS. Instead, autho- than serializing the entire response. However, this will rization hooks must be placed in the Linux kernel. increase the number of callbacks to ASM apps, resulting Fortunately, the Linux kernel already has the LSM in a trade-off. We will explore this and other methods of reference monitor interface for defining kernel refer- performance improvement in future work. ence monitors. For example, file permission and socket connect LSM hooks mediate file and net- 5.4.4 Third Party Hooks work socket operations, respectively. The main consideration for ASM is how to allow ASM ASM allows third-party Android applications to dynam- apps to interface with these LSM hooks. Several poten- ically add hooks to the ASM Bridge. These hooks are tial approaches exist. First, ASM could allow ASM apps valuable for extending enforcement into Google and de- to load LSM kernel modules directly. This approach is vice manufacturer applications (which are not in AOSP), appropriate when the ASM app developer also has the as well as third-party applications downloaded from ap- ability to rebuild the device firmware. For example, one plication markets (e.g., Google Play Store). Third-party target audience for ASM is security researchers prototyp- hooks are identified by 1) a hook name, and 2) the pack- ing new reference monitors. In this case, the ASM app age name of the application implementing the autho- developer can create userspace and kernel components rization hook. The complete hook name is a charac- and provide communication between the two. ter string of the format package name:hook name. However, we would like to also allow ASM apps to This naming convention provides third parties with their mediate kernel-level objects without rebuilding the de- own namespaces for hooks. Note that third parties do vice firmware. Therefore, a second option is to develop not specify their package name; ASM obtains it using a small mediation programming language that is inter- the registering application’s uid received from Binder. preted by an ASM LSM. In this model, the ASM app To receive callbacks for third-party hooks, ASM apps developer programs access control logic within the inter- implement two generic third-party hook methods, shown preted language, and the logic is loaded along with the in Listing 6. One method handles normal hook callbacks; ASM on boot. Using an interpreted language would en- the other method handles data modification hook call- sure kernel integrity (Goal G3). backs. When the third-party application’s authorization Our current implementation uses a third option. We hook calls the ASM Bridge callback, it passes a generic define a special ASM LSM that implements LSM hooks Bundle object. The ASM forwards the Bundle to regis- and performs synchronous upcalls to the ASM Bridge to tered ASM apps for access control decisions. As with complete the access control decision. Consistent with the
USENIX Association 23rd USENIX Security Symposium 1013 rest of the ASM design, the upcall is only activated when access these xattrs. File xattrs are needed by security en- an ASM app registers for the corresponding reference hancements such as Aquifer [22]. monitor hook. To integrate our ASM LSM into the kernel without removing SEAndroid (Goal G2), we used an un- official multi-LSM patch [27]. We implemented autho- 6 Evaluation rization hooks for many commonly used LSM hooks, in- We evaluate the ASM framework in two ways. First, we cluding file permission and socket connect. evaluate the utility of ASM via case study by implement- While the upcall approach initially sounds like it ing two recent security enhancements for Android as would have very slow performance, our key observation ASM apps. Second, we evaluate the resource impact of is that many ASM apps will require very few, if any, ASM with respect to both performance and energy con- LSM hooks. For example, an ASM app for Aquifer [22] sumption. We implemented ASM on Android version file permission would only require the and 4.4.1, hence we use the Android 4.4.1 AOSP build as our socket connect LSM hooks. Section 6.2 shows that baseline. All the experiments were performed on an LG both of the aforementioned hooks can be evaluated in Nexus 4 (GSM). The source code for ASM is available userspace with reasonable performance overhead. Fur- at http://androidsecuritymodules.org. thermore, placing all ASM app logic in one place (i.e., userspace) simplifies reference monitor design. 6.1 Case Studies To improve access performance for large files, we im- In this section, we evaluate the utility of ASM by im- plemented a cache with an expiration policy, where file plementing existing security solutions as ASM apps. We accesses (euid, pid, inode, access mask) and decisions implement and study two examples: 1) MockDroid [6] received from ASM apps on those accesses are cached; and 2) AppLock [13]. Finally, we conclude this section and are invalidated if the accesses do not repeat within a with a summary of lessons learned. timeout period of 1 ms. Since we cache and match the file inode as well as the accessing subject’s effective uid 6.1.1 MockDroid and pid, we do not provide an attacker the opportunity of taking advantage of a race condition (i.e., requesting for MockDroid [6] is a system-centric security extension for a file less than 1ms after its access is granted). the Android OS that allows users to gracefully revoke Note that this approach may lead to a case where file the privileges requested by an application without the access control is too coarse grained for a particular ASM app crashing. To do so, MockDroid provides a graphical app. For example, consider a situation where an applica- user interface that allows the user to decide whether in- tion on the device reads a file continuously. An ASM app dividual applications are presented real or fake responses grants this application access, but if at some point during when accessing sensitive system components. these accesses it wants to deny the access to this file, the Original Implementation: MockDroid extends An- file permission hook is not triggered since the file droid’s permissions model for accessing sensitive ser- is read before the timeout expires resulting in cache hits. vices by providing alternative “mock” versions. When To address this problem, we allow ASM apps to set this users install an application, they choose to use the real timeout. If multiple ASM apps set a timeout, the mas- or mock version of permissions. However, users can also ter policy can determine the timeout, e.g., the smallest revise this decision later using a graphical user interface. timeout. ASM apps may also disable the cache, which MockDroid stores the mapping between applications and provides all file access control callbacks to the ASM, but permissions in an extension to Android’s Package Man- also degrades the performance of file reads. ager Service. This policy store is the primary policy de- cision point in MockDroid. 5.5 ASM LSM MockDroid places enforcement logic in relevant An- droid OS components, as well as the kernel. If an appli- Finally, the ASM LSM provides two security features in cation is assigned a mock permission, the Android OS addition to the LSM hook upcalls. First, it implements component will return fake information. For example, the task kill LSM hook to prevent registered ASM if an application attempts to get the device IMEI, and it apps from being killed. As we discuss in Section 6.1, is assigned the mock version of READ PHONE STATE, some existing security enhancements can be disabled then the telephony service will return a fake static IMEI by killing their processes. Second, it implements the instead of the device’s real IMEI. inode *xattr LSM hooks to provide ASM apps ac- MockDroid also modifies the Linux kernel with en- cess to their own unique extended attribute namespaces. forcement logic. Recall from Section 2 that some per- That is, an ASM app can use file xattrs with a prefix missions are enforced in the Linux kernel based on GIDs matching its package name. No other applications can assigned to applications. MockDroid defines additional
1014 23rd USENIX Security Symposium USENIX Association Table 2: Hooks registered by the MockDroidASM app Access to Fake ASM Hook ASM Callback IMEI device id mod int getDeviceId mod(String fake imei[]) Fine/Coarse Location update on location changed mod int onLocationChanged mod(int uid, Location loc) Internet Connection socket connect int socket connect(String family, String type, int uid) Contacts Query contacts query mod int query contacts mod (ASMCursor c, String projection, ...) Contacts Insert contacts insert int contactsInsert(Uri uri, ContentValues values) Contacts Delete contacts delete int contactsDelete(Uri uri, String selection, String selectionArgs[], ...) Contacts Update contacts update int contactsUpdate(Uri uri, ContentValues values, String selection, ...) Receive Broadcast resolve broadcast mod int resolveBroadcastReceivers mod(List resolvedList, String resolvedtype, ..) GIDs for mock permissions enforced by GID. For exam- prompt, and the user must enter the correct password be- ple, if the user selects to assign the mock version of the fore the application can be used. INTERNET permission to an application, it is assigned Original Implementation: AppLock requests install- to the mock inet group instead of the inet group. To time permissions for 1) getting the list of running apps, 2) enforce this mock permission, MockDroid modifies the overlaying its user interface over other applications, and inet runtime check in the Linux kernel (a check added 3) killing application processes. While AppLock does by Android to Linux). In the modified check, if the appli- not require any modifications to Android’s source code, cation is in the mock inet group, a socket timeout error it is uses energy very inefficiently. It can also be circum- is returned, simulating an unavailable network server. vented using an ADB shell (e.g., “am force-stop MockDroidASM: We implemented an ASM app ver- com.domobile.applock”). sion of MockDroid called MockDroidASM. In addi- AppLock’s LockService uses a busy loop to continu- tion to ASM permissions for hook registration, Mock- ously query the Android operating system for the list of DroidASM must register for the PACKAGE INSTALL running applications while the screen is on. If the top ap- hook to receive the package name and the list of plication is protected by AppLock’s policy, LockService requested permissions when each new application overlays the current screen with a password prompt user is installed. A MockDroidASM GUI also allows interface. This interface stays on the screen, trapping all the user to configure which permissions to grace- input until the correct password is entered. If the user de- fully revoke from an application (e.g., INTERNET, cides to return from the lock screen without entering his READ PHONE STATE). password, AppLock kills the protected application. We Instead of using additional mock permissions, Mock- have verified this execution via static analysis using Ap- DroidASM registers for the modify version of ASM kTool [1] as well as with another monitoring ASM app hooks that are triggered when an application attempts that registers for the start service hook. to access sensitive system components. Since Mock- AppLockASM: We implemented an ASM app ver- DroidASM needs to modify values returned to apps, it sion of AppLock called AppLockASM. To provide the requests the REGISTER ASM MODIFY permission, as password-protected application functionality, AppLock- described in Section 5.3. ASM simply registers for the start activity hook. Table 2 shows the most important hooks used by It then receives a callback whenever an activity compo- MockDroidASM. For example, the device id mod nent is started. When this occurs, AppLockASM dis- hook allows MockDroidASM to fake the IMEI number plays its own lock screen. If the user enters the correct of the device. On the kernel-level, MockDroidASM reg- password, the start activity event is allowed. If isters for the socket connect hook to receive a call- the user decides not to enter a password, it is denied. back when an application tries to connect to a network Unlike AppLock, AppLockASM never starts the target server. If INTERNET is revoked by the user, the Mock- activity component without the correct password. DroidASM returns deny to the ASM LSM, which returns a socket timeout error to the application. 6.1.3 Summary ASM considerably simplifies development of security 6.1.2 AppLock modules such as AppLock and MockDroid. For exam- AppLock [13] is an application available on the Google ple, the original AppLock app performs its functionality Play Store. It allows users to protect the user interface by starting a service in an infinite loop, a design that is in- components of applications with a password. Users set a efficient in terms of power as well as latency. AppLock- password to access the AppLock. They then selectively ASM on the other hand needs to simply register for a lock other third-party and system applications through callback with the ASM Framework. The AppLock im- AppLock’s user interface. When the user tries to open plementation also prompts a lock screen after the app has a protected application, AppLock presents a password already been started, and has to kill the app when the lock
USENIX Association 23rd USENIX Security Symposium 1015 Table 3: Performance - Unmodified AOSP, ASM with no reference monitor, and ASM with a reference monitor app ASM (ms) Overhead (%) Overhead (ms) Protection Event AOSP (ms) w/o ASM app w/ ASM app w/o ASM app w/ ASM app w/o ASM app w/ ASM app Start Activity 19.03 1.51 20.01 1.39 22.74 1.77 5.15 19.50 0.98 3.71 ± ± ± Start Service 3.89 0.31 4.6 0.41 8.42 0.61 18.25 116.45 0.71 4.53 ± ± ± Send Broadcast 2.18 0.24 4.48 0.69 6.45 0.55 105.50 196.71 2.30 4.27 ± ± ± Contacts Insert 121.41 5.98 120.48 5.25 135.39 6.35 -0.76 11.51 -0.93 13.98 ± ± ± Contacts Query 17.41 3.88 21.10 3.13 29.50 4.36 21.19 69.44 3.69 12.09 ± ± ± File Read 59.13 1.97 62.27 2.86 65.39 2.93 5.31 10.59 3.14 6.26 ± ± ± File Write 57.68 3.01 57.98 2.76 59.03 3.60 0.52 2.34 0.30 1.35 ± ± ± Socket Create 0.65 0.086 0.79 0.13 4.26 0.56 21.54 555.38 0.14 3.61 ± ± ± Socket Connect 1.61 0.21 1.65 0.22 5.13 0.32 2.48 218.63 0.04 3.52 ± ± ± Socket Bind 2.00 0.17 1.93 0.64 5.15 0.34 -3.5 157.50 -0.07 3.15 ± ± ± screen returns. This arbitrary killing of apps is prevented establishing two additional IPCs, 2) marshalling and un- in the AppLockASM case, where the callback happens marshalling this data across the two IPCs, 3) ASM copy- before the activity is started, and the activity starts only ing the extras Bundle when sending it to the ASM app, if the AppLockASM allows. This is also beneficial from and 4) setting the returned Bundle back to the original the security point of view, as an AppLockASM-like app intent. To estimate worst case performance, we chose a does not need to register for the permission to kill other very large array (4KB) and registered our test ASM for apps, reducing the risk in case the locking app itself is modify data hooks. This worst case overhead, though malicious or malfunctions. relatively high, is not noticeable by the user due to its The original MockDroid implementation requires low absolute value. Additionally, most applications use modifications to the Package Manager Service, and has files to share very large data values. We note that while to implement an entire parallel mock permission frame- send broadcast has a high overhead percentage, the wall work. This effort can be reduced by registering for a clock overhead is in the order of milliseconds, which is small number of ASM hooks, without having to modify negligible overhead for broadcasts. system services. A general lesson learned from these case studies is that Content provider protection events: Micro bench- the ASM architecture enables developers to easily im- marks for content providers were performed on the Con- plement complex system-centric security enhancements tacts Provider. For this experiment, our ASM app reg- without the need for third party support. This broadens isters for the contacts insert callback. It pro- the outreach of ASM, and encourages third-party devel- ceeds to insert a new contact (first and last name) into opers to engage in the development of sophisticated se- the contacts database exposed by the ContactsProvider. curity solutions for Android-based devices. The overhead observed is 11.51% and negligible in terms of its absolute value. We then registered for the 6.2 Performance Overhead contacts query mod hook, and performed a query on the same contact. Query has a greater overhead, To understand the performance implications of ASM, we which is attributable to marshalling/unmarshalling the micro benchmarked the most common ASM protection data between the two IPC calls, and serialization of the events for modules in Table 1. We performed each ex- Cursor object into a parcelable. A major cause of this periment 50 times in three execution environments: 1) overhead is also that the Content Provider Cursor is not AOSP, 2) ASM with no ASM app, and 3) ASM with one populated when the query result is returned to the calling ASM app. The ASM app only registers for the callback application, but is instead filled as and when the appli- of the tested protection event; all other callbacks remain cation uses it to retrieved values. As discussed in Sec- deactivated. Since we are only interested in the perfor- tion 5.4.3, future work will consider alternative methods mance overhead caused by framework, our test callback of mediating query responses. immediately returns allow. Table 3 shows the mean re- sults with the 95% confidence intervals. File access protection events: File micro benchmarks Lifecycle protection events: To test lifecycle protection tested the file permission hook, which uses an up- events (i.e., start activity, start service, and send broad- call from the kernel. To test file access performance, our cast), we created an intent message and added a byte ar- test app performs an access (read/write) on a 5MB file. ray as its data payload (i.e., extras Bundle). Each test We pause for a second between successive executions. type registered for the modify version of the ASM hook. For writes, we do not see considerable overhead as the We sent the intent for the respective type, pausing for file is written in one shot to disk. Reads used a 16KB five seconds between consecutive executions. Potential buffer and the default 1ms expiration time for caching areas of overhead for using the hook include: 1) cost of access control decisions, as discussed Section 5.4.5.
1016 23rd USENIX Security Symposium USENIX Association Mr. Hide [20] repackage applications with inline ref- Table 4: Energy overhead of ASM. erence monitors (IRMs). While IRMs do not require Average Power Consumption (mW) Overhead (%) firmware modification, rewriting frequently breaks ap- AOSP 670.42 - plications, and the resulting mediation may be circum- ASM w/o ASM app 692.83 3.34 vented if API coverage is incomplete or native libraries ASM w/ ASM app 732.98 9.33 are used. Placing access control mediation within the OS Socket protection events: For socket operations, we provides stronger guarantees. tested the performance overhead for creating, binding ASM follows the methodology of the LSM [34] and and connecting to an IPv6 socket. Our test ASM app reg- TrustedBSD [32] reference monitor interface frame- istered for the socket create, socket bind, and works. Both frameworks have been highly successful. In socket connect callbacks. The absolute overhead is Linux, LSM is widely used to extend Linux security en- mainly caused by the callback to the userspace, and is a forcement. Version 3.13 of Linux kernel source includes constant overhead for socket operations. SELinux [28], AppArmor [3], Tomoyo [31], Smack [30], and Yama [36] LSMs. TrustedBSD is not only used by 6.3 Energy Consumption FreeBSD, but also by Apple to implement seatbelt in Mac OS X and iOS [33]. Energy consumption is a growing concern for mobile de- vices. To measure ASM’s impact on energy consump- FlaskDroid [9] also shares motivation with ASM. It tion, we perform energy measurements in same three test provides an SELinux-style Type Enforcement (TE) pol- environments as performance: 1) AOSP, 2) ASM with icy language for extending Android security. FlaskDroid no ASM app, 3) ASM with one ASM app. The ASM also allows third-party application developers to spec- app registers for all the hooks from the performance ex- ify TE policies to protect their applications. However, periments. We use the Trepn profiler 4.1 [25] provided FlaskDroid is limited to TE access control policies. By by Qualcomm to perform power measurements. Trepn providing a programmable interface, ASM enables an uses an interface exposed by the Linux kernel to the extensible interface that allows not only TE, but also power management IC used on the System on a Chip to novel security models not yet invented. Specifically, we measure energy consumption, a feature that is supported believe the ability to replace data values will become vi- on a limited set of devices, including the LG Nexus 4. tal in protecting new operating systems such as Android. Trepn samples power consumption measurements every Concurrent to and independent of our work on ASM, 100 ms. Average values are shown in the Table 4. the Android Security Framework (ASF) [4] also pro- We monitor system energy consumption while run- vides an extensible interface to implement security mod- ning the test applications from Section 6.2. When the ules. ASM and ASF are conceptually very similar: both hooks are deactivated, we measured an energy consump- promote the need for a programmable interface, autho- tion overhead of about 3.34%. Our ASM app used for rization hooks that replace data (called edit automata in the performance and energy consumption experiments ASF), and third-party hooks (via callModule() in ASF). measured an overhead of about 9.33%. This overhead is However, their individual approaches differ. A key dif- caused by the active authorization hooks in the relevant ference is that ASM seeks to ensure existing security OS components and kernel, as well as the communica- guarantees (Goal G2), whereas ASF assumes the module tion between the authorization hooks, the ASM Bridge, writer is completely trusted (e.g., can load kernel mod- and the ASM app. ules). Goal G2 is motivated by our vision of enterprise IT It should be noted that performing accurate energy and researchers loading ASM apps on production phones consumption measurements on smartphones is a chal- without root access. ASF does not support this vision. lenge. While we consider the individual measurements Furthermore, a vulnerable ASF module can undermine to be accurate, we acknowledge that the low sampling secrecy and integrity of the system and all installed ap- rate used by the Trepn profiler is problematic. However, plications. That said, ASF does provide expressibility each individual experiment is performed 50 times, there- that ASM does not. Specifically, ASF provides a pro- fore we believe Trepn’s measurements to at least provide grammable interface to adding inline reference monitors a rough estimate of the energy consumption overhead in- to apps. While IRMs run the risk of breaking apps, they troduced by ASM. do support sub-application policies that ASM cannot ex- press (e.g., forcing an app to use https over http). 7 Related Work Finally, Section 5.4 identified the AppOps security en- Section 4 discussed Android security enhancements that hancement that is currently under development in AOSP. modify the Android firmware to achieve security media- AppOps adds authorization hooks throughout the An- tion. As an alternative approach, Aurasium [35], App- droid OS. However, AppOps does not provide a pro- Guard [5], RetroSkeleton [11] and Dr. Android and grammable interface for enhancing OS security. Instead,
USENIX Association 23rd USENIX Security Symposium 1017 we envision separating the authorization hooks from Ap- [6] BERESFORD, A. R., RICE, A., SKEHIN, N., AND SOHAN, R. pOps and implementing AppOps as an ASM app. A sim- MockDroid: Trading Privacy for Application Functionality on ilar process occurred during the creation of LSM when it Smartphones. In Proceedings of HotMobile (2011). was split away from SELinux. [7] BUGIEL, S., DAV I , L., DMITRIENKO, A., FISCHER, T., AND SADEGHI, A.-R. XManDroid: A New Android Evolution to 8 Conclusion Mitigate Privilege Escalation Attacks. Tech. Rep. TR-2011-04, Technische Universitat Darmstadt, Center for Advanced Security This paper has presented the Android Security Modules Research Darmstadt, Darmstadt, Germany, Apr. 2011. framework as a programmable interface for extending [8] BUGIEL, S., DAV I , L., DMITRIENKO, A., HEUSER, S., Android’s security. While similar reference monitor in- SADEGHI, A.-R., AND SHASTRY, B. Practical and Lightweight terfaces have been proposed for Linux and TrustedBSD, Domain Isolation on Android. In Proceedings of the ACM Work- ASM is novel in how it addresses the semantically rich shop on Security and Privacy in Mobile Devices (SPSM) (2011). OS APIs provided by new operating systems such as An- [9] BUGIEL, S., HEUSER, S., AND SADEGHI, A.-R. Flexible and Fine-Grained Mandatory Access Control on Android for Diverse droid. We studied over a dozen research proposals that Security and Privacy Policies. In Proceedings of the USENIX enhance Android security to motivate the reference mon- Security Symposium (2013). itor interface hooks provided by ASM. Of particular note [10] CONTI, M., NGUYEN, V. T. N., AND CRISPO, B. CRePE: is the ability for hooks to replace data, as well as for Context-Related Policy Enforcement for Android. In Proceed- third-party application developers to define new hooks. ings of ISC (2010). ASM promotes the creation of novel security enhance- [11] DAV I S , B., AND CHEN, H. RetroSkeleton: Retrofitting Android ments to Android without restricting OS consumers (e.g., Apps. In Proceedings of MobiSys (2013). consumers, enterprise, government) to specific policy [12] DIETZ, M., SHEKHAR, S., PISETSKY, Y., S HU, A., AND WAL- LACH, D. S. Quire: Lightweight Provenance for Smart Phone languages (e.g., type enforcement). ASM currently al- Operating Systems. In Proceedings of the USENIX Security Sym- lows researchers with the ability to recompile Android to posium (2011). rapidly prototype novel reference monitors without need- [13] DOMOBILE LAB. AppLock. https://play.google. ing to consider authorization hook placement. If ASM com/store/apps/details?id=com.domobile. is adopted into the AOSP source code, it potentially al- applock. lows researchers and enterprise IT to add new reference [14] ENCK,W.,GILBERT,P.,CHUN, B.-G., COX, L. P., JUNG, monitors to production Android devices without requir- J., MCDANIEL, P., AND SHETH, A. N. TaintDroid: An Information-Flow Tracking System for Realtime Privacy Moni- ing root access, a significant limitation of existing bring- toring on Smartphones. In Proceedings of USENIX OSDI (2010). your-own-device solutions. [15] ENCK, W., ONGTANG, M., AND MCDANIEL, P. On Acknowledgements Lightweight Mobile Phone Application Certification. In Proceed- ings of ACM CCS (2009). This material is based upon work supported by the [16] FELT, A. P., EGELMAN, S., FINIFTER, M., AKHAWE, D., AND National Science Foundation. Adwait Nadkarni and WAGNER, D. How to Ask For Permission. In Proceedings of the USENIX Workshop on Hot Topics in Security (HotSec) (2012). William Enck were partially supported by NSF grants [17] FELT, A. P., HA, E., EGELMAN, S., HANEY, A., CHIN, E., CNS-1253346 and CNS-1222680. Any opinions, find- AND WAGNER, D. Android permissions: user attention, com- ings, and conclusions or recommendations expressed in prehension, and behavior. In Proceedings of SOUPS (2012). this material are those of the authors and do not neces- [18] FELT, A. P., WANG, H. J., MOSHCHUK, A., HANNA, S., AND sarily reflect the views of the funding agencies. CHIN, E. Permission Re-Delegation: Attacks and Defenses. In Proceedings of the USENIX Security Symposium (Aug. 2011). [19] HORNYACK,P.,HAN, S., JUNG, J., SCHECHTER, S., AND References WETHERALL, D. These Aren’t the Droids You’re Looking For: [1] android-apktool. https://code.google.com/p/ Retrofitting Android to Protect Data from Imperious Applica- android-apktool/. tions. In Proceedings of ACM CCS (2011). [2] ANDERSON, J. P. Computer Security Technology Planning [20] JEON, J., MICINSKI, K. K., VAUGHAN, J. A., FOGEL, A., Study. ESDTR-73-51, Air Force Electronic Systems Division, REDDY, N., FOSTER, J. S., AND MILLSTEIN, T. Dr. Android Hanscom AFB, Bedford, MA, 1972. (Also available as Vol. I, and Mr. Hide: Fine-grained Permissions in Android Applications. DITCAD-758206. Vol. II DITCAD-772806). In Proceedings of the ACM Workshop on Security and Privacy in Mobile Devices (SPSM) (2012), ACM. [3] AppArmor. http://apparmor.net. Accessed January 2014. [21] MCDANIEL, P., AND PRAKASH, A. Methods and limitations of security policy reconciliation. In Proceedings of IEEE S&P [4] BACKES, M., BUGIEL, S., GERLING, S., AND VON STYP- (2002), IEEE Computer Society. REKOWSKY, P. Android Security Framework: Enabling Generic and Extensible Access Control on Android. Tech. Rep. [22] NADKARNI, A., AND ENCK, W. Preventing Accidental Data A/01/2014, Saarland University, April 2014. Disclosure in Modern Operating Systems. In Proceedings of ACM CCS (2013). [5] BACKES, M., GERLING, S., HAMMER, C., MAFFEI, M., AND STYP-REKOWSKY, P. AppGuard - Enforcing User Requirements [23] NAUMAN, M., KHAN, S., AND ZHANG, X. Apex: Extending on Android Apps. In Proceedings of TACAS. Springer Berlin Android Permission Model and Enforcement with User-defined Heidelberg, 2013. Runtime Constraints. In Proceedings of ASIACCS (2010).
1018 23rd USENIX Security Symposium USENIX Association [24] ONGTANG, M., MCLAUGHLIN, S., ENCK, W., AND MC- [32] WATSON, R. N. M. TrustedBSD: Adding Trusted Operating DANIEL, P. Semantically Rich Application-Centric Security in System Features to FreeBSD. In Proceedings of the USENIX Android. In Proceedings of the Annual Computer Security Appli- Annual Technical Conference, FREENIX Track (2001). cations Conference (2009). [33] WATSON, R. N. M. A Decade of OS Access-Control Extensibil- [25] QUALCOMM. Trepn Profiler. https:// ity. Communications of the ACM 56, 2 (Feb. 2013). developer.qualcomm.com/mobile-development/ [34] WRITE, C., COWAN, C., SMALLEY, S., MORRIS, J., AND increase-app-performance/trepn-profiler. KROAH-HARTMAN, G. Linux Security Modules: General Secu- [26] RAO, V., AND JAEGER, T. Dynamic Mandatory Access Con- rity Support for the Linux Kernel. In Proceedings of the USENIX trol for Multiple Stakeholders. In Proceedings of ACM SACMAT Security Symposium (2002). (2009), ACM. [35] XU, R., SAIDI, H., AND ANDERSON, R. Aurasium: Practical [27] SCHAUFLER, C. [PATCH v13 0/9] LSM: Multiple concur- Policy Enforcement for Android Applications. In Proceedings of rent LSMs. https://lkml.org/lkml/2013/4/23/307, the USENIX Security Symposium (2012). 2013. [36] Yama lsm. https://www.kernel.org/doc/ [28] Security-Enhanced Linux. http://selinuxproject.org. Documentation/security/Yama.txt. Accessed Accessed January 2014. February 2014. [29] SMALLEY, S., AND CRAIG, R. Security Enhanced (SE) An- droid: Bringing Flexible MAC to Android. In Proceedings of [37] ZHOU,Y.,ZHANG, X., JIANG, X., AND FREEH, V. W. Taming NDSS (2013). Information-Stealing Smartphone Applications (on Android). In Proceedings of the International Conference on Trust and Trust- [30] The Smack Project. http://schaufler-ca.com/. Ac- worthy Computing (June 2011). cessed February 2014. [31] TOMOYO Linux. http://tomoyo.sourceforge.jp. Accessed February 2014.
USENIX Association 23rd USENIX Security Symposium 1019