Understanding Android Security
Enck et al. IEEE Security & Privacy 2009

This is an "ancient" article discussing the security enforcement provided by Android. It is like the CS101 of Android security. By the year of 2017, a lot of things have changed and a lot of new features have been added to Android. However, it is still worth reading as the principle of programming for Android is stable and unchanged. Below is an excerpt from the paper.

Android Applications

Developers must design applications in terms of components.

Component Types

• Activity components define an application's user interface.
• Service components perform background processing.
• Content provider components store and share data using a relational database interface.
• Broadcast receiver components act as mailboxes for messages from other applications.

Component Interaction

The primary mechanism for component interaction is an intent, which is simply a message object containing a destination component address and data.

Although developers can uniquely address a target component using its application's namespace, they can also specify an implicit name. In the latter case, the system determines the best component for an action by considering the set of installed applications and user choices. The implicit name is called an action string because it specifies the type of requested action---for example, if the "VIEW" action string is specified in an intent with data fields pointing to an image file, the system will direct the intent to the preferred image viewer. On the receiving end, developers use an intent filter to subscribe to specific action strings.

Inter-component communication (ICC).

Security Enforcement

Android protects applications and data through a combination of two enforcement mechanisms, one at the system level and the other at the ICC level.

In the general case, each application runs as a unique user identity, which lets Android limit the potential damage of programming flaws.

ICC isn't limited by user and process boundaries. In fact, all ICC occurs via an I/O control command on a special device node, /dev/binder. Because the file must be world readable and writable for proper operation, the Linux system has no way of mediating ICC. Although user separation is straightforward and easily understood, controlling ICC is much more subtle and warrants careful consideration.

The Android middleware implements a reference monitor providing mandatory access control (MAC) enforcement about how applications access components. Developers assign applications collections of permission labels. When a component initiates ICC, the reference monitor looks at the permission labels assigned to its containing application and—if the target component's access permission label is in that collection—allows ICC establishment to proceed. Android's permission label model only restricts access to components and doesn't currently provide information flow guarantees, such as in domain type enforcement (?).

Security Refinements

Public vs. Private Components

Instead of defining an access permission, the developer could make a component private by either explicitly setting the exported attribute to false in the manifest file or letting Android infer if the component should be private from other attributes in its manifest definition.

Others

Other refinements includes:

• Implicitly Open Components
• Broadcast Intent Permissions
• Content Provider Permissions
• Service Hooks
• Protected APIs
• Permission Protection Levels
• Pending Intents: Pending intents diverge from Android's MAC model by introducing delegation. By using a pending intent, an application delegates the ability to influence intent contents and the time of performing the action. Historically, certain delegation techniques have substantial negative effects on the tractability of policy evaluation.
• URI Permissions

Lessons in Defining Policy

Android security policy begins with a relatively easy-to-understand MAC enforcement model, but the number and subtlety of refinements make it difficult to discover an application's policy.

The label itself is merely a text string, but its assignment to an application provides access to potentially limitless resources.