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.