LogicDroid Architecture

The LogicDroid architecture is given in Figure 2.1. The detection of events is done via various “hooks” into the Android OS; these include hooks in the framework layer, system library and the Linux kernel itself. Events intercepted, such as requests to resources by an app, are forwarded to the reference monitor for further evaluation. We will discuss some implementations of the hooks below. The reference monitor resides in the Linux kernel underlying the Android OS. It processes events as they come, and for each new event, it checks whether the new event, together with the history of events processed so far, violates the current security policy. Note that we implement our security checking mechanisms on top of the Android permission mechanism, so in the case where our reference monitor does nothing, the default Android permission mechanism would still be enforced.

The current security policy to be enforced is hardcoded in the monitor for effi- ciency reasons. This, however, makes it slightly complicated to update the security policy in the monitor. We need to provide a facility to update security policies since this might be required to counter new forms of attacks that may not be handled by the current policy. Our current approach is to design the monitor as a kernel mod- ule; this allows it to be removed and reinstalled on a live system. We then devise an

§2.6 Implementation 27 Figur e 2.1: The ar chitectur e of LogicDr oid

offline monitor generation process. The monitor generator takes as input a security policy (specified in RMTL, using XML as the representation language) and generates C code that corresponds to the kernel module of the policy. This appears to be a good compromise between performance and security.

Our implementation places hooks in four services, namely accessing the Internet (opening network sockets), sending SMS, accessing location, and accessing contact database. For each of these sinks, we add a virtual UID in the monitor and treat it as a component of Android. We currently track only ICC calls through the Intent passing mechanism. Android sandboxing restricts how apps can communicate. Commu- nication between apps is typically done through the so-called Intent objects in the Android framework. It is essentially a form of inter-process communication (IPC) mechanism specific to Android. At the application level, we can often track leakage of permissions tracking the passing of Intent objects, so our framework tracks this kind of intents objects to infer privilege escalation. The most time-consuming part of our implementation was actually in tracing howIntentobjects are processed, and in figuring out where to put the hooks to be most effective in intercepting requests to resources.

The phone call hookIn general, resources in Android that are protected by the An- droid permission mechanism are located on the framework level. One such resource is the ability to make phone calls. In the source code of Android, this functional- ity is located in theOutgoingCallBroadcaster.javafile. This file is compiled into a component, and when an app wants to make a phone call, it will need to send an Intent object to this component. We can intercept the phone call request in this component. Figure 2.2 shows a snippet of the code where the permission checked is done. We place the hook just before the Android permission checks take place. The socket hookThis hook is used to detect an attempt to connect to a network (or internet) by opening a socket. Intercepting the attempts to connect to the internet or a local network proves to be quite tricky. Although there are components in the Android framework that provide internet related services, such as HTTP protocol, an app can bypass these components entirely and simply make a system call to open sockets directly. Thus to intercept this connection, we need to place the hook in the Linux kernel. In Android, any app that wants to connect to a network needs to have the INTERNET permission. This permission is checked in the kernel when an app tries to open a socket, and the permission checking is enforced through Linux access control, i.e., the network socket connection is associated with a particular group called INTERNET. Only applications (users) belonging to this group will be able to open a socket. Practically, when an application asks for the INTERNET permission during installation, it will be added as a member of the “INTERNET” group. The hook for the socket is placed in thesocket.cfile (from the Linux kernel source). The extra security checking done by LogicDroid is the same in this case, i.e., it will consult our custom monitor before returning to the normal execution flow. The snippet of code and where to place the hook is shown in Figure 2.3

This is obviously not enough to detect all possible communications between apps, e.g., those that are done through the file systems, or side channels, such as vibration

§2.6 Implementation 29 Figur e 2.2: A hook in the Andr oid frame w ork to inter cept phone calls

Figure 2.3: A hook placed in the Linux kernel to intercept calls to network sockets

setting (e.g., as implemented in SoundComber by Schlegel et al. [2011]), so our im- plementation is currently more of a proof of concept. In the case of SoundComber, our monitor can actually intercept the calls between colluding apps, due to the fact that the sender app broadcasts an intent to signal receiver app to start listening for messages from the covert channels.