http://excel.fit.vutbr.cz

Dynamic security policy enforcement on AndroidMatus Vanco

AbstractThis work deals with the concepts of Android security and proposes the system for dynamicenforcement of access rights. Each suspicious application can be repackaged by this system,so that the access to selected private data is restricted for the outer world. In the first phase,interprocess communication and existing frameworks, which are capable to intercept communicationbetween application and the operating system on the level of system calls, are explored. After that,the system is designed and developed, utilizing the possibilities of one of the compared frameworks –Aurasium framework. The system adds an innovative approach of tracking the information flowsfrom the privacy-sensitive sources using tainting mechanism without need of administrator rights.There has been designed file-level and data-level taint propagation and policy enforcement basedon Android binder.

Keywords: private data — Aurasium framework — operating system — system call — binder driver— Android security — policy enforcement — security policy

Supplementary Material: Downloadable Code*xvanco02@stud.fit.vutbr.cz, Faculty of Information Technology, Brno University of Technology

1. Introduction

Android’s fast growth of popularity has a lot of causesand consequences. Growing number of applications,increasing a number of devices and growing level ofintegration have been interfered and influenced eachother, implying increasing volume of the private data.People have put their trust in their devices and becomemore dependent on mobile technologies, using it forsocialization, trading or entertainment. Hovewer, theprivate data is being used for the profit still more oftenduring globalization, because it is the base for theknowledge-based business and targeted advertising.Even Google’s free Android generates the significantpart of its revenue just this way [1].

Since this asset is seized by many groups of peo-ple using illegal ways, Android has become the mostassaulted mobile operating system facing the wave of

malware, which is even more capable and stealthy, andcan even establish a permanent presence on the de-vice [2]. In order to address these challenges, Androidincludes permission model that protects access to sensi-tive resources. However, since permissions are overlybroad and misunderstood, applications are providedwith more access than they truly require. In particular,they are granted statically during install-time and sodoes not correspond to the actual use at the time. Thisimplicates big vulnerability even if a certain applica-tion is not intended to misuse the private data becauseit can be exploited.

Based on this insufficient built-in Android securityand his later refinements, plenty of third-party frame-works seek to supplement overall security. The currentstate of the art comprises several effective countermea-sures to issues like coarse granularity of permissions,

over-claim of permissions and permission escalationattack. Hovewer, most of these solutions are rathertoo complex and less straightforward. They replacethe whole Android permission model, or tries to trackthe information flow on the level of operating systemwhich requires the rooted device. In contrast, thereis Aurasium framework, which automatically repack-age and harden chosen applications, interposing thesandboxing code in the applications themselves. Nev-ertheless, it is robust enough to interpose almost alltypes of interactions between the application and theoperating system.

The aim of this work is to develop the system,which utilizes the Aurasium framework and restrictthe access of private data outside the device throughthe selected applications. In contrast to original Aura-sium framework, this work focuses more on the realasset, the private data, and especially on the high us-ability and easy deployment. The solution is focusedon tracking the information flows from the privacy-sensitive sources to the system sink where they aim toleave the system.

2. Android Security

Android security has been built upon fundamental secu-rity concepts of the operating systems themselves. An-droid’s Permission Label Model (PAM) has been builtupon Linux security mechanisms including MandatoryAccess Control (MAC) mechanism and Principle ofLeast Privilege (PLP) [3]. Security enforcement usingMAC uses two types of permissions – granted permis-sions (used or requested permissions) and required per-missions (access permissions). Granted permissionsare manifested during installation and are inherited byall of the application’s components. On the other hand,required permissions are usually created by the devel-oper to protect their important components. Requiredpermissions are always assigned to application com-ponents separately. When the application is started,the launcher component is invoked and the other com-ponents are called subsequently from the same or theother application or system. The mechanism of thepassing to another component and access control istransparent in both situations. Communication be-tween components is based on Linux Inter-componentCommunication (ICC), because each application runsin the separate process. It uses message passing, wheremessages contain data with the required action and arecalled intents (ACTION SEND, ACTION VIEW, etc.)[4]. Android maintains this communication using Ref-erence Monitor (RM), which is part of the Android OSMiddleware.

3. Aurasium Framework

Aurasium project has been developed in 2012 as aproject at the University of Cambridge, UK. Aura-sium use repackaging mechanism, wrapping aroundthe DVM under which the Android applications run,with monitoring code. It do not require rooted An-droid device. To attach sandboxing code, Aurariumexploits Android’s unique application architecture ofmixed Java and native code execution and introduceslibc interposition code. Because of this, Aurasiumis capable to mediate almost all types of interactionsbetween the application and the Android OS.

This project consists of three parts – automatedrepackaging system written in Python programminglanguage named pyAPKRewriter, sandboxing codeincluded in ApkMonitor application and Aurasium’sSecurity Manager (ASM) application enablingcentral handling of policy decision of all repackagedapplication on the device. [2]

Starting with sandboxing code, the top layer of theframework is written in Java. The aim is to create anwell-documented easy-to-use abstraction layer uponcumbersome native layer of the framework. The up-per layer creates interface for other possible programsand delegates all requests to the low-level part of theframework implemented in native C++ code. Thislayer consists of few shared objects that do all the realwork, such as communication with the Dalvik VM orestablishing the machanism for IPC communication.

The second part of Aurasium, the repackagingPython script utilizes the previously mentioned sand-boxing code and deploy it to Android APK installationpackage. APK file is similar to Java JAR archive andcontains AndroidManifest file, application logic inthe form of dex bytecode, compiled XML resourcesand native libraries. Each application package is alsosigned with authorship information. Besides the sand-boxing code, Aurasium has to include also severaladditional parts to APK in order to ensure the function-ality.

The last part of the Aurasium is called AurasiumSecurity Manager (ASM). ASM handles the policydecisions centrally, so that all repackaged applicationscan be maintained at one place. Security policy isbased on decision of application or user. Applicationdecision works transparently without user interaction,while the user decision is consented by dialog windowand can be remembered and used by default duringnext occurrence.

4. Android Binder

In order to perform the required mediation, the partof Android middleware called the Binder needs to berewritten. The Binder was originally developed underthe name OpenBinder by Be Inc. and later under PalmInc. and provides high-level abstraction on top of tradi-tional modern operating system services including thefacility to provide bindings to functions and data fromone execution environment to another [5]. In Android,OpenBinder is customized to provide Inter-componentCommunication as described before. All interpositioncode needs to be placed in the suitable position in theoriginal Binder implementation. Therefore, there isimportant to understand the concepts and to analysethe architecture of this part of system.

The communication between two processes is en-sured using Binder Objects (BO), which are instancesof classes that implement ioctl-based Binder interface.The most important operation which is declared inthis interface is transact(int code, Parceldata, Parcel reply, int flags). The cor-responding callback method in the Binder object iscalled onTransact(). The interface can be fur-ther extended by additional business operations us-ing Android Interface Definition Language (AIDL).Each BO uses local and global identifier. The localID is unique in the process and the global ID is cre-ated when the BO is passed to another process us-ing Binder Driver (BD). The BD then works like net-work switch and persists the mapping from local ID toglobal ID in the table structure and translate it trans-parently, similarly than the mapping using ARP pro-tocol. The Binder framework communication usesthe client-server model. However, the process canimplement the server as well as client, so the commu-nication can be still bidirectional. The Binder Client(BC) invokes an operation on a remote Binder ob-ject called Binder Transaction (BT), which may in-volve sending or receiving data over the Binder Pro-tocol. The communication is performed indirectlyusing Binder Driver. In the Android, the Binder Driveris exposed via /dev/binder file and simple APIbased on open(), release(), poll(), mmap(),flush() and ioctl() operations. Most commu-nication happens via ioctl(int fd, unsignedlong request, ... method. The first parameteris the file descriptor number which identifies currentlyopened file and is used in /proc/<pid>/fd/<fd>file. The second parameter specifies the ioctl().

In fact, most communication happens viaioctl(binderFD, BINDER WRITE READ,&bwd) operation, where the binderFD is used to ac-

cess the /dev/binder file and the bwd structure isdefined as:

The write buffer contains a series of com-mands for the driver to perform, while theread buffer contains commands for the BO inuser-space. The commands for driver are called BinderCall (BC) commands and the commands for the BO arecalled Binder Return (BR) commands. Each commandis couple (operation code, data).

The Binder Transaction is a passing data from theclient to the service, while the Binder Reply is a pass-ing data from the service back to the client. This isshown in figure 1. The whole Binder framework mech-anism is transparent for the Android developer, sincethe Binder Transaction is performed as a local functioncall using so-called thread migration. This is ensuredby the proxies and stubs, which are auto-generatedhelper classes from the AIDL files [6]. The proxy isthe helper class which transforms Java code to low-level commands for the Binder Driver. The stub worksin reverse to proxy and automatically parses and per-forms read commands on the service side. Since theBinder Driver is implemented on the low layer using Clanguage, there has to be mechanism for encapsulationof high-level Java objects. This is ensured by Parcelcontainer and corresponding Parcelable interface.A procedure for converting this higher-lever applica-tions data structures into parcels is called marshalling.The marshalling as well as unmarshalling are also inthe responsibility of the proxies and stubs.

Binder 1 Driver Binder 2

BC_TRANSACTION

BR_TRANSACTION

BC_REPLY

BR_REPLY

Figure 1. Binder Driver Interaction1

5. System Design and Implementation

Design of the system is based on previous analysisand various experiments, which were focused on theAndroid system behaviour. Design consists of threeparts – design of architecture and principle of applica-tion, design of data structures and design of configura-tion. Design of architecture can be further devided intotwo parts – desing of tainting mechanism and designof restriction.

1Inspired by Schreiber’s article [5]

Starting with the overall architecture and taintingprinciple, the tainting is based on the principle usedin TaintDroid architecture. In order to perform realmemory-level tainting, there has to be tracked eachatomic memory transfer, which from a programator’spoint of view means each assignment to a variable.This can be done only through monitoring of instruc-tions on the level of machine. In TaintDroid, thereare monitored instructions on the level of virtual ma-chines, because all possibly harmful applications arerun under Dalvik virtual machine. TaintDroid usesVirtual Taint Map (VTM), which mirrors the addressspace, but does not contain the content of memory. Itrepresents the division of memory into protected andpublic part. Before tainting process, the tainted filesare marked in VTM. Then, every copying of memoryinvokes copying of blocks in VTM. Since the applica-tions, which run on separate DVM can also exchangedata, TaintDroid introduces message-level tainting aswell.

In this project, there has been designed and in-tegrated two granularities of taint propagation – file-level tainting and data-level tainting. The message-level tainting (between components) principle fromTaintDroid is used only for final policy enforcement(restriction), because Aurasium intercepts only singleapplications and does not have possibility to moni-tor the unhardened ones. File-level tainting and data-level tainting uses the previously mentioned conceptof VTM, but it is stored in higer-level abstract datastructure and file instead of VTM.

File-level tainting between memory and the OS’sfile system can be performed in full scope, becauseAurasium can fully intercept this communication us-ing system calls fopen(), open(), write() andread(). Fuction fopen() is used for obtaining theopening mode. This is used for tainting customization(TA). If the untainted memory is written to tainted filein append mode, the files remains tainted, but if it iswritten in read mode, the file becomes untainted. Theopen() and read() calls are used for tainting the mem-ory blocks as well as new files. The data in memoryread from tainted file are marked similarily and thefiles, which are read from tainted memory blocks be-comes tainted too. However, data in memory are alsodirectly propagated.

Since the Aurasium can intercept only specificplaces (system calls) and not instruction itself, it is im-possible to implement full-scope memory-level taint-ing as is introduced by TaintDroid. This is replaced bythe newly designed data-level tainting concept. Thisconcept together with the file-level tainting is depicted

in figure 2. When the data are read from the file, con-tent of data is read and tagged using hash functionwhich assigns unique number. This tag, together withthe size of block is used during the writing unknownmemory block into file. Each unknown memory blockis tested with respect to any existing hash and markedas tainted if the hash matches. Subsequently, the file ismarked as tainted as well.

fd*

fd*

fd

fd*

fd fdfdOS:

LAS:

AL:

Time

read write write write read

hash_match() = true hash_match() = true

BR_Transact <IContentProvider>

Call with Tainting

Call without Tainting

User-selected Private File

Tainted File

Not tainted fileEvent

Figure 2. Design of Architecture

The final policy enforcement is performed usingthe interception of ioctl() call. Specifically, when theBR TRANSACTION command which contains desti-nation component ContentProvider is read, all theread() calls for the tainted files are in the mode ofrestriction.

The project is designed to secure the user-selectedfiles or folders as a entity, which are intended to beinvariable like images, pictures or videos. Documentsthat are often changed can be restricted for opening,or there can be assigned unique rights for openingto hardened application and the files are encryptedfor other applications (reverse mode). In this reversemode, data are protected with unhardened applicationsand uncovered and possibly exploited by the hardenedapplication. The reverse mode is designed as optionaland may not be implemented. Further extension isfiner granularity of data-tainting. Unknown memoryblock which is being written to file is compared againstthe tainted memory blocks which are smaller than theunknown memory block, and the memory block whichis being read from file has been divided into smallerunits with separate hash.

Data structure which works as TaintDroid’s VTMis designed as simple array of memory blocks, whichare the interconnection part between the file systemlevel and application logic performing described data-tainting. From designed perspective, each memoryblock is considered as tainted or untainted. Appli-cation can store only tainted data and other will beimplicit. Initially, only the files are marked as taintedand during tainting process, the other files and new

memory blocks are added. Each memory block canhave only one source file, one hash tag, but a lot ofdestination files to which this data are written. Dueto Tainting Customization (TA), also the file modesneed to be stored, because read() and write() functionsdoes not dispose with this information in the passedarguments.

6. Testing and ConclusionApplication has been tested on platform 4.3.1 and sev-eral publicly-available applications, which share datausing Bluetooth, Wi-fi, SMS, Email and other chan-nels. In the first phase, there were performed tests andexperiments related with Aurasium framework. Thesecond step was developing of mocking environmentaccording to previous stage. Here, the processing ofgathered system call sequences has been tested anddebugged. The last stage was to integrate these hookfunctions in real environment – firstly in developed testapplication and then in selected real application. Ex-cept for testing of configuration utility, which has beentested interacting with GUI, all the tests have beenperformed via logging files and manual evaluation.

The aim of this work was to provide the systemfor securing the user-selected private data of chosenapplications with the sandboxing mechanism. Thesolution is focused on tracking the information flowsfrom the privacy-sensitive sources to the system sinkwhere they aim to leave the system. There has beenexamined Android platform from the security perspec-tive and investigated the code and the possibilities ofAurasium framework. From this analysis, there hasbeen designed and implemented solution, which usesfile-level tainting and hash-tagging of memory in pro-cess’s logical address space. The private data from theuser-selected private files is restricted.

7. AcknowledgementsI would like to thank my supervisor Lukas Aron forhis help and motivation.

References[1] JOEL ROSENBLATT. Google’s android gener-

ates 31 billion dollars revenue, oracle says. [on-line], 2016. [cit. 2016-01-21].

[2] RUBIN XU, HASSEN SAIDI, and ROSS AN-DERSON. Aurasium: Practical policy enforce-ment for android applications. In USENIX SecuritySymposium, pages 539–552, 2012.

[3] ABRAHAM SILBERSCHATZ, PETER B.GALVIN, GREG GAGNE, and A. SILBER-

SCHATZ. Operating system concepts, volume 4.Addison-Wesley Reading, 9th edition, 1998.

[4] ANDROID. Android Developers. [online], 2016.[cit. 2016-01-26].

[5] THORSTEN SCHREIBER. Android binder. Mas-ter’s thesis, Ruhr-Universitat Bochum, 2011.

[6] ALEKSANDAR GARGENTA. Deep dive intoandroid ipc/binder framework. In AnDevCon: TheAndroid Developer Conference, 2012.