1. Mitigating Privilege-Escalation Attacks on Android
Vinoth Kanna Dr. Henry Larkin
Master of Information Technology Lecturer of Mobile Apps
Deakin University Deakin University
vkolapak@deakin.edu.au henry.larkin@deakin.edu.au

2. SID: 213526276 Page 1
Abstract
Google owned mobile operating system based on Linux kernel is called Android. Android is
low cost, ready-made and easily customisable operating system for mobile devices. The
open source platform allows each and every customer to develop and customise the
applications. This feature makes android one of the most popular and widely used mobile
operating system among the mobile manufactures (Rangwala et al., 2014). Open source
framework also makes way to the security concerns of using android and various
applications associated to it. Recent survey proves that android shows vulnerabilities to
Application-level privileges-escalation attacks. Applications on android operate over the
authorization based framework in which they are provided access to certain privilege when
the application is installed. The open source platform makes the authorization based
framework vulnerable to malicious applications by inducting privilege-escalation based
attacks. Through these attacks an application can implicitly gain access to the non-
authorized privileges tasks without user’s knowledge (Bugiel et al., 2012). In this review we
have investigated the most common approaches used for privilege-escalation attacks. This
review examines the problem of the existing security framework to privilege authorization
policy guidelines. In this review, we inspected the problem of designing and implementing a
practical android policy framework to protect against ICC security flaws. Android framework
permits applications to inter-communicate (IAC) which allows different application to
communicate between them to perform privilege-escalation (Bugiel et al., 2011). The review
will cover how the various researchers overcome this security flaw on android framework
layers and what are the security solutions they are providing. Many papers have been
published related to permission escalation attacks by various scholars. This literature review
will cover a broad spectrum of such theories, this review will generally focus and covers the
android architecture, android policy framework, inter application communication,
permission escalation attacks and security measures to overcome those issues. The
following literature reviews endeavours to show and support the premise of Mitigating
Privilege-Escalation Attacks on Android.
Introduction
Android is one of the most widely used open source mobile operating system. We describe
the security flaws and policy issues in android architecture. Permission escalation attacks is
one of the major android security flaw which is not been addressed by Google Inc. Android
policy framework is not been properly implemented by the application developers and also
the android operating system. Several authors and scholars have proposed different way of
approach and extension to those security flaws in android framework. However not all of
them target privilege extension attacks, some authors propose security extensions to
android framework.
The latest android version and usage model allows the third party applications developers to
create and upload arbitrary application to the app stores. For these concerns of android
security and privacy it deployed a new technique application sandboxing. And also
implemented a reference monitor in the middleware layer to control the inter application

3. SID: 213526276 Page 2
communications. However the reference monitor policy to mediate the communication
between the applications doesn’t provide proper security to android.
Ever since the android is developed various instance of attacks and security of android have
been reported. This shows a growing concern about the android security framework. Among
those attacks particular and importance in this context are the so called permission
escalation attacks which will be the key coverage of this paper.
Whatis PermissionEscalation Attacks?
Permission escalation attacksat application-level.
Android policy and security framework for example implementing application sandboxing
and reference monitor at middleware to monitor permission checks is not adequate to the
direct policy enforcement to counter the permission escalation attacks. (A.P, Felt. (2011)).
Important examples are confused deputy and inter-application collusion attacks. Confused
deputy attack is the scenario in which the application exploits the vulnerable interface to
access the data but initially which haven’t been provide permission by the user to access
those data. It is also said that the application duping itself as another privileged application
to access the data. Collusion attacks are of malicious application developed to collude to
merge their privileges with other applications. Thus they can execute performance beyond
their exclusive privileges. These collusion applications can either communicate directly
through IPC or they can communicate through clandestine or non-clandestine channels in
the android system components. These collusion applications can also perform permission
escalation attacks on kernel level in android framework by evading the middleware layer
reference monitor. Thus we need proper security policy enforcement over both middleware
and kernel layer of android security framework.
Security Extensions:
The security flaws on android over the permission escalation attacks are been examined
over the past few years and various security extensions and policy framework for android
have been proposed by many researchers. Such as Kirin, TaintDroid, Saint, QUIRE are among
them. Although we will discuss these extensions briefly in the later section of this paper.
None of these security extensions provide a reasonable justification about confused deputy
and collision attacks. While all these existing extensions are either insufficient or
predominantly entrust the policy framework to the applications, we discovered that
attempt to avoid collusion attacks through system-centric are responsibility over the
applications. The above mentioned extensions are either incompatible to system-centric
applications or in efficient. Thus we present the design and execution of better secure
android framework towards the confused deputy and collusion attacks. To achieve this we
extend the reference monitor concept from the middleware and introduce it to the kernel
layer. Through which we can monitor the direct IPC call among android applications and also
indirect communication between the system components. Inspired by the QUIRE (Dietz et
al., 2011) we enforce the system-centric link between the IPC calls. Reference monitor will
check the call chains during runtime to identify and protect towards the confused deputy

4. SID: 213526276 Page 3
attacks. We introduce as mentioned above Kernel-level Mandatory Access Control (MAC) to
the system files. This allows the runtime policy mapping of our extension from the
middleware to the kernel layer in android framework.
RelatedWork
(Barrera et al., 2010) in his research (Bugiel et al., 2012), (Marforio, Francillon and Capkun,
2011) and (Chin et al., 2011) targets the main aspects of how the android architecture works
and allows the communication between different applications IAC is been researched and
author also studied the policy framework set by android for the IAC is been analysed with
different third-party applications available in the market. However this research hasn’t
provided any solutions to the attacks nor provides how the third-party applications bypass
android security policy to collude with other applications to perform permission of the
attacks. (Barrera et al., 2010) fundamental commitment is a novel approach for investigating
and experimentally dissecting authorization based models. In this paper, author utilizes his
philosophy for the examination of 1,100 applications composed for the Android OS. Utilizing
the Self-Organizing Map (SOM) calculation, author propose a distinguish patterns in how
developers of these third-party applications utilize the Android consents model. We find
that while Android has countless limiting access to cutting edge usefulness on gadgets, just a
little number of these consents is effectively utilized by designers. Author investigation
recognizes authorizations that are excessively wide (i.e., controlling access to a substantial
arrangement of components). Besides we recognize application groups in light of asked for
authorizations, and concentrate the conspicuous consents inside of every bunch. The
research paper experimental perceptions give a premise to conceivable improvements to
the Android authorization model. Throughout the review of both the research paper we can
clearly understand that there is a security flaw in the present Android OS policy framework.
But it cannot be implemented without the support of android developers.
Security framework in Android architecture is the important section for this particular
research. To get a clear aspect of how important to this permission escalation attacks on
android. (Adrienne et al., 2011)In his research paper author clearly depicts the android
architecture and its security policy implemented to the application, while inter
communicating with each other. According to author the research paper proves that the
current security policy for android permission model fall short to provide trustworthy
framework to tackle permission based escalation attacks. The paper provides a greater
insight to the android communication framework about how different components and
modules communicate.
Security Extensions are one among the many solutions provided by the fellow researchers.
Although there large number of research papers published on behalf of android security
framework. Our main focus will be on security for permission escalation attacks. Among all
those papers which have been reviewed below commonly deploy a different android
security framework to secure android against permission escalation attacks on androids.
(Adrienne et al., 2011) is a security extension works on run-time whereas (Bugiel et al.,
2011a) and (Enck, Ongtang, and McDaniel, 2008) extension works on Installation-time. In

5. SID: 213526276 Page 4
complete contrast to this (Ongtang et al., 2011) proposed extension works on both
installation-time and as well as run-time on android security framework.
(Adrienne et al., 2011) suggest small run-time Android Scripting Environment to be
implemented in android platform. This security extension is called Sand-boxing mechanism.
This mechanism will separate applications from one another and also from main system
security resources. According to author this mechanism will assign a unique ID to each and
every application. Through these ID sandboxed application can have privilege over
information they have provided access by user not through Inter Application
Communication (IAC). However various malicious applications present in the market can
easily bypass this sandbox security extension model, thus making it an unreliable security
extension.
(Bugiel et al., 2011a) proposes a security extension for android security framework called
XManDroid. It is an android security policy framework that amplifies the Android
framework's monitors for real-time and prevention of permission escalation attacks.
XManDroid powerfully screens correspondence between applications through the
augmentation in the reference monitor and confirms them with security policy
characterized in a framework driven approach, in this way, distinguishing any transitive use
of permission. XManDroid can effectively distinguish correspondence connections between
progressively made parts, handle remarkable instances of pending purposes, and forestall
correspondence through clandestine channels between framework segments. It can
recognize all permission escalation attacks those utilizing ICC systems. They propose a
system-centric solution for the application-policy framework. (Bugiel et al.,
2012)configuration concept, a direct heuristic examination of Android's framework conduct
(with prevalent applications) to recognize hacking patterns, characterize diverse other rival
models, and point out the difficulties to be handled. At that point they propose an answer
for a framework driven and approach driven runtime observing of correspondence channels
between applications at numerous layers: 1) at the middleware (Bugiel et al., 2012) control
IPCs in the middle of utilizations and roundabout correspondence by means of Android
framework components.2) at the bit level author understand obligatory access control on
the document framework (counting Unix space attachments) and nearby Internet
attachments.
(Enck, Ongtang, and McDaniel, 2008) covers the wide concept of how the android policy
framework is implemented and followed by application developers. They also discuss in
detail about the policy framework and security flaws in the present framework. In this paper
they also suggest an alternate framework for policy driven system called Kirin. Author
defines the security policy invariants to set the rules and formally analyse the application at
installation and certify them. If the application doesn’t satisfy the policy rules it will not be
installed to the user mobile phone. Kirin policy framework will check the application with its
predefined set of rules such as manifest files at the time of application installation. However
android framework provides the third-party application developers with administrative
access. Thus Kirin is limited to the publicly available knowledge based metadata called
manifest files. Application developers with administrative access can hide the knowledge

6. SID: 213526276 Page 5
based manifest files. Thus detection of malware application is unreliable through Kirin. Kirin
Security policy works only at the install-time and will not allow the application to be
installed if it doesn’t certified by its predefined policy rules. In contrast(Nauman, Khan and
Zhang, 2010) in his paper, have depicted Apex – an expansion to the Android consent
system. Apex permits clients to indicate definite runtime limitations to confine the
utilization of delicate assets by applications. The framework accomplishes this with a
negligible exchange off in the middle of security and execution. The client can determine
their requirements through a basic interface of the augmented Android installer called Poly.
The expansions are fused in the Android structure with a negligible change in the code-base
and the client interface of existing security building design. Though it uses runtime policy
there are lots of limitations to security framework policies. There is another research paper
which (Ongtang et al., 2011) proposes a security policy framework called SAINT provides a
framework policy which can extend at both installation-time and run-time. Saint provides
fine-grained access to the application developers and allows them to attach their own
security policy frameworks to the newly developed application. In particular it imposes
signature based security policy. This process would group each and every application under
their respected signature. Each signature based group will give its own security policies to
certify. However Saint fails to address the third-party application developers, in this case
developers have to implement the security framework policies. If the developers fails to
implement these policies or rather did not considered all the known and unknown security
flaws in the android architecture? In the end Saint does not focus on the malicious
developers, who will not implement the security framework policy proposed by Saint.
Earlier we discussed (Enck, Ongtang, and McDaniel, 2008) proposed Kirin security
framework policy which was installation time security framework on android architecture.
The same Kirin which has lots of limitations with its manifest files. To overcome these
limitations (Enck et al., 2014) again proposed another better security framework tool called
TaintDroid. TaintDroid is a system which distinguishes unapproved outflow of sensitive
information. TaintDroid element analyse information keeping in mind the end goal to search
for the leaked information with a tainted application, review on-track tainted information as
it engenders through the framework, and caution the client if sensitive information expects
to colludes with different framework at a Taint sink (e.g., system interface). TaintDroid has
the capacity to identify information theft attacks conceivably started through a permission
escalation attacks. Then again, TaintDroid fundamentally addresses information streams,
while permission escalation attacks additionally include control streams. (Enck et al., 2014)
said that following the control stream with TaintDroid will probably bring about much higher
execution penalty. Additionally, since TaintDroid just recognizes information leakage, it
would require a far better security framework policy with respect to recognize approved
and malicious information leak.
QUIRE (Dietz et al., 2011) is the android security extension which provides attribution to the
system to avert the confused deputy attacks through the Binder IPC. To monitor the
application API QUIRE tracks and monitors the IPC calls. And provide the permission only if it
can locate the manifest files. Else it denies the permission if it cannot able to locate the
manifest files. QUIRE can extend the RPC calls to the kernel layer when the communication

7. SID: 213526276 Page 6
is going outside the device. QUIRE is also an applications-centric application thus it cannot
prevent the android device from the collusion attacks.
SELinux (Zhai et al., 2013) is one of the best security extensions for the kernel level android
framework. Since it is based on the Linux platform it provides greater reliability and usability
to the Kernel level. But we cannot use this extension to communicate with the kernel and
middleware layer. Middleware layer in part in which most of the communication occurs
using the ICC calls, which are used for the attacks. During our research we understand that
we need an open communication between the middleware and kernel layer. Thus we opted
for the TOMOYO.
AppFence: (Hornyack et al., 2011) is the extension developed upon the framework of
TaintDroid. In which the user has the authority to enable the control mechanism of the
android security framework. AppFence also provide better usability against the permission
changing mechanism from the application API’s. It provides an empty or fake resource when
the application without permission tries to access the data. AppFence provides security
extension only to the data protection over android framework. They don’t provide any
solution to the confused deputy or collusion attacks.
There is been a wide and alarming rate permission escalation attacks occurring on the
Android OS without the knowledge of its users. After reviewing all the above research
papers it is clearly state the research question that the android application can collude with
one another to gain access even if it has been refused by the user (Enck, Ongtang, and
McDaniel, 2008) research stands proof for this. To secure the android framework many
researchers have proposed their own solutions and different security extension.
Android Architecture
In this section we briefly emphasize the android architecture and evoke all its major security
frameworks.
Android is architected as a software stack involving applications, an operating system, run-
time environment, middleware, administrations and libraries. Each and every layer of the
software stack and the android framework components present inside those layers are
combined together and fine-grained to provide the better operating platform for the mobile
device (Techotopia.com, 2015).
LinuxKernel Layer: Situated at the Android's software stacks bottom, the Linux Kernel gives
a level of deliberation between the mobile equipment and the upper layers of the Android
programming stack. Taking into account Linux adaptation 2.6, the part consists of all the
device drivers like phone, settings, camera etc. Kernel performs the networking part of the
android framework. It also provides Hardware Abstraction, Network stack, memory
management and nitration with shared libraries.
Middleware Layer: It includes all the libraries required for the android operating system.
Libraries such as Dalvik Virtual Machine (DVM), Native and JAVA libraries are present in
middleware layer which provides services such as to monitor the application life cycle and

8. SID: 213526276 Page 7
its management. And additional to that it provides Mandatory Application Control (MAC)
system for the communication between the applications. Application Layer: Top of the
android architecture layer consists of application layer in which the core or preinstalled
application and Third-party application are present. Most of the android applications are
developed in coherent with JAVA language. Some may use C/C++ but with JAVA Native
Interface (JNI).
Communication between Android Applications: Binder-based Inter-Process Communication
(IPC) (Enck et al., 2009) present in the middleware layer provides a standard mechanism for
the communication between applications over android framework. These communications
through Binders will occur through the application components. These communications are
often referred as Inter-Component Communications (ICC) which is different from the IPC
calls from kernel layer. ICC uses a special message called Intent. These messages intent are
wrapping-up of data of the task that needs to be performed.
Android Framework: Sensitive data such as call interface, contact database, internet access
are secured by permissions allowed by security policy framework predefined by the android
system. Most of the sensitive information stored in the android system application. Third-
party application developers should declare the permission required for the application to
implement the application properly. Android uses a file system to record all the requested
and provided permission to the applications called Manifest files (Dengre, S. and Kaushal, R,
2013). These file contain the required and new permissions of the application, which is an
integral part of the installation package. According the permission set available in the
Manifest files application will request the appropriate permissions during the install time.
Android user can grant all of the requested or deny the requested permission by aborting
the installation. If user grants permission to the application he cannot revoke the granted
permission to the application. Middleware layer also have the ICC calls enforced by MAC.
These allow the android middleware layer to extend reference monitor to check and
monitor permissions of all the calls during the system runtime. The reference monitor has
authority to deny the ICC calls if the call does not have the required permissions. But most
of the important permissions like Bluetooth, Internet, and external storage are not
controlled by the reference monitor but monitored by the Linux kernel.
Sandboxing of application: The Linux Kernel is the process isolation of application with the
permissions group. The sandboxing technique, which each and every instance of the android
application is allocated with unique user identifier (UID). These applications can access only
the files they have permissions to or which they have written as world-wide readable.
Existing Problem
Classification of Attacks
In this section we will discuss the various classifications of attacks on android. We will briefly
describe the classifications on permission escalation attacks and define the security model
that we propose.

9. SID: 213526276 Page 8
Permission escalation attacks can be classified in two types. They are confused deputy
attacks and collusion attacks. Confused deputy is a malicious code in the applications which
acts leverage for the vulnerable interfaces. During our research showed that these confused
deputy attacks are common on both the third-party and default core android applications.
The default applications like Phone and settings are also vulnerable to confused deputy
attacks. Confused deputy attacks follow two approaches and they are classified either
socket based or the Inter-Component Communication based attacks.
The other collusion attacks are the malicious application which colludes with other
application to perform tasks and access data which they have not give permissions. For
example Soundcomber (Schlegel, Zhang and Wang, 2011) is attack in which one application has
the permissiontorecordcallsandotherapplicationhasthe permissiontoaccess internettheseboth
applications will collude togetherandcapture the sensitive details of the user and transfer it to the
unknown source over the internet. Same as the confused deputy attacks, collision attacks can also
communicate directlyoverICCcallsorthroughthe previouslyestablished socket connections. They
can share files through open/closed communication channels in the system components.
AdversaryModel
There are four types of adversary models for the android framework. We considered all the
scalable models present in the android security framework. If the ICC channels are attacked
by the known confused deputy application attacks is classified under Weak Adversary
model. In this the attacks comprises of exploiting all the user known security flaws is said to
be Weak Adversary attack model. If the attack is launched with the combination of both the
unknown attacks and the vulnerabilities of the internet socket attack are followed in Basic
Adversary model. Advanced Adversary model comprises of both the confused deputy and
the combination of collusion attacks through direct ICC calls. At last we have Strong
Adversary model in which the combination of both the confused deputy and collision
attacks launched through in-direct communication such as system components, internet
connections are Strong Adversary model.
Our Proposed Model
Initially, we will discuss the Strong Adversary model and to improve the security flaws
present in it towards the confused deputy and collusion attacks. In later sections we will
briefly describe the design and implementation of the android framework which is both
universal and exquisite at the same time for the security framework. To achieve fine-grained
control we should study the attack coverage and android system policy enforcement. If we
go for too much fine-grained adversary model, will lead it to false positive. This false positive
will lead to the limited attack coverage and eventually limiting the usability of our adversary
model and its reliability to protect our android over other vulnerabilities and attacks. And
also the idea of combining the already existing security adversary model will not be suited
to the android framework. Thus it will eventually downgrade the android performance.
Thus we propose a new and more flexible android security framework to regulate the
difference between the policy enforcement and android security framework usability. SO
our security framework will comprises of all the above mentioned adversary models Weak,

10. SID: 213526276 Page 9
Basic, Advanced and Strong adversary models effectively into one adversary model
compatible with the android framework.
Proposed Design andImplementation
In this section, initially we discuss the overview of the proposed android security framework
architecture. And later we briefly describe the implementation and performance of the
proposed framework and how it will adjust and communicate with the existing security
framework and work towards securing the android.
Framework Outline
Our proposed android security framework performs across both the middleware and Kernel
level layers. Thus it can extend its reference monitor from middleware layer to the kernel
level and check the permissions over the IPC calls. Thus it can provide a better security
towards the malicious communications between the ICC calls based on the system-centric
security framework policy. We also maintain the system manifest files in which all the
applications permissions have been recorded and maintained including the internet sockets,
direct and indirect communication calls. Direct calls are the middleware layer ICC calls and
the indirect links are the external storage and internet sockets. Our proposed security
extension is conjured when applications endeavour to build up an ICC call, access
documents or interface with attachments. The system approves whether the asked for
operation can conceivably be misused for a permission escalation attacks (taking into
account the fundamental security framework policy).
Architecture of the proposed framework
The proposed architecture is built upon the preceding work of (Bugiel et al., 2011) in his
XManDroid which improves the middleware level security and TaintDroid by (Enck et al.,
2014) which enhance the kernel level security on the android security framework. We
extend and combine these two level modules into our security extension. We will briefly
describe the interactions between the components of our security extension.
ReferenceMonitor
ICC calls are monitored during the runtime of the system. The Reference monitor present in
our android security framework will intercept all the runtime ICC calls of the applications.
The intercepted calls will be checked with the Android Permissions database by the
reference monitor and acquire the necessary information about the ICC calls and then it
authorize the ICC call to establish connections. One the Reference Monitor permits the ICC
calls it will be subjected to the Decision Mechanism through which it checks the ICC calls in
regards with the android security framework policy. To allow this communication Decision
Mechanism will demand an already stored record of this particular ICC call from the Policy
Assessment database. If Policy Assessment able to locate the record from its database then
Decision Mechanism will use the already existing decision call be followed. If not Decision
Mechanism will contact the Android Permission database and check with the information
over and create a new policy from the inputs of Permission database with associations of
System Guideline Policy and System View. Later DecisionMechanism will store the new

11. SID: 213526276 Page 10
Decision made in the Policy Assessment Database. Either if it is affirmative or negative the
DecisionMechanism will update the communication link between the applications in the
System View. The Decision made by the DecisionMechanism will be updated to the
Reference Monitor about the communication link decision it has made. From the new
decision provided by the DecisionMechanism Reference Monitor can either permit or deny
the ICC call of the application.
The Runtime Monitor is the important function in the security extension. This runtime
monitor extends from the middleware layer to the kernel layer and monitors all the ICC
calls. This provides the main core functions of the security extension.
Improvised Decision Storage
We implement an enhanced Decision Storage for our extension. Through which we can
perform better android security permission system. In this we introduce a new concept of
Auto-Permissions, once the DecisionMechanism create and stores the positive decision of
the applications API calls. Those positive decisions will be stored in the improved Decision
Storage as Auto-Permission (AP). This Auto-permission will allow the system to intercept the
permission granted by the callee to the API caller. The AP will be moved to the Android
Permission Database and monitored by the Reference Monitor. Once our extension
provided with positive decision, then AP will have no interruption from the future API calls.
Thus the runtime over head is avoided by not invoking ICC calls for every instance.
Application & System Policy Installer
Application installer is the standard component in the android framework responsible for
the applications installation and un-installations. It has the enhanced Package Manager in
which the components will have the new System View. While the application is installed by
the user it will check and approve the permissions requested by the application. And it also
ensures the removal all the entities related to the application during the un-installation and
removes the entire application from the System View. System Policy Installer is used to
update and install the policy framework into the middleware level of android architecture.
During the system policy installation the rules of the security policy will be written by the
PolicyInstaller and update those rules in the database of the SystemPolicy. It will erase all
the earlier decision made by the DecisionMechanism and reset the SystenView
Application Objective Classification
One of the major concerns is the communication-links leads to the confused deputy attacks.
These attacks establish links between different ICC calls. Inspired by the QUIRE (Dietz et al.,
2011) we build a frameworks through which each and every instance of the application is
give Unique User Identity (UIDs) in relations to their respective ICC calls. In contrast to the
QUIRE extension we are opting for the system-centric approach to develop our security
extension. To develop such extension we extend the current Binder to access the IPC calls to
the Kernel layer in the android security framework. This allow reference monitor to extend
its authority to Kernel layer and monitor the ICC calls between the application components.
The proposed design will be of Objective-Based application mapping. Through which the

12. SID: 213526276 Page 11
application are grouped together according to the Manifest files. This will help the Decision
Mechanism to automatically tag the application Permissions to the ReferenceMonitor.
SystemView
We use the ProcessManager to identify the application graph and its connection links in
between the application components. The vertex technique is used to approach the
sandbox process. Sandbox technique is used in the framework to share the resources and
permission. The Manifest files of all the permissions present in the Sandbox application with
the shared Unique User Identity is merged with Vertex. To make our extension universally
accessible we use the world-wide readable/writeable files. This technique is efficient
enough to secure the sandboxed files which will be saved privately through the vertex. We
also extend the ActivityManager (Chan, Hui and Yiu, 2012). ActivityManager is usually
managed to spot and record all the installation details of the application during the system
boot-up. We extend this ActivityManager to the Kernel level to monitor the ICC calls. System
Service Manager is not been implemented in our extension because it will not differentiate
the core application from the third-party application. Thus modifying the content provider
we can prevent the colluding of the applications to exchange data over the content
providers. For each and every application permission in the database is tagged and
registered with the Unique User Identity. While writing the application content the tags are
automatically updated. Upon the application requesting permissions it will be checked our
extension and the interface will authorize the corresponding security policy framework.
PolicyAssessment
PolicyAssessment stores the Boolean value for the DecisionMechanism created manifest
files which will be registered for all verified ICC calls. This technique is used to map and
differentiate the ICC towards the DecisionMechanism result. The mapping result will be
indexed as caller and callee form of the android security framework. This technique is one of
the predominant processes across system boot.
Kernel Mandatory AccessControl (MAC)
Default Android application does not come with the Mandatory Access Control (MAC) in the
Kernel level. To enable the access of MAC over the kernel level we implement the TOMOYO
Linux (Harada, Horie and Tanaka, 2014). SELinux (Zhai et al., 2013) is the alternate of
TOMOYO it is the MAC application available over the Linux Security Model (LSM). TOMOYO
is analysed as the best option for the readily available user-space which provide the
communication channel between the middleware and the kernel the SELinux does not have
the inter communication between the two layers. Since android file system does not
provide cross layer file attributes between middleware and kernel layer by default.
TOMOYO MAC implementation is path-based, thus is don’t require any inbuilt file system to
communicate between the layers. Moreover SELinux has more complex rules to satisfy the
android security framework requirements and it will be difficult to monitor over the mobile
devices. The TOMOYO Mandatory Access Control will help us to communicate between the
two bottom layers of android framework. The default TOMOYO cannot be implemented
with the android framework to implement the TOMOYO we use the native libraries to

13. SID: 213526276 Page 12
access it over the android framework. The interface will be compiled with the use of Java
Native Interface. The TOMOYO will monitor the ICC calls over the both middleware and
kernel layer. The extended interface of the TOMOYO will enable the runtime policy updates.
This will allow the TOMOYO to request from the DecisionMechanism. Besides this we also
extend the functionality of the both TOMOYO and middleware layer. We implement the
JAVA parser to able to communicate and understand what the TOMOYO requesting from
the middleware and what the middleware is requesting from the TOMOYO. TOMOYO
extends the Unique User Identity (UID) (Shcheglov and Shcheglov, 2015) to permit the
middleware to make decision at a runtime system policy. This mechanism will process the
ICC calls to monitor the application components. DecisionMechanism present in the
middleware layer will process the permission and transmit the decision to TOMOYO.
TOMOYO kernel is carefully developed and exclusively written for the android security
policy. The TOMOYO policy file is purposely maintained in the kernel memory during the
system boot. The TOMOYO will always inspect the application communication between the
kernel and middleware application and monitor the ICC calls so that the confused deputy
attacks won’t occur. If the ICC calls is accepted during the reference monitor present in the
middleware. Then the permission will be sent to the DecisionMechanism query will be sent
without any more decision. The DecisionMechanism can communicate with the TOMOYO
either directly requests the system call to process or it could solicit the TOMOYO to
generate the new policy decision. This flexibility present in the TOMOYO will allows the
system to reduce the ICC calls switching between the kernel and middleware layers.
Application level Extension
The application level is at the top of the android architecture layer consists of application
layer in which the core or preinstalled application and Third-party application are present.
The application present in the system will communicate with the native libraries and Java
libraries. The extension along the application layer will process the application content
providers to in which the extension will keep track of all the functionality of the application
content. This will allow the extension to manage the application interface.
Security Enforcement in Application Level
Android secures applications and information through a mix of two requirement
components, one at the framework level and the other at the ICC level. ICC intervention
denies the centre security structure and is this present article's concentrate, however it
expands on the assurances gave by the basic Linux framework. In the general case, every
application keeps running as an extraordinary client character, which lets Android confine
the potential harm of programming flaws.
PolicyEnforcement
In accordance to the adversary models and the system requirement we create a specified
adversary correspondent to the models. The newly created profiles for the WeakAdversary,
BasicAdversary, AdvancedAdversary and StrongAdversary for these models we create a
DefaultProfile, BasicProfile, AdvancedProfile and StrongProfile respectively for the adversary

14. SID: 213526276 Page 13
models. The DefaultProfile will help to defend against the all known confused deputy
attacks. The policies rules of the DefaultProfile will help to defend the attacks occur over the
ICC calls (Lee et al., 2014). These policy frameworks will be formulated with the predefined
process which does not result in the false positive and usability of the android framework.
The other Profiles like the Basic, Advanced and StrongProfile can stimulate by the android
user with higher android security framework. These profiles are useful when the android
user is using the device for both private and business purpose. These policy profiles will
provide customised system usability and security requirement of the android framework.
We provide the new policy language. The language is capable of expressing the components
of the android framework. The mapped system policy enforcement will be implemented
throughout the application instances. The new policy framework will eventually help to
process the system application. The policy framework will be enforced to all the application
during the installation time of the app and this policy will permit the each and every
instance of the application.
Securing from Permissionescalationattack
The permission escalation attacks pattern is been studied and we provide a set of critical
permissions to the system. For an example the application which has access over the
internet can collude with application which has permission over the location service and
transmit those sensitive data to the unknown source is called as the collusion attacks. In the
confused deputy attacks the unprivileged application will gain access over the certain
resources by duplicating the other app permissions.
We plan to provide the authorization framework with the capacity to deny API solicitations
made by the confused deputy in the interest of an unprivileged requester. Such a
permission access control component keeps the requester from executing special activities
with symptoms or asking for sensitive information through another application. On the
other hand, we don't address the issue of keeping an important application from sharing
touchy information that it has really and freely acquired. We concentrate on ensuring access
reliability, while miscommunication and improper information sharing is an android security
issue. Forestalling information spillage is a correlative issue past the extent of our work.
GrantingPermission
Android framework allows two type of granting permission by the android user. The two
types of permission granting mechanism are enhanced in our extension.
Time of Use:
The time of use permission are based on the process in which the third-party app will be
granted permission while the application API is used by the android user. When the
application triggers the respective API call the users are request to either approve or deny
the permission for the respective application. The permission can be granted for a single
instance or for the period of time. Mostly web browsers or the third-party application

15. SID: 213526276 Page 14
accessing internet will be using this type of permission. Our extension will monitor all the
application API’s through the android framework.
Install Time:
In an android framework with install time permission, an application API will state its
required permissions during its installation time. Android user can both permit the
requested permissions of the application and install the application or he can deny and
abort the installation process. One of the major disadvantages of this permission granting
process is that android user cannot revoke his permissions. Once the user provides
permission he cannot change the application API during runtime.
Methodology
In this section we will discuss the heuristic approach to the communication patterns inside
the third party application and also provide the methodologies used in our research paper.
For our research we use the quantitative methodology by doing the manual testing with
user group as the security extension is implemented over the android system mobile
devices. The automated testing is been carried out to determine the device usability and
performance. The security extension provides a reliable security against the confused
deputy and collusion attacks. Only in few instance the unknown deputy attacks has been
successfully breached our security extension. The main aspect of this observation is that
providing users with the extension and exploring all the application features with the
installation and un-installation of different third party applications as much as possible into
the system.
Observations
The security implementation also used to study and observe the way of communication
happening between the different third-party applications in the security extended android
framework. Through which we mapped all the patterns of the important and popular third-
party application present in the app stores.
The analysis show that most of the third-party application either follows File and Socket
based communication or the ICC based communication. After our security extension our
observation shows that applications neither communicate through system resource nor
share the file system in the android framework. The attack vector which comprises of files
or the socket-based ICC communication as a medium is been identified by the MAC present
at the kernel level. As far as the ICC based Communication is concerned our extension
precisely addresses this correspondence design, since it executes a fine-grained
arrangement implementation in the framework parts, and direct correspondence between
applications, which is the principle focus of non specific framework approach standards,
happens at times and provided that this is true, with an exceptionally distinct example.
Confused deputyand Collusion attack detection and prevention
We calculate both the false positive (denying permissions to the legitimate applications) and
false positive (providing permissions to the malicious applications). Considering these two

16. SID: 213526276 Page 15
factors we determine the effectiveness of the security extension. From our runtime test we
analysed that the system found almost most of the confused deputy and collusion attacks
and also there was little negligible runtime error and no to false positive of certain
legitimate applications is been recorded. Thus the communication calls of the third-party
applications over the android framework are mapped.
Usability and Performance
Despite the fact that we didn't watch any false positives points in our tests, any legitimate
application denied correspondences must be maintained a strategic distance from, on the
grounds that they can have an extreme effect on the convenience of the device. Denying
applications ICC that was required to be permitted probably renders this application broken.
Besides, application designers don't expect this circumstance, since introduced applications
have been conceded all the permissions, and therefore regularly preclude exemption taking
care of code, making applications crash in the event that their ICC call is denied.
This issue applies to all methodologies taking into account changing permissions at post-
install time or on denying ICC at runtime. It is especially difficult to understand for
circumstances where one can't plainly recognize a confused deputy attacks and collusion
attacks.
However our extension performs with the slight standard deviation of the device security
framework with the small negligible runtime overhead. The latency of the runtime system is
negligible compared to the ratio. Future work in this field can remove the overhead.
Conclusion
In this paper, we address the issue of confused deputy and collusion attacks on Android. We
propose the outline and usage of a basic security structure for Android that screens
application correspondence diverts in Android's middleware and in the hidden Linux bit
(specifically, IPC, record framework, Unix area and Internet attachments) and guarantees
that they agree to a framework driven security strategy. We propose a few adversary
models, characterize confused deputy and collusion attacks in view of a policy based
representation of our security system and examine normal correspondence examples of
Android applications by method for a heuristic study. Our outline precisely addresses our
perceptions, as it actualizes a fine-grained strategy implementation in the framework
segments, which are the essential means for applications to share information. Propelled by
QUIRE, we incorporate Application Objective strategies into our framework (yet in a
framework driven manner) with a specific end goal to expand the accuracy of our
examination. In addition, a prototype of our model is the runtime cooperation between our
security communications to the Android middleware and TOMOYO Linux, taking into
consideration dynamic runtime approach mapping from the semantically rich middleware to
the kernel Linux bit. Our assessment results demonstrate that our structure is proficient,
compelling and usable. It can counteract as of latest permission escalation attacks,
propelled by means of indirect channels in the Android framework segments.

17. SID: 213526276 Page 16
Future Work
For our future work, we arrange broad client tests of our security system utilizing third-party
applications from the Android market. Besides, we intend to proceed with our present
theory at performing framework wide ICC call-chain check at the Binder level. At long last,
we might want to inspect how we can coordinate SELinux into our security system.
Reference
Adrienne, P., Steven, H., Erika, C., Helen, J. and Moshchuk, E. (2011). Permission re-
delegation: Attacks and defenses.
Barrera, D., Kayack, H., Oorschot, P. and Somayaji, A. (2010). A Methodology for Empirical
Analysis of Permission-Based Security Models and its Application to Android.
Bugiel, S., Davi, L., Dmitrienko, A., Fischer, T., Sadeghi, A. and Shastry, B. (2012). Towards
Taming Privilege-Escalation Attacks on Android.
Chan, P., Hui, L. and Yiu, S. (2012). DroidChecker: analyzing android applications for
capability leak. WISEC '12 Proceedings of the fifth ACM conference on Security and Privacy in
Wireless and Mobile Networks, pp.125-136.
Chin, E., Porter Felt, A., Greenwood, K. and Wagner, D. (2011). Analyzing inter-application
communication in Android.
Dengre, S. and Kaushal, R. (2013). Privilege Escalation Attacks in Android: Their Approaches,
Detection and Defense Techniques.
Dietz, M., Shekhar, S., Wallach, D., Pisetsky, Y. and Shu, A. (2011). : Lightweight provenance
for smartphone operating systems. In 20th USENIX Security Symposium, 2011.
Enck, W., Gilbert, P., Chun, B., Cox, L., Jung, J., McDaniel, P. and Sheth, A. (2014). TaintDroid.
Communications of the ACM, 57(3), pp.99-106.
Enck, W.; Ongtang, M.; McDaniel, P., "Understanding Android Security," in Security &
Privacy, IEEE , vol.7, no.1, pp.50-57, Jan.-Feb. 2009
Enck, W., Ongtang,, M. and McDaniel, P. (2008). Mitigating Android Software Misuse Before

18. SID: 213526276 Page 17
It Happens.
Harada, T., Horie, T. and Tanaka, K. (2014). Task oriented management obviates your onus
on Linux (TOMOYO). Research and Development Headquarters, NTT DATA CORPORATION,
2(7), pp.13-25. (Harada, Horie and Tanaka, 2014)
Lee, H., Kim, D., Park, M. and Cho, S. (2014). Protecting data on android platform against
privilege escalation attack. International Journal of Computer Mathematics, pp.1-14. (Lee et
al., 2014)
Hornyack, P., Han, S., Jung, S., Schechter, S. and Wetherall, D. (2011). These Aren’t the
Droids You’re Looking For. Retrofitting Android to Protect Data from Imperious Applications,
5, pp.77-84.
Marforio, C., Francillon, A. and Capkun, S. (2011). Application Collusion Attack on the
Permission-Based Security Model and its Implications for Modern Smartphone Systems.
Nauman, M., Khan, S. and Zhang, X. (2010). Extending Android Permission Model and
Enforcement with User-defined Runtime Constraints. In: Proceedings of the 5th ACM
Symposium on Information, Computer and Communications Security.
Ongtang, M., McLaughlin, S., Enck, W. and McDaniel, P. (2011). Semantically rich
application-centric security in Android. Security and Communication Networks, 5(6), pp.658-
673.
Rangwala, M., Zhang, P., Zou, X. and Li, F. (2014). A taxonomy of privilege escalation attacks
in Android applications. International Journal of Security and Networks, 9(1), p.40.
Schlegel, R., Zhang, K. and Wang, X. (2011). Soundcomber: A Stealthy and Context-Aware
Sound Trojan for Smartphones. 18th Annual Network and Distributed System Security
Symposium (NDSS), 2(5), pp.36-41. (Schlegel, Zhang and Wang, 2011)
Shcheglov, K. and Shcheglov, A. (2015). PROTECTING AGAINST PRIVILEGE ESCALATION
ORIENTED ATTACKS. Vestnik komp'iuternykh i informatsionnykh tekhnologii, pp.36-42.

19. SID: 213526276 Page 18
Techotopia.com, (2015). An Overview of the Android Architecture - Techotopia.
(Techotopia.com, 2015)