1page.title=System and kernel security 2@jd:body 3 4<!-- 5 Copyright 2014 The Android Open Source Project 6 7 Licensed under the Apache License, Version 2.0 (the "License"); 8 you may not use this file except in compliance with the License. 9 You may obtain a copy of the License at 10 11 http://www.apache.org/licenses/LICENSE-2.0 12 13 Unless required by applicable law or agreed to in writing, software 14 distributed under the License is distributed on an "AS IS" BASIS, 15 WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 16 See the License for the specific language governing permissions and 17 limitations under the License. 18--> 19<div id="qv-wrapper"> 20 <div id="qv"> 21 <h2>In this document</h2> 22 <ol id="auto-toc"></ol> 23 </div> 24</div> 25 26<p>At the operating system level, the Android platform provides the security of 27 the Linux kernel, as well as a secure inter-process communication (IPC) 28 facility to enable secure communication between applications running in 29 different processes. These security features at the OS level ensure that even 30 native code is constrained by the Application Sandbox. Whether that code is 31 the result of included application behavior or a exploitation of an application 32 vulnerability, the system would prevent the rogue application from harming 33 other applications, the Android system, or the device itself.</p> 34<h3 id="linux-security">Linux Security</h3> 35<p>The foundation of the Android platform is the Linux kernel. The Linux kernel 36 itself has been in widespread use for years, and is used in millions of 37 security-sensitive environments. Through its history of constantly being 38 researched, attacked, and fixed by thousands of developers, Linux has become a 39 stable and secure kernel trusted by many corporations and security 40 professionals.</p> 41<p>As the base for a mobile computing environment, the Linux kernel provides 42 Android with several key security features, including:</p> 43<ul> 44 <li>A user-based permissions model</li> 45 <li>Process isolation</li> 46 <li>Extensible mechanism for secure IPC</li> 47 <li>The ability to remove unnecessary and potentially insecure parts of the kernel</li> 48</ul> 49<p>As a multiuser operating system, a fundamental security objective of the Linux 50 kernel is to isolate user resources from one another. The Linux security 51 philosophy is to protect user resources from one another. Thus, Linux:</p> 52<ul> 53 <li>Prevents user A from reading user B's files</li> 54 <li>Ensures that user A does not exhaust user B's memory</li> 55 <li>Ensures that user A does not exhaust user B's CPU resources</li> 56 <li>Ensures that user A does not exhaust user B's devices (e.g. telephony, GPS, 57 bluetooth)</li> 58</ul> 59<h3 id="the-application-sandbox">The Application Sandbox</h3> 60<p>The Android platform takes advantage of the Linux user-based protection as a 61 means of identifying and isolating application resources. The Android system 62 assigns a unique user ID (UID) to each Android application and runs it as that user 63 in a separate process. This approach is different from other operating systems 64 (including the traditional Linux configuration), where multiple applications 65 run with the same user permissions.</p> 66<p>This sets up a kernel-level Application Sandbox. The kernel enforces security 67 between applications and the system at the process level through standard Linux 68 facilities, such as user and group IDs that are assigned to applications. By 69 default, applications cannot interact with each other and applications have 70 limited access to the operating system. If application A tries to do something 71 malicious like read application B's data or dial the phone without permission 72 (which is a separate application), then the operating system protects against 73 this because application A does not have the appropriate user privileges. The 74 sandbox is simple, auditable, and based on decades-old UNIX-style user 75 separation of processes and file permissions.</p> 76<p>Since the Application Sandbox is in the kernel, this security model extends to 77 native code and to operating system applications. All of the software above the 78 kernel in <em>Figure 1</em>, including operating system libraries, application 79 framework, application runtime, and all applications run within the Application 80 Sandbox. On some platforms, developers are constrained to a specific 81 development framework, set of APIs, or language in order to enforce security. 82 On Android, there are no restrictions on how an application can be written that 83 are required to enforce security; in this respect, native code is just as 84 secure as interpreted code.</p> 85<p>In some operating systems, memory corruption errors generally lead to 86 completely compromising the security of the device. This is not the case in 87 Android due to all applications and their resources being sandboxed at the OS 88 level. A memory corruption error will only allow arbitrary code execution in 89 the context of that particular application, with the permissions established by 90 the operating system.</p> 91<p>Like all security features, the Application Sandbox is not unbreakable. 92 However, to break out of the Application Sandbox in a properly configured 93 device, one must compromise the security of the the Linux kernel.</p> 94<h3 id="system-partition-and-safe-mode">System Partition and Safe Mode</h3> 95<p>The system partition contains Android's kernel as well as the operating system 96 libraries, application runtime, application framework, and applications. This 97 partition is set to read-only. When a user boots the device into Safe Mode, 98 only core Android applications are available. This ensures that the user can 99 boot their phone into an environment that is free of third-party software.</p> 100<h3 id="filesystem-permissions">Filesystem Permissions</h3> 101<p>In a UNIX-style environment, filesystem permissions ensure that one user cannot 102 alter or read another user's files. In the case of Android, each application 103 runs as its own user. Unless the developer explicitly exposes files to other 104 applications, files created by one application cannot be read or altered by 105 another application.</p> 106<h3 id="se-linux">Security-Enhanced Linux</h3> 107<p>Android uses Security-Enhanced 108 Linux (SELinux) to apply access control policies and establish an environment of 109 mandatory access control (mac). See <a 110href="{@docRoot}security/selinux/index.html">Validating 111 Security-Enhanced Linux in 112 Android</a> for details.</p> 113<h3 id="crypto">Cryptography</h3> 114<p> Android provides a set of cryptographic APIs for use by applications. These 115 include implementations of standard and commonly used cryptographic primitives 116 such as AES, RSA, DSA, and SHA. Additionally, APIs are provided for higher level 117 protocols such as SSL and HTTPS. </p> 118<p> Android 4.0 introduced the <a href="http://developer.android.com/reference/android/security/KeyChain.html">KeyChain</a> class to allow applications to use the system credential storage for private 119 keys and certificate chains. </p> 120<h3>Rooting of Devices</h3> 121<p> By default, on Android only the kernel and a small subset of the core 122 applications run with root permissions. Android does not prevent a user or 123 application with root permissions from modifying the operating system, kernel, 124 and any other application. In general, root has full access to all 125 applications and all application data. Users that change the permissions on an 126 Android device to grant root access to applications increase the security 127 exposure to malicious applications and potential application flaws. </p> 128<p> The ability to modify an Android device they own is important to developers 129 working with the Android platform. On many Android devices users have the 130 ability to unlock the bootloader in order to allow installation of an alternate 131 operating system. These alternate operating systems may allow an owner to gain 132 root access for purposes of debugging applications and system components or to 133 access features not presented to applications by Android APIs. </p> 134<p> On some devices, a person with physical control of a device and a USB cable is 135 able to install a new operating system that provides root privileges to the 136 user. To protect any existing user data from compromise the bootloader unlock 137 mechanism requires that the bootloader erase any existing user data as part of 138 the unlock step. Root access gained via exploiting a kernel bug or security 139 hole can bypass this protection. </p> 140<p> Encrypting data with a key stored on-device does not protect the application 141 data from root users. Applications can add a layer of data protection using 142 encryption with a key stored off-device, such as on a server or a user 143 password. This approach can provide temporary protection while the key is not 144 present, but at some point the key must be provided to the application and it 145 then becomes accessible to root users. </p> 146<p> A more robust approach to protecting data from root users is through the use of 147 hardware solutions. OEMs may choose to implement hardware solutions that limit 148 access to specific types of content such as DRM for video playback, or the 149 NFC-related trusted storage for Google wallet. </p> 150<p> In the case of a lost or stolen device, full filesystem encryption on Android 151 devices uses the device password to protect the encryption key, so modifying 152 the bootloader or operating system is not sufficient to access user data 153 without the user’s device password. </p> 154<h3>User Security Features</h3> 155<h4 id="filesystem-encryption">Filesystem Encryption</h4> 156<p>Android 3.0 and later provides full filesystem encryption, so all user data can 157 be encrypted in the kernel using the dmcrypt implementation of AES128 with CBC 158 and ESSIV:SHA256. The encryption key is protected by AES128 using a key 159 derived from the user password, preventing unauthorized access to stored data 160 without the user device password. To provide resistance against systematic 161 password guessing attacks (e.g. “rainbow tables” or brute force), the 162 password is combined with a random salt and hashed repeatedly with SHA1 using 163 the standard PBKDF2 algorithm prior to being used to decrypt the filesystem 164 key. To provide resistance against dictionary password guessing attacks, 165 Android provides password complexity rules that can be set by the device 166 administrator and enforced by the operating system. Filesystem encryption 167 requires the use of a user password, pattern-based screen lock is not supported.</p> 168<p>More details on implementation of filesystem encryption are available at <a 169href="{@docRoot}security/encryption/index.html">Encryption</a>.</p> 170<h3 id="password-protection">Password Protection</h3> 171<p>Android can be configured to verify a user-supplied password prior to providing 172 access to a device. In addition to preventing unauthorized use of the device, 173 this password protects the cryptographic key for full filesystem encryption.</p> 174<p>Use of a password and/or password complexity rules can be required by a device 175 administrator.</p> 176<h3 id="device-administration">Device Administration</h3> 177<p>Android 2.2 and later provide the Android Device Administration API, which 178 provides device administration features at the system level. For example, the 179 built-in Android Email application uses the APIs to improve Exchange support. 180 Through the Email application, Exchange administrators can enforce password 181 policies — including alphanumeric passwords or numeric PINs — across 182 devices. Administrators can also remotely wipe (that is, restore factory 183 defaults on) lost or stolen handsets.</p> 184<p>In addition to use in applications included with the Android system, these APIs 185 are available to third-party providers of Device Management solutions. Details 186 on the API are provided at <a 187href="https://developer.android.com/guide/topics/admin/device-admin.html">Device 188Administration</a>.</p> 189