Ccs10-Som-A Methodology for Empirical Analysis of Permission-based Security Models and Its Application to Android


of 12
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
A Methodology for Empirical Analysis of Permission-Based Security Models and its Application to Android David Barrera H. Güne¸ s Kayacık P.C. van Oorschot Anil Somayaji School of Computer Science, Carleton University Ottawa, ON, Canada ABSTRACT Permission-based security models provide controlled ac- cess to various system resources. The expressiveness of the permission set plays an importa
  A Methodology for Empirical Analysis ofPermission-Based Security Modelsand its Application to Android David Barreradbarrera@ccsl.carleton.caH. Güne¸s Kayacıkkayacik@ccsl.carleton.caP.C. van Oorschotpaulv@scs.carleton.caAnil School of Computer Science, Carleton UniversityOttawa, ON, Canada ABSTRACT Permission-based security models provide controlled ac-cess to various system resources. The expressiveness of the permission set plays an important role in providing theright level of granularity in access control. In this work,we present a methodology for the empirical analysis of permission-based security models which makes novel useof the Self-Organizing Map (SOM) algorithm of Kohonen(2001). While the proposed methodology may be appli-cable to a wide range of architectures, we analyze 1,100 Android applications as a case study. Our methodologyis of independent interest for visualization of permission-basedsystemsbeyondourpresentAndroid-specificempiri-cal analysis. We offer some discussion identifying potentialpoints of improvement for the Android permission model,attempting to increase expressiveness where needed with-out increasing the total number of permissions or overallcomplexity. Categories and Subject Descriptors I.2.6 [  Artificial Intelligence ]: Learning— Connectionismand neural nets ; D.4.6 [ Operating Systems ]: Securityand Protection—  Access Controls General Terms Security, Experimentation Keywords  Access control, self-organizing maps, permission-based se-curity, smartphone operating systems, visualization This is the authors’ version of the work. It is posted here by permission of the ACM for your personal use. Not for redistribution. The definitive ver-sion was published in ACM CCS’10, October 4–8, 2010, Chicago, Illinois,USA.Copyright 2010 ACM 978-1-4503-0244-9/10/10 ...$10.00. 1. INTRODUCTION  Access control lists (ACLs) and permission-based secu-rity models allow administrators and operating systemsto restrict actions on specific resources. In practice, de-signing and configuring ACLs (particularly those with alarge number of configuration parameters) is a compli-cated task. More specifically, reaching a balance betweenthe detailed expressiveness of permissions and the usabil-ity of the system is not trivial, especially when a systemwill be used by novices and experts alike.One of the main problems with ACLs and permissionmodels in general is that they are typically not designed bythe users who will ultimately use the system, but rather bydevelopers or administrators who may not always forseeall possible use cases. While some argue that the prob-lem with these permission-based systems is that they arenot designed with usability in mind [11], we believe thatin addition to the usability concerns, there is not a clearunderstanding of how these systems are used in practice,leading security experts to blindly attempt to make thembetter without knowing where to start.While there are many widely deployed systems whichuse permissions (some are discussed in Section 2.2), wefocus on the empirical analysis of the permission model in-cluded in Android OS [1]. Android is a newcomer to thesmartphone industry and in just a few years of existencehas managed to obtain significant media attention, marketshare, and developer base. Android uses ACLs extensivelyto mediate inter-process communication (IPC) and to con-trol access to special functionality on the device (e.g., GPSreceiver, text messages, vibrator, etc.). Android develop-ers must request permission to use these special featuresin a standard format which is parsed at install time. TheOS is then responsible for allowing or denying use of spe-cific resources at run time. The permission model usedin Android has many advantages and can be effective inpreventing malware while also informing users what ap-plications are capable of doing once installed.The main objectives of our empirical analysis are: (1) toinvestigate how the permission-based system in Androidis used in practice (e.g., whether the design expectationsmeet the real-world usage characteristics) and (2) to iden-  tify the strengths and limitations of the current implemen-tation. We believe such analysis can reveal interestingusage patterns, particularly when the permission-basedsystem is being used by a wide spectrum of users with varying degrees of expertise. As of July 2010, there areover 80,000 applications available for Android [2], manyof which are free and written by both large software de- velopment companies and hobbyists. Also, the AndroidMarket is not controlled as tightly as other mobile appli-cation stores [5]. This implies the applications may exhibitmore variety in terms of requested permissions along withother behavioral characteristics which might not occur ina closed environment. Contributions. Our main contribution is a novelmethodology for exploring and empirically analyzingpermission-based models. In this paper, we employ ourmethodology for the analysis of 1,100 applications writ-ten for the Android OS. Using the Self-Organizing Map(SOM) algorithm [16], we identify trends in how devel-opers of these applications use the Android permissionsmodel. We find that while Android has a large numberof permissions restricting access to advanced functionalityon devices, only a small number of these permissions areactively used by developers. Our analysis identifies per-missions that are overly broad (i.e., controlling access to alarge set of features). Furthermore we identify applicationclusters based on requested permissions, and extract theprominent permissions within each cluster. Our empiricalobservations provide a basis for possible enhancements tothe Android permission model.The remainder of this paper is structured as follows.Section 2 presents background on permission-based se-curity architectures, provides examples of some currentlydeployed permission-based systems and discusses relatedwork. Section 3 describes the Android operating systemand its novel permission model. The dataset used in ourcase study is also covered in this section. In Section 4we discuss our methodology based on the Self-OrganizingMap algorithm. Section 5 covers the results of our analysisand discusses the generated visualizations. Section 6 sum-marizes key findings and suggests points for improvementin Android. We conclude in Section 7. 2. BACKGROUND  Access control systems have existed for a long time [17].In its basic form, a security system based on access con-trol lists allows a subject  to perform an action (e.g., read,write, run) on an object  (e.g., a file) only if the subject  has been assigned the necessary permissions. Permis-sions are usually defined ahead of time by an administra-tor or the object’s owner. Basic file system permissions onPOSIX-compliant systems [12] are the traditional exampleof ACL-based security since objects – in this case, files –can be read, written or executed either by the owner of the file, users in the same group as the owner, and/or ev-eryone else. More sophisticated ACL-based systems allowthe specification of a complex policy to control more pa-rameters of how an object can be accessed.We use the term permission-based security  to refer to asubset of ACL-based systems in which the action doesn’tchange (i.e., there is only one possible action to allow ordeny on an object). This would be similar to having multi-ple ACLs per object, where each ACL only restricts accessto one action. We note that reducing the allowable ac-tions to one does not necessarily make the system easierto understand or configure. For example, in the Androidpermission model, developers implement finer level gran-ularity by defining separate permissions for read and writeactions. This implies that, compared to general ACLs, thepermission hierarchy is flat and has limited sense of group-ing. 2.1 Permission-Based Security Examples  An example of a permission-based security model isGoogle’s Android OS for mobile devices. Android requiresthat developers declare in a manifest a list of permissionswhich the user must accept prior to installing an applica-tion. Android uses this permission model to restrict accessto advanced or dangerous functionality on the device [14].The user decides whether or not to allow an application tobe installed based on the list of permissions included bythe developer. We describe the Android security architec-ture in detail in Section 3.Similar to Android OS, the Google Chrome web browseruses a permission-based architecture in its extension sys-tem [4]. Extension developers create a manifest wherespecific functionality (e.g., reading bookmarks, openingtabs, contacting specific domains) required by the exten-sion can be requested. The manifest is read at extensioninstall time to better inform the user of what the extensionis capable of doing, and reduce the privileges that exten-sions are given [10]. In contrast, Firefox extensions, whichdo not have this permission architecture, run all extensioncode with the same OS-level privileges as the browser it-self. A third example of a currently deployed permission-based architecture is the Blackberry platform from Re-search In Motion (RIM). Blackberry applications written in Java must be cryptographically signed in order to gain ac-cess to advanced functionality (known as Blackberry APIswith controlled access) such as reading phone logs, mak-ing phone calls or modifying system settings [3]. TheBlackberry OS enforces through signature validation thatan application has been granted permissions to access thecontrolled APIs. 2.2 Related Work Enck et al. [13] describe the design and implementationof a framework to detect potentially malicious applicationsbased on permissions requested by Android applications.The framework reads the declared permissions of an appli-cation at install time and compares it against a set of rulesdeemed to represent dangerous behaviour. For example,an application that requests access to reading phone state,record audio from the microphone, and access to the Inter-net could send recorded phone conversations to a remotelocation. The framework enables applications that don’tdeclare (known) dangerous permission combinations to beinstalled automatically, and defers the authorization to in-stall applications that do to the user.  Ontang et al. [18] present a fine-grained access con-trol policy infrastructure for protecting applications. Theirproposal extends the current Android permission modelby allowing permission statements to express more detail.For example, rather than simply allowing an application tosend IPC messages to another based on permission labels,context can be added to specify requirements for config-urations or software versions. The authors highlight thatthere are real-world use cases for a more complex policylanguage, particularlybecauseuntrustedthird-partyappli-cations frequently interact on Android.On the topic of analysis of permission-based architec-tures, Barth et al. [10] analyzed 25 browser extensions forFirefox and identified that 78% are given more privilegesthan necessary, increasing the attack surface on thesefeature-enhancing add-ons. The analysis lead the authorsto the design of a permission-based system for browser ex-tensions in Google Chrome. The system controls access tobookmarks, tabs, and domains available to a particular ex-tension. Investigating the usability of permission-based ar-chitectures, Reeder et al. [19] developed a framework fordisplaying and editing file permissions on a Windows oper-ating system. They employed a matrix-based visualizationcalled expandable grid, which provides a conceptual visu-alization of file permissions in a graphical format. Theiruser studies showed this grid visualization allows users tocomplete tasks quickly and more accurately.Bearing similarities to our work, but not in methodol-ogy or application, Smetters et al. [20] conducted a studyofpermission-basedarchitectures, particularlyaccesscon-trol lists for document sharing within an organization. Var-ious data mining techniques were utilized to understandhow employees used access control lists. Smetters et al.argued that to find the appropriate balance between con-trol and complexity in a permission-based architecture, itis important to determine what level of control users needby analyzing how users interact with the architecture inpractice. In this paper, we analyze the real world use of  Android permissions through an empirical analysis. 3. ANDROID PERMISSION MODEL We review the Android operating system and itspermission-based security model. We also discuss thedataset used for our analysis and highlight some initial ob-servations made prior to applying our data mining method-ology. 3.1 Android  Android is middleware for mobile devices that is built ontop of Linux. Currently mainly deployed on smartphones,the Android platform is quickly gaining market share anddue to its open source nature, has been ported to otherdevices such as laptops, tablets and ebook readers. An-droid has a strong focus on security and attempts to ad-dress some of the shortcomings of other mobile operatingsystems. Android applications are written in Java syntaxand each run in a custom virtual machine known as Dalvik,a light-weight replacement for the standard Java VirtualMachine. The effect of running each application inside a virtual machine is extensive process isolation which in atleast one instance [6] has prevented an exploit in an ap-plication to also impact other parts of the OS. Isolation isfurther enforced by each application being installed as itsown user and group ID [14]. Applications written for Android can be distributed toend users directly through a developer’s web site, orthrough the on-device application store known as the An-droid Market. The Android Market offers a central loca-tion where developers can submit their applications and,with minimal interaction from Google, reach end user de- vices. This differs from the Apple iTunes App Store whereall applications must pass through a vetting process [5](performed by Apple in a closed manner) before reachingconsumers. Android Market applications are not alwaysinspected upon submission, allowing malicious applicationdevelopers to quickly get their applications onto end userdevices. With this security concern in mind, Android hasbeen designed to isolate third party applications from eachother, as well as to protect the operating system and usersfrom malicious applications. 3.2 Android Permissions  At the core of the Android security security model isa permission-based system that by default denies accessto features or functionality that could negatively impactthe user experience, the system, or other applications in-stalled on the device. Examples of these features are send-ingmessagesormakingphonecalls, whichmayincurmon-etary cost to the user; keeping the device screen on or ac-cessing the vibrator, which could result in battery drain;and reading the user’s address book which could result inprivacy violations.To make use of the restricted functionality (which couldpotentially be dangerous if used in combination with otherfeatures, or in a different way than intended by the An-droid OS designers), Android requires application devel-opers to declare which of the restricted features are in-tended to be used by their application. Failure to declarea particular permission will result in the related systemcall or inter-process communication being denied 1 by An-droid. There are currently 110 items of functionality whichare identified as requiring an explicit permission in orderfor Android to grant access [8]. These permissions controlaccess to network and GPS functions, personal informa-tion, system hardware and settings, and many other de- vice features. However, Android is designed such that anythird party application can define new functionality (e.g.,through an API) and make that specific functionality avail-able to other applications based on developer-defined  per-missions. In the case of developer-defined (also known as self-defined  ) permissions, Android enforces that both thecaller and callee applications have matching permissions(i.e., the callee defined the permissions using the permis- sion tag in its manifest, and the caller requested the per-missions using uses-permission ) to allow the IPC to takeplace.Every application (including system applications such asthephoneorcalendarapplications)writtenfortheAndroid 1 The actual interaction is mediated by IBinder which is aLinux Kernel module.  platform must include an XML-formatted file named An- droidManifest.xml  . This essential part of the Android se-curity model contains (along with other metadata such asminimum OS version requirements) the permission dec-larations that the application is requesting access to [7].Permissions are declared in the manifest using the uses-  permission tag followed by a common namespace (usually android.permission.* for Google defined permissions,and expressed in this paper as a.p.* ). Self-declared per-missions which other applications can request are labeledwith the permission tag. The Android manifest containsentries which can be automatically generated by the de- veloper environment but some fields, specifically those re-lated to permission declarations, must be manually en-tered. Manual permission declaration can lead to appli-cation developers over-declaring or erroneously declaringpermissions that don’t exist, as explained in Section 3.4Permissions are enforced by Android at runtime, butmust be accepted by the user at install time. When usersinstall a new application in Android (regardless of how theapplication was obtained), they are prompted to accept ordeny the permissions requested by the application. Per-missions are also described in a more user friendly lan-guage at install time. These descriptions attempt to givea brief, technical explanation of the permission, but do notdisclose what the developer intends to use access to thoseresources for. 3.3 Dataset The dataset used for our empirical study consists of 1,100 applications, the top 2 50 free applications down-loaded in December 2009 from each of the 22 categoriesin the Android Market. In the Market, Google makes a dis-tinction between applications and games. Both of thesemain categories are further subdivided: the games cate-gory into 4 sub-categories (Brain and Puzzle, Arcade and Action, Cards and Casino, and Casual); the applicationsinto 18 sub-categories (Comics, Communication, Enter-tainment, Finance, Health, Lifestyle, Multimedia, Newsand Weather, Productivity, Reference, Shopping, Social,Sports, Themes, Tools, Travel, Demo, and Software li-braries). Applications in our dataset were obtained in standardZIP or ZIP-compatible Android Packages (APK). For eachapplication, we used the Android Asset Packaging Tool toextract the manifest and read all XML entries of type uses-  permission (i.e., permissions that are being requested, notnewly defined). Each application is then represented asa bit vector x = [ x 1 ,x 2 ,...,x j ] T  ∈ { 0 , 1 } j , in which x j de-noteswhetherthepermission  j isrequested. Representingapplications this way allows us to employ Self-OrganizingMaps (SOM) for our analysis and enables us to utilize asuitable distance metric to express similarities betweenapplications.Table 1 lists each of the 22 categories in the AndroidMarket and provides an aggregate count of all the uniquepermission labels requested by each application in a given 2 Top applications on the Android Market are believed tobe ranked by Google using a combination of number of downloads and aggregate user rating of the application. Type Category Permissions Avg. Perms.  App.Comics 9 0.98Communication 62 6.72Demo 16 1.46Entertainment 21 2.86Finance 21 1.84Health 15 1.50Libraries 40 1.36Lifestyle 45 3.42Multimedia 34 3.60News 22 3.62Productivity 52 3.98Reference 21 2.20Shopping 35 4.08Social 37 4.52Sports 17 2.20Themes 1 0.02Tools 49 3.88Travel 40 3.74Games Arcade 7 1.74Casino 15 2.30Casual 14 2.00Puzzle 10 1.60 Table 1: Total number of permissions requested for each of the 22 categories in the Android Market. category (i.e., if 5 applications in a category requested ac-cess to system configuration, it is only counted once). Thefourthcolumnpresentstheaveragenumberofpermissionsrequested by applications in each category. The Communi-cation category is by far the most diverse, with 62 permis-sions requested. This category also had the highest num-ber of permissions per application, with one application(Handcent SMS) requesting 22 different permissions. TheThemes category was the least diverse containing 49 ap-plications which requested no additional permissions andone which requested access to the Internet.Our dataset includes 119 distinct permission requests,out of which 38 (31.93%) were to self-defined permissions,and the remainder were to Android permissions in the android.permission.* namespace. Figure 1 shows thedistribution of the requested permissions, in which the y -axis denotes the number of applications that request thepermission and the x -axis denotes the permission index.Permissions are ordered according to the their requestcounts. The a.p.INTERNET permission (indexed as 1) wasrequested by 686 applications (62.36% of all applications). a.p.RECEIVE_BOOT_COMPLETED (indexed as 10), which en-ables an application to start at system boot, was requestedby 63 applications (5.72% of the total). The distribution of permissions in Figure 1 demonstrates that the frequencyof permission requests decays rapidly, and there is a longtail of permissions that are only requested by one or twoapplications in the dataset. Dataset Limitations. Our dataset contains applica-tions from a large number of developers in a broad range
Related Search
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks