easip-web5
October 25th, 2010 By Owais

Real world Use Cases for Target Android Applications and the Design of New Policy Language

ABSTRACT

Access Control model gives option to the user to either grant or revoke a specific permission pertaining to use of a particular resource e.g. revoking the permission from a particular application to make an outgoing call or allowing an application to use the GPS resource. This model gives greater freedom to users to make decisions to their requirements and greater control over the use of resources. Fine grained access control, a variant of access control model allows users to further add constraints to use of resource e.g. time limit, restricting the number of SMS to be sent, blocking a list of numbers etc thus controlling the use of resources a much granular level. Design of policy writing tool has been given to enable user to enter high level policy and generate XML policies to accomplish access control mechanism on our target Android device. Finally, this report will lead us to complete EASIP’s next milestones, i.e. the ‘Completion of the design of a Policy Enforcement Framework’ and ‘Completion of Design and Implementation of Policy writing tool’.

OBJECTIVE

  • Resources
  • Introduction of access control and fine grained access control model
  • Highlighting real world use cases for target Android application
  • Design and flow of Policy language

INTRODUCTION

Android’s existing security architecture does not provide a check on the access and usage of a resource. This, in our opinion is a significant limitation of the existing architecture. For example, an application requests permissions to access several resources such as MMS and GPS. Once these permissions are granted, application can access the GPS or start sending a large number of MMS messages. The user has no way of restricting the usage of a specific resource or denying access to one resource without losing the ability to use the rest of the application. The only way of stopping this sort of behavior is not to grant the required permissions to the application, which results in not being able to install the application at all. Moreover, in case of applications already installed on the phone, the user has no way of imposing such restrictions.

We address these issues by enhancing the existing security architecture of Android by introducing a policy enforcement framework. This framework enables the user to manage access control and in some cases fine grained access control permissions of applications at runtime and design of policy language (that assists in writing a particular access policy), for better control and command over resource distribution and acquisition.

RESOURCES

ACCESS CONTROL

Our policy enforcement framework enables the user to grant or revoke any resource (permission) granted to that particular application at install time.

FINE GRAINED ACCESS CONTROL

In our fine grained access control, four major Android resources which an application can invoke separately or in any combination are handled. Each resource can have dynamic constraints. For associating dynamic constraints with permissions, application attributes are introduced. Each application having these resources is associated with a finite set of attributes.

  1. SMS/MMS

ATTRIBUTE: SEND_SMS/SEND_MMS

PERMISSION: android.permission.SEND_SMS

CONSTRAINTS: SMS_LIMIT/MMS_LIMIT, ALLOW, DENY, TIME

2. GPS

3. INTERNET

4. DIALER

USE CASES

The use cases explained will portray real world use of our policy enforcement framework. In such scenarios an application or equivalently a software or system might invoke one or more resources to exercise access control and/or fine grained access control of permissions.

CASE 1: ‘Upload Direct App’ resembling many of the applications available allows user to upload their photos to three social networks (twitter, face- book, hi5) or an email profile via MMS. After username/password verification through respective back-end activities of the social networks, a front-end GUI allows user for adding photos simultaneously for each social network in a stream lined manner and passes it to their particular content provider data stores on the phone. The back-end activities extract these data and update them to their respective social networks. For cost purposes the user can limit the number of MMS to a predefined figure during peak charging time. Also the user may DENY sending MMS for a particular time interval where MMS service charges are high and take advantage of off peak timings where MMS are sent at a minimal rate offered by the network.

CASE 2: ‘Travel with Us’ is a sample application resembling many other applications available. It provides services through permission for INTERNET and GPS resources. Based on user current location the application retrieves data from a local website showing various heritage sites, restaurants, transport facilities, parks, gyms etc, in close proximity to the user. The application fetches position coordinates and passes it on to the browser back-end service. The site performs a search from its database of localities and returns the closest sites in accordance with the user location. This data is extracted to the content provider data store of phone. The interactive GUI receives these messages from the content provider and displays probable locations of interest to the user. Based on privacy concerns, user may define a policy to deny permission to GPS and retrieve general information for a particular city/town rather than nearest available e.g. total number of star bucks coffee outlets.

Design and Flow of Policy language

The following figure outlays the major constituting parts of our policy writing tool in a logical flow. Starting from grammar definition for our high-level language in ANTLR (Another Tool for Language Recognition) to the low level XML policy generation using Xstream.

 

Figure Design Flow Diagram of Policy language

For a detailed report click here

Leave a Reply


(Required)

(Required)