.png)
Understanding Android System Architecture
The general Android architecture has, at times, been described as “Java on
Linux.” However, this is a bit of a misnomer and doesn’t entirely do justice to the
complexity and architecture of the platform. The overall architecture consists
of components that fall into fi ve main layers, including Android applications,
the Android Framework, the Dalvik virtual machine, user-space native code,
and the Linux kernel. Figure 2-1 shows how these layers comprise the Android
software stack.
Source: Karim Yaghmour of Opersys Inc. (Creative Commons Share-Alike 3.0 license)
http://www.slideshare.net/opersys/inside-androids-ui
Android applications allow developers to extend and improve the functionality
of a device without having to alter lower levels. In turn, the Android Framework
provides developers with a rich API that has access to all of the various facilities
an Android device has to offer—the “glue” between apps and the Dalvik virtual
machine. This includes building blocks to enable developers to perform common
tasks such as managing user interface (UI) elements, accessing shared data stores,
and passing messages between application components.
Both Android applications and the Android Framework are developed in the
Java programming language and execute within the Dalvik virtual machine
(DalvikVM). This virtual machine (VM) was specially designed to provide an
effi cient abstraction layer to the underlying operating system. The DalvikVM
is a register-based VM that interprets the Dalvik Executable (DEX) byte code
format. In turn, the DalvikVM relies on functionality provided by a number of
supporting native code libraries.
The user-space native code components of Android includes system services,
such as vold and DBus; networking services, such as dhcpd and wpa_supplicant;
and libraries, such as bionic libc, WebKit, and OpenSSL. Some of these services
and libraries communicate with kernel-level services and drivers, whereas others
simply facilitate lower-level native operations for managed code.
Source: Karim Yaghmour of Opersys Inc. (Creative Commons Share-Alike 3.0 license)
http://www.slideshare.net/opersys/inside-androids-ui
Android applications allow developers to extend and improve the functionality
of a device without having to alter lower levels. In turn, the Android Framework
provides developers with a rich API that has access to all of the various facilities
an Android device has to offer—the “glue” between apps and the Dalvik virtual
machine. This includes building blocks to enable developers to perform common
tasks such as managing user interface (UI) elements, accessing shared data stores,
and passing messages between application components.
Both Android applications and the Android Framework are developed in the
Java programming language and execute within the Dalvik virtual machine
(DalvikVM). This virtual machine (VM) was specially designed to provide an
effi cient abstraction layer to the underlying operating system. The DalvikVM
is a register-based VM that interprets the Dalvik Executable (DEX) byte code
format. In turn, the DalvikVM relies on functionality provided by a number of
supporting native code libraries.
The user-space native code components of Android includes system services,
such as vold and DBus; networking services, such as dhcpd and wpa_supplicant;
and libraries, such as bionic libc, WebKit, and OpenSSL. Some of these services
and libraries communicate with kernel-level services and drivers, whereas others
simply facilitate lower-level native operations for managed code.
Android's underpinning is the Linus kernel. Android made numerous additions
and changes to the kernel source tree, some of which have their own security
ramifi cations. We discuss these issues in greater detail in Chapters 3, 10, and
12. Kernel-level drivers also provide additional functionality, such as camera
access, Wi-Fi, and other network device access. Of particular note is the Binder
driver, which implements inter-process communication (IPC).
The “Looking Closer at the Layers” section later in this chapter examines key
components from each layer in more detail.
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 permissions 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 permissions 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 privilegedand 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.
NOTE 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.
NOTE A complete discussion on Linux capabilities is out of the scope of this
chapter. You can fi 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;
.png)
.jpeg)
.png)
.jpeg)
