Android Permissions Review

Applications need approval to perform tasks their owner might object to, such as sending SMS messages, using the camera, or accessing the owner’s contact database. Android uses manifest permissions to track what the user allows applications to do. An application’s permission needs are expressed in its AndroidManifest.xml file, and the user agrees to these upon install.

Note

The same install warnings are used for side-loaded and Market applications. Applications installed with adb don’t show warnings, but that mechanism is only used by developers. The future may bring more installers than these three.

When installing new software, users have a chance to think about what they are doing and to decide to trust software based on reviews, the developer’s reputation, and the permissions required. Deciding up front allows them to focus on their goals rather than on security while using applications. Permissions are sometimes called manifest permissions or Android permissions to distinguish them from Linux file permissions. In some rare cases, Android needed to tweak the underlying Linux kernel to support powerful permissions. For example, to support the INTERNET permission, which controls which programs can create network connections, the OS has been altered to require membership to the inet group (typically GID 3003) for certain system calls to work. This isn’t the usual way a Linux system is configured, but it works well. Programs with INTERNET permission are granted membership in the inet group. By enforcing permissions in the OS rather than in the VM or system libraries, Android maintains its security even if the VM is compromised by a hostile application. Writing secure VMs that perform well, use little power, and stop applications from misbehaving (like Sun Microsystem’s Java VM does) is rather hard, and Android’s design avoids needing to do all of this. Breaking out of the Dalvik VM is actually very easy, and documented APIs allow it to be done. However, this doesn’t affect enforcement of Android permissions.

To be useful, permissions must be associated with some goal that a user can understand. For example, an application needs the READ_CONTACTS permission to read the user’s address book (the permission’s full name is “android.permission.READ_CONTACTS”). A contact management program needs READ_CONTACTS permission, but a block stacking game shouldn’t (although if the game vibrates the phone or connects to a high-score Internet server, it might need VIBRATE and INTERNET permission). Because the permission model is simple, it’s possible to secure the use of all the different Android IPC mechanisms with just a single type of permission.

Starting Activities, starting or connecting to Services, accessing ContentProviders, sending and receiving broadcast Intents, and invoking Binder interfaces can all require the same permission. Users only need to understand that their new contact manager needs to read contacts, not what the actual C mechanism used are.

Tip

Users won’t understand how their device works, so keep permissions simple and avoid technical terms such as Binder, Activity, and Intent when describing permissions to users.

Once installed, an application’s permissions can’t be changed. By minimizing the permissions an application uses, you minimize the consequences of potential security flaws in the application and make users feel better about installing it. When installing an application, users see requested permissions in a dialog similar to the one shown in Figure 1. (This dialog lists permissions; the installation dialog gives a bit more information and the option to install as well.) Installing software is always a risk, and users will shy away from software they don’t know, especially if it requires a lot of permissions. Make sure you ask for the minimum set of permissions you can get away with.

Figure 1. Dialog showing Application permissions to users. (Chu, 2008.)

From a developer’s perspective, permissions are just strings associated with a program and its UID. You can use the Context class’s checkPermission(String permission, int pid, int uid) method to programmatically check whether a process (and the corresponding UID) has a particular permission, such as READ_CONTACTS (note that you would pass the fully qualified value of READ_CONTACTS, which is “android.permission.READ_CONTACTS”). This is just one of many ways permissions are exposed by the runtime to developers. The user view of permissions is simple and consistent; the idiom for enforcement by developers is consistent, too, but adjusts a little for each IPC mechanism.

The following code (AndroidManifest.xml) shows a sample permission definition. Note that the description and label are resources to aid in localizing the application.

<permission
    xmlns:android="http://schemas.android.com/apk/res/android"
    android:name="com.isecpartners.android.ACCESS_SHOPPING_LIST"
    android:description="@string/access_perm_desc"
    android:protectionLevel="normal"
    android:label="@string/access_perm_label">
</permission>

Manifest permissions like this one have a few key properties. Two text descriptions are required: a short text label and a longer description used on installation. An icon for the permission can also be provided (but isn’t included in the example). All permissions must also have a name that is globally unique. The name is the identifier used by programmers for the permission and is the first parameter to Context.checkPermission. Permissions also have a protection level (called protectionLevel, as shown in the preceding example).

Table 1 shows the four protection levels for permissions. (See http://code.google.com/android/reference/android/R.styleable.html#AndroidManifest-Permission_protectionLevel or search for “Android Manifest Permission protectionLevel” for platform documentation.)

Table 1. Android Manifest Permission Protection Levels

Protection Levels	Protection Behavior
Normal	Permissions for application features whose consequences are minor (for example, VIBRATE, which lets applications vibrate the device). Suitable for granting rights not generally of keen interest to users. Users can review them but may not be explicitly warned.
Dangerous	Permissions such as WRITE_SETTINGS and SEND_SMS are dangerous because they could be used to reconfigure the device or incur tolls. Use this level to mark permissions users will be interested in or potentially surprised by. Android will warn users about the need for these permissions upon install, although the specific behavior may vary according to the version of Android or the device upon which it is installed.
Signature	These permissions are only granted to other applications signed with the same key as the program. This allows secure coordination without publishing a public interface.
SignatureOrSystem	Similar to Signature, except that programs on the system image also qualify for access. This allows programs on custom Android systems to also get the permission. This protection helps integrate system builds and won’t typically be needed by developers.
	Note: Custom system builds can do whatever they like. Indeed, you ask the system when checking permissions, but SignatureOrSystem-level permissions intend for third-party integration and thus protect more stable interfaces than Signature.

If you try to use an interface you don’t have permissions for, you will probably receive a SecurityException. You may also see an error message logged indicating which permission you need to enable. If your application enforces permissions, you should consider logging an error on failure so that developers calling your application can more easily diagnose their problems. Sometimes, aside from the lack of anything happening, permission failures are silent. The platform itself neither alerts users when permission checks fail nor allows granting of permissions to applications after installation.

Note

Your application might be used by people who don’t speak your language. Be sure to internationalize the label and description properties of any new permission you create. Have someone both technical and fluent in the target languages review them to ensure translations are accurate.

In addition to reading and writing data, permissions can allow applications to call upon system services as well as read or alter sensitive data. With the right permission, a program can cause the phone to dial a number without prompting the user, thus potentially incurring tolls.