Abstract
As smartphones have become an indispensable part of daily life, mobile users are increasingly relying on them to process personal information with feature-rich applications. This situation requires robust security mechanisms for protecting sensitive applications and data on mobile devices. Android, as one the most popular smartphone operating systems, provides two core security mechanisms, application sandboxing and a permission system. However, recent studies show that these mechanisms are vulnerable to be passed by a variety of attacks. In this paper, we argue for the need of designing and implementing more comprehensive security mechanisms for Android. We realize that mediating Inter-Process Communication (IPC) channels used by Android applications can mitigate prominent attacks effectively and efficiently. Based on this observation, we propose a practical multi-layer security framework called
Introduction
According to IDC [31], the worldwide smartphone market is expected to grow 32.7% year over year in 2013, reaching a total shipment of 958.8 million units. With the surging computing power and network connectivity of smartphones, more applications are deployed on smartphone platforms to enable users to customize their devices. Meanwhile, users are increasingly relying on applications to process their personal information. However, many applications tend to manipulate users’ sensitive information such as contact list, location information, and other credentials. This requires robust security mechanisms for mobile platforms to protect sensitive resources.
Android, as a fast-evolving modern smartphone operating system, implements a security architecture that adopts a kernel-level application sandbox to ensure that applications can only access their own files, and a permission system to control accesses on system resources. Although these security mechanisms significantly confine applications’ privileges, we have seen a number of attacks that can bypass them. We classify these attacks as two categories: (1) attacks bypassing permissions. A malicious application may abuse the components of other applications to gain extra privileges via Inter-Component Communication (ICC) [5,15,21,26]. Moreover, irrevocable and coarse-grained permissions grant unnecessary capabilities to applications, which violates the principle of least privilege [25]; (2) attacks bypassing the sandbox. Sensitive resources of system services can be accessed by any application via non-permission-protected APIs or globally readable files [28]. In addition, malicious applications can exploit vulnerabilities in the device nodes and Linux kernel to gain root privileges [24,50].
To defend Android against these attacks, a number of security extensions have been proposed to implement enhanced mandatory access control (MAC) in Android. Some frameworks implement enforcement mechanisms by modifying sensitive Android APIs [1,3,4,39,44,51]. Given the large number of Android APIs, these frameworks would require extensive work to achieve complete mediation. Meanwhile, some frameworks implement reference monitors by rewriting applications [16,33,40,43,47]. However, a recent study [29] shows that such frameworks may not be tamper proof.
In this paper, we re-explore the problem of designing and implementing a practical MAC framework for Android. We propose a multi-layer security framework called
This paper makes the following contributions:
We discuss the challenges in enabling effective and practical mandatory access control in Android;
We propose a multi-layer security framework,
We implement a proof-of-concept prototype of
We evaluate
The remainder of this paper proceeds as follows. Section 2 describes two classes of existing security issues in Android and existing countermeasures. Section 3 explains the Android IPC mechanisms. Section 4 introduces the design of
Motivation
In this section, we first discuss the attacks that bypass existing Android security mechanisms. We then articulate the existing countermeasures that defend Android against such attacks.
Existing attacks
Android has been a promising mobile platform nowadays. It includes a monolithic Linux kernel and a loosely-coupled middleware layer. Due to the mixed nature of this platform, Android not only inherits security issues rooted in the Linux kernel, but also faces unique security problems introduced by the middleware.
Attacks bypassing permissions
A malicious application may perform privilege escalation attacks by abusing ICC. As applications may unintentionally expose private components without proper permission protection, ICC can be abused for unauthorized intent receipt and intent spoofing [5]. For example, a malicious application can sniff, modify and replace messages sent by a benign application. Moreover, public components are also vulnerable to capability leaks. Lineberry et al. shows that a zero-permission application may upload without the
A coarse-grained permission covers multiple capabilities for accessing resources with different sensitivity levels. For example,
System services may fail to protect their APIs with appropriate permissions, exposing sensitive resources to all applications. For example, the
Attacks bypassing the sandbox
Files that are set globally accessible render DAC-based isolation useless. For example, a vulnerability in Skype exposes the user’s profile information and instant messages due to improper file permission settings [10]. Similarly, the file that stores the list of applications is globally readable in Android and any application can access it without extra permission [28].
A malicious application may also exploit Linux kernel vulnerabilities to break the sandbox [7–9,11–13]. These exploits (also known as “jailbreaks”) allow adversaries to escalate their privilege to root privilege and bypass existing security mechanisms. Recent reports have shown the existence of root-capable malicious applications that download additional malware [41] and replace system binaries [42]. Indeed, the occurrence of such exploits is quite high [50] and almost every popular Android device had a publicly available exploit for at least 74% of the device’s lifetime [24].
Existing countermeasures
Given the diversified attacks, it is imperative to remedy Android’s default security mechanisms to provide better security guarantees. Recently, a wide spectrum of security extensions has been proposed to implement enhanced MAC in Android. Depending on how they implement MAC, we can divide them into two categories.
MAC implemented in the Android system
The history of SELinux has demonstrated the effectiveness of system-centric MAC implementations. Such MAC implementations require patching and/or recompiling the system. In recent years, plenty of security frameworks [1,3,4,6,38,44,51] follow this approach to (1) add kernel MAC for reinforcing application sandboxes; and/or (2) add middleware MAC to remedy the shortcomings of permissions. The kernel MAC implementations reuse or extend previous Linux MAC frameworks such as SELinux and TOMOYO Linux. The middleware MAC implementations are usually tailored to the problems they attempt to address. In particular, FlaskDroid [4] is the first security extension that attempts to address diverse security requirements with a generic security framework. However, generic MAC implementations come with a cost of relatively large code base and difficulties in maintainability. For example, FlaskDroid includes 12 Userspace Object Managers (USOM). Each USOM must be re-evaluated and patched once new Android versions are released. And it remains a question whether the 12 USOMs can completely cover all the attack vectors. Android Security Framework (ASF) [1] attempts to address the limitations of FlaskDroid with loadable security modules and a comprehensive set of security APIs. Despite that the loadable modules could reduce the work required to instantiate different security models, the security APIs themselves that are scattered in various Android system services still suffer from deployment and maintenance issues.
MAC implemented in applications
To address the deployment issues of system-centric MAC implementations, application-centric approaches [16,33,40,43,47] have been proposed. These security frameworks, which are also known as inlined reference monitors, rewrite applications by instrumenting applications’ byte code or native code and thus do not require any changes to the underlying Android system. Despite their significant improvement in deployment, a recent study [29] shows that application-centric MAC implementations are subtle and they could be bypassed or subverted, because the instrumented code runs within the same process as that of the confined application. Apparently, an application is able to modify itself to remove or suppress the instrumented code.
Android IPC
While the Android application sandbox disallows an application to directly access the resources of other applications and Android system, the application can communicate with other applications and utilize the system services through several Android IPC channels. Unfortunately, these IPC channels can be abused by malicious applications (see examples in Section 2). In this section, we elaborate three kinds of Android IPC mechanisms in detail, which will serve as the basis for our approach. Figure 1 depicts several examples of Android IPC channels.

Examples of Android inter-process communication.
Inter-Component Communication (ICC) is commonly used to support communication between Android applications. Android applications are compartmentalized into individual components, including activities, services, broadcast receivers, and content providers. An application’s components can be published and accessed by other applications via ICC channels. Specifically, an application can request an ICC channel with a message called intent. An intent holds the description of the caller’s expected functionalities, e.g., viewing a picture. Then, the intent is handled by a system service called ActivityManagerService, which delivers the intent to valid recipient application components. As shown in Fig. 1, application
Binder IPC
Applications frequently access system resources using Android APIs, which are implemented with Binder IPC channels established between applications and system services. A Binder IPC channel is established through the following six steps: (1) an application invokes an API that is essentially a public function of a proxy in the application framework; (2) the proxy encapsulates the service’s handle, the caller’s data, and a command code in a parcel; (3) the proxy sends the parcel to Binder; (4) Binder delivers the parcel to the remote service; (5) the remote service unpacks the parcel, handles the data as instructed by the command code, and sends results back to the proxy via Binder; and (6) the application receives the results. Alternatively, an application can send Binder messages without involving proxies of the application framework. In such a case, the application can use a utility called
As depicted in Fig. 1, application
Linux IPC
Traditional Linux IPC mechanisms are still available in Android. Examples include local sockets, Unix-domain sockets, and Netlink sockets. In a broader sense, Linux IPC also includes communications via signals and files. System services can use Linux IPC to communicate with other services and the kernel. At the same time, applications may communicate with system services via Linux IPC, bypassing Android’s middleware. Note that applications by default cannot directly utilize Linux IPC channels created by privileged system processes, but recent attacks [48,49] have demonstrated the feasibility of exploiting globally accessible resources.
Figure 1 shows that application
System design
In this section, we first discuss the design goals in implementing an effective and practical MAC framework for Android. We then propose our design and implementation of
Design goals
Mandatory access control is a type of access control by which the operating system confines the abilities of subjects to access certain objects based on a centralized security policy. An effective MAC implementation, no matter whether it is system-centric or application-centric, should fulfill at least the following design goals:
Towards a practical MAC implementation, we further propose the additional design goals:
We assume a threat model that the Android system is trusted. In other words, our trusted computing base (TCB) includes the Linux kernel and the Android middleware, and we do not trust any installed Android application.

Multi-layer reference monitors
In this section, we elaborate the design of the three reference monitors and explain how they achieve our proposed design goals.
ICCMon
We propose ICCMon to handle ICC requests that are between applications. We choose ActivityManagerService as the choke point for ICCMon because ActivityManagerService is the single system service responsible for establishing and shutting down ICC channels.

ICCMon workflow.
Figure 3 depicts the workflow of ICCMon. Specifically, ICCMon labels application components with the UIDs of their corresponding application processes, and labels intents with their meta-information including action, category, and data URI. To ensure complete mediation, we analyze the call graph of ActivityManagerService and identify 4 functions that can capture all ICC requests, including
Android APIs are implemented based on Binder IPC. The mappings between Android APIs and Binder IPC transactions are specified in the AIDL1
Android Interface Definition Language.
To identify choke points of Binder IPC, we analyze the entire Binder IPC subsystem and we choose to place the enforcement hooks in LibBinder (
BinderMon mediates Binder IPC before the permission framework is consulted. Therefore, it enables dynamic permission revocation without affecting the existing permission framework. Furthermore, BinderMon offers finer granularities at the API level, whereas the granularity of the Android permission framework is a set of permissions where each permission maps to multiple APIs. Moreover, BinderMon protects 1,448 public and private Android APIs implemented by more than 70 system services, while FlaskDroid only protects 136 APIs in 12 system services.

BinderMon workflow.
A detailed workflow of BinderMon is shown in Fig. 4. To make an API call, an application sends an Binder IPC request using the proxy of the API’s corresponding remote system service (Step 1). Alternatively, this application can send a request without involving the proxy (Step 1′). BinderMon intercepts both types of requests and queries the decision manager with the caller application’s UID, the callee service’s name, and the command code which indicates the API to be called. If the request is allowed, BinderMon returns control to LibBinder. Otherwise, BinderMon shuts down the IPC channel and returns an error code
The default Android application sandbox is flawed. Although Android applications are expected to use Android APIs to access system resources, they still possess capabilities to bypass APIs and access sensitive Linux IPC channels that general Android applications should not necessarily use. However, ICCMon and BinderMon cannot revoke all of these unnecessary capabilities. Therefore, we propose a kernelspace reference monitor, OSMon, to mediate Linux IPC channels and enforce the principle of least privilege for Android applications.
Figure 5 depicts the workflow of OSMon. Similar to SELinux [45] and TOMOYO Linux [30], we identify choke points as the hooks defined by Linux Security Module (LSM) [46]. However, OSMon only use the hooks are specific to the Linux IPC mechanisms. Table 1 shows the implemented 23 hooks which cover objects like inodes, file systems, tasks, local sockets, Unix-domain sockets, and Netlink sockets. These hooks can be enabled or disabled individually in the kernel configuration file. In addition, OSMon plays as the trusted computing base (TCB) of the entire

OSMon workflow.
Implemented hooks in OSMon
Our unified policy scheme for
(Target).
A target is a 3-tuple Subject is a set of entities to which the authorization is granted; Resource is a set of entities to which accesses need to be mediated; and Action is a set of actions being authorized or forbidden.
(Access control policy).
An access control policy is a 3-tuple
To evaluate an access request over access control policies, if the request satisfies both the target and condition of a policy, the response is sent with the decision specified by the effect element in the policy. Otherwise, the response yields “deny”.
We next describe three kinds of
Components in TripleMon Policies
Components in
ICC policies regulate the intent-based IPC between applications. Thus, application group, application, and component comprise the
For example, an adversary who does not possess the INTERNET permission may still access the Internet by sending an intent with action
Binder policy
Binder policies specify the behaviors of Binder IPC channels between applications and system services. Thus, application group and application comprise the
For instance, as we discussed previously, the permission
OS policy
OS policies mediate Linux IPC channels. In an OS policy, as illustrated in Table 2,
As we mentioned earlier, GingerBreak is a root exploit that attacks a system service called Vold by sending forged and malformed Netlink messages. Such an exploit can be easily prevented by defining an OS policy that disables applications from sending Netlink messages. Indeed, Android applications are currently not strictly prohibited from using some operating system features. Malicious applications may take advantage of these features to launch attacks. Thus, we need to define corresponding OS policies to prevent applications from abusing these features.
Decision manager
The decision manager is the policy decision point of
Communication with reference monitors
As the only policy decision point in
Policy management
The decision manager parses a JSON-like plaintext policy file that follows the policy scheme defined in Section 4.4. The policy file is stored in an internal read-only filesystem. In addition, OSMon enforces rules to disallow access on the policy database from any process except the decision manager.
The decision manager maintains two tracks of security policies, namely slow track and fast track. The slow track is enforced by OSMon only. This track defines the common and least privileges of general installed applications. The fast track is enforced by ICCMon and BinderMon. This track expects more frequent policy updates because ICCMon and BinderMon are required to meet per-application security requirements. Specifically, ICCMon or BinderMon always consults the decision manager to acquire decisions generated based on the latest fast track policy. On the contrary, OSMon caches a copy of the slow track policy in the kernel and makes decisions by itself. It only consults the decision manager to get the latest slow track policy when it initializes itself.
Decision reconciliation
Decision reconciliation is necessary to resolve conflicts when multiple reference monitors are involved to mediate accesses on the same resource. For example, an adversary attempts to access the camera via ICC and Binder IPC, expecting that there would be a capability leak somewhere. Suppose a strategy,
Evaluation
In this section we evaluate
Applications assumed to be benign and trusted by general users
Applications assumed to be benign and trusted by general users
Similar to other policy-driven MAC implementations,
For the set of benign applications, we handpicked 10 applications (Table 3) from Google Play’s top charts. These applications are from renowned developers and under different application categories. We assumed that these applications are trusted by general users and we used them to outline the general expected runtime behaviors of Android applications. The malicious applications were 1,260 malware samples from the Android Malware Genome Project [50]. We fuzzed each application through 5 iterations with randomized touch inputs and system events.
System services protected by TripleMon but unprotected by FlaskDroid
System services protected by
The generated policy demonstrated the coverage of system resources protected by
In terms of Linux IPC channels,
Case studies
To further validate the effectiveness of
ICCMon vs information stealing malware
To test ICCMon, we selected a malware strain called Gone60 (short for “gone in sixty seconds”). Gone6 accesses the Contact applications via ICC channels and uploads user’s contacts to remote servers. In our experiments, we put the malware samples into an application group designated for testing suspicious applications. Then, we applied the following ICC policies to revoke this application group’s capabilities to access user’s contacts. The experiments on 9 Gone60 samples demonstrated that 
BinderMon vs coarse-grained permissions
Next, we validated 
OSMon vs root exploits
In Table 5, we show a list of known root exploits [50], vulnerabilities, and programs attacked by the exploits. We also show the hooks of
Root exploits and countermeasures with TripleMon
Root exploits and countermeasures with
In our experiments, we tested two exploits, GingerBreak and ZergRush, which have been used by recent malicious applications [11,12]. GingerBreak and ZergRush attack Vold’s Netlink socket and local socket, respectively. We defined the following policies to deprive their capabilities to access Vold.
We tested the exploits using (1) samples of GingerMaster, and (2) the shell of Android Debugging Bridge (ADB). Our experimental results showed that OSMon can successfully intercept and prevent such exploits. Figure 6 depicts that ZergRush failed because OSMon denied its attempt to crash

ZergRush fails to exploit Vold.
We further examined a list of known root exploits.2
Next we evaluated how the decision managers helped coordinate the reference monitors. An Android application may read/write the SMS storage with a two-step method: acquiring a handle to the SMS database via ICC, and then accessing the database file.
We defined a policy set to mediate applications’ accesses on SMS. The policy rules in the same policy set protect the same resource (SMS) that corresponds to the objects at multiple layers. As each access involves multiple steps, we define a policy for each step. The decisions made by two policies were aggregated, and the final decision was then made by leveraging the
Performance overheads compared to its related work on the same device
Performance overheads compared to its related work on the same device
We evaluated the performance of
Memory overhead
Memory overhead
The policy generation process using benign and malicious applications is limited by the fact that dynamic random fuzzy testing fundamentally fails to reveal all possible execution paths. Recent work [27] shows that the coverage can be lower than 40%. Thus, the policy still has a lot of space to improve. For the malware samples used in our evaluation, we observed that their malicious payloads usually executed immediately after the applications started. Therefore, fuzzy testing over a large number of malware samples is helpful for understanding common malicious behaviors to be denied in our policy.
In
The current implementation of
Related work
Android security mechanisms have attracted significant attention in recent years. A large number of research projects have been conducted for designing and implementing security extensions on Android to tackle a variety of specific attacks.
FlaskDroid [4] is a two-layer MAC framework that provides flexible and fine-grained mandatory access control on both Android’s middleware and kernel layers. It bears the most similarity with our framework. While FlaskDroid and
Smalley et al. [44] proposed SEAndroid that extends SELinux as kernel-level MAC and adopts a set of middleware extensions to support middleware MAC. Unlike
XManDroid [2] and TrustDroid [3] both are multi-layer security frameworks that adopt TOMOYO Linux as the underlying kernel MAC and a set of middleware extensions for middlware MAC. Their middleware MAC implementations are tailored to their specific problems: XManDroid [2] attempts to mitigate privilege escalation attacks and TrustDroid [3] establishes an isolated domain for business applications. Along these lines,
QUIRE [18] enables provenance in Android IPC by propagating verifiable signatures along IPC chains. The signature provides context of the sender application so that a recipient can authenticate the origin of the data they received indirectly. However QUIRE requires that applications must be modified to support QUIRE-style IPC, which is infeasible for most applications whose source code is not available to general users. In contract to QUIRE,
IPC Inspection [26] is a security framework for tackling permission re-delegation attacks. IPC Inspection reduces the privileges of a recipient application to the intersection of permissions of applications along the IPC chain. However, automatically restricting permissions for collaborative applications is not a decent solution in some cases and may lead to usability loss. Our work employs a policy-based approach and users can specify a group of her trusted applications which can collaborate with each other without restrictions.
TISSA [51] is a policy-driven security extension that protects user’s private data. TISSA implements a privacy mode where access to private data can be dynamically and independently controlled. TISSA puts hooks in several privacy-related system services, such as LocationManagerService and TelephonyManagerService. The hooks redirect control flows to a centralized decision maker. Compared to TISSA,
Several recent work addressed fine-grained and context-aware ICC mediation. SAINT [38] is a policy-driven framework that enforces semantically rich policies on ICC at runtime and during installation. Apex [36] provides a similar solution where users can specify runtime constraints for applications. CRePe [6] enables context-aware ICC where environmental constraints such as location and time can be considered for policy enforcement. Although these extensions are not sufficient to cover all existing attacks discussed in Section 2.1, they demonstrate the necessity and value of flexible and fine-grained access control in ICC. Inspired by their work,
Conclusion
In this paper, we have presented the design and implementation of a multi-layer security framework,
Footnotes
Acknowledgments
This work was partially supported by the grants from Global Research Laboratory Project through National Research Foundation (NRF-2014K1A1A2043029) and the Center for Cybersecurity and Digital Forensics at Arizona State University. Any opinions, findings, and conclusions or recommendations expressed in this material are those of the authors and do not reflect the views of the funding agencies.
