Fine-Grained Access Control for Mobile Platforms

Fine-grained Access Control for Mobile Platforms

Thomas Nyman Department of Computer Science University of Helsinki [email protected].ﬁ

ABSTRACT considerable financial losses with phone plans allowing ac- With the introduction of the smartphone, mobile phones cess with little user intervention to premium numbers and have gone from closed systems with limited capability to mo- services [18]. bile software platforms with rich software ecosystems. The same operating systems are now present in other mobile de- Even though the number of mobile malware samples col- vices as well, such as tablets. The security mechanism of lected by security companies such as F-secure and McAfee such software platforms have, apart from end-user require- has increased dramatically in 2012 compared to previous ments, heavily been influenced by business and legislative years [12, 19], the reasons behind platform security measures requirements. in place in mobile devices are largely related to business and regulatory requirements. Apart from malware, the threat The enormous growth of the smartphone business has spurred model of mobile operating systems also includes malicious interest in research on mobile device security. This paper users attempting to circumvent content protection schemes, explores the security architecture and access control mech- subsidy locks or otherwise tamper with the device. Regula- anisms present in Android, a well established mobile device tors want to ensure secure storage of radio frequency param- platform and compares the approach to Tizen, a up-and- eters and device identifiers usable as theft deterrent, such comping mobile operating systems developed by Intel and as the International Mobile Equipment Identifier (IMEI). Samsung. In addition some research directions in mobile Mobile networks operators want to enforce vendor lock-in, device security are briefly presented. such as in preventing customer who bought subsidized mobile phones from moving to other operators for the duration of their contract. Preventing tampering with the IMEI and 1. INTRODUCTION the International Mobile Subscriber Identifier (IMSI) is es- In 1996 Nokia introduced the Nokia 9000 Communicator, sential in enforcing such subsidy locks [18]. one of the first devices reminiscent of modern smartphones. In addition to phone calls it allowed uses to send and receive In order to meet the business, regulatory and end-user re- faxes, e-mail and SMS messages as well as access the Inter- quirements mobile platform vendors have developed various net. It also featured functions such as an electronic address hardware and platform security measures. Many platforms book, calendar, notepad and perhaps most importantly an have been designed with some kind of permissions based open development environment enabling third party applica- security schemes of varying granularity allowing limited action development [5]. Since then, smartphones have become cess to device capabilities by third-party applications ac- a multi-billion dollar business. According to estimates by cording to the principle of least privilege. A trend in such Strategy Analytics the number of smartphones in use ex- systems seems to be movement towards finer granularity in ceeded 1 billion units in 2012 [7]. permissions and better extendability by third-party developers. The developments of mobile platforms and the increase Modern smartphones are characterized by many of the same in popularity of smartphones has also led to an increased properties as the original Nokia Communicator. They sup- interest in research on mobile device security [18]. port installation of third-party applications, typically have wireless Internet access and also contain private or sensitive This paper explores the security architecture and access con- information such as personal messages, contacts etc. [18]. trol models of two Linux-based operating systems for mobile Recently, the same operating systems present in smartphones devices. A well established system, namely Android, is com- have been adopted to a multitude of different devices, such pared to Tizen, a up-and-coming system targeting various as tablets, netbooks, smart TVs and perhaps, in the near device types. The architecture and access control models future, In-Vehicle Infotainment (IVI) systems as well [24]. of the two systems are described in Section 2. Commonal- ities and differences between the two services are discussed Mobile phones started out as closed systems with limited in more detail in Section 3. Section 4 gives a brief overview functionality. As mobile platforms have been opened up to of the current state of research concerning mobile device se- third-party developers, it’s become increasingly important curity. Section 5 concludes. to protect end users from malicious or malfunctioning software. Apart from privacy issues, which can become a nui- sance, such software can cause direct harm, such as incurring 2. MOBILE SOFTWARE PLATFORMS Content Providers provide persistent local data storage What follows is an overview of the security architecture and and also facilitate sharing data between applications. access control models of Android and Tizen. Both operating Content Providers are accessed through a Uniform Re- systems are Linux-based, which presents a favorable basis for source Identifier (URI) defined by the application own- comparison. Furthermore information on the internals for ing the content provider [8]. both systems is publicly available. Other prominent mobile platforms, such as iOS, Windows Phone 8 and Blackberry, for which information is not as readily available, are outside Application access to system resources is controlled via install- the scope of this paper as are recently introduced operating time permissions. Permissions may be required to invoke systems such as Firefox OS and Ubuntu Phone. methods defined in the Android Application Framework API, access Content Providers and for Inter Process Communi- cation (IPC). Applications can also define permissions of 2.1 Android their own in order to protect access to application compo- Android is an operating system for mobile devices devel- nents [13]. oped by a consortium of technology companies and mobile operators known as the Open Handset Alliance, led by Android applications are distributed as Application Package Google [23]. According to estimates made by research com- Files (APKs). Applications must declare in advance what pany Gartner, Android had a market share of close to 70% permissions they require in a application manifest file, con- of worldwide smartphone sales to end users in the fourth tained within the APK. When an user installs a application quarter of 2012 [14]. Android is also the most targeted plat- the permissions required by that applications are displayed form by malware. According to a report by F-secure, close to the user, who must confirm the permissions in order to to 80% mobile threats targets the Android platform [12]. continue with the installation. The user does not have the option to selectively refuse certain permissions from a par- 2.1.1 Architecture Overview ticular application but can abort the installation [25]. The foundation of the Android platform architecture, shown in Figure 1, is the Linux kernel and a set of device drivers APKs are cryptographically signed with a developer certifi- depending on the devices hardware configuration. At the cate. Applications updates are required to be signed with core of the architecture lies the Android Runtime, consist- the same certificate as the original application [25]. Appli- ing of the Core Libraries and the Dalvik virtual machine, a cations will not receive automatic updates if the the new register based bytecode interpreter optimized for mobile sys- version of the applications declares more permissions than tems. Android also includes C/C++ libraries which provide the old one. In this case the application update must the various functionality to different system components, such confirmed by the user. This has been suggested as an in- as a BSD-derived standard C system library (libc), SQLite- centive to break the principle of least privilege, and declare database and the Webkit rendering engine. The function- unnecessary permissions in order to automatically update in ality of these libraries is exposed to developers through the the future when the extra permissions have become neces- Android Application Framework, which provides an Applica- sary [13]. tion Programming Interface (API) for accessing middleware system services underlying each application [1]. Application Sandbox The kernel enforces process and file level separation between Application Components applications and the Android system through Linux user Android applications are typically written using the Java identifiers (UID) and group identifiers (GUID). Each appli- programming language, where the Java standard library has cation is assigned a unique low-privilege UID, which func- been replaced with the Android Application Framework. tions as the effective UID of the application process and However, applications can also include or consist completely owner of the applications files. Thus, by default, applica- of native code [3]. tions cannot interact with one another or access each others files. As the application sandbox is enforced by the kernel, Android applications consist of four different kind of com- all software above the kernel, including the C/C++ libraries, ponents [8]: application framework and runtime and the application code itself, including native code, is subject to to the process iso- lation [3]. Activities are visible portions of application user inter- faces [8]. Permission Enforcement

Services are software components which run in the back- The Android Application Framework consists of a library ground without interacting directly with the user. Ser- contained within each applications runtime environment and vices provide functionality to other application compo- an API implementation running as part of the system pro- nents through a client-server interface. In order to in- cess(es). The API implementation in the system process voke methods provided by service’s interface, the client is privileged and not subject to any permissions checks, component must first bind to the service [8]. whereas the library is run with the same permission as the application it is attached to. When an application invokes a Broadcast Receivers facilitate messaging between multi- function, part of the public library API, the library invokes ple applications [8]. These are discussed in more detail a Remote Procedure Call (RPC) stub part of the libraries in Section 2.1.2. private interface, which in turn initiates an RPC request Figure 1: The Android architecture [3] to the system process where the appropriate system service Intents handles the requested operation [13]. Applications can specify an Intent to be delivered to a par- To enforce permissions the API implementation in the sys- ticular application component, specified in the Intent itself. tem process calls a permissions validation mechanism when These are called explicit Intents. Apart from the recipi- necessary to make sure the calling application has the re- ent component name Intents can include action, category quired permissions to invoke the operation in question. The and data fields. The action field specifies an operation to framework library in the application process may also re- be performed upon the receipt of the Intent. The category dundantly check the calling applications permissions. How- fields provides additional information about the operation ever, this must not be relied upon, as the calling applica- and the data field specifies the type of data to operate on. tion may utilize Javas reflection mechanism to invoke the If an Intent does not include a recipient component name libraries private RPC stub directly, thus bypassing any per- it is considered implicit. This means that the Intent leaves missions checks in the API method of the library [13]. determining the recipient up to the platform based on the remaining Intent fields. In other words the intent can be Some permissions are enforced by the kernel by using Linux delivered to any application which supports a particular op- groups. Namely applications which are granted the INTER- eration. Implicit Intents are important in that they enable NET, WRITE_EXTERNAL_STORAGE or BLUETOOTH permissions are late runtime binding between applications [8]. assigned to groups which have access to the relevant sockets and files. Thus the framework library which runs within the Intents can be sent between Activity, Service and Broadcast application process and therefore has the same access rights Receiver application components introduced in Section 2.1.1. as the application itself can access the relevant sockets and Intents are used to start and stop Activities, bind to Services files directly, without going through the system process [13]. and notify Broadcast Receivers. Both explicit and implicit It is worth noting that the external storage is shared be- Intents can be used for these purposes, but by default any tween applications and any files that need to the protected component can only receive Intents originating from within from being accessed by other applications should be stored the same application. In order to receive external Intents, on internal storage instead [2]. components must be exported in the application manifest, a configuration file included in the application installation package. A component is considered exported if it has least one Intent filter or the EXPORTED flag in the manifest. Broad- 2.1.2 IPC Mechanism cast Receivers can exceptionally also be exported at run- The Android message passing system is based on self-contained time [8]. messages called Intents. Intents are used both for inter- application and intra-application communication. Addition- Intent Filters ally the operating system can notify applications of certain events by sending Intents. Such notifications can be broad- Intent filters are used to constrain the type of implicit In- cast system-wide [8]. tents that will be delivered to a component. An Intent filter for implicit Intents regardless of if the component is capable of performing an action requested by an Intent. In order to protect exported application components from receiving malicious Intents developers can add permission requirement to the manifest for the entire application of individual components. Broadcast senders can limit to the propagation of broadcasts Intents to Broadcast Receivers having a particular permission [8].

2.1.3 Permission Granularity Android permissions are divided into four levels [8]:

Normal permissions control access to API calls which are not considered harmful, such as changing the home screen background image or cause the device to vi- brate [13]. These permissions are automatically granted to all application [8]. Figure 2: Prompt for selecting preferred application Dangerous permissions control access to API calls which [8] can can be harmful if abused, such as incurring mon- etary costs for the user or expose private information [13]. Dangerous permissions are granted by the can specify action, category and data fields just as an In- device user at applications install time [8]. tent. An implicit Intent can be delivered to the component if the component includes each action, category and data Signature permissions protect functionality which can cause of the Intent in its Intent filter. When multiple applications significant data loss or damage such as resetting the register components accepting same kinds of Intents, the op- system to factory defaults or disable the device. To erating system must determine which component the Intent obtain signature permissions an application must be is actually delivered to. When multiple Activities are eligi- cryptographically signed using the device manufactur- ble to receive an Intent, the operating system will prompt ers certificate. Signature permissions can also be used the user to select a preferred application amongst those el- by developers to restrict access to an application com- igible to receive the Intent as shown in Figure 2, where an ponent to applications by the same developer. In this user wanting to change the background image of the device case the application requesting the permission must be home screen has the option of several possible sources of signed with certificate of the developer that defined the background images to complete the action. When multi- permission [8]. ple Services are eligible to receive an Intent, the operating SignatureOrSystem permissions can be obtained in the system choose one receiver randomly amongst the eligible same way as signature permissions or installing the ap- Services. The process of determining receivers of broadcast plication to a special system directory. Typically such Intents depends on the type of broadcast [8]. applications are pre-installed by the Original Equip- ment Manufacturer (OEM). manufacturer [13]. Broadcasts Broadcast Intents can be normal, sticky or ordered. Nor- The purpose of division of permissions into different groups mal broadcasts are sent to all Broadcast Receivers eligible is to raise the difficulty of obtaining the most destructive per- to receive the Intent at once. Sticky broadcast are simi- missions. Obtaining Normal permissions is trivial. Obtain- lar to normal broadcasts, but are stored by the system and ing Dangerous permissions requires user confirmation during re-broadcast to new eligible Broadcast Receivers when such install. Signature of SignatureOrSystem are the hardest to become available. Ordered broadcasts are delivered each eli- obtain as they require access to the OEM signing certificate gible Broadcast Receiver one at a time, and the propagation or root access to the device normally available only to the of the Broadcast Receiver stops when one of the receivers in OEM [13]. the chain decides to handle the Intent. Broadcast Receivers have the option of specifying a priority level as part of its In order to access the Internet an application needs the Dan- Intent filter, which is used to determine the order of in which gerous INTERNET permission and thus Internet access needs ordered broadcast are delivered to Broadcast Receivers [8]. to be confirmed by the user. The INTERNET permission is coarse grained in that once obtained, the application is Intent Security granted full access to the Internet. It is not possible to restrict Internet access to a particular host or domain [17]. The Intent Filter mechanism by itself does not provide any security, as a sender can specify any action, category or data Read and Write access to system Content Providers, such in an Intent or bypass the Intent Filters entirely by sending as the Contacts Provider are protected by separate permis- an explicit Intent. Furthermore there is no restriction on sions (READ_CONTACTS and WRITE_CONTACTS) in case of the the kind of Intent Filters that can be defined for a compo- Contacts Provider. It is however not possible to restrict read nent, allowing any component to become an eligible receiver or write access to only particular contact fields [17]. Figure 3: The Tizen architecture [4]

Some sensors, such as the Global Positioning System (GPS) Access control enforcement in Tizen is done on two levels. subsystem provide both coarse and ﬁne grained access to Process level containment is based on a kernel level applica- an approximate or more exact location through the AC- tion sandbox. On top of this the WRT Access Control En- CESS_COARSE_LOCATION and ACCESS_FINE_LOCATION permis- gine (ACE) provides ﬁne grained access control of JavaScript sions [17]. APIs [6].

Some Android permissions provide read or update access to The Tizen access control model differs from the one in An- several unrelated properties, such as as the READ_PHONE_STATE droid in that all applications run under the same predefined permission which, amongst other things, allows an autho- non-root UID as do most of the middleware daemons of the rized application to determine if a phone call is currently core services layer. Privilege elevation from non-root user occurring, but also allows the application access to the IMEI to root is not allowed. Access to privileged features is pro- number of the device. Another such example is the vided by service daemons and subject to user space access WRITE_SETTINGS permission which allows an application to control [16]. change several distinct settings on the device, harmless ones such as changing the default notification sounds, but also modify the network settings [17]. Application Sandbox 2.2 Tizen Tizen is an Linux-based open source software platform aimed Application sandboxing on Tizen is based on kernel enforced towards many different kinds of devices such as smartphones, access control through the Simple Mandatory Access Con- tablets, netbooks, IVI systems and smart TVs. One of the trol Kernel (SMACK). SMACK is a Linux Security Module aims with the platform is to provide consistent user experi- (LSM) which provides a simple filesystem label based access ence across these different types of devices. Tizen develop- control enforcement [16]. ment is governed within The Linux Foundation by a Tech- nical Steering Group consisting of Intel and Samsung [24]. A subject in SMACK terminology refers to an active entity attempting to access resources i.e. a Linux task. SMACK recognizes read, write, execute and append accesses. An 2.2.1 Architecture Overview object is a passive entity that is accessed, such as a files, The Linux kernel along with device drivers and a Hardware sockets or tasks. A label identifies the security characteris- Abstraction Layer (HAL) make up the foundation of the Ti- tics of a subject or object in the SMACK context. SMACK zen platform architecture, shown in Figure 3. The middle- defines two types of labels that are stored in extended file ware layer of the architecture consists of a set of core services attributes. Object labels define a SMACK context for filesys- such Multimedia, Telephony and Messaging subsystems. Ti- tem objects. Process labels can be defined for executables zen provides a Web API which consists of HTML5 APIs and and set the SMACK context of a subject when the exe- the Tizen Device API, which provides access to the core ser- cutable is executed [6]. vices. Web applications (widgets) are the primary type of application on the Tizen platform, although native applica- The access control policy enforced by SMACK is defined as tions are also supported through separate APIs as well [22]. a set of rules of the form: The Web RunTime (WRT) which handles web application subject_label object_label access_mode installation and execution is based on the WebKit rendering For example the rule: engine [6]. Album Camera r would grant read access to any object with the label Camera Access Control Model for any subjects with the label Album [6]. Figure 4: Tizen IPC mechanism [16]

In order to support SMACK Tizen, adds a Security Manifest vice, the App Service, determine the actual application to Plugin to the RPM Package Manager which sets SMACK la- launch [21]. bels for files being installed based on a manifest file included in the RPM package. The manifest must at least declare a The App Service exposes general operations, such as view, security domain for an application, which will determine the create, call etc. Each service is described through an op- default SMACK labels for the application and its files. Ad- eration, URI scheme and a MIME type. The App Ser- ditional labels can be defined and assigned to application vice will inquire the Application Information Library (AIL) files in manifest as well [16]. for services matching a particular description. The AIL in turn will query the Application Information Database, which Each widget runs in a separate security domain. A wid- houses information on installed applications and the services get cannot access the files of other applications, systems they provide. The database is maintained by the package files nor communicate other processes such as system service manager which will invoke the AIL to add application in- daemons without proper SMACK rules. SMACK rules are formation at install time. Once the application to be in- configured during install, uninstall or update by the package voked has been determined, either via the App Service or manager, at runtime by a trusted Security Server daemon an explicit launch request, the AUL library will request the and as a result of user confirming feature permissions for a Launch Pad to launch the application, passing along possible widget [6]. launch arguments. The Application Data Exchange (ADE) occurs through a dictionary of storing abstract key-value Tizen also adds SMACK support to Xorg through the X pairs called a bundle. If the calling application does not Access Control Extension (XACE) which allows for isola- specify any launch arguments the Launch Pad can query tion between processing requiring Xorg access. Similary the the Application Information Database through the AIL for D-Bus IPC system has been modified to enforce SMACK the default configuration of the application to be launched. access rules in order to restrict access between application The AUL will then proceed to launch the application passing accessing the message bus. Finally the udev device manager along the bundle of launch arguments. Any results gener- has been modified to create device nodes with SMACK la- ated invoked application is passed back as a bundle to the bels, allowing for instance the device node /dev/camera to invoking application [21]. be created with a Camera label [16]. User Space Access Control 2.2.2 IPC Mechanism When unprivileged applications are accessing system resources Application launch is aided by Application Utility Library through the system services such as the Launch Pad or App (AUL). The AUL consists of a library part of the appli- Service, the actual privileged operation is done by the ser- cation which will send and receive requests for application vice itself, thus kernel enforced access control is insufficient launch and termination. A AUL daemon, better known as and the service must enforce access restrictions regarding the Launch Pad, will handle the requests made by the AUL the calling application. Tizen has two mechanisms for this, library. The AUL enables applications to invoke other appli- Direct IPC and Indirect IPC, illustrated in Figure 4 [16]. cations to perform operations on their behalf. Applications can explicitly invoke a particular application or implicitly With Direct IPC the application will make a service request request a service and let a high level application launch ser- to the service daemon directly through native sockets. The Service in turn will check the SMACK rules for the client 3. DISCUSSION process label through SMACKFS access, a mechanism allowing Even though Android and Tizen have significant architec- userspace application check SMACK permissions [16]. tural differences, they both provide similar sets of features. Both have permission based access control models, allow for With Indirect IPC the unprivileged application will first con- late runtime binding of application invocations, application tact the Security Server daemon through a native socket sandboxing and similar sets of systems services. In regards interface. The Security Server will identify the client and to the application sandbox Android takes a rather unconven- issue it a random security cookie. The client can then use tional approach in using Linux user separation mechanism the issued cookie to contact the appropriate service daemon to enhance process separation. Application sandboxing in through a intermediate process (namely D-Bus). The service Tizen is based on the SMACK LSM. daemon can verify the permissions of the requesting application by consulting the Security Server, which can identify In regards to permission granularity Tizen has some advan- the client application using the security cookie. The Security tages such as allowing restricting Internet access to certain Server will verify the SMACK rules of the client label on be- domains, compared to the single permission in Android en- half of the service daemon [16]. Without the security cookies abling full Internet access. A study done on popular Android and assistance from the Security Server the service daemon applications by Jeon et.al. suggests that many applications would not be able to identify application permissions on in- access a fairly small number of domains, suggesting that dividual application level and access control would rely on enumerating per-domain permissions is plausible for many the more course grained access to a particular D-Bus inter- applications [17]. Of course it does not makes sense for gen- face. This would open up the service daemon to privilege eral purpose applications such as web browsers or feed read- escalation through a confused deputy attack. ers, but for many applications, such as news media or social network apps, which basically offer alternatives to regular web pages per-domain permissions can be appropriate. 2.2.3 Permission Granularity A subset of the JavaScript APIs on Tizen are considered re- Another advantage with Tizen is the flexibility the WRT stricted. Restricted functions provide access to private data ACE policy mechanism allows, supporting end-user inter- on the device, such as location, contacts calendar etc. In or- vention while still allowing to set more authoritative poli- der to access restricted parts of the API widget developers cies. Similar application hardening schemes have been been need to declare which features the widget wants access to suggested for Android in several research projects [17, 25]. in the widget manifest file. Features are divided into API Groups, such as Time, Calendar, Contact etc. Features per- There clearly is no one-size-fits all solution to defining per- taining to a API group typically allow full, read or write mission granularity. Coarse permissions might lead to over- access. A feature will be granted to a widget by the WRT privilege in applications [17]. Very fine grained permissions based on a Original Equipment Manufacturer (OEM) config- again might increase developer burden, unless the develop- urable WRT ACE policy and user confirmation to a prompt, ment environment provides some sort of automated mecha- the type of which is defined by the policy. Example prompts nism for determining the sufficient application permissions. displayed to the user are shown in Figure 5. Users can affect the policy only in a restricted way through preference configuration. The possible prompt types are [6]: 4. RELATED WORK Several research projects have extended the Android security model. Research has focused on four major directions: Blanket Prompt which prompts the user to confirm ac- static and dynamic application analysis, security enhance- cess to feature once, the first time the feature is ac- ments based on modifying parts of the Android system, vir- cessed by the widget. Once confirmed user is not tualization and application hardening [25]. In this section prompted on subsequent accesses. some approaches are briefly presented.

Session Prompt which prompts the user to confirm access to feature once per session. Static and Dynamic Analysis Static and Dynamic analysis has been used to detect mal- One-Shot Prompt which prompts the users to confirm ac- ware or software vulnerabilities in Android applications. A cess to feature each time it is accessed. drawback of static analysis is limitations regarding Java reflection, whereas dynamic analysis can add runtime over- Permit which always permits access to the feature, without head and adversely affect application performance [25]. prompting the user. Enck et al. have developed ded, a decompiler for Dalvik byte- Deny which always denies to the feature. code and performed a study of Android application security by performing static analysis of popular applications [11].

By default widgets are denied all network access. In or- Felt et al. have used dynamic analysis to build a permis- der to access network resources the widget manifest must sion map that correlates Android permissions requirement declare which protocols, domains and sub-domains the wid- to Android Framework API calls. Based on the map they get wishes to access. Widgets can also request full network have also developed StowAway, a static analysis tool which access [6]. detects overprivilege in Android applications. [13]. Figure 5: Tizen prompt types [6]

Chin et al. have developed ComDroid, a tool that performs itself, allowing in principle for more widespread deployment static analysis of Android Applications in order to detect compared to approaches discussed in Section 4. A drawback vulnerabilities related the Android IPC model. Such may of application repackaging is that it interferes with the pack- arise when implicit Intents are used for intra-application age signatures. This can be mitigated by re-signing packages communication or application components are inadvertently by the same author using the same self-signed certificate [25]. exported [8]. Xu et al. have developed Aurasium, an application harden- Operating System Modification ing tool which supports fine-grained access control features such as IP blacklisting and intercepting service access at- Numerous research projects have modified the Android oper- tempts allowing users to selectively confirm or deny access ating system to provide enhanced security and privacy con- to individual resources [25]. trols. Unless adopted by upstream developers such modi- fications face considerable challenges hindering widespread Jeon et al. have developed Mr. Hide, a fine-grained permis- adoption. A major challenge is that Android plagued by sion enforcement service and Dr. Android, a tool for modify- platform fragmentation due to several different operating ing existing Android applications to support Mr. Hide. The systems versions with differing API versions being in use a fine-grained permissions provided by Mr. Hide include re- multitude of different hardware configurations [25]. stricting Internet access to specific URLs and restricting access to individual columns of contacts Content Provider [17]. Enck et al. have developed TaintDroid, a system capable of tracking the flow of privacy sensitive data on Android 5. CONCLUSION and identified privacy leaks in popular third-party Android This paper has given an overview of the security architecture applications [10]. and access control mechanism of the Android and Tizen mobile platforms. Both systems provide similar functionality, Hornyack et al. have developed AppFence, system which such as application sandboxing, late runtime binding of ap- protects user privacy by substitutes shadow data in place plication invocations and permission based access restriction of private information and hinders private data from being of system APIs. The more recent Tizen provides improve- transmitted from the device [15]. ments in access policy configurability for device manufac- tures, finer-grained permissions such as per-domain network Dietz et al. have developed Quire, a system intended to access restrictions and application feature control for end guard against confused deputy attacks by adding mecha- users. Similar enhancements have been developed for an- nism to Android which allows applications to operate with droid by several research projects. In addition some research reduced permissions. Quire also adds a signature scheme directions mobile device security have been briefly discussed. which allows application to create signatures verifiable by other applications on the device [9].

Nauman et al. have developed Apex, a policy enforcement framework which modiﬁes Android to allow users to selectively grant permissions to applications [20].

Application Hardening In a fairly recent development systems which modify and repackage android applications, adding monitoring and policy enforcement code which enables more fine-grained access control policies compared to the default Android permissions. An advantage with these types of approaches is that they don’t require any modification to the operating system 6. REFERENCES and communications security, CCS ’11, pages 627–638, [1] Android App Framework. http:// New York, NY, USA, 2011. ACM. developer.android.com/about/versions/index.html. [14] Gartner. Gartner Says Worldwide Mobile Phone Sales Retrieved 22.02.2013. Declined 1.7 Percent in 2012. [2] Android Developers: Saving Files. http://www.gartner.com/newsroom/id/2335616, Feb. http://developer.android.com/training/basics/ 2013. Retrieved 25.02.2013. data-storage/files.html. Retrieved 8.3.2013. [15] P. Hornyack, S. Han, J. Jung, S. Schechter, and [3] Android Security Overview. http: D. Wetherall. These aren’t the droids you’re looking //source.android.com/tech/security/index.html. for: retrofitting android to protect data from Retrived 28.02.2023. imperious applications. In Proceedings of the 18th [4] Architecture of Tizen. https://developer.tizen.org/ ACM conference on Computer and communications help/topic/org.tizen.gettingstarted/html/tizen_ security, CCS ’11, pages 639–652, New York, NY, overview/tizen_architecture.htm. Retrieved USA, 2011. ACM. 27.02.2013. [16] B. Im and R. Ware. Tizen Security Overview. http: [5] Nokia Unveils World’s First All-In-One Communicator //download.tizen.org/misc/media/conference2012/ For The Americas. http://press.nokia.com/1996/09/ tuesday/ballroom-c/2012-05-08-1600-1640-tizen_ 19/nokia-unveils-worlds-first-all-in-one- security_framework_overview.pdf, may 2012. Tizen communicator-for-the-americas/, September 1996. Developer Conference. Retrieved 05.02.2012. [17] J. Jeon, K. K. Micinski, J. A. Vaughan, A. Fogel, [6] O. Aciicmez and A. Blaich. Understanding the N. Reddy, J. S. Foster, and T. Millstein. Dr. android permissions and access control model for tizen and mr. hide: fine-grained permissions in android application sandboxing. http://download.tizen.org/ applications. In Proceedings of the second ACM misc/media/conference2012/wednesday/seacliff/ workshop on Security and privacy in smartphones and 2012-05-09-0945-1025-understanding_the_ mobile devices, SPSM ’12, pages 3–14, New York, NY, permission_and_access_control_model_for_tizen_ USA, 2012. ACM. application_sandboxing.pdf, may 2012. Tizen [18] K. Kostiainen, E. Reshetova, J.-E. Ekberg, and Developer Conference. N. Asokan. Old, new, borrowed, blue –: a perspective [7] S. Analytics. Worldwide Smartphone Population Tops on the evolution of mobile platform security 1 Billion in Q3 2012. architectures. In Proceedings of the first ACM http://blogs.strategyanalytics.com/WDS/post/ conference on Data and application security and 2012/10/17/Worldwide-Smartphone-Population- privacy, CODASPY ’11, pages 13–24, New York, NY, Tops-1-Billion-in-Q3-2012.aspx, oct 2012. USA, 2011. ACM. Retrieved 05.02.2012. [19] M. Labs. McAfee Threat Reports: Fourth Quarter [8] E. Chin, A. P. Felt, K. Greenwood, and D. Wagner. 2012, jan 2013. Analyzing inter-application communication in android. [20] M. Nauman, S. Khan, and X. Zhang. Apex: extending In Proceedings of the 9th international conference on android permission model and enforcement with Mobile systems, applications, and services, MobiSys user-defined runtime constraints. In Proceedings of the ’11, pages 239–252, New York, NY, USA, 2011. ACM. 5th ACM Symposium on Information, Computer and [9] M. Dietz, S. Shekhar, Y. Pisetsky, A. Shu, and D. S. Communications Security, ASIACCS ’10, pages Wallach. Quire: lightweight provenance for smart 328–332, New York, NY, USA, 2010. ACM. phone operating systems. In Proceedings of the 20th [21] Y. Park and J. Lee. An Overview of the Tizen USENIX conference on Security, SEC’11, pages 23–23, Application Framework. http://download.tizen.org/ Berkeley, CA, USA, 2011. USENIX Association. misc/media/conference2012/wednesday/ballroom- [10] W. Enck, P. Gilbert, B.-G. Chun, L. P. Cox, J. Jung, b/2012-05-09_0900-0940-an_overview_of_the_ P. McDaniel, and A. N. Sheth. Taintdroid: an tizen_application_framework.pdf, may 2012. Tizen information-flow tracking system for realtime privacy Developer Conference. monitoring on smartphones. In Proceedings of the 9th [22] S. Saxena and V. Kwon. Tizen Architecture. USENIX conference on Operating systems design and http://download.tizen.org/misc/media/ implementation, OSDI’10, pages 1–6, Berkeley, CA, conference2012/tuesday/ballroom-a/2012-05-08_ USA, 2010. USENIX Association. 1330-1410-tizen_architecture.pdf, may 2012. [11] W. Enck, D. Octeau, P. McDaniel, and S. Chaudhuri. Tizen Developer Conference. A study of android application security. In Proceedings [23] S. Tarkoma and E. Lagerspetz. Arching over the of the 20th USENIX conference on Security, SEC’11, mobile computing chasm: Platforms and runtimes. pages 21–21, Berkeley, CA, USA, 2011. USENIX Computer, 44(4):22–28, Apr. 2011. Association. [24] The Linux Foundation. http:// [12] F-Secure. Mobile Thread Report Q4 2012. www.linuxfoundation.org/collaborate/labs/tizen. http://www.f-secure.com/static/doc/labs_global/ Retrieved 28.02.2013. Research/Mobile\%20Threat\%20Report\%20Q4\% [25] R. Xu, H. Sa¨ıdi, and R. Anderson. Aurasium: 202012.pdf, jan 2013. practical policy enforcement for android applications. [13] A. P. Felt, E. Chin, S. Hanna, D. Song, and In Proceedings of the 21st USENIX conference on D. Wagner. Android permissions demystified. In Security symposium, Security’12, pages 27–41, Proceedings of the 18th ACM conference on Computer Berkeley, CA, USA, 2012. USENIX Association.