1 Design and Implementation of Efficient Integrity Protection for Open Mobile Platforms

Xinwen Zhang, Member, IEEE, Jean-Pierre Seifert, Member, IEEE, and Onur Acıic¸mez, Member, IEEE

Abstract—The security of mobile devices such as cellular phones and smartphones has gained extensive attention due to their increasing usage in people’s daily life. The problem is challenging as the computing environments of these devices have become more open and general-purpose while at the same time they have the constraints of performance and user experience. We propose and implement SEIP, a simple and efficient but yet effective solution for the integrity protection of real-world cellular phone platforms, which is motivated by the disadvantages of applying traditional integrity models on these performance and user experience constrained devices. The major security objective of SEIP is to protect trusted services and resources (e.g., those belonging to cellular service providers and device manufacturers) from third party code. We propose a set of simple integrity protection rules based upon open mobile operating system environments and application behaviors. Our design leverages the unique features of mobile devices, such as service convergence and limited permissions of user installed applications, and easily identifies the borderline between trusted and untrusted domains on mobile platforms. Our approach thus significantly simplifies policy specifications while still achieves a high assurance of platform integrity. SEIP is deployed within a commercially available Linux-based smartphone and demonstrates that it can effectively prevent certain malware. The security policy of our implementation is less than 20kB, and a performance study shows that it is lightweight.

Index Terms—integrity protection, open mobile platforms, smartphone security. ✦

1 INTRODUCTION be very efficient and leave only a tiny footprint in the limited memory. Second, in order to save battery energy, With the increasing computing capability and network an always concurrently running PC-like anti-virus solution connectivity of mobile devices such as cellular phones and is, of course, not acceptable. Third, security functionality smartphones, more applications and services are deployed should require minimum or zero interactions from a mobile on these platforms. Thus, their computing environments user, e.g., the end user shouldn’t be required to configure become more general-purpose and open than ever before. individual security policies. This demands then that the The security issue in these environments has gained con- solution must be simple but general enough so that most siderable attention nowadays. According to McAfee’s 2008 users can rely on default configurations — even after new Mobile Security Report [8], nearly 14% of global mobile application installations. users have been directly infected or have known someone On the other side, existing exploits in mobile phones who was infected by a mobile virus. More than 86% of con- have shown that user downloaded and installed applications sumers worry about receiving inappropriate or unsolicited are major threats to mobile services. According to F- content, fraudulent bill increases, or information loss and secure [28], by the end of 2007, more than 370 different theft, and more than 70% of users expect mobile operators malware have been detected on various cell phones, includ- or device manufacturers to preload mobile security func- ing viruses, Trojans, and spyware. Most existing infections tionality. The number of infected mobile devices increases are due to user downloaded applications, such as Dampig 1, remarkably according to McAfee’s 2009 report [9]. Fontal, Locknut, and Skulls. Other major infection mech- Existing research on mobile device security mainly fo- anisms include Bluetooth and MMS (Multimedia Message cuses on porting PC counterpart technologies to mobile de- Service), such as Cabir, CommWarrior, and Mabir. Many vices, such as signature- and anomaly-based analysis [19], exploits compromise the integrity of a mobile platform [21], [27], [30], [34], [38]. However, there are several by maliciously modifying data or code on the device (cf. reasons that make these infeasible. First of all, mobile Section 2.2 for integrity compromising behaviors on mobile devices such as cellular phones are still limited in comput- devices). PandaLab reports the same trends [13] in 2008. ing power. This mandates that any security solution must Based on the observation that user downloaded applications are the major security threats, one objective of securing • X. Zhang is with Huawei Research Center, Santa Clara, CA, USA. mobile terminal should be confining the influence of user E-mail: [email protected] installed applications. This objective requires restricting the • J-P. Seifert is with Deutsche Telekom Laboratories and Technical University of Berlin. Email: [email protected] 1. Description of all un-referred viruses and malware in this pa- • O. Acıic¸mez is with Samsung Information Systems America, San Jose, per can be found at http://www.f-secure.com/en EMEA/security/security- CA, USA. Email: [email protected] threats/virus/. 2 permissions of applications to access sensitive resources solution in a real-world Linux-based mobile phone and functions of mobile operating system (OS), customers, device, and we leverage SELinux to define a re- device manufacturers, and remote service providers, thus spective policy. Our policy size is less than 20kB maintaining high integrity of a mobile device, which usually in binary form and requires less than 10 domains indicates its expected behavior. Considering the increasing and types. We demonstrate that our implementation attacks through Bluetooth and MMS interfaces, an effective can prevent major types of attacks towards system integrity protection should confine the interactions between integrity through mobile malware. Our performance any code or data received from these communication inter- study shows that the incurred overhead is significantly faces and system parts. smaller compared to PC counterpart technology. Towards simple, efficient, and yet effective solution, we Outline In the next section we discuss potential integrity propose SEIP, a mandatory access control (MAC) based assets and threats to mobile platform integrity. Section 3 integrity protection mechanism of mobile phone terminals. gives an overview of SEIP. Details of our design and in- Our mechanism is based upon information flow control tegrity rules are described in Section 4, and implementation between trusted (e.g., customer, device manufacturer, and and evaluation in Section 5 and Section 6, respectively. service providers) and untrusted (e.g., user downloaded We discuss some limitations of our solution in Section 7. through browser or received through Bluetooth and MMS) Related work on integrity model and mobile platform domains. By confining untrusted applications’ write opera- security are presented in Section 8. We conclude this paper tions to trusted domains, our solution effectively maintains in Section 9. runtime integrity status of a device. To achieve the design objectives of simplicity and efficiency, several challenges exist. First, we need to efficiently identify the interfaces 2 THREAT MODEL between trusted and untrusted domains and thus sim- We focus our study on the integrity protection of mobile plify required policy specification. For example, in many platforms. Particularly for this purpose, we study the adver- SELinux systems for desktop and servers, very fine-grained sary model of mobile malware from two aspects: integrity policy rules are defined to confine process permissions assets and attack mechanisms. Note that in this paper we based on a least-privilege principle. However, there is no consider attacks from application level. clear integrity model behind these policies, and it is difficult to have the assurance or to verify if a system is running in a good integrity state. Second, many trusted processes 2.1 Assets for Platform Integrity on a mobile device provides functions to both trusted and Besides regular computing and operating resources, there untrusted applications, mainly the framework services such are several unique targets towards a mobile platform’s as telephony server, message service, inter-process commu- integrity. We identify the following sets of assets. nications, and application configuration service. Therefore Operating system resources The operating system re- simply denying the communications between trusted and sources mainly consist of the trusted computing base of untrusted process decreases the openness of mobile devices an operating system, including boot components, system – mobile users enjoy downloading and trying applications binaries and configurations, and services. Attacks to these from different resources. We address these challenges by resources can easily compromise the integrity of the whole efficiently determining boundaries between trusted and un- platform. trusted domains from unique filesystem layout on mobile Resources of network service provider A mobile device devices, and by classifying trusted subjects (processes) usually consists of sensitive data from network service according to their variant interaction behaviors with other provider, such as those stored in SIM card for network processes. We propose a set of integrity protection rules to and service profiles. Unauthorized access to these data control the inter-process communications between different can compromise the running behavior of the device and types of subjects. communications between the device and wireless network. Our contributions are three-fold in this paper. • We analyze integrity threats on mobile platforms based Device data and status settings Modern mobile de- on infection and compromising mechanisms. We then vices are employed with many sensors, such as timer, identify salient requirements for security solutions on GPS, touchscreen, and webcam. Manipulating these sensors mobile terminals and propose our strategies towards without authorization from the user can cause unexpected these requirements. behavior of a device. Also, a device provides many status • Based on different functional behaviors of subjects in setting functions such as those for 3G, WiFi, Bluetooth, mobile systems, we propose a set of integrity protec- screen brightness level, and battery. A malware can mali- tion rules to control their interactions with others. Our ciously change these settings to attack the integrity of a solution focuses on the protection of phone and plat- platform, e.g., to turn on screen when the device is in idle, form management services from untrusted applications or switch between data network channels stealthily. such as those downloaded by users or received from Resources of mobile user A user stores many personal data Bluetooth/MMS. on device, such as messages, address book, and online cre- • We present the design and implementation of our dentials. Many online service providers store user data on 3

TABLE 1 Integrity Compromising Mechanisms Many mobile mal- Example Mobile Malware and Their Behaviors ware compromise a platform’s integrity by disabling legal

Malware Infection/Propagation Compromising Integrity Assets phone or platform functions. For example, once installed, DAmpig, Bluetooth, MMS, modify system files and configura- mobile viruses like Dampig, Fontal, Locknut, and Skulls Fontal, Internet tions, disable application manager Locknut, and phone services. maliciously modify system files and configurations thus Cabir, Bluetooth, MMS scan new devices with Bluetooth , disable application manager and other legal applications. CommWarrior, sends user data and malicious code Mabir to new targets without authoriza- Doomboot installs corrupted system binaries into c: drive tion. of a Symbian phone, and when the phone boots these Doomboot Bluetooth, Internet, change binaries of system files in corrupted binaries are loaded instead of the correct ones, MMS c:, make device unable to reboot. Skulls Bluetooth disable phone and message ser- and the phone crashes at boot. Similarly Skulls can break vices. phone services like messaging and camera. Cardblock Bluetooth, MMS block access to memory card, delete system files and installed As a mobile phone contains lots of sensitive data of its application files and data. user and network service provider, they can be targets of Redbrowser download Java ap- send SMS messages to premium plication rate number at a rate of $5 - $6 attacks. For example, Cardblock sets a random password to per message. a phone memory card thus makes it no longer accessible. Mquito download game ap- sends SMS messages to premium plication rate number. It also deletes system directories and destroys information about installed applications, MMS and SMS messages, phone numbers stored on the phone, and other critical system data. Other malware such as Pbstealer and Flexispy device side, such as online bank and entertainment services, do not compromise the integrity of a platform, but stealthily which are targets for malware. By sending SMS/MMS copy user contact information and call/message history and messages and making hidden phone calls to premium phone send to external hosts. numbers, a malware can generate monetary cost to a mobile Monetary loss is an increasing threat on mobile phones. user. Many viruses and Trojans trick a device to make expensive We note that this is not intended to be an exhaustive calls or send messages. For example, Redbrowser infects list for integrity assets. Table 1 summarizes some example mobile phones running Java (J2ME) and sends SMSs to a malware and their infection mechanisms and target integrity fixed premium rate number at a rate of $5 - $6 per message, assets. which is charged to the user’s account. Mquito, which is distributed with a cracked version of game Mosquitos in 2.2 Attach Mechanisms pirate channels, sends an SMS message to a premium rate Infection Mechanisms With the constraints of computing number before the game starts normally. capability, network bandwidth, and I/O, the major usage Propagation Mechanisms On an Internet-enabled desktop of mobile devices is for consuming data and services from or server, a malware can propagate itself by building remote service providers, instead of providing data and ser- connections to other internet-connected hosts and sending vices to others. Based on this feature, the system integrity its malicious code. For example, many worms randomly objective for mobile devices is different from that in desk- pick IP addresses and try to build connections if there top and server environments. For typical server platforms, are vulnerable services running on target hosts. On mobile one of the major security objectives is to protect network- devices, however, a malware can propagate with many other faced applications and services such as httpd, smtpd, ftpd, connectivity mechanisms, such as Bluetooth, SMS/MMS, and samba, which accept unverified inputs from others [31]. and WiFi. Many malware have been found which use Blue- For mobile phone platforms, on the other side, the major tooth and SMS/MMS to propagate. Also, some malware can security objective is to protect system integrity threaten by leverage multi-connection interfaces on a mobile devices user installed applications. According to mobile security for more complex attacks, such as cross-service attacks [34] reports from F-Secure [28] and PandaLab [13], most exist- and deny-of-service attack to cellular network [24]. ing malware on cell phones are unintentionally downloaded and installed by user, and so far there are no worms that do not need user interaction for spreading. 3 SEIPOVERVIEW Although most phones do not have Internet-faced ser- vices, many phones have local and low bandwidth commu- 3.1 Requirements nication services such as file-sharing via Bluetooth. Also, Simplicity and Effectiveness It is very expensive to change the usage of multimedia messaging service (MMS) has any system function on a mobile device once it is massively been increasing. Many viruses and Trojans have been found produced and sold to final customers. Also, a mobile user in Symbian phones which spread through Bluetooth and/or typically does not have skills and knowledge to configure MMS such as Cabir, CommWarrior, and Mabir. Therefore, any security functions except some simple application-level any code or data received via these services should be settings. On the other side, due to the complexity of mobile regarded as untrusted, unless a user explicitly prompts to business model, i.e., hardware and software components trust it. The same consideration applies for any received can be integrated from different vendors, complex security data via web browsers on mobile devices. policies and mechanisms can increase the cost of system 4 integration and deployment. Therefore it is desirable to have native applications such as LiMo [5], Maemo [7], GPE [3], a simple but effective security model. Qtopia [14], and JNI-enabled Android. Thirdly and most Efficiency One critical performance requirement lies on importantly, most of these “ad-hoc” approaches do not typical usage behaviors with mobile devices. A mobile apply any kind of foundational security model. Logically, user is not so “sticky” as that in desktop environments, it is nearly impossible to specify and verify policies for where she spends a lot of time using a particular appli- fundamental security properties such as system integrity. cation. While a mobile user is “bouncy”, and flies in and In our design, we use MAC-based security model, thus back out between different applications [17]. Therefore a different processes from the same user can be assigned trusted subject (e.g., a service daemon) may accept requests with different permissions. Further, our approach enables from both trusted and untrusted application concurrently deeper security checks than simply allowing/denying API (although may not be absolutely concurrent). Traditional calls. Finally, instead of considering extremely fine-grained integrity models are not efficient and flexible under these permission control thus requiring a complete and formal scenarios. For example, LOMAC [25] requires a process verified policy, we focus on read- and write-like permis- dynamically downgrade its security level whenever it ac- sions that affect system integrity status, thus make integrity cesses low integrity objects or receives inputs from low verification feasible. integrity processes. However, the process needs to re- Trusted subjects handling both trusted and untrusted start whenever it needs to access high integrity objects data Traditional integrity models either prohibit infor- later, which is not efficient for mobile devices. Efficiency mation flow from low integrity sources to high integrity is a must requirement for user experience of consumer processes (e.g., BIBA [18]), or degrade the integrity level electronic (CE) devices. of high integrity processes once they receive low data (e.g., LOMAC [25]). However, both approaches are not flexible 3.2 Design Overview enough for the security and performance requirements of To effectively achieve integrity protection goals while re- mobile platforms. Specifically, due to function convergence, spect the constraints of mobile computing environments, one important feature of mobile phone devices is that we propose the following tactics for our design. resources are maintained by individual framework services Simplified boundary of trusted and untrusted domains which run as daemons and accept requests from both Instead of considering fine-grained least privileges for trusted and untrusted processes. For example, in LiMo individual applications, we focus on integrity of trusted platform [5], a message framework controls all message domains. With this principle, we identify domain boundary channels between the platform and base stations, and along with relatively simpler filesystem layout in many implements all message-related functions. Any program Linux-based mobile phones than in PC and server environ- that needs to receive/send SMS or MMS messages has ments. Specifically, based on our investigation, most phone- to call the interfaces provided by this framework, instead related services from device manufacture and network of directly interacting with the wireless modem driver. provider are deployed on dedicated filesystems, while user Other typical frameworks include telephony service serving downloaded application can only be installed on another voice conversation and SIM card accesses, and network dedicated filesystem or directory, or flash memory card. manager serving network access such as GPRS, WiFi, Thus, for example, one policy can specify that by default and Bluetooth. All these frameworks are implemented as all applications belonging to the manufacturer or service individual daemons with shared libraries, and expose their provider are trusted for integrity purpose, while user in- functions through public interfaces (e.g., telephony APIs). stalled applications are untrusted. An untrusted application Similar mechanisms are used for platform management can be upgraded to trusted one only through extra authen- functions such as application management (application in- tication mechanisms or explicit authorization from user. stallation and launch), configuration management, and data MAC-based integrity model Many mobile platforms use storage. Many frameworks need to accept inputs from both digital signature to verify whether a downloaded applica- trusted and untrusted applications during runtime — to tion can have certain permissions, such as Symbian [26], provide, e.g., telephony or message services. However, due Qtopia [15], MOTOMAGX [10], and J2ME [4]. All the to performance reasons they cannot frequently change their permissions specified by a signed application profile are security levels. Thus, traditional integrity models such as high level APIs, e.g., making phone call or sending mes- BIBA and LOMAC are not flexible enough to support such sages. There are several issues with these approaches. First security and performance requirements. Similarly, domain of all, they cannot check the parameters of allowed API transitions used in SELinux are infeasible for mobile plat- calls, thus a malicious application may get sensitive access forms. or functions with allowed APIs, such as call or send SMS Towards this issue, we propose that some particular messages to premium rate numbers. Second, API invocation trusted processes can accept untrusted information while control cannot restrict the behaviors of the target application maintaining their integrity level. The critical requirement when it makes low level system calls, e.g., invoking system here is that accepted untrusted information does not affect process or changing code and data of trusted programs. the behavior of such trusted process and others. We achieve This is especially true for platforms that allow installing this goal via separating information received from subjects 5 of different integrity levels. For example, the telephony such as accessing SIM or user data, e.g., for mobile bank server accepts requests from both trusted and untrusted and payment applications. For an application belonging to applications, while enforces constraints to the types of 3rd party service provider, its integrity level may be based phone calls that an untrusted application can make. For on the trust agreement between the service provider and another example, during the installation and launching of user or manufacturer/network provider. For example, an applications on mobile platforms, untrusted applications anti-virus agent on a smartphone from a trusted service can be installed and launched through a trusted package provider needs to access many files and data of the user management tool and application launcher (which of course and network provider and should be protected from mod- operate on both trusted and untrusted domains), while ification of low integrity software, therefore it is regarded the installer and launcher still maintain their respective as high integrity. Other high integrity applications can be integrity. We insert security hooks into these daemons, trusted platform management agents such as device lock, and define a set of integrity rules to label the data a certificate management, and embedded firewall. trusted subject reads and isolate them when these data are Usually, extra authentication mechanism is desired when processed or handed over to other subjects. We identify a user installed application is considered as high integrity the general principles and places to isolate untrusted access or trusted, such as application source authentication via requests in typical service frameworks on a mobile termi- digital signature verification, or explicitly authorized via nal including telephony service, message service, platform user interface actions from the user. configuration service, and device status monitoring service. Based on the integrity objective of SEIP — to protect An important feature that distinguishes our approach from system and service components from user installed ap- traditional information flow–based integrity models is that, plications — we specify the boundary in the filesystem we do not sanitize low integrity information and increase its of mobile devices. We lay out all Linux system binaries, integrity level, as Clark-Wilson–like [22], [29], [37] models shared libraries, privileged scripts, and non-mutable config- do. Instead, we separate the data from different integrity uration files into dedicated file system or system partition. levels within a trusted subject so receiving untrusted data Similar layout can be used for all phone related application does not affect its behavior. binaries, configurations, and framework libraries. All user applications can only be installed in a writable filesystem 4 DESIGN OF SEIP or a directory and the /mnt/mmc, which is mounted when a flash memory card is inserted. However, many This section presents design details and integrity rules phone related files are mutable, including logs, tmp files, of SEIP for mobile platform based on discussed security database files, application configuration files, and user- threats and our strategies. Although we describe within customizable configuration files, thus have to be located in the context of Linux-based mobile systems (specifically, writable filesystems. Policies should be carefully designed LiMo platform), our approach can be applied to other to distinguish the writing scope of a user application. phone systems such as Symbian, as they have similar We have observed similar approaches have been used on internal software architecture. One assumption is that we Motorola EZX series [12] and Android [1]. do not consider attacks in kernel and hardware, such as installing kernel rootkits or re-flashing unauthentic kernel We note that filesystem layout is determined by the and filesystem images to devices. That is, our goal is to manufacturer of a device and such a separation can be en- prevent software-based attacks from application level. forced quite easily. This approach simplifies policy defini- tions and reduces runtime overhead compared to traditional approaches such as SELinux on PCs, which sets the trust 4.1 Trusted and Untrusted Domains boundaries based on individual files. Note that we assume To preserve the integrity of a mobile device, we need to there is secure re-flashing of the firmware of a device. identify the integrity level of applications and resources. If arbitrary re-flashing is enabled, an attacker can install In mobile platforms, typically trusted applications such untrusted code into the trusted side of the filesystem offline, as those from device manufacture and wireless network and re-flash the filesystem image to the device. When the provider are more carefully designed and tested as they devices boots, the untrusted code is loaded into trusted provide system and network services to other applications. domain during runtime and can ruin the system integrity. Thus, in our model we regard them as high integrity applications or subjects. Note that completely verifying the trustworthiness of a high integrity subject, e.g., via 4.2 Subjects and Objects static code analysis, is out of the scope of SEIP. As Like traditional security models, our design distinguishes aforementioned, our major objective is to prevent platform subjects and objects in OS. Basically, subjects are active integrity compromising from user installed applications. entities that can access objects, which are passive entities Therefore by default all user installed applications later in a system such as files and sockets. Subjects are mainly on the platform are regarded as low integrity. In some active processes and daemons, and objects include all cases, a user installed application should be regarded as possible entities that can be accessed by processes, such high integrity, e.g., if it is provided by the network carrier as files, directories, filesystems, network objects, program or trusted service provider and requires sensitive operations and data files. Note that a subject can also be an object as it 6 can be accessed by another process, e.g., being launched or default, which can be considered as trusted subjects in killed. In an OS environment, there are many different types our strategy. However, they mostly read untrusted Internet of access operations. For example, SELinux pre-defines content or play downloaded media files in flash memory a set of object classes and their operations. For integrity card. These subjects usually do not communicate with purposes, we focus on three access operations: create, read, other high integrity subjects in most current smartphone and write. From information flow perspective, all access systems, and they do not write to objects which should operations between two existing entities can be mapped to be read by other trusted subjects. Therefore, in our design read-like and write-like operations [16]. we downgrade their integrity level during runtime without In many cases, objects are not visible in OS, while affecting their functions and system performance. only accessible through framework services, i.e., accessed Type III trusted subjects These are mainly service by daemons. Other processes communicate with daemons daemons such as telephony, message, network manager, to create and access objects via APIs. This encapsulated inter-process communication (IPC), device status manager approach can be found in many service-oriented software (reading and setting hardware status), and application and architectures. For example, telephony server creates and platform configuration services. Usually these subjects need maintains telephone conversation sessions for other ap- to interact with both low and high integrity subjects. For plications which request to make phone calls. Also, the integrity purpose, we need to prevent any information telephony server maintains SIM data of a mobile phone flowing from low integrity entities to high integrity entities device, which are not be accessed via other application by using these daemons’ functions. directly in OS environment, but can only be accessed by the telephone server. The network manager framework in LiMo 4.4 Integrity Rules creates and maintains all network connections and profiles for different applications, such as Packet Data Protocol For integrity protection, it is critical to control how infor- (PDP) sessions for GPRS and access point associations mation can flow between high and low integrity entities. for WiFi connections. Another example, Gconf daemon We propose a set of information flow control rules for (gconfd) stores configuration data for individual phone different types of subjects, with focus on create, read, and 3 applications, which can only access their data via GConf write operations . Table 2 summarizes these integrity rules, APIs, and gconfd is the only subject that can physically where L(x) is the integrity level of subject or object x, and (in OS point of view) read and write the objects. Not only Figure 1 shows allowed information flow between subjects for those objects in regular OS such as files and sockets, based on these rules. our design protects objects internally maintained by these TABLE 2 service daemons which affect the integrity of a platform. Rules for Information Flow Control

4.3 Trusted Subjects Create Object: We distinguish three types of trusted subjects 2 on mobile Rule 1: create(s, o) ← L(o)= L(s): when object o is created by platforms, according to their functionalities and behaviors. a process s, o inherits s’s integrity level. Different integrity rules (cf. Section 4.4) are applied to them Rule 2: create(s1,s2, o) ← L(o) = MIN((L(s1),L(s2)): when for integrity protection purpose. o is an object created by process s1 with input from another process s2, o inherits the lower bound of integrity levels of s1 and s2. Type I trusted subjects This type includes high in- tegrity system processes and services such as init and Read/Write: busybox, which are basically the trusted computing base Rule 3: can read(s, o) ← L(s) ≤ L(o): a low integrity process s (TCB) of the system. Only high integrity subjects can have can read from a low or high integrity process or object o. information flow to those subjects, while untrusted subjects Rule 4: can write(s, o) ← L(s) ≥ L(o): a high integrity process can only read from them. Type I trusted subjects also in- s can write to a low or high integrity process or object o. clude pre-installed applications from device manufacture or Rule 5: can read(s, o1) ← L(s) ≥ L(o1) ∧ can write(s, o2) service provider, such as dialer, calendar, clock, calculator, ∧L(o1) ≥ L(o2): a high integrity process s can receive information contact manager, etc. As they usually only interact with from low integrity subject or object o1, provided that the information will be written to low integrity subject or object o2 by the high other high integrity subjects and objects, their integrity level integrity process s. is constant during runtime. ′ Rule 6: change level : L (s) = L(o) ← read(s, o) ∧ L(s) > Type II trusted subjects These are applications provided L(o): when a high integrity process s reads low integrity object o, by trusted resources, but usually read low integrity data its integrity level is changed to L(o). only, such as browser, MMS agent, and media player. They are usually pre-deployed in many smartphones by Rule 1: create(s, o) ← L(o) = L(s): when an object is created by a process, it inherits the integrity level of the 2. The concept of trusted subjects in SEIP is different from that in process. traditional trusted operating system and database [33]. Traditionally, a trusted subject is allowed to bypass MAC and access multiple security levels. Here we use it to distinguish applications from trusted resources 3. We consider destroying/deleting an object is the same operation as and user downloaded. writing an object. 7

s can receive information from low integrity entity o1, provided that the information is separated from that of other High Low high integrity entities, and it flows to low integrity entity o2 (a) by the high integrity process s. As Figure 1(b) shows, this rule allows a trusted subject

High Trusted Low to behave as a communication or service channel between untrusted entities. This rule is particularly for the Type III trusted subjects, which can read/receive inputs from low High Low integrity entities while maintaining its integrity level, under (b) the condition that the low integrity data or requests are separated from high integrity data and handled over to a Fig. 1. Information flows are allowed between high and low integrity entity by the trusted subject. low integrity entities, directly or indirectly via trusted Rule 5 requires that any input from untrusted entities subjects. does not affect the runtime behavior of the high integrity subject. Therefore not every subject can be trusted for this purpose. Typically, communications between applications ← Rule 2: create(s1,s2, o) L(o) = and service daemons can be modelled with this rule. For MIN((L(s1),L(s2)): when an object is created by example, on a mobile phone device, a telephony daemon a trusted process s1 with input/request from another can create a voice conversation between an application and process s2, the object inherits the integrity level of the wireless modem, upon the calling of telephony APIs. A lower bound of s1 and s2. low integrity process cannot modify any information of These two rules are exclusively applied upon a single the connection created by a high integrity process, thus object creation. Typically, Rule 1 applies to objects that preventing stealthily forwarding the conversation to a ma- are privately created by a process. For example, an appli- licious host, or making the conversation into a conference cation’s logs, intermediate and output files are private data call. For another example, data synchronizer from device of this process. This rule is particularly applied to Type I manufacture or network provider can be trusted to read both trusted subjects and all untrusted subjects. Rule 2 applies high and low integrity data without mixing them. to objects that are created by a process upon the request Rule 6: change level : L′(s) = L(o) ← read(s, o) ∧ of another process. In one case, s1 is a server running as a L(s) > L(o): when a trusted subject reads low integrity daemon process, the s2 can be any process that leverages object, its integrity level is changed to that of the object. the function of the daemon process to create objects, e.g., to create a GPRS session, or access SIM data. In another This rule is dedicated for the Type II trusted subjects, case, s1 is a common tool or facility program that can be which usually read untrusted data (e.g., Internet content used by s2 to create object. In these cases, the integrity or media files). As these subjects do not communicate level of the created object is corresponding to the lower of with other trusted subjects, downgrading their integrity level s1 and s2. This rule is applied to Type III trusted subjects does not affect their functions and system performance in as aforementioned. our design. This is the only rule that changes a subject’s Rule 3: can read(s, o) ← L(s) ≤ L(o): a low integrity integrity level during runtime. process can read from both low and high integrity entities, but a high integrity process can only read from entity of 4.5 Enforcing Integrity Rules the same level. For Type I subjects, since no low integrity information can ← ≥ Rule 4: can write(s, o) L(s) L(o): a high flow to them, any write access from untrusted subject is integrity process can write to both low and high integrity blocked. The enforcement is implemented in OS kernel entities, but a low integrity process can only write to entity by controlling IPC between processes. Note we have the of the same level. assumption that the kernel is trusted. For Type II subjects, As Figure 1(a) shows, these two rules indicate that there the enforcement of integrity rules is straightforward: when is no restriction on information flow within trusted entities, a subject read low integrity data, its integrity level is and within untrusted entities, respectively. However, these downgraded to the low level, which is also enforced by also imply that information flow is only allowed from high kernel. integrity entities to low integrity entities, which is, funda- Integrity policy enforcement for Type III trusted subjects mentally, BIBA-like integrity policy. Note that a reading is more complex. Towards information flow control, we or writing operation can happen between a subject and an further identify two classes of Type III subjects: those object, or between two subjects via IPC mechanisms. These implementing functions to manage critical resources of a two rules are applied to direct communication between platform such that only trusted subjects can write, e.g., the Type I trusted subjects and all untrusted entities. device status manager in our LiMo evaluation platform (cf. Rule 5: can read(s, o1) ← L(s) ≥ L(o1) ∧ Section 5.3) and telephone daemon for SIM data access, write(s, o2) ∧L(o1) ≥ L(o2): a high integrity process and those implementing variant services for both untrusted 8 and other trusted subjects, e.g., IPC service like D-Bus dae- integrity messages from dbusd. Also, according to Rule 5, mon, telephony server, message server, and configuration if a process is a Type III trusted daemon, like telephony or server. As policy enforcement is within a trusted Type III message server daemon, it can receive high and low in- subject, we have to hook into its implementation to check tegrity messages from dbusd, and handle them separately access requests from other subjects. within the daemon. Specifically, a typical service framework provides func- tions to other applications via APIs defined in library files. 4.7 Program Installation and Launching We identify all read-, create-, and write-like APIs for a An application to be installed is packaged according to framework, and track their implementing methods in the particular format (e.g., the .SIS file for Symbian and .ipk daemon. For the first class Type III subjects, read-like for many Linux-based phone systems), and application accesses are allowed to all other subjects, while write-like installer reads the program package and meta-data and accesses are only allowed to trusted subjects, e.g., to allow copies the program files into different locations in local them to set devices status. Our implementation of secure filesystem. As the application installer is a Type III trusted SIM data access (Section 5.3) and secure device status subject specified by policy, it can read both high and service (Section 5.4) takes this approach. low integrity application packages. Also, according to our For the second type of Type III subjects, careful inves- integrity Rule 2 and 5, it writes (when installing) to trusted tigation to the internal architecture of a daemon is needed part of the filesystem when reads high integrity software to isolate information from trusted and untrusted subjects package, and writes to untrusted part of the filesystem when following integrity Rule 5, i.e., low integrity information reads low integrity package. flows to low integrity subjects or objects, and high integrity Similar to installation, during the runtime of a mobile information can only flow to high integrity subjects or system, a process is invoked by a trusted program called objects via the trusted subject. In general, for a creating program launcher, which is also a Type III trusted subject method, we insert a hook to label the new object with according to policy. Both high and low integrity processes the integrity level of the requesting subject. For a write- can be invoked by the program launcher. All processes like method, we insert a hook to check the label of target invoked from trusted program files are in high integrity object and the requesting subject, and deny or allow the level, and all processes invoked from untrusted program access according to pre-defined policies according to our files are in low integrity level. Compare to traditional integrity rules. Our implementation for secure D-Bus (Sec- POSIX-like approaches, where a process’s security context tion 5.2), secure phone services (Section 5.3), and secure and privileges typically are determined by a calling process, configuration service (Section 5.4) is in this case. in our design, a process’s integrity level is determined by The reminder of this section illustrates the high level the integrity level of its program files including code and design of applying these principles to some critical platform data 4. On one aspect, this enhances the security as a management framework including IPC and application in- malicious application cannot be launched to a privileged stallation. We present the implementation details of secure process, which is a major vulnerability in traditional OS; phone and device services in next section. on the other aspect, this simplifies policy specification in a real system, which can be seen in next section. 4.6 Dealing with IPC According to Rule 1, most IPC objects inherit the integrity 4.8 Dealing with Bluetooth/MMS/Browser and level of the processes that create them, including domain Their Received Code/Data sockets, pipes, fifo, message queues, shared memory, and As aforementioned in Section 2, increasing malware in- shared files. Therefore, when a low integrity process creates fect mobile phones via variant communication channels an IPC object and write to it, a high integrity process between phone devices and networks. For example, many cannot read from it, according to our integrity rules. In malware in Symbian-based phones send malicious codes many mobile Linux platforms such as LiMo, OpenMoko, via Bluetooth channel, or distribute with MMS messages GPE, Maemo, and Qtopia, D-Bus is the major IPC, which (either in message contents or as attachments). In the mean is a message-based communication mechanism between time more smartphones have been deployed with Internet processes. A process builds a connection with a system- browsers, which is another interface to access and receive or user-wide D-Bus daemon (dbusd). When the process untrusted code and data. SEIP regards MMS agents and wants to communicate to anther process, it sends messages mobile browsers as Type II trusted subjects via security to dbusd via its connection. The dbusd maintains con- policy. According to integrity Rule 6, their integrity level nections of many processes, and routes messages between is changed to low whenever they receive data from outside, them. A D-Bus message is an object in our design, which e.g., reading message or browsing web content. Any code inherits integrity level from its creating process. According or data received from Bluetooth, MMS, and browser is to Rule 5, Type III trusted subject dbusd (specified by policy) can receive any D-Bus message (low or high 4. Superficially this feature is similar to the setuid in Unix/Linux. However setuid is mainly for privilege elevation for low privileged integrity level) and forward to corresponding destination processes to complete sensitive tasks, while here we confine a process’s process. Typically, a trusted process can only receive high integrity aligning with its program’s integrity level. 9

Untrusted untrusted by default since during runtime these subjects can Trusted Subjects Subjects only write untrusted system resources such as filesystems. sys_t, telephony_t, statusmg_t, controlled Thus, any process directly invoked from arbitrary code by jvm_t, gconfd_t, dbusd_t, ... communication MMS agent or browser is in low integrity level, according to our integrity Rule 1. Furthermore, any code saved by these subjects is in low integrity level and it cannot be launched to high integrity processes, as the program launcher is Type III trusted subject following integrity Rule 5. Thus it cannot read read/write read read read/write write to trusted resources and services, such as corrupting system binaries or changing platform configurations. More ext3 read-write fine-grained policy rules can be defined to restrict phone filesystems related functions that an untrusted process can have, such read-write dir & filesystem as accessing phone address book, sending messages, and read-only filesystems (e.g, /app/usr, building Bluetooth connections, which prevent further dis- (e.g, cramfs) /mnt/mmc) tribution of potentially malicious code from this untrusted Fig. 2. Trusted and untrusted domains and allowed subject. information flow between them on evaluation platform. It is possible that some software and data received from Bluetooth, MMS, and browser are trusted. For instance, a user can download a trusted bank application from his PC filesystem. All mutable phone related files are located in via Bluetooth or from a trusted financial service provider’s an ext3 filesystem, including logs, tmp files, database files, website via browser. For another example, many users use application configuration files, and user-customizable con- Bluetooth to sync calendar and contact list between mobile figuration files (e.g., application settings and GUI themes). devices and PC. SEIP does not prevent these types of By default, all codes and data downloaded by user, e.g., via applications. Usually, with extra authorization mechanism USB, Bluetooth, MMS, or browser, are stored and installed such as prompting via user actions, even an application or under /app/usr of the ext3 filesystem and in /mnt/mmc data is originally regarded as untrusted, it can be installed or (which is mounted when a flash memory card is inserted), stored to the trusted side, e.g., by the application manager unless explicitly prompted by the user to install to the or similar Type III trusted subjects on the phone. Similar trusted ext3 filesystem. mechanism can be used for syncing user data or installing As Figure 2 shows, all read-only filesystems and part of user certificate via browser. ext3 filesystem where phone related files are located are re- garded as trusted, and user writable filesystems are regarded 5 IMPLEMENTATION as untrusted. By default, processes launched from trusted filesystems are trusted subjects, and processes launched We have implemented SEIP on a real LiMo platform [5]. from untrusted filesystems are untrusted subjects. Note Our implementation is built on SELinux, which provides that our approach does not prevent trusted user application comprehensive security checks via Linux Security Module from being installed on the device. For example, a trusted (LSM) in kernel. Also SELinux provides domain-type and mobile banking application can be installed in the trusted role-based policy specifications, which can be used to read-write filesystem, and the process launched from it is define policy rules to implement high level security models. labelled as trusted. We also label any process invoked by However, existing deployments of SELinux on desktop and message agent (e.g., MMS or email agent) or browser as servers have very complex security policies and usually untrusted. According to SEIP, trusted subjects can read and involve heavy administrative task. Furthermore, current write to trusted filesystem objects, and untrusted subjects SELinux does not have an integrity model built-in. On can read all filesystem objects, but can only write to one side, our implementation simplifies SELinux policy for untrusted objects. Figure 2 also shows the information mobile phone devices based on SEIP. On the other side, flow between subjects and filesystem objects. The access our implementation augments SELinux policy with built-in controls are enforced via SELinux kernel level security integrity consideration. server. As created by kernel, virtual filesystems like /sys, 5.1 Trusted and Untrusted Domains /proc, /dev and /selinux are trusted. Similar to the Figure 2 shows a high-level view of the filesystem ext3 filesystem, /tmp and /var include both trusted and and memory space layout in our evaluation platform. untrusted file and directory objects, depending on which All Linux system binaries (e.g., init, busybox), processes create them. shared libraries (/lib, /usr/lib), scripts (e.g., inetd, network, portmap), and non-mutable configuration 5.2 Securing IPC via D-Bus files (fstab.conf, inetd.conf, inittab.conf, mdev.conf) are located in a read-only cramfs filesystem. D-Bus is the major IPC mechanism for most Linux- Also, all phone related application binaries, configurations, based mobile platforms. The current open source D-Bus and framework libraries are located in another cramfs implementation has built-in SELinux support. Specifically, 10

a dbusd can control if a process can acquire a well- OEM Telephony App Telephony Server known bus name, and if a message can be sent from Driver /Modem one process to another, by checking their security labels. These partially satisfy our integrity requirement: a policy tapi_call_setup() security_check_hook() can specify that a process can only send message to another process with the same integrity level. However, as tapi_oem_call_setup() in mobile devices, including our evaluation platform, both response status notifications trusted and untrusted applications need to communicate status notifications and with framework daemons via dbusd, e.g., to make phone callback calls or access SIM data, or set up network connections with voice conversation state connectivity service. Therefore, existing D-Bus security mechanism cannot satisfy this requirement. Following our integrity rules, we extend D-Bus built-in Fig. 3. Secure telephony server. A security hook in security in two aspects. Firstly, each message is augmented telephony daemon checks if a voice call can be build with a header field to specify its integrity level based on the for the client application. process which sends the message, and the value of this field is set by dbusd when it receives the message and before TABLE 3 dispatches it. As dbusd listens to a socket on connection Telephony and Message Server APIs where Integrity requests from other processes, it can get the genuine process Check is Enforced information from the kernel. Note that as dbusd is a Type Telephony Service III trusted process, both high and low integrity processes Call setup Call answer Call release SendDTMF Call releaseall Hold can send messages to it. Secondly, according to our integrity Retrieve ECT Join rules, if a destination bus name is a Type I trusted subject, Split Call forward Call wait it can only accept high integrity messages; otherwise, it can Call bar SetRestrictCallId Short Message Service accept both high and low integrity messages. Sms write Sms delete Sms send With these, each message is labeled with an integrity Sms setCbconfig Sms setPreferredbearer Sms setSca level, and security policies can be defined to control Sms setSMSParameters Sms SendDeliveryReport Access SIM Resources communication between processes. When a message is Sim changePin Sim unblockPin Sim EnablePin received by a trusted daemon process, its security label is Sim DisablePin Sim update Sim EnableFDN further used by the security mechanism inside the daemon Sim DisableFDN Sim UpdatePBRecord Sim deletePBRecord to control which object that the original sending process can access via the method call in the message, which is communication channels. In our LiMo platform, message explained in the following subsections. framework and data network framework are dedicated Our implementation introduces less than 200 line of for short message and data network access services. An code based on the D-Bus framework of our LiMo platform, application first talks to these framework severs which in mainly for adding a security context field of D-Bus message turn talk to the telephony server. Security controls for those header, setting this field by dbusd message dispatcher, services can be implemented in their daemons. and checking security policy before dispatching based on Different levels of protection can be implemented for the integrity level of a message and its destination process. secure voice call. For example, one policy allows that only Specifically, as each client process (the sender) connects trusted applications can make phone calls, while untrusted dbusd with a dedicated socket, the dispatcher calls application cannot make any phone call, which is the dbus_connection_get_unix_process_id() to case in many feature phones. For another example policy, obtain the pid of the sender, then the security context untrusted applications can make usual phone calls but not of the sender with getpidcon(), and then sets the those of premium services such as payment-per-minute value into the header field. This field is used later when 900 numbers. Different labels can be defined for telephone the message arrives at a destination trusted subject, i.e., numbers or their patterns. In our implementation, we allow to make access control decision of whether the original untrusted applications to call 800 toll-free numbers only. sender of the message can invoke a particular function or Similar design is used in message framework. Figure 3 access an object. shows the workflow for a typical voice call. A client application calls tapi_call_setup() to initialize a phone call with TelCallSetupParams t, which includes 5.3 Securing Phone Services the target phone number and type (voice call, data call, The telephony server provides services to typical phone- or emergency call), and a callback function to handle related functions such as voice call, data network (GSM possible results. The telephony server provides intermediate or UMTS), SIM access, messages (SMS and MMS), and notifications including modem and connection status to GPS. An application calls telephony APIs (TAPI) to access the client. Once the call is established with the modem, services provided by the telephony server, which in turn the telephony server sends the connected indication to connects to the wireless modem of the device to build the TAPI library which in turn notifies the application 11 via the registered callback function about the status of TABLE 4 call (connected or disconnected), and then the application Example Trusted Subjects Specified by Policy handles the processing. We insert a security hook in the Type I trusted subjects all Linux TCB processes and services, telephony server daemon which checks the integrity level dialer, calendar, clock, calculator (security context) of calling client from D-Bus message and Type II trusted subjects browser, email/SMS/MMS clients, me- decides to allow or deny the call request. For simplicity the dia player Type III trusted subjects daemon processes of telephony server, dbusd is ignored in Figure 3. message server, data network connec- As mentioned in Section 4.5, security hooks are inserted tion server, D-Bus, GConf, program in- into the APIs of each trusted daemon subject (Type III). staller and launcher, device status man- ager, contact manager As examples, we list the voice call APIs in telephony Untrusted subjects all applications in /app/usr and server in Table 3. Similar security hooks are inserted to /mnt/mmc control access to SIM data items, such as contacts and PIN, and access to SMS service. Note that by default 5.5 Policy Specification any write-like operation to SIM is denied for all untrusted applications in our policy. We also have introduced new As we do not consider very fine-grained least privilege SELinux permission class telephony and added corre- principle, and our integrity rules classify different subjects sponding permissions, such as call_setup, sms_send, clearly, defining security policy with our design is a much and sim_disablepin, according to individual APIs. easier task than that in traditional SELinux systems. How- Note that for integrity protection we only list create- and ever, it is still desired to define different domains for some write-like functions here. other purposes on a phone. For example, for confidentiality reason, DRM keys are only readable to DRM agent on a mobile phone, although typically other applications or 5.4 Securing Device and System Services services from device manufacturer and network service The system framework in our platform maintains all system provider are trusted by the DRM agent. Therefore we define status such as phone status, device status, memory status for a specific domain for DRM agent and types for DRM key out-of-memory, audio path, and volume status, and provides objects, and corresponding policy rules. Similarly, only Java get/set APIs for accessing them. A status manager (a dae- Virtual Machine (JVM) can access Java related policies and mon) in this framework collects global system status from digital certificates, only gconfd can write configuration other frameworks, such as phone status (busy/idle/standby) resource files, and only package switch manager (PSMAN) from telephony server, power levels from power manager in can write to data network profiles. kernel, and device status from various kernel device drivers. We define four domain attributes to specify high and Although typically every application can get the statuses via low integrity processes: trustedI, trustedII, trustedIII, and get APIs, only trusted applications can set these variables untrusted, for different types trusted subjects and untrusted via set APIs. That is, the status manager is a Type III subjects, respectively. Table 4 list some subjects of each trusted subject. We insert security hooks in corresponding type. The development of policy rules follows two prin- API implementations in the status manager to enforce our ciples: maximally enable permissions between trusted do- integrity protection policy. mains, and minimally enable permissions between trusted GConf is a service to store configuration data for and untrusted domains. Specifically, regular permissions other applications on our evaluation platform and many are enabled between trustedI and trustedIII domains such other Linux-based mobile phone devices including Maemo, as those defined in permission classes of process, socket, OpenMoko, GPE, and ALP. In current implementation of and netlinks. For untrusted domains and objects, by default GConf, any application can read and modify any config- we enable all read-like permissions and disable all write- uration data, and there is no separation among configu- like operations from untrusted domains to trusted side ration data from different applications. Thus, the major (including processes and objects). In most cases, we do not security requirement for GConf is to control access to need to define rules to allow a trusted domain to access an configuration keys from processes of different integrity untrusted domain, except that some basic domain transition levels. Specifically for integrity purpose, we insert security rules are needed to enable the program launcher to invoke hooks into all write operations to the configuration keys untrusted processes from untrusted programs. Note that in of high integrity applications. The hooked GConf APIs are mobile phone devices, trusted domains typically do not similar to those in [20]. However we note that a difference actively read untrusted data except that framework daemons between [20] and our implementation is that [20] leverages accept service requests from untrusted processes, which is the GConf client library to pass security context of a calling reflected by our integrity rules. For trustedII domain, our process to the GConf daemon (gconfd), which is an current policy regards them as same as untrusted domain, “undesirable” solution [20] since the client library can be although they are deployed by device manufacture and bypassed via static linking or malicious implementation. In regarded as trusted subjects on our evaluation platform. our implementation, we leverage the trusted D-Bus daemon We use generalized filesystem labelling mechanism to pass the security context of a process, which is a securer (genfscon) [11] to label both cramfs and ext3 filesys- solution. tems. This saves space in filesystem, while introduces extra 12 footprint in RAM as all file labelling information is loaded server is untrusted process, the shellcode’s phone call is when the kernel boots. However, with our clearly defined denied by the telephony server. trusted and untrusted filesystem partitions and limited num- Bypassing security mechanism A common way to ber of types, we only have less than 20 filesystem labelling circumvent an access control mechanism is to exploit rules, including those for proc, sysfs, selinuxfs, and privileged applications. This implies two methods in our tmpfs. system: exploit trusted processes and hijack their security level to obtain privileged accesses, or exploit trusted service 6 EVALUATION daemons which enforce access control policies. We first implement a code-injection attack with a user installed 6.1 Security Evaluation application (developed by ourselves). This untrusted ap- It is a challenging task to test a security mechanism plication maliciously injects a shellcode to any trusted completely. Instead, we test three types of attacks: typical process with ptrace() and changes the program register attacks towards mobile platform integrity according to our eip (register 15) to the address of injected shellcode. The threat model in Section 2, cross-service attacks, and attacks shellcode is then executed and the malicious process writes towards access control mechanism. As we do not have back the original code and register thus the trusted pro- the source code of existing mobile malware, we mimic cess resumes. The shellcode simply disables the SELinux such attacks with our own implementation on evaluation enforcement in the kernel therefore after this attack any platform and test the effectiveness of our solution. untrusted process can get full privileges of writing to Malicious access to system files and status data Several trusted side. Further, we implement a code-replacement Symbian malware have been found which maliciously attack to Type III trusted subject gconfd, which bypasses install files into system directories and disable application the security hook in database_handle _set() and manager such that applications cannot be launched and the always returns true (allowed) to any access request. Thus device cannot be rebooted. These include Dampig, Fontal, the untrusted process can set new key values to any high Locknut, and Skulls, all of which can be accidentally integrity object such as phone unlock password and data installed by an unintentional user. In our implementation, a network connection profile. We implement similar attack user application can only be installed on untrusted side of to the telephone server by replacing the permission check the filesystem and it cannot write to trusted side, therefore hook function in tapi_call_setup() with a trivial this type of attacks can be easily prevented. WiFi faker [30] one, thus an untrusted process can make phone calls to is another malware which rapidly exhausts the battery of any phone number including premium rate ones. All these a mobile phone. With the power management functions of attacks work as both trusted and untrusted applications DevicePower-Notify() and SetDevicePower() run with the same uid in our evaluation thus untrusted in Symbian system, this malware sets the WiFi radio process can ptrace to trusted process. When our security operating in the highest power mode but shows inactive mechanism is enabled, both attacks failed with denied write status icon in system tray. We simulate this attack using operations (ptrace) from untrusted processes to trusted similar APIs provided by the system framework in our processes. platform. This attack causes the phone to run out of battery in less than one hour even it is not used at all. By controlling that only trusted processes can set the WiFi status, our 6.2 Performance Evaluation implementation prevents this attack successfully. Cross-service attacks With multiple network interfaces Our policy size is less than 20KB including genfscon on a single mobile device, there are multiple network rules for filesystem labelling. Comparing to that in typical connections and services available for mobile applications. desktop Linux distributions such as Fedora Core 6 (which Attackers can exploit from one network interface and get has 1.2MB policy file), our policy footprint is tiny. As afore- unauthorized access to another network service. For exam- mentioned, the small footprint of our security mechanism ple, some existing mobile malware leverage vulnerability in is result from the simple way to identify the borderline Bluetooth stack to infect devices and thus send SMS/MMS between trusted and untrusted domains, and the efficient messages via their wireless interface such as Bluebug [2] way to control their communications. and commwarrior. One cross-service attack prototype is We study the performance of our SELinux-based imple- implemented in Windows CE mobile phone device [34], mentation with microbenchmark to investigate the overhead which compromises a user installed FTP server running for various low-level system operations such as process, with WiFi interface via buffer overflow vulnerability and file, and socket accesses. Our benchmark tests are per- then makes premium-service phone calls via TAPI inter- formed with the LMbench 3 suites [6]. Table 5 shows the face. We simulate this attack with a dummy echo server measurements in microseconds and percentage overhead, which accepts inputs from ethernet via USB. With a simple compared with the NSA SELinux overhead on desktop en- strcpy buffer-over-flow vulnerability, a client can execute vironment [32]. The results show that our security enforce- a shellcode which dials a premium phone number. However, ment has much better performance than the counterpart when our security mechanism is enforced, as the echo technology on PC [32]. 13

TABLE 5 8 RELATED WORK Benchmark Results. Smaller is Better. Information flow-based integrity models have been pro- Benchmark Base SEIP Overhead NSA SELinux (ms) (ms) (%) Overhead (%) posed and implemented in many different systems, in- null I/O 1.89 1.97 4 33 cluding the well-known Biba [18], Clark-Wilson [22], and stat 9.7 11.3 16 28 LOMAC [25]. Biba integrity property restricts that a high open/close 14.1 16.7 18 27 0KB create 42.2 44.9 6 18 integrity process cannot read lower integrity data, execute 0KB delete 28.5 29.5 4 10 lower integrity programs, or obtain lower-integrity data in fork 2182 2230 2 1 any other manner. In practices, there are many cases that exec 7539 7801 3 3 sh 121 130 7 10 a high integrity process needs to read low integrity data or pipe 398.2 421.4 6 12 receive messages from low level integrity processes. LO- AF UNIX 443 449 1 19 MAC supports high integrity process’s reading low integrity UDP 735 771.7 5 15 TCP 1017 1051 3 9 data, while downgrading the process’s integrity level to the TCP connect 1742 1761 1 9 lowest integrity level it has ever read. PRIMA [29], [35] and UMIP [31] dynamically downgrade a process’s integrity level when it reads untrusted data. As a program may need 7 LIMITATIONS to read and write to high integrity data or communicate to Although we have implemented our design in some major high integrity subjects after it reads low integrity data, it services of our evaluation platform including IPC (D-Bus), needs to be re-launched by a privileged subject or user telephony, device status manager, and system configuration to switch to high level. Although these approaches can service, obviously this is not a complete list for a whole achieve a platform’s integrity status, they are not efficient platform. For example, due to lack of source code, we for always-running service daemons on mobile devices. do not have implementation on data network service and Clark-Wilson [22] provides a different view of integrity message service. In general, the framework services of a dependencies, which states that through certain programs mobile phone device can be provided by many different so-called transaction procedures (TP), information can flow vendors, such that a complete implementation so far is not from low integrity objects to high integrity objects. CW- feasible in our prototype. One of our design goals is to ease lite [29], [37] leverages the concept of TP where low the integration of security between functional frameworks. integrity data can flow to high integrity processes via Typically, a framework provider just needs to identify filters such as firewall, authentication processes, or program sensitive functions or APIs that need to be controlled for interfaces. Different from the concept of filter, UMIP [31] integrity purpose, declare a set of corresponding permission uses exceptions to state the situations that require low in- names, and insert a common security hook function into tegrity data to flow to high integrity processes. A significant the API implementations of the service functions, which difference between these and our solution is that, we do not is implemented in a trusted library based on our integrity sanitize low integrity information and increase its integrity rules. We believe this significantly releases the burden of level. Instead, our design allows a trusted process to accept security considerations for system framework developers. low integrity data if it is separated from high integrity One novelty of our integrity protection mechanism is data thus does not affect the behavior of the process. This that a trusted daemon can accept information (i.e., service fits the requirements of framework services which provide request) from low integrity processes. Therefore we require functions to both high and low integrity processes on open that low integrity information cannot affect the behavior mobile platforms. of a trusted daemon. This is viable for many daemons Mulliner et al. [34] develop a labelling mechanism to which are appropriately implemented to separate received distinguish data received from different network interfaces low and high integrity information by inserting security of a mobile device. However, there is no integrity model hooks. However, as a daemon provides interfaces to other behind this mechanism, and this approach does not protect applications, vulnerabilities such as buffer-over-flow can be applications accessing data from multiple interfaces. Also, used by malicious processes to get the high privileges of the monitoring and enforcing points are not complete, the trusted daemon, thus bypassing security enforcement which only include hooks in execve(2), socket(2) and in the daemon as well as the whole system. By defining open(2) system calls, and cannot capture program launching least privileges for the daemon we can reduce the damages via IPC such as D-Bus. when this kind of attacks occurs. However, fundamentally, Android classifies application permissions into four pro- our approach is not to prevent such implementation vulner- tection levels, namely Normal, Dangerous, Signature, and abilities. That is, the high integrity level of a subject does SignatureOrSystem [1], [23]. The first two are available for not mean no vulnerability of its implementation, although general applications, while the last two are only available we put more trust on its provider’s effort to eliminate for applications belonging to those signed by the same vulnerabilities. Overall, SEIP takes a user-space object application provider. Most permissions that can change manager like approach to control interactions between Type a system’s configurations belongs to the last one, which III trusted subjects and the rest, which we believe is a cost- usually only allows Google or trusted party to have. This is effective solution for large legacy codebase. similar to SEIP: sensitive permissions that alter platform in- 14 tegrity are only available to trusted domain. However, SEIP [12] OpenEZX, http://wiki.openezx.org/main page. does not have a complete solution to distinguish permission [13] Pandalab report, http://pandalabs.pandasecurity.com/blogs/images /pandalabs/2008/04/01/quarterly report pandalabs q1 2008.pdf. sets for general third-party applications as Android does, [14] Qtopia phone edition, http://doc.trolltech.com. since SIP focuses on platform integrity protection only. [15] Security in qtopia phones, http://www.linuxjournal.com/article/9896. Shabtai et al. [36] deploy SELinux to confine high- [16] Setools–policy analysis tools for selinux, http://oss.tresys.com/projects/setools. privileged processes on Android devices, such as those [17] The six secrets to mobile computing success, run in root and system uids. The main motivation of this http://news.cnet.com/8301-13579 3-9929210-37.html. confinement is to limit attacking interfaces by exploiting [18] K. J. Biba. Integrity consideration for secure computer system. Technical report, Mitre Corp. Report TR-3153, Bedford, Mass., any vulnerability of these privileged processes; that is, it 1977. tries to offer least privileges to root and system processes. [19] A. Bose and K. Shin. Proactive security for mobile messaging Different from this, SEIP aims to protect system integrity networks. In Proc. of ACM Workshop on Wireless Security, 2006. [20] J. Carter. Using gconf as an example of how to create a userspace by confining risky operations from user downloaded appli- object manager. In Proc. of Security Enhanced Linux Symposium, cation to system resources. Therefore these two approaches 2007. complement each other. [21] J. Cheng, S. Wong, H. Yang, , and S. Lu. Smartsiren: Virus detection and alert for smartphones. In Proc. of ACM Conference on Mobile Systems, Applications, 2007. 9 CONCLUSION [22] D. D. Clark and D. R. Wilson. A comparison of commercial and military computer security policies. Proceedings of the IEEE In this paper we present a simple but yet effective and symposium on security and privacy, 1987. efficient security solution for integrity protection on mo- [23] W. Enck, M. Ongtang, and P. McDaniel. Understanding android security. IEEE Security & Privacy, 7(1), 2009. bile phone devices. Our design captures the major threats [24] W. Enck, P. Traynor, P. McDaniel, and T. L. Porta. Exploiting open from user downloaded or unintentionally installed applica- functionality in sms-capable cellular networks. In Proc. of ACM tions, including codes and data received from Bluetooth, CCS, 2005. [25] T. Fraser. LOMAC: MAC you can live with. In Proc. of Usenix MMS and browser. We propose a set of integrity rules to Annual Technical Conference, 2001. control information flows according to different types of [26] C. Heath. Symbian os platform security, symbian press, 2006. subjects in typical mobile systems. Based on easy ways [27] G. Hu and D. Venugopal. A malware signature extraction and detection method applied to mobile networks. In Proc. of 26th to distinguish trusted and untrusted data and codes, our IEEE International Performance, Computing, and Communications solution enables very simple security policy development. Conference, 2007. We have implemented our design on a LiMo platform and [28] M. Hypponen. State of cell phone malware in 2007, http://www.usenix.org/events/sec07/tech/hypponen.pdf. demonstrated its effectiveness by preventing a set of attacks. [29] T. Jaeger, R. Sailer, and U. Shankar. PRIMA: Policy-reduced The performance study shows that our solution is efficient integrity measurement architecture. In Proc. of ACM SACMAT, 2006. by comparing to the counterpart technology on desktop [30] H. Kim, J. Smith, and K. G. Shin. Detecting energy-greedy anomalies and mobile malware variants. In Proc. of MobiSys, 2008. environments. We plan to port our implementation to other [31] N. Li, Z. Mao, and H. Chen. Usable mandatory integrity protections Linux-based platforms and develop an intuitive tool for for operating systems. In Proc. of IEEE Symposium on Security and policy development. Privacy, 2007. [32] P. Loscocco and S. Smalley. Integrating flexible support for security policies into the linux operating system. In Proceedings of USENIX REFERENCES Annual Technical Conference, pages 29 – 42, June 25-30 2001. [33] T. Lunt, D. Denning, R. Schell, M. Heckman, and M. Shockley. [1] Android, http://code.google.com/android/. The seaview security model. IEEE Transactions on Software [2] Bluebug, http://trifinite.org/trifinite stuff bluebug.html. Engineering, 16(6), 1990. [3] Gpe phone edition, http://gpephone.linuxtogo.org/. [34] C. Mulliner, G. Vigna, D. Dagon, , and W. Lee. Using labeling [4] J2ME CLDC specifications, version 1.0a, to prevent cross-service attacks against smart phones. In Proc. of http://jcp.org/aboutjava/communityprocess/final/jsr030/index.html. Conference on DIMVA, 2006. [5] Limo foundation, https://www.limofoundation.org. [35] D. Muthukumaran, A. Sawani, J. Schiffman, B. M. Jung, and [6] LMbench-tools for performance analysis. T. Jaeger. Measuring integrity on mobile phone systems. In Proc. http://www.bitmover.com/lmbench. of ACM SACMAT, 2008. [7] Maemo, http://www.maemo.org. [36] A. Shabtai, Y. Fledel, and Y. Elovici. Securing android-powered [8] Mcafee mobile security report 2008, http://www.mcafee.com mobile devices using selinux. IEEE Security & Privacy, 8(3), 2010. /us/research/mobile security report 2008.html. [37] U. Shankar, T. Jaeger, and R. Sailer. Toward automated information- [9] Mcafee mobile security report 2009, flow integrity verification for security-critical applications. In Proc. http://www.mcafee.com/us/local content/reports/ of NDSS, 2006. mobile security report 2009.pdf. [38] D. Venugopal, G. Hu, and N. Roman. Intelligent virus detection on [10] Motomagx security, http://ecosystem.motorola.com/get- mobile devices. In Proc. of International Conference on Privacy, inspired/whitepapers/security-whitepaper.pdf. Security and Trust, 2006. [11] NSA Security-Enhanced Linux Example Policy. http://www.nsa.gov/selinux/.