Making Smartphone Application Permissions Meaningful for the Average User Amer Chamseddine and George Candea School of Computer and Communication Sciences École Polytechnique Fédérale de Lausanne (EPFL), Switzerland May 2012 Abstract address book and send the contacts to spammers? Do they track the user’s movements via GPS? Do Smartphones hold important private information, they turn on the phone’s camera/microphone and yet users routinely expose this information to ques- spy on the user? This is serious, because smart- tionable applications written by developers they phones, unlike computers, are always on, network- know nothing about. Users may be tempted to connected, and always with their user. think of smartphones as old-style dumb phones, not Today’s smartphones are powerful computers, as powerful network-connected computers, and this but it is easy for users to think of them as “dumb” opens a gap between the permissions-based secu- phones; the magic by which apps can dynamically rity paradigm (offered by platforms like Android) augment the functionality of this “phone” is not and what users expect. This makes it easy to fool fully understood and is therefore ignored. Cer- users into installing applications that steal their in- tain concepts, such as “app permissions” do not re- formation. Not surprisingly, Android is now a more ally have an equivalent in the world of traditional favored target for hackers than Windows [14]. phones. Discrepancies of this sort create a gap that, We propose an approach for closing this gap, from a security standpoint, invites exploitation. We based on the observation that the current per- aim to bridge this gap by making the concept of app missions system—rooted in good ol’ UNIX-style and app permissions more “natural” to users, thus thinking—is both too coarse and too fine grained, making it easier to understand and manage. because it uses the wrong axes for defining the permissions space. We argue for replacing the We start by looking at Android, both because paradigm in which “an app accesses device re- of its popularity and because we think it has im- sources” (which is foreign to most non-geeks) with portant weaknesses in this context. Android per- aparadigminwhich“anappaccessesuser-tangible missions were conceived to mitigate the threats de- services.” By using a simple piece of middleware, scribed above, by putting the user in control: users we can wrap this view of application control around must explicitly grant the app, at installation time, today’s permission system, and, by doing so, no access to the resources it requires. Unfortunately, conceptual refactoring of applications is required. many Android permissions are too coarse grained, thus leading to a violation of the “least privilege” principle. For example, a weather forecast applica- 1Introduction tion may simply need to download data from a spe- Mobile applications (“apps”) have captured the cific server, but in the current Android Permissions mind and soul of consumers, with much of the com- System a user would have to give this app full Inter- petition in the smartphone arena revolving around net access. Other permissions are too technical for the variety and coolness of apps available on a given average users, like “use SIP service” or “change the device. An average smartphone owner has more Z-order of tasks.” A puzzled user trying to choose than 40 applications installed [1], actively uses 15 of between saying “no” and getting to (install and) use them, and spends more than ten hours a month inter- the app will likely opt for the latter. And, in so do- acting with these applications—more time is spent ing, the user may unwittingly hand over to the app with apps than spent talking on the phone or using control over his/her data. it to browse the Web [13]. Our goal is to eliminate the mismatch between Most users do not know what exactly their in- user expectations and actual app behavior, as per- stalled apps do or have access to. Do they read the tains to user data. We describe a split/merge ap-
1 proach for morphing the Android Permissions Sys- tem into user-meaningful permissions: split proxies on the phone turn permissions that are too coarse into finer ones, and merge proxies combine low- level or too-technical permissions into semantically meaningful ones. Permissions and proxies form a hierarchy, and applications access the top layer of this hierarchy. We envision service providers (such as AdMob, Facebook, or Google Analytics) defin- ing the permissions by writing such proxies and pro- viding them to developers as part of their SDKs. Before describing our approach in more detail, we briefly present the Android Permissions System.
2AndroidPermissions:TheGoodandtheBad Each mainstream smartphone platform has its Figure 1: Installing Android apps: On the left, a weather own security model, with pros and cons. iOS and forecast app requests full access to the Internet (unnecessar- Windows Phone 8 control apps’ behavior largely by ily coarse grained). On the right, a VoIP app requests access to “send sticky broadcast,” “reroute outgoing calls,” etc. (too testing them before admitting them in the respec- technical for an average user). tive app store/marketplace; users trust Apple and Microsoft to do proper checking of the apps. Of UNIX-style users and groups, respectively. When course, full verification of an app is still an open installing a new app, Android creates a new userid challenge, and apps can still misbehave [15]. An- for it, and runs the app as that user. Android main- droid, however, defers the choice for what an app is tains one usergroup for each permission and, if the allowed to do to the end user. We believe the ideal user grants a particular permission at install time, smartphone security model will offer users some the app’s userid is added to the respective usergroup. level of choice, and thus the question of how to for- When the app invokes system services, the ker- mulate and grant permissions will remain pertinent. nel checks whether the app is entitled to make the This makes Android an interesting research target. respective system call or not (e.g., if an app tries to create a network socket but its userid does not 2.1 Android Permissions System: An Overview belong to the “Internet access” usergroup, Android The Android Permissions System [2] allows de- denies the socket creation attempt). Enforcement velopers to specify a list of accesses and permis- is performed in the kernel so that even native code sions their app needs in order to function properly; cannot bypass the permissions system. this list is part of the app’s manifest file. These The benefit of the Android Permissions System is permissions control access to sensitive device APIs, that the operating system promises users that each such as the camera, the microphone, or GPS sensor. app will only be allowed to access the APIs that Which permissions are granted to an app is de- were granted by the user at install time. Further- cided upfront, at app installation time—after instal- more, a user can determine at any time what permis- lation, apps cannot request additional permissions. sions an app has by looking at its list of permissions, When a user installs an app, the operating system which is available post-installation. displays the list of requested permissions (see for 2.2 Shortcomings example Figure 1). Presumably, the user reads the list, makes an informed decision on whether to grant Unfortunately, most users are not prepared to or not the requested permissions, and clicks Install exercise their right to choose, because some An- or Cancel. Installation can only proceed if the user droid permissions can be incomprehensible to them. accepts all requested permissions. These typically relate to device details that are out- Underneath the covers, Android (which runs a side the user’s realm of comprehension (access Sur- modified Linux kernel) enforces its security poli- faceFlinger, broadcast WAP PUSH receipt notifica- cies by mapping applications and permissions onto tions, perform I/O over NFC, etc.). In a recent study,
2 only 17% of users were aware of the requested per- sion proxy takes permissions from a lower layer missions list and, of those, only 3% had some under- and transforms them into a new permission exposed standing of the permissions’ meaning, power, and to the upper layer. We have two types of per- consequences [9]. In our experience, even tech- mission proxies: split proxies that divide permis- nical users make the decision based on intuition sions into finer-grain ones, and merge proxies that rather than careful analysis. This is because, even combine multiple permissions into a semantically when understanding what the permissions are about, higher-level one. reasoning about how a combination of permissions might compromise privacy or security is difficult. 3.1 Proxy-based Permission System At the same time, some Android permissions Proxies are built as thin Android apps that lever- force the violation of the “least privilege” princi- age Android’s flexibility for defining new permis- ple by being too coarse-grained, as illustrated by sions, thus not requiring changes to the OS in most the weather forecast app in Figure 1. Another com- cases. Each proxy X declaring a new permission mon case is when a non-networked app uses a li- P also defines an API corresponding to the use brary/SDK to show ads (e.g., via AdMob) or to of P.Forexample,aswillbedetailedlater,us- collect usage statistics (e.g., via Google Analytics): ing a selective form of HTTP access would re- even though the user knows the app should not re- quire using the SelectiveHttpClient class pro- quire Internet access, the fact that it is ad-supported vided by the corresponding proxy, instead of the forces it to ask for such access. This way, users DefaultHttpClient class. When an app requests are trained to accept that any reasonable app needs permission P,oursystemensuresthattheappuses Internet access. This is problematic, given that al- the API exposed by P,andpreventsitfromcircum- most 25% of today’s free Android apps request ac- venting X to go straight to the APIs used by X.In cess to private user information (location data, de- other words, X interposes hermetically between the mographic information, etc.) claiming it is used for app and the permission(s) underneath X. targeted ads only, but this data ends up being sent to Apps are generally written using various SDKs the app provider’s servers [11, 5, 4]. Careful users (for example, the Google Analytics SDK), and we have little choice too: by being conservative and re- envision such SDKs defining the proxy/proxies they jecting such apps, one is deprived by much of what need. The proxies themselves will typically be writ- makes a smartphone compelling. ten by the provider of the SDK, but it is possible The current Android Permissions System is both for SDKs from different providers to use the same too fine-grained and too coarse-grained at the same proxy/proxies. For example, if Android were to time. This paradoxical situation stems from the per- provide the Domain-Selective Internet Access per- missions being defined along the (in our opinion) mission (described below), advertising companies wrong axes: the permissions system is thought in could build their SDKs using this permission. An terms of apps accessing device resources, and this app then uses the SDK as a library and may well be is a highly OS-centric view of what the smartphone oblivious to the existence of the proxy, because the does. It leaves to the user to extrapolate which SDK itself invokes the proxy-specific API. user-visible services could be accessed via those re- To make proxy distribution efficient, we envision sources, or which user data could be read/written. them being in a special “Proxies” section of the We argue that, instead, the permissions system Play Store, and SDKs ship with metadata describ- should use as primitives those abstractions and ser- ing which proxies they require. When installing an vices that are user-visible, such as ad services, web app using that SDK, if the required proxy(ies) is sites that can be browsed by the user, etc. not already on the device, it gets retrieved and in- stalled. When a new proxy is installed, it requests 3OurApproach:Split/MergeProxies permissions just like Android apps do today, and Our goal is to enable users to more easily map the user can choose to grant them or not. In other permissions to “tangible” services. To make this words, proxies get no special privileges. Split prox- possible, our system is a new layer introduced be- ies, such as the Domain-Selective Internet Access tween the OS and the apps (Figure 2). It consists proxy, could as well be incorporated in Android di- of a hierarchy of permission proxies. A permis- rectly.
3 2 1 A
A Applications The situation is similar when using phone storage, and apps use the SD card in a rather chaotic manner. Many applications create a folder dta cus aap Merge proxies on the root of the SD card and use it to store files, configuration files, or even backup files, with no naming convention at all. Even though newer ga
am Split proxies versions of Android specify standard ways of Location Net. State SD Card Internet Permissions Unlock Bluetooth Microphone Vibrate storing files on the SD card, most applications on
OS Android the Play Store still use their own conventions. The
am: Access to *.admob.com dta: Display targeted ads SD card can contain highly sensitive data, such ga: Access to *.google-analytics.com cus: Collect usage statistics aap: Act as a phone as pictures, videos, recorded conversations, and downloaded files. Just because an application needs Figure 2: Our proposed Split/Merge Permissions Proxy archi- to store files on the SD card does not mean that it tecture. Here, A1 follows the traditional style of Android per- should have full access to the user’s personal files missions, and requests its permissions directly from the OS, or to another application’s files stored on the SD whereas A2 requests the semantically meaningful permissions to collect usage statistics and communicate with its server. card. We use the Selective SD Card Access proxy to split the SD card permission into finer-grained, Compared to today’s permission system, our pro- folder-level access permissions: each app gets posed system requires strictly less trust from the end automatically assigned its own folder, named user, because no new low-level permissions are cre- /sdcard/Android/data/
4 screen and ring the device when a phone call arrives. droid service that other applications can bind to. Once the call is connected, they need the micro- The service interface is defined using the Android phone recording permission (to capture the user’s Interface Definition Language. voice) and the Bluetooth permission (if a wireless Apps using SelectiveHttpClient,instead headset is used). We introduce the Act-as-a-Phone of requesting Full Internet Access, only request merge proxy to combine all these permissions. VoIP the Domain-Selective Internet Access permission. applications (such as CSipSimple, Skype, and oth- SelectiveHttpClient routes all traffic through ers) can now request the Act-as-a-Phone permis- the proxy, which checks that the access requests are sion, instead of requesting a long list of highly tech- being made to the domains approved by the user; if nical permissions. It is also conceivable for a merge yes, the requests are forwarded to the network. proxy to restrict certain aspects of the underlying The Collect-Usage-Statistics proxy is also built permissons, such as only allowing an app that is as a normal Android app that requests a Domain- “acting as a phone” to turn on the microphone in Selective Internet Access permission and the Net- response to an explicit user action. work State Access permission, and exposes a new 3.4 User-Controlled Permission Slicing Collect-Usage-Statistics permission. In our prelim- inary prototype, the Collect-Usage-Statistics proxy In addition to provided proxies, our permission only reports to Google Analytics. The communica- system is also amenable to (expert) users deciding tion between apps and this proxy is done through on the fly to only selectively grant requested per- Android’s standard Intent Messaging API. missions. For example, a legacy app that does not We analyzed many real-world apps (like Face- use our proposed system may request full Internet book, Skype, WhatsApp, etc.) and found that they access, but the user decides to give it access only to all request Full Internet Access permission. 73% of specific domains that are deemed safe. If the appli- the Play Store apps are free, and, of those, 80% are cation never attempts to access any other domains, ad-supported [12]. These applications end up gain- all is OK, and the user is safe. If the application at- ing access to sensitive personal data, such as con- tempts to access other domains, then blocking those tacts and email, GPS location, demographic data, accesses would likely prevent it from functioning— etc, without legitimately needing it [10]. Having instead, our system can prompt the user, much the the Domain-Selective Internet Access permission way a personal firewall would do, and (upon the makes it possible to guard users’ information, with- user’s request) block the connection outright, let it out depriving users of the wide variety of free ap- go through, or fake the connection and pretend that plications or preventing developers from generating the host is unreachable, thereby giving the app a revenue by displaying ads. chance to recover and continue operating. There is one caveat to the Domain-Selective In- ternet Access permission: since Android allows 4PrototypeandEarlyResults apps to modify the device’s DNS server when con- As a first step, we implemented the Domain- nected to a WiFi network, it becomes possible for a Selective Internet Access split proxy and the malicious app to subvert the proxy: if it can enlist Collect-Usage-Statistics merge proxy. the cooperation of a rogue DNS server that supplies Many Android apps, when communicating with afakeIPaddresswhenqueriedforadomain,the app could access servers outside the list that the user their server side, employ the DefaultHttpClient class. We built Domain-Selective Internet Ac- approved. In other words, this proxy is as secure as cess as described earlier, and it provides its DNS itself. This weakness can be fixed by using DNSSEC or disabling the ability of apps to change own implementation of the HttpClient interface, the DNS server configured on the phone. SelectiveHttpClient,whichextendsthesame classes as DefaultHttpClient and offers the Performance. From a performance perspective, same functionality. This class communicates di- going through a proxy normally introduces over- rectly with our Domain-Selective Internet Access head. However, since most of the proxied opera- proxy. The proxy requests Full Internet Access from tions are bottlenecked by the latency of I/O any- the OS and exposes the Domain-Selective Internet way, the measured overhead introduced by our Access permission. The proxy is essentially an An- proxies is not perceivable. To time HTTP inter-
5 actions with and without the proxy, we created 32 5Conclusion DefaultHttpClient objects and used them to is- We presented an approach for turning hard-to- sue 32 POST requests; the average time of the en- understand low-level permissions of smartphone tire interaction (all 32 POSTs) was on the order of apps into ones that are semantically meaningful to 30 ms. In the case of the Domain-Selective Inter- average users. We propose a layer of proxies be- net Access, most of the functionally essential op- tween the OS and apps, which can then merge and erations deal with sockets, and have essentially the split low-level permissions in a way that matches same latency and throughput, with or without the user expectations. The proxies are small, verifiable, proxy. For Selective SD Card Access, the bottle- and require no conceptual refactoring of apps. neck is in the file I/O operations. Since smartphone applications usually have a GUI, they spend most References of their time waiting for user interaction; we expect [1] J. Aimonetti. Nielsen: 1 in 2 own a smartphone, that, even if future proxies introduce some over- average 41 apps. CNET Technology Reviews,May head, it would not be user-perceptible. 2012. http://reviews.cnet.com/8301-19512_7-57435397- 233/nielsen-1-in-2-own-a-smartphone-average-41-apps/. Deployment. We believe our proposed system is [2] Android permissions. http://developer.android.com/guide/ easy to adopt and deploy today. Writing the proxies topics/security/permissions.html. [3] Android permissions reference. http://developer.android. is relatively straightforward and requires little code com/reference/android/Manifest.permission.html. (the Domain-Selective Internet Access proxy has [4] Bit9. Pausing Google Play: More than 100,000 Android less than 500 LOC). Non-malicious apps should not apps may pose security risks. https://www.bit9.com/files/ need to be conceptually refactored in order to use 1/Pausing-Google-Play-October2012.pdf, Oct. 2012. [5] T. Bradley. Study finds 25 percent of android the proposed permission system; at most they may apps to be a security risk. PCWorld,Nov.2012. need to replace the use of some interfaces with those http://www.pcworld.com/article/2013524/study-finds- provided by the proxies. From the developers’ per- 25-percent-of-android-apps-to-be-a-security-risk.html. spective, these changes are worthwhile because they [6] M. Burrows, M. Abadi, and R. Needham. A logic of au- thentication. ACM Transactions on Computer Systems, make apps more trustworthy. Unlike today (when 8(1):18–36, Feb 1990. users are “trained” to trust questionable apps), our [7] C. Cadar, D. Dunbar, and D. R. Engler. KLEE: Unas- proposed system may gradually push users to dis- sisted and automatic generation of high-coverage tests for trust apps that bypass the proxies and request direct complex systems programs. In OSDI,2008. access to low-level resources. [8] V. Chipounov, V. Georgescu, C. Zamfir, and G. Candea. Selective symbolic execution. In HotDep,2009. Manageability. Permission proxies are either part [9] A. P. Felt, E. Ha, S. Egelman, A. Haney, E. Chin, and D. Wagner. Android permissions: User attention, com- of Android or part of SDKs. We can also imagine an prehension, and behavior. In SOUPS,2012. after-market for “better” versions of the same prox- [10] K. J. Higgins. http://www.darkreading.com/mobile- ies; users can then substitute one proxy for another. security/167901113/security/privacy/240012705/more- We estimate that a “power user” of Android smart- than-25-of-android-apps-know-too-much-about- you.html, Nov. 2012. phones will require about a couple dozen permis- [11] B. Levine. Be wary of free Android apps. http://www.sci- sion proxies, which compares well to the set of 130 tech-today.com/story.xhtml?story_id=13200006Q1XO. permissions currently defined by Android [3]. [12] I. Lunden. In mobile apps, free ain’t free, but cambridge university has a plan to fix it. TechCrunch,Mar.2012. Permissions Calculus. As mentioned earlier, it http://techcrunch.com/2012/03/06/in-mobile-apps-free- is difficult for users to reason in their head (even aint-free-but-cambridge-university-has-a-plan-to-fix-it/. when they understand what a set of permissions [13] A. Mindlin. Using phones, but not to talk or surf. The New York Times,Mar.2011. is about) about how a combination of permissions http://www.nytimes.com/2011/03/07/business/me- might compromise privacy or security. Our sys- dia/07drill.html. tem outsources this task to proxy developers who [14] D. Reisinger. Android overtakes Windows as must now think about whether combining permis- top threat. MIT Technology Review, Dec. 2012. http://www.technologyreview.com/view/508316/the- sions does not open up holes. It is of course good to changing-face-of-security-android-overtakes-windows- have this done by trusted proxy developers, but we as-top-threat/. also believe there is an opportunity to employ a for- [15] R. Ritchie. iOS 6 wants: Granular privacy control. iMore, mal approach—we are currently looking into using Feb. 2012. http://www.imore.com/path-apps-accessing- avariantofBANlogic[6]forthis. contacts-inspiration-android.
6