Deepdroid: Dynamically Enforcing Enterprise Policy on Android Devices

DeepDroid: Dynamically Enforcing Enterprise Policy on Android Devices

Xueqiang Wang∗†, Kun Sun‡, Yuewu Wang∗ and Jiwu Jing∗ ∗ Data Assurance and Communication Security Research Center, Institute of Information Engineering, Chinese Academy of Sciences {wangxueqiang, ywwang, jing}@is.ac.cn †University of Chinese Academy of Sciences ‡Department of Computer Science, College of William and Mary [email protected]

Abstract—It is becoming a global trend for company to influence the design and usage of mobile devices in employees equipped with mobile devices to access compa- the enterprise environments. While users are blurring the ny’s assets. Besides enterprise apps, lots of personal apps lines between company and personal usage, enterprises from various untrusted app stores may also be installed demand a secure and robust mobile device management on those devices. To secure the business environment, to protect their business assets. For instance, in a building policy enforcement on what, how, and when certain apps can access system resources is required by enterprise IT. that forbids any audio recording, all mobile devices’ However, Android, the largest mobile platform with a microphones should be disabled when the users check market share of 81.9%, provides very restricted interfaces in the building and be enabled when the users check for enterprise policy enforcement. In this paper, we present out. DeepDroid, a dynamic enterprise security policy enforcement scheme on Android devices. Different from existing The permission model on Android, the largest mobile approaches, DeepDroid is implemented by dynamic mem- platform with a market share of 81% [2], only grants ory instrumentation of a small number of critical system an “all-or-nothing” installation option for mobile users processes without any firmware modification. DeepDroid to either accept all the permissions an app asks for or can be easily deployed on various smartphone platforms simply decline to install the app. After installation, the with a wide range of Android versions. Moreover, based on the context information extracted from Binder intercep- app can keep accessing the approved system resources tion, a fine-grained policy can be enforced. We develop a all the time. In Android 4.3, an experimental feature prototype of DeepDroid and test it on various smartphones called “App Ops” [3] is added to permit mobile users and Android versions. The experimental results show to configure one app’s runtime permissions. However, that DeepDroid can effectively enforce enterprise resource this feature has been removed from Android 4.4.2 due access policies with negligible performance overhead. to “the increasing burden for user configuration and the impacts on advertisement market” [4]. SEAndroid has I.INTRODUCTION evolved from Permissive mode in Android 4.2 and 4.3 to Enforcing mode in Android 4.4 and later to provide Nowadays, an increasing number of employees are flexible mandatory access control (MAC) mechanism in allowed to use mobile devices in workplace and con- the Linux kernel. However, until now, even the newest nect to enterprise assets. Cisco surveyed that 51% of Android 5.0 has not fully integrated MAC mechanism end users rely on smartphones to perform their daily in Android middleware [5]. Moreover, SEAndroid is business activities in 2013 [1]. This trend will continue not available on legacy systems running old versions of Android.

Permission to freely reproduce all or part of this paper for non- commercial purposes is granted provided that copies bear this notice Since Android 2.2, Google provides Device Adminis- and the full citation on the first page. Reproduction for commercial tration APIs [6] to help enforce enterprise security poli- purposes is strictly prohibited without the prior written consent of the cies; however, these APIs only provide a limited set of Internet Society, the first-named author (for reproduction of an entire functionalities that vary among different Android releas- paper only), and the author’s employer if the paper was prepared within the scope of employment. es. The Mobile Device Management concept (MDM) [7] NDSS ’15, 8-11 February 2015, San Diego, CA, USA has also been introduced to enterprise administrators Copyright 2015 Internet Society, ISBN 1-891562-38-X for a long time; however, OEMs usually develop their http://dx.doi.org/10.14722/ndss.2015.23263 own proprietary MDM solutions [8], [9]. For instance, Second, it is flexible to provide fine-grained Samsung Knox provides a complete enterprise solution, enterprise-level control over each app. The enterprise including secure boot, kernel integrity checking, and administrators can dynamically update the policy rules SEAndroid [9]; however, it is only available on Samsung for each mobile device’s individual app. We cannot only devices [10]. enforce a general rule to constrain one specific service/resource access for an app, but also achieve a context- In this paper, we propose an enterprise-level security aware access control by inspecting the communications policy enforcement mechanism called DeepDroid that between apps and service processes through Android can be easily ported on various Android devices to Binder. In this paper, we focus on providing security dynamically enforce a fine-grained system service and re- mechanisms instead of developing detailed policy rules source access control policy by enterprise administrators. given an enterprise’s security requirements. The basic idea is to apply dynamic memory instrumentation on the app runtime environment in Android. All Finally, it has minimal impacts on user experience. current versions of Android share a common structure DeepDroid is transparent to mobile users and supports feature that system services and resource access are location-aware automatic configuration. For instance, the controlled by a small number of system processes. Thus, enterprise policy enforcement mechanism only needs to we only need to instrument these system processes whose be enabled when a user enters the workplace; when the structures are almost the same on all Android versions. user leaves the workplace, the policy enforcement mech- DeepDroid dynamically hooks system server process in anism can be automatically disabled. Moreover, since Android and uses it as a centralized controller to enforce our mechanism only needs to instrument a very small the enterprise-level permissions when an app requests to number of critical Android processes and perform simple access a system service. It also tracks the zygote process checkings, it has negligible performance overhead. to authorize native code’s access requests. Moreover, In summary, we make the following contributions. DeepDroid can intercept the Binder interactions between apps and a few system processes to retrieve details of • We solve the portability problems of enforcing apps’ requests for a fine-grained access control. enterprise’s security policies on various Android de- DeepDroid needs root privilege to instrument and vices. Our approach is based on dynamic code instru- track system processes. It can be satisfied in a corporate mentation and process tracing, which enforce access environment where companies usually either rent or control policies in Android middleware and Linux purchase mobile devices from telecommunication com- kernel, respectively. Our system can be ported on panies and request vendors to customize the software different Android mobile devices with small changes. image before distributing the devices to employees. S- • We can achieve a fine-grained control policy over ince DeepDroid does not need to statically change the each Android app. By hooking and tracing critical Android middleware and the Linux kernel, it carries little Android components, we can extract request details to burden on vendors for device customization. better regulate one app’s operations. Thus, it enables enterprise administrators to set fine-grained policy Our enterprise-level policy enforcement solution has rules considering temporal and spatial constraints for several good properties. First, it is portable. Our solution each app. can be deployed on almost all Android mobile devices • We minimize the impacts of our mechanism on with very small customization efforts. Instead of tailoring Android system. Only a few critical processes (e.g., various Android systems from different OEMs, we use system server) need to be dynamically instrumented dynamic instrumentation and process tracing techniques in their memory spaces, and the performance overhead to hook the Android app runtime environment. The code is minimal. Also, its impacts on Android system base of our system remains largely unchanged when is temporary and can be easily removed when the deployed on different Android versions. Our solution policies are no longer desired. It is compatible with only requires minimal configuration changes in Android the existing permission mechanism. OS during the installation stage and does not need any • We develop a DeepDroid prototype and evaluate changes on any app. We have evaluated our system on a its effectiveness and efficiency on a number of main- variety of Android devices from different OEMs running stream Android devices with various Android versions. Android 2.3 through Android 4.4. The evaluation results show that DeepDroid can work

2 process ensures that supplementary groups are properly settings. For instance, it should be quickly activated set to the app process by initiating setgroups. Next, the when the user enters the workplace and removed imme- app’s process will have the privilege to access resources diately when the user leaves the workplace. Moreover, available to those groups. its impacts on Android system performance should be minimal. III.GOALS,CHALLENGESAND ASSUMPTIONS DeepDroid requires root privilege for installation. DeepDroid targets at effectively enforcing enterprise This requirement is common among enterprise mobile security policies on Android devices, and it is designed management solutions, and typically the root privilege to meet the following goals: can be obtained from OEMs. With OEM support, since Portability. Our scheme should be easily deployed to DeepDroid does not change the framework and the various Android versions and different Android mobile kernel of Android system, its installation is simple and devices. Current state-of-the-art solutions add proprietary straightforward. We assume the enterprise administrators enterprise mobile management interfaces into Android can be trusted. Some keying material is shared between source code, so the interfaces are typically customized the smartphone and enterprise policy center to generate to specific Android versions and devices. When one secret keys for communication protection. We assume company wants to adopt one mobile device that has not the keying material is well protected and secure. integrated the management interfaces, the development We assume the Android OS kernel can be trusted. cost will increase and the delivery time will be extended. Users have the freedom to install their favorite apps on Our goal is to support various kinds of Android devices their Android smartphones. Though some apps may be through making minimal configuration changes. malicious, we assume they cannot compromise the OS Fine granularity. Our scheme should support fine- kernel or get the root privilege. A malicious or uncoop- grained service and resource access control on individual erative device user may attempt to disable our policy apps. It cannot only supervise the permission privileges enforcement mechanism, so we should guarantee that of an app, but also regulate the service provision proce- DeepDroid is reliably active in the workplace. DeepDroid dure. Thus, our solution can support various enterprise opens a management interface for policy enforcement, policies. For instance, during working hours, SMS is which may increase the attack surface for some new only allowed between employees. In this case, we need attacks misusing the interface. to limit the receiver of a SMS message rather than prohibiting all SMS messages blindly. Location Based IV. DEEPDROID SYSTEM ARCHITECTURE Service (LBS) apps may lead to location privacy leakage; DeepDroid consists of two parts: Enterprise Policy however, blindly forbidding location related operations Center and DeepDroid On-device, as shown in Figure 2. may generate except signals, which leak the information that the user may be at workplace. This problem can A. Enterprise Policy Center be solved by regulating each location operation and replacing some sensitive locations with fake information. Enterprise Policy Center consists of three modules to authenticate the mobile devices, distribute enterprise Trustworthy. All access control policy rules should policies, and monitor the mobile devices, respectively. be completely enforced, so that malicious apps cannot The authentication module is responsible for authen- violate any rules. We trust the Android middleware and ticating the mobile devices. After being successfully the low-level Linux kernel. In Android, resource access authenticated, a device can share a temporary secret operations through system services are controlled by key with enterprise policy center. A policy repository Android permission mechanism; however, an app may provides policy rules according to enterprise’s security access resources using native system calls that totally requirements and the user’s role. Since all communica- bypass the permission checking. Thus, to assure all tions between the policy center and the mobile device resource accesses are being supervised, our scheme must are protected by the secret key, the policy rules can enforce the policy rules in both Android middleware and be securely distributed to mobile devices. Moreover, the Linux kernel layers. status of mobile devices should be continuously reported Ease of use. Our mechanism could be promptly acti- to the policy center for logging and auditing purpose. vated and deactivated according to the enterprise policy Particularly, the policy center can use encrypted heartbeat

TABLE II: Binder Resource Accessing Interfaces Resource Process Service Function Code IMEI phone iphonesubinfo getDeviceInfo 1 Phone # phone iphonesubinfo getLine1Number 5 location system server location getLastKnownLocation 17 contacts* system server activity getContentProvider 29 camera mediaserver media.camera connect 3 account system server account getAccounts 4 SMS/MMS phone isms sendText 5 it is difficult to define and enforce policy criterion on process is suspended after entering syscall-enter-stop high volume media-related resources (such as camera and and syscall-exit-stop. We maintain a flag for each target audio) without an efficient support on image or voice process to distinguish its system call entries from system recognition. It is much easier for apps using Android call exits. In a typical work flow, this module first uses APIs to perform operations like locating or photograph- ptrace to extract CPU register information of a suspended ing. However, an App may have multiple ways to bypass target. According to routines of ARM Procedure Call it using normal Android APIs. To solve this problem, we Standard [15], the parameters of system calls are stored can extend DeepDroid with a behavior detection model in registers R0∼R3 and SP, and the result of a system similar to what has been proposed in FireDroid [14]. call is always stored in register R0. Therefore, our traces can easily parse the parameters and return value of the D. Native Code Context Enforcement system calls. According to the policy rules, we can either simply decline a resource access request or send a fake The process creation guard in Section V-B constrains return value. the access privileges of native operations with a course- Again, our work focuses on providing a mechanism grained Granted or Denied decision; however, enterprises to support native code context enforcement, instead of may request a more fine-grained control on native op- designing detailed policy rules. For various applications, erations. For instance, instead of disconnecting an app different parsers may be required to inspect their unique completely from the Internet, the app may be allowed context information. For instance, to restrict datagram to access some specific trusted web servers. Therefore, communication with a certain remote server, we need besides configuring inet group, we develop a native to regulate system calls like sendto, sendmsg, recvmsg code context enforcement module to regulate network and recvfrom. At the entry of sendto, the destination accessing operations by confining the context of socket address is extracted from sockaddr structure. Then, the calls, such as connect, recvfrom and sendto. system calls can go through if the destination address We trace system calls of the target process to con- is valid or be stopped otherwise. Similarly, at the exit strain its native behaviors. Since it is important to of recvfrom, we can recognize received buffer data and guarantee that the tracing code is executed before any mask its content accordingly. operation of target process, we must detect the launching of the target process and monitor the process through VI.DEEPDROID EVALUATION its entire life cycle. To achieve this goal, we trace fork Our goal of DeepDroid evaluation is threefold: (1) to calls of the processes (e.g., zygote, adbd) that are in demonstrate that security policies on resource accessing charging of new app process creation and then map can be effectively enforced; (2) to demonstrate that newly created processes to applications by matching DeepDroid can be easily deployed to various Android their uid. Once the target app is identified, system calls platforms, and (3) to measure its performance overhead. of its process tree are traced recursively by setting We also analyze security and reliability of DeepDroid. ptrace options including TRACEFORK, TRACEVFORK and TRACECLONE. Since our module works as a tracer A. Functional Evaluation on a target process, when the target process is attached successfully, the tracer can receive signals at both the To test the effectiveness of DeepDroid, we choose entry and exit of system calls, and meanwhile the target the prevalent resources of Android identified in [13]

9 TABLE III: Tested Resources

Resource Permission Group PEP1 Result2 √ IMEI READ PHONE STATE package √ Phone # READ PHONE STATE package √ location ACCESS FINE LOCATION package √ contacts READ CONTACTS package √ camera CAMERA camera package/PCG √ account GET ACCOUNTS package √ logs READ LOGS log PCG √ SMS/MMS message SEND SMS package √ network INTERNET inet package/PCG 1 PEP is the policy enforcement point. 2 The policy is enforced either in package service or by Process Creation Guard (PCG). and run a number of popular apps that access these 1) Permission Enforcement Overhead: Permission en- resources. For each resource, 5 most widely used apps forcement overhead is mainly introduced by Permission that access this resource are chosen from Google Play. In Configurator in the system server and behavior moni- our experiment, we manually instrument each resource toring from binder interception. Permission Configurator related method call to check if the operations can be overrules system original permission checking procedure successfully regulated when we activate DeepDroid to with enterprise permission rules, and the Binder wrapper prohibit accessing this resource. Table III shows the e- parses the binder messages to perform app’s behavior valuation results, which verify that all resource accessing monitoring. operations are controlled effectively. Since most benchmarks focus on overhead of the entire process or the whole system, we need to design a mechanism to benchmark the overhead of permission en- B. Portability Evaluation forcement operations. To minimize measurement errors, We run DeepDroid on a series of smart phones we choose sensitive operations that do not depend on a with Android OS from version 2.3 to 4.x. As Table IV certain hardware module or volatile surroundings (e.g., summarizes, DeepDroid can be successfully deployed on stability of network signal). As shown in Table V, we mainstream commercial Android devices with very small construct a test case from a subset of prevalent resources system modification. described in [13].

TABLE V: Tested Permission Checking Transactions TABLE IV: DeepDroid Portability Class Permission Trigger Point Device Android Result phone state android.permission. TelephonyManager. √ READ PHONE STATE getDeviceId Nexus S(Samsung) Android OS 2.3.6 √ contacts android.permission. ContentResolver. Sony LT29i Android OS 4.1.2 √ READ CONTACTS query(Phone.CONTENT URI...) Android OS 4.2.2 √ SMS android.permission. SmsManager. Galaxy Nexus(Samsung) Android OS 4.0 √ messages SEND SMS sendTextMessage Samsung Galaxy Note II Android OS 4.1 √ Samsung Galaxy Note 3 Android OS 4.3 √ Nexus 5(LG) Android OS 4.4 We evaluate the performance by initiating resource 1 √ Meizu MX II Flyme 3.2 √ access operations that require a permission checking HUAWEI Honor 3c Android OS 4.2 procedure in the following scenarios. 1 Flyme 3.2 is a customized version of Android OS 4.2.1 • Normal mode (S). The tested apps are granted re- C. Performance Evaluation quired permissions by original permission mechanism and the trigger points are executed successfully. DeepDroid’s system overhead is mainly introduced • Intercepted mode (S). The tested apps are granted by the operations on permission enforcement, binder required permissions by Permission Conﬁgurator and message interception, and system call tracing. Since a the trigger points are intercepted and monitored by the permission checking is always accompanied by a binder binder. transaction, we combine the ﬁrst two overhead factors. • Normal mode (F). The tested apps are denied required

D. Security Analysis enterprise administrators to send false policy rules to the Our system can ensure an enterprise security policy mobile devices; however, since the attacker cannot obtain enforcement on Android device through dynamic mem- the keying material shared between the device and the ory instrumentation of several critical system processes. enterprise server, it cannot perform this type of attacks. DeepDroid exposes one control interface of Android Malicious apps. DeepDroid may allow device users system to third parties; however, since the code base of to install their favorite apps on their Android smart- DeepDroid is small and may be formally verified, the phones. Some apps may be malicious and target at com- attacker can hardly misuse our mechanism to attack the promising our policy enforcement mechanism. However, system. Moreover, since all the communications between since the user-level malicious processes are securely the trusted enterprise server and the mobile device are isolated into separate containers, they cannot manipulate protected by a shared secret key, an external attacker the code or the control flow of DeepDroid unless they cannot steal the policy rules through eavesdropping. have the root privilege, which is strictly protected and monitored by enterprise administrators. We assume the VII.DISCUSSION Android OS can be trusted. Therefore, without the root At Google I/O 2014 conference, Android L was un- privilege, malicious apps cannot compromise our mech- veiled and the previously experimental Android Runtime anism. (ART) [25] has replaced Dalvik as a default environment. Permission escalation attacks. An Android system ART compiles byte code into executable ELF only once may suffer from permission escalation attacks, such as during app installation. In spite of the runtime transfor- confused deputy attack and collusion attack [18], [19], mation, foundations of DeepDroid, including permission [20]. In confused deputy attack, a malicious application mechanism, system service architecture, and binder IPC, exploits the vulnerable interfaces of another privileged are barely changed. In other words, DeepDroid can (but confused) application to perform unauthorized op- be easily ported to ART. Only the implementation of erations. This kind of attack usually happens when a runtime method interception in section V-A needs to be privileged app unintentionally exposes interfaces of sen- changed accordingly. In ART, the .oat executable file sitive operation to an app without required permissions. compiled from Java byte code is mapped into process by In collusion attack, malicious apps collude and combine calling dlopen function, and all Methods refer to their their permissions in order to perform actions beyond their native code in oatexec segment of .oat. ART runtime individual privileges. DeepDroid can be used to regulate method interception can be achieved by native code two apps’ communications that go through the binder inline-hooking. Hence, DeepDroid can also work on and system calls; however, if two apps may communicate ART-enabled devices with little modification. through some covert channels that are out of the control DeepDroid requires root privilege for installation. of DeepDroid, we need to deploy other mechanisms to This requirement is common among enterprise mobile help remove the covert channels. management solutions, and usually the root privilege can Uncooperative user. Some employees may be re- be obtained from OEMs. With OEM support, DeepDroid luctant to conform to enterprise’s security policies due installation is simple and straightforward. OEMs only to various reasons, and they may simply deactivate our need to modify the “init.rc” file and import DeepDroid as system. Therefore, it is critical to guarantee that Deep- a service. Then DeepDroid can run with a root privilege Droid is correctly running on employees’ mobile devices, and all other Android security features remain intact. and we use heartbeat messages to prove it. Therefore, Since DeepDroid does not change the framework and a mobile device that stops sending encrypted heartbeat the kernel of Android system, the above configuration messages will trigger further investigation. Moreover, we incurs very little impact on OEMs. Some other work can use software based attestation approach [21], [22], such as FireDroid [14] adopts a similar idea to obtain [23] to make sure the integrity of DeepDroid. On the root privilege from OEMs. Alternatively, with the support mobile platforms with TrustZone hardware support [24], of ARM TrustZone mechanism [24], DeepDroid may we can also use TrustZone to keep monitoring the use the secure domain for the installation in the normal integrity of DeepDroid, similar to what has been done domain. in Knox [9]. There exists a number of system access control solu- DeepDroid misuse. An attacker may impersonate the tions for enterprise management, but our solution has

12 some advantages when comparing to those solutions, control mechanisms when we can access the source code particularly, SELinux [26] and Knox [9]. SEAndroid for the enterprise-customized Android system. Because enforces mandatory access control (MAC) in Android Android permission framework does not provide flexible kernel. Android’s support for SELinux has evolved from runtime configuration interface [28] and permission priv- permissive in 4.3 to full enforcement in 5.0 (L). SELinux ilege leaks happen to commercial images [20], several enhances system security by confining privileged pro- security extensions have been proposed to the permission cesses and enforce policies on various domains. How- framework [29], [30], [31], [32], [33], [26], [34], [13], ever, it is unavailable or disabled by default on Android [35], [36]. Apex [29] enables users to grant a selected set versions older than 4.4. Thus, old devices cannot be well of permissions and supports user-defined restrictions on protected by SEAndroid. Moreover, it requires manufac- apps. CRePE [30] can enforce fine-grained permission turers to have a better understanding of SELinux im- policies by using context information of the mobile plementations. Until now, SEAndroid has not been fully devices. By introducing a privacy mode, TISSA [31] em- supported since Android 5.0 does not include middleware powers users to define what kinds of personal informa- MAC mechanism [5]. On the contrary, DeepDroid does tion are accessible to apps. To mitigate security problems not rely on any unique kernel features and thus works aroused by a certain third-party component, Compac [32] well on almost all Android versions and platforms. We manages to distribute a narrowed set of permissions to may enhance the security of DeepDroid with SEAndroid one component. While the above approaches focus on mechanism. protection of system resources, Saint [33] provides an infrastructure that protects apps’ interfaces and resources. Samsung Knox has risen up to provide a complete enterprise solution. It focuses on providing capabili- Another way to enhance access control is achieved ties including Trusted Boot, TrustZone-based Integrity by introducing Security Enhanced Linux (SELinux). A Measurement Architecture (TIMA), SE for Android, flexible mandatory access control (MAC) can be support- and Knox container, to protect Android system from ed on both Android’s middleware and kernel layers [26], adversaries and isolate different working scenarios [9]. [34]. Besides directly hardening access control system, Through secure boot and kernel integrity checking, Knox privacy data can be further protected by being replaced can ensure a trusted OS in the normal world based on with some dummy data before providing it to apps [13]. ARM TrustZone hardware. As for policy enforcement, TaintDroid [35] monitors usage of sensitive data by Knox integrates SEAndroid and provides management dynamic taint tracking and analysis. Based on Taintdroid, APIs to customize security policies. Despite that Knox TreeDroid [36] presents a novel scheme to monitor APIs are integrated into Android 5.0 [27], its adoption security policies on data processing. is limited to Samsung devices [10]. Moreover, Knox requires ARM TrustZone hardware support, which limits Since all these approaches require Android source its deployment to only certain Android platforms. Our code modification, they have portability problem due to DeepDroid system is a software-based solution that can the high cost incurred when customizing a specific An- be deployed on almost all Android platforms. Mean- droid branch from different OEMs. Our system performs while, on TrustZone-enabled platforms, DeepDroid may dynamic memory instrumentation on the stable Android utilize TrustZone to obtain the root privilege of the structures, so it can be deployed similarly on various normal domain and protect the integrity of the rich OS Android versions. in the normal domain. Rewriting apps. Compared with modifying Android system code, app code can be rewritten to ensure a VIII.RELATED WORK resource access policy. Due to good portability, enforcing security on apps themselves becomes a competitive ap- Enterprise demands system resource access control proach. It is mainly implemented by integrating security interfaces in Android when employees are equipped measures into Android app with app rewriting. [37] with Android smartphone in workspace. Android access enables identifying and interposing of Security Sensitive control mechanisms can be generally categorized into APIs by dalvik bytecode rewriting. [38] supports retrofit four classes by their technical approaches. of app’s behaviors by static and dynamic method inter- Modifying Android source code. Android source ception. [39] is an on-the-phone instrumentation scheme, code can be directly modified to support new access which enables flexible policies on apps by intercepting

13 high-level java calls. Security policies of [40] are en- of process structures in various versions. Thus, Deep- forced by low-level libc.so rewriting. Droid may be deployed on various Android versions with a similar installation procedure. Since DeepDroid Interactions between an app and Android system can can regulate each app’s service access operations by be recovered from system calls. [41] helps to perfor- intercepting Binder transactions and tracing system calls, m fine-grained permissions on resource accessing by it can achieve a fine-grained context-aware policy en- introducing a new module that supports parameterized forcement. The evaluation results of a prototype show permissions. Any access to sensitive resources from apps that DeepDroid can work effectively on various Android is forwarded to this module. To support behavior study- platforms with negligible performance overhead. ing, [42] allows user to insert instrumentation code into an app from a high-level of abstraction. App rewriting X.ACKNOWLEDGMENT is an effective way that requires no modification to Android ROM. However, incomplete implementations of The authors would like to thank the shepherd, Xi- bytecode rewriting may result in several potential attack- aofeng Wang from Indiana University, and the anony- s [43]. It is difficult to assure that all apps are rewritten mous reviewers for their valuable comments and sug- which is critical to enterprise security management. In gestions. This work is partially supported by National addition, due to signature difference of repackaging 973 Program of China under award No. 2013CB338001 process, all history information of the original app cannot and No. 2014CB340603. Dr. Kun Sun’s work is sup- be shared by the rewritten app. ported by U.S. Office of Naval Research under award number N00014-11-1-0471 and U.S. Army Research Isolating business apps. Besides adding extra control Office under Grant W911NF-12-1-0448. This paper’s measures on Android system or apps, creating an isolated corresponding author is Yuewu Wang. secure domain is another promising solution for running business related apps. It divides all user apps into two REFERENCES categories: personal apps and business apps. Business [1] “Cisco global work your way study,” http://www.cisco. apps are running in a secure isolated environment, com/c/dam/en/us/solutions/collateral/borderless-networks/ and thus attacks originated from personal domain can unified-access/ua survey infographic.pdf. be blocked out. Trustdroid [44] is an isolation frame- [2] “Android pushes past 80156.0http://www.idc.com/getdoc.jsp? containerId=prUS24442013. work based on modifying Android system source code. [3] “App ops: Android 4.3’s hidden app permission KNOX [45] provides a complete enterprise management manager, control permissions for individual apps!” http: solution including an integrity checking component in the //www.androidpolice.com/2013/07/25/app-ops-android-4-3s/ secure domain. All these solutions do not directly aim hidden-app-permission-manager/-control-permissions-for/ at enforcing enterprise security policies on employee’s -individual-apps/. mobile device. It also has the portability problem due to [4] “App ops removed by google in android 4.4.2 update,” http://www.phonearena.com/news/ the changing of Android system or hardware supports. App-Ops-removed-by-Google-in-Android-4.4.2-update id50340/. Modifying Android runtime. Our system relies on [5] “Merge status,” http://seandroid.bitbucket.org/MergeStatus. dynamically modifying the Android runtime environ- html. ment. Patchdroid [46] uses a similar technique to apply [6] “Device administration,” http://developer.android.com/guide/ security patches for the entire Android system, while topics/admin/device-admin.html. our work focuses on enforcing enterprise policies on all [7] “Mobile device management,” http://en.wikipedia.org/wiki/ installed apps. Mobile device management. [8] Samsung, “Samsung For Enterprise,” http://www.samsung. com/us/business/samsung-for-enterprise/index.html. IX.CONCLUSIONS [9] S. Electronics, “Samsung KNOX,” http://www.samsung.com/ global/business/mobile/solution/security/samsung-knox. In this paper, we present a mechanism named Deep- [10] “Knox workspace supported devices,” https: Droid to enforce enterprise security policy on Android //www.samsungknox.cn/en/solutions/knox/technical/ knox-supported-devices. devices. DeepDroid provides good properties including [11] “Openbinder,” http://www.angryredplanet.com/ hackbod/open- portability, fine-grained control, and minimal perfor- binder/docs/html/. mance overhead through dynamically injecting control [12] “System permissions,” http://developer.android.com/guide/ code into Android framework, which has a stable set topics/security/permissions.html.

14 [13] P. Hornyack, S. Han, J. Jung, S. Schechter, and D. Wetherall, [33] M. Ongtang, S. McLaughlin, W. Enck, and P. McDaniel, “These aren’t the droids you’re looking for: Retrofitting android “Semantically rich application-centric security in android,” to protect data from imperious applications,” in Proceedings of Computer Security Applications Conference, Annual, 2009. the 18th ACM Conference on Computer and Communications [34] S. Bugiel, S. Heuser, and A.-R. Sadegh, “Flexible and Fine- Security, ser. CCS ’11, 2011. Grained Mandatory Access Control on Android for Diverse [14] G. Russello, A. B. Jimenez, H. Naderi, and W. van der Mark, Security and Privacy Policies,” in 22nd USENIX Security “FireDroid: Hardening Security in Almost-stock Android,” in Symposium (USENIX Security ’13), 2013. Proceedings of the 29th Annual Computer Security Applica- [35] W. Enck, P. Gilbert, B. gon Chun, L. P. Cox, J. Jung, tions Conference, 2013. P. McDaniel, and A. Sheth, “TaintDroid: An Information- [15] http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042e/ Flow Tracking System for Realtime Privacy Monitoring on IHI0042E aapcs.pdf. Smartphones,” in OSDI, 2010, pp. 393–407. [16] “Caffeinemark 3.0,” http://www.benchmarkhq.ru/cm30/. [36] A. L. Mads Dam, Gurvan Le Guernic, “Treedroid: A tree au- [17] “Quadrant standard edition,” https://play.google.com/store/ tomaton based approach to enforcing data processing policies,” CCS apps/details?id=com.aurorasoftworks.quadrant.ui.standard. in , 2012. [37] B. Davis, B. S, A. Khodaverdian, and H. Chen, “I-arm- [18] A. D. T. F. A.-R. S. B. S. Sven Bugiel, Lucas Davi, “Towards droid: A rewriting framework for in-app reference monitors for taming privilege-escalation attacks on android,” in NDSS, 2012. android applications,” in In Proceedings of the Mobile Security [19] A. P. Felt, H. J. Wang, A. Moshchuk, S. Hanna, and E. Chin, Technologies 2012, MOST 12. IEEE, 2012. “Permission Re-Delegation: Attacks and Defenses,” in USENIX [38] B. Davis and H. Chen, “RetroSkeleton: Retrofitting Android Security Symposium, 2011. Apps,” in Proceeding of the 11th Annual International Confer- [20] Z. W. X. J. Michael Grace, Yajin Zhou, “Systematic detection ence on Mobile Systems, Applications, and Services, 2013. of capability leaks in stock android,” in NDSS, 2012. [39] M. Backes, S. Gerling, C. Hammer, M. Maffei, and P. von [21] V. K. Y. K. Mark Shaneck, Karthikeyan Mahadevan, “Remote Styp-Rekowsky, “AppGuard: Enforcing User Requirements on software-based attestation for wireless sensors,” Security and Android Apps,” in Proceedings of the 19th International Con- Privacy in Ad-hoc and Sensor Networks, vol. 3813, pp. 27–41, ference on Tools and Algorithms for the Construction and 2005. Analysis of Systems, 2013. [22] v. D. L. K. P. Seshadri. A, Perrig A, “Swatt: software-based [40] R. Xu, H. Sa¨ıdi, and R. Anderson, “Aurasium: Practical Policy attestation for embedded devices,” in IEEE Symposium on Enforcement for Android Applications,” in Proceedings of the Security and Privacy, 2004. 21st USENIX Conference on Security Symposium, 2012. [23] M. Dietz, S. Shekhar, Y. Pisetsky, A. Shu, and D. S. Wallach, [41] J. Jeon, K. K. Micinski, J. A. Vaughan, A. Fogel, N. Reddy, “Quire: Lightweight Provenance for Smart Phone Operating J. S. Foster, and T. Millstein, “Dr. Android and Mr. Hide: Fine- Systems,” in Proceedings of the 20th USENIX Conference on grained Permissions in Android Applications,” in Proceedings Security, 2011, pp. 23–23. of the Second ACM Workshop on Security and Privacy in [24] T. Alves and D. Felton, “TrustZone: Integrated hardware and Smartphones and Mobile Devices, 2012. software security,” ARM white paper, vol. 3, no. 4, 2004. [42] S. Hao, D. Li, W. G. Halfond, and R. Govindan, “SIF: A S- [25] http://source.android.com/devices/tech/dalvik/art.html. elective Instrumentation Framework for Mobile Applications,” in Proceeding of the 11th Annual International Conference on [26] S. Smalley and R. Craig, “Security Enhanced (SE) Android: Mobile Systems, Applications, and Services, 2013. Bringing Flexible MAC to Android,” in NDSS, 2013. [43] H. Hao, V. Singh, and W. Du, “On the Effectiveness of API- [27] “A closer look at knox contribution in android,” https://www. level Access Control Using Bytecode Rewriting in Android,” samsungknox.cn/en/androidworkwithknox. in Proceedings of the 8th ACM SIGSAC Symposium on Infor- [28] X. Wei, L. Gomez, I. Neamtiu, and M. Faloutsos, “Permis- mation, Computer and Communications Security, 2013. sion Evolution in the Android Ecosystem,” in Proceedings of [44] A. D. S. H. A.-R. S. B. S. Sven Bugiel, Lucas Davi, “Practical the 28th Annual Computer Security Applications Conference, and lightweight domain isolation on android,” in SPSM, 2011. 2012. [45] Samsung Electronics, “White Paper: An Overview of [29] M. Nauman, S. Khan, and X. Zhang, “Apex: Extending An- Samsung KNOX,” http://www.samsung.com/global/business/ droid Permission Model and Enforcement with User-defined business-images/resource/white-paper/2013/06/Samsung Runtime Constraints,” in Proceedings of the 5th ACM Sympo- KNOX whitepaper June-0.pdf. sium on Information, Computer and Communications Security, [46] C. Mulliner, J. Oberheide, W. Robertson, and E. Kirda, “Patch- 2010. Droid: Scalable Third-party Security Patches for Android De- [30] M. Conti, V. T. N. Nguyen, and B. Crispo, “CRePE: Context- vices,” in Proceedings of the 29th Annual Computer Security related Policy Enforcement for Android,” in Proceedings of the Applications Conference, 2013. 13th International Conference on Information Security, 2011. [31] X. J. Yajin Zhou, Xinwen Zhang and V. W. Freeh, “Taming Information-Stealing Smartphone Applications (on Android),” in In: Trust and Trustworthy Computing, 2011. [32] Y. Wang, S. Hariharan, C. Zhao, J. Liu, and W. Du, “Compac: Enforce Component-level Access Control in Android,” in Pro- ceedings of the 4th ACM Conference on Data and Application Security and Privacy, 2014.