Blog home for Gunnar Peterson (@OneRaindrop) and Ken van Wyk (@KRvW) for topics related to our joint Mobile App Security Triathlon events. For more info, see our website: www.MobileAppSecTriathlon.com Contact us to schedule a MobAppSecTriathlon at your organization.
Tuesday, September 18, 2012
Building an Android Security Toolkit Part 2
In the last post, we started building out an Android Security Toolkit, things every Android developer should know about security. Access control is fundamental to application security. In my perfect world, when a developer learns a new language they first learn Hello World, the next thing a developer learns should be how to implement who are you and what can you do in the langauge - authentication and authorization. The AndroidManifest.xml file describes the access control policy that forms the application boundary, but where is this boundary enforced and what services does it provide?
The access control chain consists of
1. Defining access control policy
2. Enforcing access control policy
3. Managing access control policy
The AndroidManifest.xml defines the permissions that the application requires, such as:
<uses-permission android:name="android.permission.
INTERNET" />
<uses-permission android:name="android.permission.
WRITE_EXTERNAL_STORAGE" />
The user is able to confirm or deny installation (but not change permissions) based on the AndroidManifest.xml file, this defines step 1 above. The policy is distributed with the application so policy management is under control of the distribution point such as AppMarket. This leaves step 2, enforcing access control policy.
Android apps run in the Dalvik VM, however IPC is not managed in the VM, instead its managed further down in the stack in the Binder IPC Driver which resides in the Linux kernel. Not sure, but I suspect the reason is that there are a number of permissions that requires lower level access.
The binder maps the permission and either the caller's identity or binder reference to verify access privileges. From a design standpoint, permission boundaries can be defined and enforced at different layers in the App including Content Provider, Service, Activity, and Broadcast Receivers.
Access control is the beginning of thinking about security but its not the endgame, the next step to building an Android security toolkit is defensive coding, how to deal with cases like code injection that are designed to subvert the access control scheme.
**
Come join two leading experts, Gunnar Peterson and Ken van Wyk, for a Mobile App Security Training - hands on iOS and Android security, in San Jose, California, on November 5-7, 2012.
No comments:
Post a Comment