October 25th, 2010 By Owais

Strengths and Weaknesses of Policy Enforcement Mechanism for Open Source mobile platform 


This report is written on behalf of research project EASIP ( Extending Android Security for Intent Policies) funded by ICT R&D, to SERG (Security Engineering Research Group). The report describes Strengths and Weaknesses of policy enforcement mechanisms for Open Source mobile platforms. This report is prepared after achieving the milestones “Completion of Implementation of a rudimentary Selective Permission Mechanism for Android” and “Completion of analysis of current policy enforcement mechanisms for open source mobile platforms and current potential target Android applications” as mentioned in EASIP project proposal. We have considered both the cons and pros of current policy enforcement mechanisms in Open Source mobile platforms in general while Android (followed by Openmoko) in particular. The aim of writing the report is to analyze the strengths and weaknesses of policy enforcement mechanisms in Open Source mobile platforms. Moreover achieving this milestone will help us achieve our next target milestone that is “White paper on real world use cases for target Android applications and the design of the new policy language”. 


Today, there are 1.5 billion television sets in use around the world. 1 billion people are on the Internet. But nearly 3 billion people have a mobile phone, making it one of the world’s most successful consumer products. There are two major categories in mobile phone platforms. Open Source and Closed Source. Mobile users demand more functionalities and innovative mobile platform in order to customize their handset according to their personal desires. Open Source mobile platform provides Consumers with cheaper and more innovative mobile devices and services, which inevitably features more engaging and easier-to-use interfaces. Comparative to closed source an Open source platform helps semiconductor companies add support for their newest products in a timely manner and gives a clear way to 3rd party developers to access enhanced functionality. Developers are able to build innovative applications because they have comprehensive API access to handset capabilities. 

Open Handset Alliance is formed to provide such common plate form for different mobile manufacturers and developers to contend with aforementioned challenge. The resultant product they manage to work on is the Android, an open source mobile platform. 

Overview of Android Architecture 

Android operating system is a layered architecture, containing application layer, application framework layer, and Android runtime with system libraries. Application layer is shipped with a set of core applications including an email client, SMS program, calendar, maps, browser, contacts, and others. The application framework layer contains different API’s that allow developers to build innovative applications by taking advantage of the hardware resources. These API’s provide access to content providers, location managers, notification manager and so on. Android includes a set of C/C++ libraries used by various components of the Android system for example: System C library, Media Libraries, Surface Manager, LibWebCore, SGL, 3D libraries, and FreeType SQLite. Android runtime includes core libraries and a virtual machine known as Dalvik virtual machine. Android enforces a sand boxing mechanism by running each application in a separate process of the Dalvik virtual machine. Different instances of the virtual machine communicate with each other through a specialized inter- process communication mechanism provided by the application framework layer. The core system services of Android rely on Linux kernel version2.6, such as security, memory management, process management, network stack, and driver model. The kernel also acts as an abstraction layer between the hardware and the rest of the software stack. 

Figure 1 Android Layered Architecture

Overview of Openmoko Architecture 

Openmoko Inc. started funding FSO (freesmartphone.org) from January 2008. FSO is a project which aim is to create a standardized service layer i.e., middle ware for Linux based smart phones so that high level services can be accessed from UI that supports dbus. This middle ware has been integrated into most of current distributions e.g. Debian and Gentoo. The FSO is implemented successfully on Openmoko phones. 

Openmoko framework is based on four layers: 

  • Application Layer
  • Middle ware Layer
  • Low-Level services Layer
  • Kernel Layer

The application layer communicates with the middle ware layer totally over dbus. This allows a great degree of freedom for the application layer as there is neither programming language nor toolkit constraints involved. The middleware layer contains the FSO services. The middleware is composed from discrete subsystems split into two abstraction layers. Middleware subsystems communicate both horizontally and vertically over dbus. The Low-Level services layer contains existing solutions for lower level services such as networking, Bluetooth, audio, etc. Some of these services offer dbus interfaces as well. The kernel layer contains the hardware drivers and provides low level access via sysfs, ioctls, and similar interfaces. The architecture is depicted in the figure. Openmoko uses D-Bus as a middle ware interface that enables applications to interact with other applications and also to make available applications as a system services. D-Bus is an inter-process communication mechanism-a medium for local communication between processes. D-Bus is chosen for FSO because it’s meant to be fast and lightweight, and is designed for use as a unified middle ware layer. Two separate buses have been defined for integrating in Openmoko architecture. These are: a system bus for root which runs whenever the phone is on and a session bus which is started for the user when X starts. 

Figure 2 Openmoko Architecture

Strengths and Weaknesses of Policy Enforcement Models 

Strengths of Android Policy Model 

1.  Private Components: 

Applications often contain components that another application should neveraccess. For example, component related to password storing. The solution is   present in Android by declaring private component. This significantly reduces the attack surface for many applications to access secure components of another application. 

2.  Protection of Sensitive API’s: 

Android protects sensitive APIs with additional permission label checks. Appli cations will have to declare their intention to use sensitive API’s like locationand messaging, at install time. 

3.  Protecting Broadcast Intent: 

Intent is an abstract description of an operation to be performed. It provides a facility     for   performing late runtime binding between different applications. Its most significant use is in the launching of activities. Sending an unprotected intent is a privacy risk. For example a malicious application can register itself for an unprotected broadcast intent and respond to it when the intent is raised. Android API for broadcasting intents optionally allows the developer to specify a permission label to restrict access to the intent object. 

4.  Simplified Access Control Policy: 

Android simplifies access control policy specification by having developers define permission labels to access their interfaces. 

5.  Access Restrictions: 

In Android, no application has permission to perform operations that could harm the operating system. For example applications that run those harmful script that affect other applications or the user. Sensitive data of users will not be  even touched by unauthorized applications. This mechanism is known as sand box. 

6. Unique Signatures: 

All Android applications require a signature that is unique to the application developer. This has advantage as it assigns a level of culpability to poorly designed software. 

7.  Media Holes: 

Google forces audio and video to run on an outside media server. Therefore, malicious files cannot gain access to cookies or user credentials. For example some users can use browsers to check bank accounts or view information from the workplace. 

Weaknesses in Android Policy Model 

1. No Usage Control: 

Android lacks usage control policy to enforce restrictions on utilization of a particular service.   For example, it cannot enforce that no more than 10 SMS messages are sent per day. This is a limitation of Android. 

2.  No Information Flow Guarantee: 

Android’s permission label model only restricts access to components and doesn’t currently provide information flow guarantees. Information flow control can protect the confidentiality and integrity of information. 

3.  Static Permissions enforcements: 

Android policy is static in sense that it does not support runtime logic. Android’s policy enforcement is mandatory, as all permission labels are set at install time and can’t change until the application is reinstalled. 

4.  No Fine-Grained Permissions: 

Android permission enforcement is based on allow or deny policy. So applications have limited ability to fine grain the permissions required by application. 

5. No Customization of Permissions: 

Android is based on all-or-nothing policy, which means that application should be granted with all permissions at install time otherwise installation will result in failure. There are no mechanisms in current Android policy model to facilitate user with customization of permission. 

Strengths of Openmoko Policy Model 

1.  Protection of API’s and Services Interfaces: 

API and service interfaces in Openmoko needs to be protected by the owner of that service or resource. Openmoko uses mandatory access control to do it at low level and use Dbus policies to handle it at middle-ware level. 

2.  Secure Inter-Process Communication: 

Openmoko uses features of Dbus to secure inter application communication. Security policy is specified in XML files and loaded when D-BUS starts. 

3.  Security by Signatures: 

Openmoko provides security to applications and system by developing trust full relation between them. This is achieved by signatures of package repositories and the package itself. 

4.  Information Flow Guarantee 

5.  No Static Permission Enforcement 

6.  Fine Grained Permissions 

7.  Customization of Permissions 

Weaknesses of Openmoko Policy Model 

1. No Usage Control: 

Similar to Android, Openmoko lacks usage control mechanism to impose any restrictions and limitation on usage of a resource 

2. Not User Friendly: 

In Openmoko lot of additional Security features exists that can be added to existing framework. These features enhances security of platform to a greatextend. For example Security enhanced Linux is type of security enforcement model that can be added with Openmoko to provide fine grained securityfeatures. But due to its complex nature and non-friendly policy model, it isused in military based security environment. A common mobile phone useris rarely interested to implement such a complex security enforcement type model. 

3. Complex Stakeholder Policy: 

Openmoko provides security to stakeholders that be local as well as remote stakeholders. Implementation of such policies is possible, but managing policies between stakeholders becomes complex. Due to complexity of policy management in multiple stakeholder environment, it is rarely used. Stakeholders are rarely interested to use such complex security enforcement. 

For a detailed report click here

Leave a Reply