Understanding Security Boundaries and Enforcement

Security boundaries, sometimes called trust boundaries, are specifi c places within a system where the level of trust differs on either side. A great example is the boundary between kernel-space and user-space. Code in kernel-space is trusted to perform low-level operations on hardware and access all virtual and physical memory. However, user-space code cannot access all memory due to the boundary enforced by the central processing unit (CPU).

The Android operating system utilizes two separate, but cooperating, per-missions models. At the low level, the Linux kernel enforces perper-missions using users and groups. This permissions model is inherited from Linux and enforces access to fi le system entries, as well as other Android specifi c resources. This is commonly referred to as Android’s sandbox. The Android runtime, by way of the DalvikVM and Android framework, enforces the second model. This model, which is exposed to users when they install applications, defi nes app permis-sions that limit the abilities of Android applications. Some permispermis-sions from the second model actually map directly to specifi c users, groups, and capabilities on the underlying operating system (OS).

Android’s Sandbox

Android's foundation of Linux brings with it a well-understood heritage of Unix-like process isolation and the principle of least privilege. Specifi cally, the concept that processes running as separate users cannot interfere with each other, such as sending signals or accessing one another’s memory space. Ergo, much of Android’s sandbox is predicated on a few key concepts: standard Linux process isolation, unique user IDs (UIDs) for most processes, and tightly restricted fi le system permissions.

Android shares Linux’s UID/group ID (GID) paradigm, but does not have the traditional passwd and group fi les for its source of user and group credentials.

Instead, Android defi nes a map of names to unique identifi ers known as Android IDs (AIDs). The initial AID mapping contains reserved, static entries for privileged

and system-critical users, such as the system user/group. Android also reserves AID ranges used for provisioning app UIDs. Versions of Android after 4.1 added additional AID ranges for multiple user profi les and isolated process users (e.g., for further sandboxing of Chrome). You can fi nd defi nitions for AIDs in system/core/

include/private/android_filesystem_config.h in the Android Open Source Project (AOSP) tree. The following shows an excerpt that was edited for brevity:

#define AID_ROOT 0 /* traditional unix root user */

#define AID_SYSTEM 1000 /* system server */

#define AID_RADIO 1001 /* telephony subsystem, RIL */

#define AID_BLUETOOTH 1002 /* bluetooth subsystem */

...

#define AID_SHELL 2000 /* adb and debug shell user */

#define AID_CACHE 2001 /* cache access */

#define AID_DIAG 2002 /* access to diagnostic resources */

/* The 3000 series are intended for use as supplemental group id's only.

* They indicate special Android capabilities that the kernel is aware of. */

#define AID_NET_BT_ADMIN 3001 /* bluetooth: create any socket */

#define AID_NET_BT 3002 /* bluetooth: create sco, rfcomm or l2cap sockets */

#define AID_INET 3003 /* can create AF_INET and AF_INET6 sockets */

#define AID_NET_RAW 3004 /* can create raw INET sockets */

...

#define AID_APP 10000 /* first app user */

#define AID_ISOLATED_START 99000 /* start of uids for fully

isolated sandboxed processes */

#define AID_ISOLATED_END 99999 /* end of uids for fully

isolated sandboxed processes */

#define AID_USER 100000 /* offset for uid ranges for each user */

In addition to AIDs, Android uses supplementary groups to enable pro-cesses to access shared or protected resources. For example, membership in the sdcard_rw group allows a process to both read and write the /sdcard directory, as its mount options restrict which groups can read and write. This is similar to how supplementary groups are used in many Linux distributions.

N O T E Though all AID entries map to both a UID and GID, the UID may not necessarily be used to represent a user on the system. For instance, AID_SDCARD_RW maps to sdcard_rw, but is used only as a supplemental group, not as a UID on the system.

Aside from enforcing fi le system access, supplementary groups may also be used to grant processes additional rights. The AID_INET group, for instance, allows for users to open AF_INET and AF_INET6 sockets. In some cases, rights may also come in the form of a Linux capability. For example, membership in the AID_INET_ADMIN group grants the CAP_NET_ADMIN capability, allowing the user to confi gure network interfaces and routing tables. Other similar, network-related groups are cited later in the “Paranoid Networking” section.

In version 4.3 and later, Android increases its use of Linux capabilities. For example, Android 4.3 changed the /system/bin/run-as binary from being set-UID root to using Linux capabilities to access privileged resources. Here, this capability facilitates access to the packages.list fi le.

N O T E A complete discussion on Linux capabilities is out of the scope of this chapter. You can ﬁ nd more information about Linux process security and Linux capabilities in the Linux kernel’s Documentation/security/credentials.txt and the capabilities manual page, respectively.

When applications execute, their UID, GID, and supplementary groups are assigned to the newly created process. Running under a unique UID and GID enables the operating system to enforce lower-level restrictions in the kernel, and for the runtime to control inter-app interaction. This is the crux of the Android sandbox.

The following snippet shows the output of the ps command on an HTC One V. Note the owning UID on the far left, each of which are unique for each app process:

app_16 4089 1451 304080 31724 ... S com.htc.bgp

app_35 4119 1451 309712 30164 ... S com.google.android.calendar app_155 4145 1451 318276 39096 ... S com.google.android.apps.plus app_24 4159 1451 307736 32920 ... S android.process.media

app_151 4247 1451 303172 28032 ... S com.htc.lockscreen app_49 4260 1451 303696 28132 ... S com.htc.weather.bg app_13 4277 1451 453248 68260 ... S com.android.browser

Applications can also share UIDs, by way of a special directive in the application package. This is discussed further in the “Major Application Components” section.

Under the hood, the user and group names displayed for the process are actually provided by Android-specifi c implementations of the POSIX functions typically used for setting and fetching of these values. For instance, consider the getpwuid function (defi ned in stubs.cpp in the Bionic library):

345 passwd* getpwuid(uid_t uid) { // NOLINT: implementing bad function.

346 stubs_state_t* state = __stubs_state();

347 if (state == NULL) { 348 return NULL;

349 } 350

351 passwd* pw = android_id_to_passwd(state, uid);

352 if (pw != NULL) { 353 return pw;

354 }

355 return app_id_to_passwd(uid, state);

356 }

Like its brethren, getpwuid in turn calls additional Android-specifi c functions, such as android_id_to_passwd and app_id_to_passwd. These functions then populate a Unix password structure with the corresponding AID’s informa-tion. The android_id_to_passwd function calls android_iinfo_to_passwd to accomplish this:

static passwd* android_iinfo_to_passwd(stubs_state_t* state,

const android_id_info* iinfo) { snprintf(state->dir_buffer_, sizeof(state->dir_buffer_), "/");

snprintf(state->sh_buffer_, sizeof(state->sh_buffer_),

"/system/bin/sh");

passwd* pw = &state->passwd_;

pw->pw_name = (char*) iinfo->name;

pw->pw_uid = iinfo->aid;

pw->pw_gid = iinfo->aid;

pw->pw_dir = state->dir_buffer_;

pw->pw_shell = state->sh_buffer_;

return pw;

}

Android Permissions

The Android permissions model is multifaceted: There are API permissions, fi le system permissions, and IPC permissions. Oftentimes, there is an intertwining of each of these. As previously mentioned, some high-level permissions map back to lower-level OS capabilities. This could include actions such as opening sockets, Bluetooth devices, and certain fi le system paths.

To determine the app user’s rights and supplemental groups, Android pro-cesses high-level permissions specifi ed in an app package’s AndroidManifest .xml fi le (the manifest and permissions are covered in more detail in the “Major Application Components” section). Applications’ permissions are extracted from the application’s manifest at install time by the PackageManager and stored in /data/system/packages.xml. These entries are then used to grant the appropriate

rights at the instantiation of the app’s process (such as setting supplemental GIDs). The following snippet shows the Google Chrome package entry inside packages.xml, including the unique userId for this app as well as the permis-sions it requests:

<package name="com.android.chrome"

codePath="/data/app/com.android.chrome-1.apk"

nativeLibraryPath="/data/data/com.android.chrome/lib"

flags="0" ft="1422a161aa8" it="1422a163b1a"

ut="1422a163b1a" version="1599092" userId="10082"

installer="com.android.vending">

</sigs>

<perms>

...

...

...

</perms>

</package>

The permission-to-group mappings are stored in /etc/permissions/

platform.xml. These are used to determine supplemental group IDs to set for the application. The following snippet shows some of these mappings:

...

</permission>

</permission>

</permission>

</permission>

...

The rights defi ned in package entries are later enforced in one of two ways.

The fi rst type of checking is done at the time of a given method invocation and is enforced by the runtime. The second type of checking is enforced at a lower level within the OS by a library or the kernel itself.

API Permissions

API permissions include those that are used for controlling access to high-level functionality within the Android API/framework and, in some cases, third-party frameworks. An example of a common API permission is READ_PHONE_STATE, which is defi ned in the Android documentation as allowing

“read only access to phone state.” An app that requests and is subsequently granted this permission would therefore be able to call a variety of meth-ods related to querying phone information. This would include methmeth-ods in the TelephonyManager class, like getDeviceSoftwareVersion, getDeviceId, getDeviceId and more.

As mentioned earlier, some API permissions correspond to kernel-level enforce-ment mechanisms. For example, being granted the INTERNET permission means the requesting app’s UID is added as a member of the inet group (GID 3003).

Membership in this group grants the user the ability to open AF_INET and AF_INET6 sockets, which is needed for higher-level API functionality, such as creating an HttpURLConnection object.

In Chapter 4 we also discuss some oversights and issues with API permis-sions and their enforcement.

File System Permissions

Android’s application sandbox is heavily supported by tight Unix fi le system permissions. Applications’ unique UIDs and GIDs are, by default, given access only to their respective data storage paths on the fi le system. Note the UIDs and GIDs (in the second and third columns) in the following directory listing.

They are unique for these directories, and their permissions are such that only those UIDs and GIDs may access the contents therein:

root@android:/ # ls -l /data/data

drwxr-x--x u0_a3 u0_a3 ... com.android.browser drwxr-x--x u0_a4 u0_a4 ... com.android.calculator2 drwxr-x--x u0_a5 u0_a5 ... com.android.calendar drwxr-x--x u0_a24 u0_a24 ... com.android.camera ...

drwxr-x--x u0_a55 u0_a55 ... com.twitter.android drwxr-x--x u0_a56 u0_a56 ... com.ubercab

drwxr-x--x u0_a53 u0_a53 ... com.yougetitback.androidapplication.virgin.

mobile

drwxr-x--x u0_a31 u0_a31 ... jp.co.omronsoft.openwnn

Subsequently, fi les created by applications will have appropriate fi le permissions set. The following listing shows an application’s data directory, with ownership and permissions on subdirectories and fi les set only for the app’s UID and GID:

root@android:/data/data/com.twitter.android # ls -lR

-rw--- u0_a55 u0_a55 16928 2013-10-22 18:17 global.db-journal ./files:

-rw-rw---- u0_a55 u0_a55 155 2013-10-17 00:07 com.crashlytics.prefs.

xml

-rw-rw---- u0_a55 u0_a55 143 2013-10-17 00:07 com.twitter.android_preferences.xml

As mentioned previously, certain supplemental GIDs are used for access to shared resources, such as SD cards or other external storage. As an example, note the output of the mount and ls commands on an HTC One V, highlighting the /mnt/sdcard path:

Here you see that the SD card is mounted with GID 1015, which corresponds to the sdcard_rw group. Applications requesting the WRITE_EXTERNAL_STORAGE permission will have their UID added to this group, granting them write access to this path.

IPC Permissions

IPC permissions are those that relate directly to communication between app components (and some system IPC facilities), though there is some overlap with API permissions. The declaration and enforcement of these permissions may occur at different levels, including the runtime, library functions, or directly in the application itself. Specifi cally, this permission set applies to the major Android application components that are built upon Android’s Binder IPC mechanism. The details of these components and Binder itself are presented later in this chapter.

Dans le document ffi rs.indd 01:50:14:PM 02/28/2014 Page ii (Page 59-66)