blob: 12ae1bb493fbdc35954615e1c6757361036137d8 [file] [log] [blame]
page.title=System and kernel security
Copyright 2014 The Android Open Source Project
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
See the License for the specific language governing permissions and
limitations under the License.
<div id="qv-wrapper">
<div id="qv">
<h2>In this document</h2>
<ol id="auto-toc"></ol>
<p>At the operating system level, the Android platform provides the security of
the Linux kernel, as well as a secure inter-process communication (IPC)
facility to enable secure communication between applications running in
different processes. These security features at the OS level ensure that even
native code is constrained by the Application Sandbox. Whether that code is
the result of included application behavior or a exploitation of an application
vulnerability, the system would prevent the rogue application from harming
other applications, the Android system, or the device itself.</p>
<h3 id="linux-security">Linux Security</h3>
<p>The foundation of the Android platform is the Linux kernel. The Linux kernel
itself has been in widespread use for years, and is used in millions of
security-sensitive environments. Through its history of constantly being
researched, attacked, and fixed by thousands of developers, Linux has become a
stable and secure kernel trusted by many corporations and security
<p>As the base for a mobile computing environment, the Linux kernel provides
Android with several key security features, including:</p>
<li>A user-based permissions model</li>
<li>Process isolation</li>
<li>Extensible mechanism for secure IPC</li>
<li>The ability to remove unnecessary and potentially insecure parts of the kernel</li>
<p>As a multiuser operating system, a fundamental security objective of the Linux
kernel is to isolate user resources from one another. The Linux security
philosophy is to protect user resources from one another. Thus, Linux:</p>
<li>Prevents user A from reading user B's files</li>
<li>Ensures that user A does not exhaust user B's memory</li>
<li>Ensures that user A does not exhaust user B's CPU resources</li>
<li>Ensures that user A does not exhaust user B's devices (e.g. telephony, GPS,
<h3 id="the-application-sandbox">The Application Sandbox</h3>
<p>The Android platform takes advantage of the Linux user-based protection as a
means of identifying and isolating application resources. The Android system
assigns a unique user ID (UID) to each Android application and runs it as that user
in a separate process. This approach is different from other operating systems
(including the traditional Linux configuration), where multiple applications
run with the same user permissions.</p>
<p>This sets up a kernel-level Application Sandbox. The kernel enforces security
between applications and the system at the process level through standard Linux
facilities, such as user and group IDs that are assigned to applications. By
default, applications cannot interact with each other and applications have
limited access to the operating system. If application A tries to do something
malicious like read application B's data or dial the phone without permission
(which is a separate application), then the operating system protects against
this because application A does not have the appropriate user privileges. The
sandbox is simple, auditable, and based on decades-old UNIX-style user
separation of processes and file permissions.</p>
<p>Since the Application Sandbox is in the kernel, this security model extends to
native code and to operating system applications. All of the software above the
kernel in <em>Figure 1</em>, including operating system libraries, application
framework, application runtime, and all applications run within the Application
Sandbox. On some platforms, developers are constrained to a specific
development framework, set of APIs, or language in order to enforce security.
On Android, there are no restrictions on how an application can be written that
are required to enforce security; in this respect, native code is just as
secure as interpreted code.</p>
<p>In some operating systems, memory corruption errors generally lead to
completely compromising the security of the device. This is not the case in
Android due to all applications and their resources being sandboxed at the OS
level. A memory corruption error will only allow arbitrary code execution in
the context of that particular application, with the permissions established by
the operating system.</p>
<p>Like all security features, the Application Sandbox is not unbreakable.
However, to break out of the Application Sandbox in a properly configured
device, one must compromise the security of the the Linux kernel.</p>
<h3 id="system-partition-and-safe-mode">System Partition and Safe Mode</h3>
<p>The system partition contains Android's kernel as well as the operating system
libraries, application runtime, application framework, and applications. This
partition is set to read-only. When a user boots the device into Safe Mode,
only core Android applications are available. This ensures that the user can
boot their phone into an environment that is free of third-party software.</p>
<h3 id="filesystem-permissions">Filesystem Permissions</h3>
<p>In a UNIX-style environment, filesystem permissions ensure that one user cannot
alter or read another user's files. In the case of Android, each application
runs as its own user. Unless the developer explicitly exposes files to other
applications, files created by one application cannot be read or altered by
another application.</p>
<h3 id="se-linux">Security-Enhanced Linux</h3>
<p>Android uses Security-Enhanced
Linux (SELinux) to apply access control policies and establish an environment of
mandatory access control (mac). See <a
Security-Enhanced Linux in
Android</a> for details.</p>
<h3 id="crypto">Cryptography</h3>
<p> Android provides a set of cryptographic APIs for use by applications. These
include implementations of standard and commonly used cryptographic primitives
such as AES, RSA, DSA, and SHA. Additionally, APIs are provided for higher level
protocols such as SSL and HTTPS. </p>
<p> Android 4.0 introduced the <a href="">KeyChain</a> class to allow applications to use the system credential storage for private
keys and certificate chains. </p>
<h3>Rooting of Devices</h3>
<p> By default, on Android only the kernel and a small subset of the core
applications run with root permissions. Android does not prevent a user or
application with root permissions from modifying the operating system, kernel,
and any other application. In general, root has full access to all
applications and all application data. Users that change the permissions on an
Android device to grant root access to applications increase the security
exposure to malicious applications and potential application flaws. </p>
<p> The ability to modify an Android device they own is important to developers
working with the Android platform. On many Android devices users have the
ability to unlock the bootloader in order to allow installation of an alternate
operating system. These alternate operating systems may allow an owner to gain
root access for purposes of debugging applications and system components or to
access features not presented to applications by Android APIs. </p>
<p> On some devices, a person with physical control of a device and a USB cable is
able to install a new operating system that provides root privileges to the
user. To protect any existing user data from compromise the bootloader unlock
mechanism requires that the bootloader erase any existing user data as part of
the unlock step. Root access gained via exploiting a kernel bug or security
hole can bypass this protection. </p>
<p> Encrypting data with a key stored on-device does not protect the application
data from root users. Applications can add a layer of data protection using
encryption with a key stored off-device, such as on a server or a user
password. This approach can provide temporary protection while the key is not
present, but at some point the key must be provided to the application and it
then becomes accessible to root users. </p>
<p> A more robust approach to protecting data from root users is through the use of
hardware solutions. OEMs may choose to implement hardware solutions that limit
access to specific types of content such as DRM for video playback, or the
NFC-related trusted storage for Google wallet. </p>
<p> In the case of a lost or stolen device, full filesystem encryption on Android
devices uses the device password to protect the encryption key, so modifying
the bootloader or operating system is not sufficient to access user data
without the user’s device password. </p>
<h3>User Security Features</h3>
<h4 id="filesystem-encryption">Filesystem Encryption</h4>
<p>Android 3.0 and later provides full filesystem encryption, so all user data can
be encrypted in the kernel using the dmcrypt implementation of AES128 with CBC
and ESSIV:SHA256. The encryption key is protected by AES128 using a key
derived from the user password, preventing unauthorized access to stored data
without the user device password. To provide resistance against systematic
password guessing attacks (e.g. “rainbow tables” or brute force), the
password is combined with a random salt and hashed repeatedly with SHA1 using
the standard PBKDF2 algorithm prior to being used to decrypt the filesystem
key. To provide resistance against dictionary password guessing attacks,
Android provides password complexity rules that can be set by the device
administrator and enforced by the operating system. Filesystem encryption
requires the use of a user password, pattern-based screen lock is not supported.</p>
<p>More details on implementation of filesystem encryption are available at <a
<h3 id="password-protection">Password Protection</h3>
<p>Android can be configured to verify a user-supplied password prior to providing
access to a device. In addition to preventing unauthorized use of the device,
this password protects the cryptographic key for full filesystem encryption.</p>
<p>Use of a password and/or password complexity rules can be required by a device
<h3 id="device-administration">Device Administration</h3>
<p>Android 2.2 and later provide the Android Device Administration API, which
provides device administration features at the system level. For example, the
built-in Android Email application uses the APIs to improve Exchange support.
Through the Email application, Exchange administrators can enforce password
policies — including alphanumeric passwords or numeric PINs — across
devices. Administrators can also remotely wipe (that is, restore factory
defaults on) lost or stolen handsets.</p>
<p>In addition to use in applications included with the Android system, these APIs
are available to third-party providers of Device Management solutions. Details
on the API are provided at <a