Attribute-based Permission Model for Android Smartphones

Attribute-based Permission Model for Android Smartphones
Abdulrahman A. Muthana#1
, Abdulraqeb I. Al-Samei*2
#
Faculty of Computer Science and Information Systems
Thamar University, Yemen
1ab.muthana@smartsecurity-y.com
*
Computer Networks, Faculty of Computing & Information Technology
University of Science & Technology, Yemen
2abdu.alsamee@gmail.com
Abstract- The dependence of users on smartphones to accomplish their daily works is growing increasingly.
Every day many mobile applications are downloaded and installed by the users to perform different desirable
tasks for them. Before it can be installed in the smartphone, the mobile application requests from the user
granting some sort of permissions, which may include the access right to users’ sensitive resources. In absence of
a security mechanism that can enforce fine-grained permission control, the application may abuse the granted
permissions and thus violates the security of sensitive resources. This paper proposes an attribute-based
permission model ABP for Android smartphones to control how the mobile application can exercise the granted
permissions. The finer granularity of the permission language used by ABP model ensures that the mobile
application cannot violate the user’s security. By using ABP model, the users can enjoy the useful tasks the
mobile applications provide while protecting sensitive resources from unauthorized use.
Keywords: android smartphone; attribute-based permission; fine-grained permission; mobile application;
I. INTRODUCTION
Modern mobile systems such as Android and iOS implement permission-based access control model to
protect sensitive resources from unauthorized use. In this model, the accesses to protected resources
without granted permissions would be denied by the permission enforcement system. Ideally, the Android
permission model should prevent malicious applications from abusing sensitive resources. However, due to
some features of the Android ecosystem, malicious entities could easily abuse permissions, leading to the
explosion of Android malware and the numerous reported application vulnerabilities in the past few years
[1].
Given this problem, a number of extensions have been proposed to refine the Android permission model.
Dr. Android and Mr. Hide framework [2] provides fine-grained semantics for serval permissions by adding
a mediation layer. SEAndroid [3] hardens the permission enforcement system by introducing SELinux
extensions to the Android middleware. FlaskDroid [4] extends the scope of current permission system by
regulating resource accesses in Linux kernel and Android framework together within a unified policy
language. Context aware permission models [5], [6] are proposed to support different permission policies
according to external contexts, such as location, time of the day. However, these works still could not
address the two limitations described above. There are also some work dedicated to reducing the risk of
inter-application communication [6], [4] or to isolate untrusted components inside an application [7], [8].
However, none could achieve unified and flexible control according to the system-wide application context.
In this paper we present an attribute-based permission model ABP to protect personal data and sensitive
resources in Android platform. The finer granularity of the permission language used by model ABP
ensures that the mobile application cannot violate the user’s security.
International Journal of Computer Science and Information Security (IJCSIS),
Vol. 16, No. 3, March 2018
189 https://sites.google.com/site/ijcsis/
ISSN 1947-5500

The remainder of this paper is organized as follows: section 2 describes security model in android
platform focusing mainly on permissions. A summary of related work is given in section 3. Section 4 and 5
present the proposed attribute-based permission model and its security analysis and section 6 concludes.
II. ANDROID SECURITY MODEL
Security of smartphones is extensively affected by user behavior, as every potentially dangerous
application requires permissions when being installed. Malicious software usually requires inadequate set
of permissions according to its purpose. If users paid a proper attention to these permissions, the risk of
threats to their devices would be minimized. However, according to many studies, only around 20% of
users pay attention to permissions when installing applications to their smartphones [9]. In other words, the
applications that are installed form Android store may compromise personal security, user, and mobile
privacy by misusing sensitive information such as documents, SMS, e-mails, contact list, calling
services, location (GPS) network /data, camera, and battery [10].
Android enforces permission-based mechanisms to provide a fine-grained access control to system
resources and third-party applications. Specifically, sensitive system APIs are protected by system
permissions, and third-party applications can make use of these APIs by first requesting the corresponding
permissions in its manifest file. At the beginning of installation process, all requested permissions are
presented to the user. If the user agrees to complete the installation, all those requested permissions are to
be granted. Applications may also define and enforce their own permissions, which is called custom
permissions. All custom permissions can specify one of the four protection levels: normal, dangerous,
signature, signatureOrSystem. The custom permissions, as well as system permissions, can be used to
protect third-party applications. An application can specify a certain permission that client applications
must have for interaction, by setting the android permission attribute of the application element (for all
components) or of a component in the manifest file. It is also possible for an application to check caller’s
permissions during runtime, which is embedded in its source code.
For accessing sensitive resources, however, users should grant the requested permissions to applications.
These permissions are of two types in Android: signature and system permissions, which both sound
privileged services, content providers, and regular permissions which are all available to all applications
such as Android Manifest file (Android-Manifest.xml). Whenever the application tries to access a
privileged system resource, the Android framework requires permission management system PMS to check
the state of application of whether it has the necessary permission to do so or not [11].
As the capability-based security model found in the Android operating system proves to fall short at
protecting the users' privacy, the need arises to find another solution for this problem to make users free and
have control over their personal data. This problem evokes the researcher to think deeply for the sake of
addressing this problem. In fact, a number of studies have never covered this part of inquiry due to the
copious interests in other critical areas ignoring the most important tenets in the current technologies
devices such as android systems as will show later.
Vol. 16, No. 3, March 2018
ISSN 1947-5500

III. RELATED WORK
Several security researches have discussed permission-based systems [1, 2, 5, 11, 12, 13, 16, 20, 21, 22,
23, 24, 29, 32, 33] and on Android security [9, 14-19, 25-28, 31] and the permission model of Android has
been well described in [21]. Here we introduce some most relevant related works.
The authors in [20] investigated Android OS system to find how the permission methods are
implemented. To this end, they analyzed around 1100 Android-based applications. The analysis results,
showed that the applications have excessive usage of permissions that negatively impact users. The
researchers suggested development access control model to control the usage of permission.
Stowaway, [21] developed a tool "Stowaway" to help in checking permissions files and the source code
of the application to reveal the application that has API calls on the source-code, which was not specified in
the Androidmanifest.xml file. According to the study results, 35% of the applications used unnecessary
permissions. Additionally, the study analyzed the causes behind why the applications behave this way and
investigated suspicious behaviors, unnecessary permission usage and method calls.
In [22], the researchers investigated the popular and the more used permissions, and how many of these
permissions were actually used by application and how they affected the users. To this end, researchers
analyzed 10,000 applications by using data mining techniques. According to the research analysis results,
40% of applications used unnecessary permissions and the permissions that are more popular were misused
more. Although the researchers provide a deep analysis of Android applications, but the researchers don’t
provide any solution for the problem that they referred to.
The authors in [2] Dr. Android and Mr. Hide framework provides fine-grained semantics for several
permissions by adding a mediation layer to protect security and privacy issues in the Android systems. The
research was conducted on only 19 applications from various categories. According to the results of study,
the system rebuilt the amended applications successfully. However, Mr. Hide causes an extra 10-50%
overhead on the android OS, and it takes around one minute to rebuild the application. It causes overload,
in addition to that the modified application runs slower than their original ones. Furthermore, the proposed
system wasn’t released to the public that makes it unusable.
Like the other studies [23] developed a software that analyzed permissions of the android-based
applications and generates risk signals accordingly. The study analyzed only 121 malicious apps and
150,000 harmless apps during the generation of the risk signals. The research only conducted on 26
permissions out of 122 Android permissions, which are high critical. However, the results of the study
limited on the calculation of the risk scores according to specific data that were in hand.
FineDroid [1] is used for providing a fine-grained permission system. It covers both intra-inter-
application in addition to systematizing the context sensitive permission rules. TaintDroid [16] is used for
detaining information flows on Android smartphones because it is assumed that all applications installed by
users cannot be trusted. However, the study doesn’t consider control flows and is limited to flow of data
Vol. 16, No. 3, March 2018
ISSN 1947-5500

tracking. Moreover, it notifies the user when discovered an illegal data flows, but it doesn’t enforce
permissions to prevent that. PasDroid [24] is a real-time security scheme based on TaintDroid which is
used for informing users about the state of permissions of whether they should be allowed or not.
The authors in [5] developed a tool "CRePE" on Android OS to enable/disable functionalities "objects"
and enforce fine-grained policies of security taking into consideration both time and location features.
There are interception and enforcement for the policies when starting the activities by CRePE. Policies in
CRePE are composed of propositional conditions concerning the allowance and denying of actions.
As shown by this state of the art, a solution that provides a fine-grained access control mechanism is
required. Module proposed in this work is an authentication language that can serve as a policy for a fine-
grained access control to protect personal data in android operating system.
IV. THE SOLUTION
To protect the security of sensitive resources in Android smartphones against unauthorized access, it is
required to control how the mobile application makes an access to these resources. To meet these
requirements, our solution provides an attribute-based permission model ABP for a fine-grained permission
enforcement in Android smartphones.
Permissions := <Permission-Object> [, <Permissions>] | <Permission-Object>
Permission-Object := {<Action>, <App>, <Permission>, <Object>, <Context>}
Action := grant | deny
Figure 1. Permission language
The permission language is a declarative language to express the rules for handling permission requests
in a context-sensitive manner. Fig.1 shows the general structure of our permission language while the
details of permission rules are given in Appendix A. Basically, the language specifies the action <Action>
to perform when an application <App> requests a permission <Permission> under the application context
of <Context>. To ease the expression of permissions, each language rule is structured in JSON format, with
the following main keys:
• Action key. It is the key for specifying a policy action. Tow values are required to designate the
action value (grant or deny) when the user grant or revoke the permission <Permission> to/from an
application <App>.
• App key. It describes the subject or applications, which user grant or revoke the permission
<Permission> to/from. Package name can also be used as the identity of the application.
• Permission key. It describes permission information for a single application participated.
• Object key. It describes the object name, which user grant or revoke the permission <Permission>
on.
• Context key. It describes the constrictions on application through running in the calling context.
Vol. 16, No. 3, March 2018
ISSN 1947-5500

The Android platform has a wide range of permissions that provide access to different kinds of resources
and objects. However, the current Android security model cannot provide the required fine-grained
permission control. For example, an application can be granted a permission to the whole SD-Card, while
to perform its task it needs only to access some files on the SD-Card. This way, a malicious mobile
application can abuse such permission and make unauthorized access to SD-Card content. To protect
against unauthorized access to sensitive resources like SD-Card, the application should be given only a
permission to files that are necessary for its functionality, which complies with the least privilege security
principle.
The policy that Android security model follows when granting permissions to an application to access
the resources is “Everything or Nothing”. Meaning that, when it is granted a permission to an object the
application can make access to the whole object even if it is not necessary as mentioned in the above
example. This policy can lead to security issues as the mobile application can abuse the granted
permissions. The solution consists in improving Android permission control model to ensure a finer control
over mobile applications and ensure that least privilege security principle is always maintained.
This paper suggests an improvement of Android permission model by introducing an-attribute-based
permission concept where more attributes for the resources objects to be accessed are considered and the
granted permission can be parametrized by the object attribute(s) or part(s) granted to the requester
application. The permission parameterizing ensures a fine-grained permission control enforcement. It
worthy to note that, attribute-based concept is not applied to all objects. Only certain objects are refined,
which represent the most important resource objects in Android smartphone. The object refinement results
in two types of permissions: Multi-Attributes Objects and Single-Attribute Objects. Table 1 shows the types of
resource objects.
TABLE 1
Types of Objects in Android Permission Control Model
Multi-Attributes Objects Single-Attribute Objects
SD_Card Phone_address Credential PACKAGE_SIZE
SMS Phone_call STATUS_BAR BATTERY_STATS
PHONE Sites_Zone Tasks KEYGUARD
Wi-Fi / Network Internet STICKY Alarm
Bluetooth Site BOOT_COMPLETED WAP_Push
Camera System_settings MOCK_LOCATION TIME_ZONE
Microphone Downloads BACKGROUD_PROCESSES WALLPAPER
Contact_List Accounts ANIMATION_SCALE APN_SETTINGS
Social_Information System_tools PERSISTENT_PROCESSES FILESYSTEMS
Calendar USB HISTORY_BOOKMARKS NFC
Location SYNC User_Dictionary SIP
Social_Stream Lock
A. Multi-Attributes Objects
This type contains 22 Android resource objects. In this type, granting access to the whole object without
specifying the object’s attribute for which access is granted may lead to compromise of personal security
and exposure sensitive resources to dangers. This type includes objects like documents, SMS, e-mails,
contact list, calling services, location (Global Positioning System GPS), network/data, camera, and battery
[10]. By restricting the permission scope, a finer-grained permission control could be achieved and results
Vol. 16, No. 3, March 2018
ISSN 1947-5500

in better security. Finally, it is up to the user to decide whether the permission can be granted to the whole
object or to some attributes of the object. The user may grant an access to the whole object if he decides
that the application may need to. To make permission granting process more flexible, the presented
permission language supports using the wild card character “*”. The use of * indicates that permission on
the while object is granted to the application.
B. Single-Attribute Objects
This type contains 24 Android resource objects that do not fit into the first type, either because they
already are sufficiently fine-grained or because they would not benefit from finer granularity. For
example, RECEIVE BOOT_COMPLETED has only one purpose that does not seem useful to subdivide,
and while KILL BACKGROUND_PROCESSES could potentially be fragmented (e.g., by restricting the
processes that could be killed), doing so seems unlikely to add much practical security.
V. SECURITY ANALYSIS
As the number of Android-based smartphones increases, more data are used by these devices. Due to the
enormous amount of personal data on these devices, they pose a threat and present an inviting environment
within which cyber criminals can attack. To defeat attacks, we propose a fine-grained permission language
that can serve as a policy for fine-grained permission enforcement. The key idea is to include more
resource object attributes and minimize the object surface exposure to attack. The object surface is the
part/attribute of the object that is granted to the application. For each permission request a detailed
permission rule including attributes or parts of the resource object is constructed when suitable and make
granting decisions based on this permission language. Since the permission enforcement system could keep
the access rights to the sensitive resource objects at the minimum, it can mitigate the impact of any security
breach that caused by a malicious mobile application. In the following, we discuss some scenarios that
demonstrate where Android permission control model pitfalls and demonstrate how our permission
language can protect sensitive resource objects.
A. SD Card Permission
The SD Card READ permission in Android permission control model allows an application to read the
whole content of SD Card, so any application may read the other applications data. Our fine-grained
permission language parameterizes the permission (Fig. 2) with the folder(s) that can be accessed by the
application and thus minimizing the surface exposure to attack.
Sd_Card := Files | Folders | *
Files : = File | File [ , Files]
File : = FileName
Folders := Folder | Folder [ , Folders ]
Folder : = FolderName
Figure 2. SD Card permission
B. INTERNET Permission
The Internet access “Wi-Fi/Network” permission in Android permission control model allows an
application to access Internet indiscriminately. However, the application may contact malicious websites,
Vol. 16, No. 3, March 2018
ISSN 1947-5500

and thus breaching the security of user’s privacy or leaking sensitive data. It is wise to request the
application to specify the Internet domain(s) or website(s) that it will communicate with to perform its
tasks, so the user made be aware of such website(s). Our fine-grained permission language parameterizes
the permission (Fig. 3) with the website(s) that can be communicated by the application and thus
minimizing the surface exposure to attack.
Wi-Fi / Network : = Wi-Fi / network_connectivity | Wi-Fi/ network _connectivity | Full_network | Sites_Zone | *
Sites_Zone : = Internet | Local intranet | Trusted_sites | Restricted_sites
Internet : = Site | Internet
Site : = Location | URI | IP
Figure 3. Wi-Fi/Network permission
C. SMS Permission
The SMS access “SMS” permission in Android permission control model allows an application to access
SMS service for send/receive or read/write permissions. whenever it is granted sending SMS messages, the
application may send SMS to specific mobile numbers that are intended for advertisements and provided
with the applications and thus consuming the user’s credit without his knowledge. It would better for the
user if he knows the destination mobile numbers distained by the application before granting SMS
permission to the application. Our fine-grained permission language parameterizes the permission (Fig. 4)
with the mobile number(s) that can be distained by the application and thus protecting the user against such
attacks.
SMS := SMS-TYPE to Contacts | *
SMS-TYPE : = SMS | MMS
Contacts : = Local | International | *
Local := +967 Contact_List [, Local] | *
International : = + Number Contact_List [,International]
Contact_List := Number | Numbers
Numbers : = Number | Number [ , Numbers ]
Number := 0|1|2|3|4|5|6|7|8|9
Figure 4. SMS permission
6. CONCLUSION
This paper presents an attribute-based permission model for fine-grained permission enforcement in
Android smartphones. By using the proposed permission model, mobile applications cannot breach the
security of the sensitive resources. The fine-grained permission rules provide the users with a flexible
method to control the access to their sensitive resources and ensure that unauthorized access to sensitive
resources will not occur.
APPENDIX A. PERMISSION LANGUAGE
The main result of this appendix is the rules of fine-grained permission language to protect sensitive
resources from unauthorized use in Android mobile system.
Permissions := <Permission-Object> [, <Permissions>] | <Permission-Object>
Vol. 16, No. 3, March 2018
ISSN 1947-5500

Permission-Object := {<Action>, <App>, <Permission>, <Object>, <Context>}
Action := grant | deny
Object := SD_Card | Phone_address | SMS | Phone_call | PHONE | Sites_Zone | Wi-Fi / Network | internet |
Bluetooth | Site | Camera | SYNC | USB | Calendar | System_settings | Microphone | Downloads |
Contact_List | Accounts | Social_Information | System_tools | Location
Permission = read | open | send | receive | pair | write | call | connect | edit | view | modify | close | access | active | take |
install | uninstall | draw | allow | add | locate | remove | measure | record | get | create | subscribed_feeds|
authenticate | manage | set | process | find | google | admin | use | wake | reorder | disable | expand | format |
mount | unmount | broadcast| change | control
admin := [discover, Requst_pair, Replay_pair, unpaired, accept_connection, visible, invisible, enable, disable, change]
control := [ send, receive, show_files]
Sd_Card := Files | Folders | *
Files : = File | File [ , Files]
File : = filename
Folders := Folder | Folder [ , Folders ]
Folder : = foldername
SMS := SMS-TYPE to Contacts | *
SMS-TYPE : = SMS | MMS
Contacts : = Local | International | *
Local := +967 Contact_List [, Local] | *
International : = + Number Contact_List [,International]
Contact_List := Number | Numbers
Number := 0|1|2|3|4|5|6|7|8|9
Phone := phone_status | phone_identity | phone_address | call_log | SIP
outgoning_call | voicemail | None | * | device_ID | phone_call |
phone_address := Contact_list | Non_Contact_list | Number | Numbers | *
Phone_call := call_phone | call_Emergency | call_Privileged | *
Wi-Fi / Network : = Wi-Fi / network_connectivity | Wi-Fi/ network _connectivity | Full_network | Sites_Zone | *
Sites_Zone : = Internet | Local intranet | Trusted_sites | Restricted_sites
Internet : = Site | Internet
Site : = Location | URI | IP
Bluetooth := Bluetooth _settings | Bluetooth_ Data | audio_channel | Internet_access | Paired_list | Non_ Paired_list | *
Camera := Pictures | Videos | *
Pictures : = Picture | Picture [ , Pictures ]
Videos : = Video | Video [ , Videos ]
Microphone := Audios | *
Audios : = Audio_settings | Audio | Audio [ , Audios]
Identify the applications that used Camera / Microphone to Record:
Camera / Microphone := Videos | Audios | Video_Audio | None | *
Social_Informations := Contacts | call_log
Contact_List := Full | Non_ Contact_List | Number | numbers | *
Calendar := Calendar_Date | Event _settings | Calendar_settings
Location := Fine_location | Coarse_location | None | *
Accounts := account | Google_accounts | accounts_password |
Vol. 16, No. 3, March 2018
ISSN 1947-5500

Google_Service_Configure | Local_accounts | accounts_settings | accounts_data | *
System_tools := Shortcut | System_settings | Home_setting | App_Storage_Space | Tool [ , Tools ]
System_settings := Volume_Control_Widgets | notification_Widgets | GPS_Utilities | settings_Widgets | Wi-Fi_Utilities |
System_setting |
System_setting [ , System_settings ]
USB := USB_settings
Downloads := Content_URI | Location |
SYSC := SYSC _settings | SYSC _stats |
JSON Format for permission:
{ "app" : "com.masdroidapp","action" : "allow", "permission" : ["receive "," send"], "object" : " WAP_Push ",
"context" : "None", "comment" : "None"}
{ "app" : "com.masdroidapp", "action" : "allow", "permission" : ["read "," write "] , "object" : "
history_bookmarks",
{ "app" : "com.masdroidapp", "action" : "allow", "permission" : "use" , "object" : " credential", "context" :
"None", "comment" : "None"}
{ "app" : "com.masdroidapp", "action" : "allow", "permission" : " set " , "object" : " alarm ", "context" :
{ "app" : "com.masdroidapp", "action" : "allow", "permission" : [" get " ," reorder "], "object" : " task",
{ "app" : "com.masdroidapp", "action" : "allow", "permission" : "wake " , "object" : " Lock ", "context" :
{ "app" : "com.masdroidapp", "action" : "allow", "permission" : " receive" , "object" : " Boot_Completed ",
{ "app" : "com.masdroidapp", "action" : "allow", "permission" : " get " , "object" : " package_size",
{ "app" : "com.masdroidapp", "action" : "allow", "permission" : " access " , "object" : " mock_location ",
{ "app" : "com.masdroidapp", "action" : "allow", "permission" : " set" , "object" : " time_Zone ", "context" :
{ "app" : "com.masdroidapp", "action" : "allow", "permission" : " set" , "object" : " time_Zone ", "context" :
{ "app" : "com.masdroidapp", "action" : "allow", "permission" : " disable " , "object" : " KeyGuard ",
{ "app" : "com.masdroidapp", "action" : "allow", "permission" : " expand " , "object" : " status_bar",
REFERENCES
[1] Zhang, Y., Yang, M., Gu, G., & Chen, H. (2016). Rethinking Permission Enforcement Mechanism on Mobile Systems. IEEE
Transactions on Information Forensics and Security, 11(10), 2227-2240.
[2] Jeon, J., Micinski, K. K., Vaughan, J. A., Fogel, A., Reddy, N., Foster, J. S., & Millstein, T. (2012). Dr. Android and Mr. Hide:
fine-grained permissions in android applications. Paper presented at the Proceedings of the second ACM workshop on Security
and privacy in smartphones and mobile devices.
[3] Smalley, S., & Craig, R. (2013). Security Enhanced (SE) Android: Bringing Flexible MAC to Android. Paper presented at the
NDSS.
[4] Bugiel, S., Heuser, S., & Sadeghi, A.-R. (2013). Flexible and Fine-grained Mandatory Access Control on Android for Diverse
Security and Privacy Policies. Paper presented at the USENIX Security Symposium.
[5] Conti, M., Nguyen, V. T. N., & Crispo, B. (2010a). CRePE: Context-related policy enforcement for Android. Paper presented at
the International Conference on Information Security.
[6] Ongtang, M., McLaughlin, S., Enck, W., & McDaniel, P. (2012). Semantically rich application‐centric security in Android.
Security and Communication Networks, 5(6), 658-673.
[7] Shekhar, S., Dietz, M., & Wallach, D. S. (2012). AdSplit: Separating Smartphone Advertising from Applications. Paper
presented at the USENIX Security Symposium.
[8] Wang, Y., Hariharan, S., Zhao, C., Liu, J., & Du, W. (2014). Compac: Enforce component-level access control in Android.
Paper presented at the Proceedings of the 4th ACM Conference on Data and Application Security and Privacy.
[9] Burguera, I., Zurutuza, U., & Nadjm-Tehrani, S. (2011). Crowdroid: behavior-based malware detection system for android.
Paper presented at the Proceedings of the 1st ACM workshop on Security and privacy in smartphones and mobile devices.
[10] Yuksel, A. S., Zaim, A. H., & Aydin, M. A. (2014). A Comprehensive Analysis of Android Security and Proposed Solutions.
International Journal of Computer Network and Information Security, 6(12), 9.
Vol. 16, No. 3, March 2018
ISSN 1947-5500

[11] Au, K. W. Y., Zhou, Y. F., Huang, Z., & Lie, D. (2012). Pscout: analyzing the android permission specification. Paper presented
at the Proceedings of the 2012 ACM conference on Computer and communications security.
[12] Felt, A. P., Greenwood, K., & Wagner, D. (2011). The effectiveness of application permissions. Paper presented at the
Proceedings of the 2nd USENIX conference on Web application development.
[13] Felt, A. P., Wang, H. J., Moshchuk, A., Hanna, S., & Chin, E. (2011). Permission Re-Delegation: Attacks and Defenses. Paper
presented at the USENIX Security Symposium.
[14] Bose, A., Hu, X., Shin, K. G., & Park, T. (2008). Behavioral detection of malware on mobile handsets. Paper presented at the
Proceedings of the 6th international conference on Mobile systems, applications, and services.
[15] Chaudhuri, A. (2009). Language-based security on Android. Paper presented at the Proceedings of the ACM SIGPLAN fourth
workshop on programming languages and analysis for security.
[16] Enck, W., Gilbert, P., Han, S., Tendulkar, V., Chun, B.-G., Cox, L. P., Sheth, A. N. (2014). TaintDroid: an information-flow
tracking system for realtime privacy monitoring on smartphones. ACM Transactions on Computer Systems (TOCS), 32(2), 5.
[17] Enck, W., Octeau, D., McDaniel, P., & Chaudhuri, S. (2011). A Study of Android Application Security. Paper presented at the
USENIX security symposium.
[18] Enck, W., Ongtang, M., & McDaniel, P. (2009). On lightweight mobile phone application certification. Paper presented at the
Proceedings of the 16th ACM conference on Computer and communications security.
[19] Hornyack, P., Han, S., Jung, J., Schechter, S., & Wetherall, D. (2011). These aren't the droids you're looking for: Retrofitting
android to protect data from imperious applications. Paper presented at the Proceedings of the 18th ACM conference on
Computer and communications security.
[20] Barrera, D., Kayacik, H. G., van Oorschot, P. C., & Somayaji, A. (2010). A methodology for empirical analysis of permission-
based security models and its application to android. Paper presented at the Proceedings of the 17th ACM conference on
Computer and communications security.
[21] Felt, A. P., Chin, E., Hanna, S., Song, D., & Wagner, D. (2011). Android permissions demystified. Paper presented at the
Proceedings of the 18th ACM conference on Computer and communications security.
[22] Stevens, R., Ganz, J., Filkov, V., Devanbu, P., & Chen, H. (2013). Asking for (and about) permissions used by Android apps.
Paper presented at the Proceedings of the 10th Working Conference on Mining Software Repositories.
[23] Sarma, B. P., Li, N., Gates, C., Potharaju, R., Nita-Rotaru, C., & Molloy, I. (2012). Android permissions: a perspective
combining risks and benefits. Paper presented at the Proceedings of the 17th ACM symposium on Access Control Models and
Technologies.
[24] Hsiao, S. W., Hung, S. H., Chien, R., & Yeh, C. W. (2014). PasDroid: Real-Time Security Enhancement for Android. Paper
presented at the Innovative Mobile and Internet Services in Ubiquitous Computing (IMIS), 2014 Eighth International
Conference on.
[25] Baláž, A., Madoš, B., & Ambróz, M. (2015). Android Access Control Extension. Acta Informatica Pragensia, 4(3), 310-317.
[26] Bugiel, S., Davi, L., Dmitrienko, A., Fischer, T., Sadeghi, A.-R., & Shastry, B. (2012). Towards Taming Privilege-Escalation
Attacks on Android. Paper presented at the NDSS.
[27] Conti, M., Nguyen, V. T. N., & Crispo, B. (2010b). CRePE: Context-Related Policy Enforcement for Android. Paper presented
at the ISC.
[28] Hoopes, J. (2009). Virtualization for security: including sandboxing, disaster recovery, high availability, forensic analysis, and
honeypotting: Syngress.
[29] Nauman, M., Khan, S., & Zhang, X. (2010). Apex: extending android permission model and enforcement with user-defined
runtime constraints. Paper presented at the Proceedings of the 5th ACM symposium on information, computer and
communications security.
[30] Shan, Z., Wang, X., Chiueh, T.-c., & Meng, X. (2012). Facilitating inter-application interactions for OS-level virtualization.
Paper presented at the ACM SIGPLAN Notices.
[31] Vargas, R. J. G., Huerta, R. G., Anaya, E. A., & Hernandez, A. F. M. (2012). Security controls for Android. Paper presented at
the Computational Aspects of Social Networks (CASoN), 2012 Fourth International Conference on.
[32] Wei, X., Gomez, L., Neamtiu, I., & Faloutsos, M. (2012). Permission evolution in the android ecosystem. Paper presented at the
Proceedings of the 28th Annual Computer Security Applications Conference.
[33] Wu, L., Du, X., & Zhang, H. (2015). An effective access control scheme for preventing permission leak in Android. Paper
presented at the International Conference on Computing, Networking and Communications (ICNC), 2015.
Vol. 16, No. 3, March 2018
ISSN 1947-5500

Attribute-based Permission Model for Android Smartphones

More Related Content

What's hot

Similar to Attribute-based Permission Model for Android Smartphones

Recently uploaded

Attribute-based Permission Model for Android Smartphones