fuquan/allwinner_a64
1
1
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

upload android base code part8

Browse source
This commit is contained in:
August 2018-08-08 20:10:12 +08:00
parent 841ae54672
commit 5425409085
57075 changed files with 9846578 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

1119
android/docs/source.android.com/en/security/overview/acknowledgements.html Normal file
View file

File diff suppressed because it is too large Load diff

383
android/docs/source.android.com/en/security/overview/app-security.html Normal file
View file

@ -0,0 +1,383 @@
<html devsite>
<head>
<title>Application security</title>
<meta name="project_path" value="/_project.yaml" />
<meta name="book_path" value="/_book.yaml" />
</head>
<body>
<!--
Copyright 2017 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
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
-->
<h2 id="elements-of-applications">Elements of Applications</h2>
<p>Android provides an open source platform and application environment for mobile
devices. The core operating system is based on the Linux kernel. Android
applications are most often written in the Java programming language and run in
the Dalvik virtual machine. However, applications can also be written in native
code. Applications are installed from a single file with the .apk file
extension.</p>
<p>The main Android application building blocks are:</p>
<ul>
<li>
<p><strong>AndroidManifest.xml</strong>: The <a
href="https://developer.android.com/guide/topics/manifest/manifest-intro.html">AndroidManifest.xml</a>
file is the control file that tells the system what to do with
all the top-level components (specifically activities, services, broadcast
receivers, and content providers described below) in an application. This also
specifies which permissions are required.</p>
</li>
<li>
<p><strong>Activities</strong>: An <a
href="https://developer.android.com/guide/topics/fundamentals/activities.html">Activity</a>
is, generally, the code for a single, user-focused task. It usually
includes displaying a UI to the user, but it does not have to -- some
Activities never display UIs. Typically, one of the application's Activities
is the entry point to an application.</p>
</li>
<li>
<p><strong>Services</strong>: A <a
href="https://developer.android.com/guide/topics/fundamentals/services.html">Service</a>
is a body of code that runs in the background. It can run in its own
process, or in the context of another application's process. Other components "bind" to
a Service and invoke methods on it via remote procedure calls. An example of a
Service is a media player: even when the user quits the media-selection UI, the
user probably still intends for music to keep playing. A Service keeps the
music going even when the UI has completed.</p>
</li>
<li>
<p><strong>Broadcast Receiver</strong>: A <a
href="https://developer.android.com/reference/android/content/BroadcastReceiver.html">BroadcastReceiver</a>
is an object that is instantiated when an IPC mechanism
known as an <a
href="https://developer.android.com/reference/android/content/Intent.html">Intent</a>
is issued by the operating system or another application. An application
may register a receiver for the low battery message, for example, and
change its behavior based on that information.</p>
</li>
</ul>
<h2 id="the-android-permission-model-accessing-protected-apis">The Android Permission Model: Accessing Protected APIs</h2>
<p>All applications on Android run in an <a
href="/security/overview/kernel-security#the-application-sandbox">Application Sandbox</a>.
By default, an Android application can only access a limited range of system
resources. The system manages Android application access to resources that, if
used incorrectly or maliciously, could adversely impact the user experience,
the network, or data on the device.</p>
<p>These restrictions are implemented in a variety of different forms. Some
capabilities are restricted by an intentional lack of APIs to the sensitive
functionality (e.g. there is no Android API for directly manipulating the SIM
card). In some instances, separation of roles provides a security measure, as
with the per-application isolation of storage. In other instances, the
sensitive APIs are intended for use by trusted applications and protected
through a security mechanism known as Permissions.</p>
<p>These protected APIs include:</p>
<ul>
<li>Camera functions</li>
<li>Location data (GPS)</li>
<li>Bluetooth functions</li>
<li>Telephony functions</li>
<li>SMS/MMS functions</li>
<li>Network/data connections</li>
</ul>
<p>These resources are only accessible through the operating system. To make use
of the protected APIs on the device, an application must define the
capabilities it needs in its manifest. When preparing to install an
application, the system displays a dialog to the user that indicates the
permissions requested and asks whether to continue the installation. If the
user continues with the installation, the system accepts that the user has
granted all of the requested permissions. The user can not grant or deny
individual permissions -- the user must grant or deny all of the requested
permissions as a block.</p>
<p>Once granted, the permissions are applied to the application as long as it is
installed. To avoid user confusion, the system does not notify the user again
of the permissions granted to the application, and applications that are
included in the core operating system or bundled by an OEM do not request
permissions from the user. Permissions are removed if an application is
uninstalled, so a subsequent re-installation will again result in display of
permissions.</p>
<p>Within the device settings, users are able to view permissions for applications
they have previously installed. Users can also turn off some functionality
globally when they choose, such as disabling GPS, radio, or wi-fi.</p>
<p>In the event that an application attempts to use a protected feature which has
not been declared in the application's manifest, the permission failure will
typically result in a security exception being thrown back to the application.
Protected API permission checks are enforced at the lowest possible level to
prevent circumvention. An example of the user messaging when an application is
installed while requesting access to protected APIs is shown in <em>Figure 2</em>.</p>
<p>The system default permissions are described at <a href="https://developer.android.com/reference/android/Manifest.permission.html">https://developer.android.com/reference/android/Manifest.permission.html</a>.
Applications may declare their own permissions for other applications to use.
Such permissions are not listed in the above location.</p>
<p>When defining a permission a protectionLevel attribute tells the system how the
user is to be informed of applications requiring the permission, or who is
allowed to hold a permission. Details on creating and using application
specific permissions are described at <a href="https://develo
per.android.com/guide/topics/security/security.html">https://developer.android.com/guide/topics/security/security.html</a>.</p>
<p>There are some device capabilities, such as the ability to send SMS broadcast
intents, that are not available to third-party applications, but that may be
used by applications pre-installed by the OEM. These permissions use the
signatureOrSystem permission.</p>
<h2 id="how-users-understand-third-party-applications">How Users Understand Third-Party Applications</h2>
<p>Android strives to make it clear to users when they are interacting with
third-party applications and inform the user of the capabilities those
applications have. Prior to installation of any application, the user is shown
a clear message about the different permissions the application is requesting.
After install, the user is not prompted again to confirm any permissions.</p>
<p>There are many reasons to show permissions immediately prior to installation
time. This is when user is actively reviewing information about the
application, developer, and functionality to determine whether it matches their
needs and expectations. It is also important that they have not yet
established a mental or financial commitment to the app, and can easily compare
the application to other alternative applications.</p>
<p>Some other platforms use a different approach to user notification, requesting
permission at the start of each session or while applications are in use. The
vision of Android is to have users switching seamlessly between applications at
will. Providing confirmations each time would slow down the user and prevent
Android from delivering a great user experience. Having the user review
permissions at install time gives the user the option to not install the
application if they feel uncomfortable.</p>
<p>Also, many user interface studies have shown that over-prompting the user
causes the user to start saying "OK" to any dialog that is shown. One of
Android's security goals is to effectively convey important security
information to the user, which cannot be done using dialogs that the user will
be trained to ignore. By presenting the important information once, and only
when it is important, the user is more likely to think about what they are
agreeing to.</p>
<p>Some platforms choose not to show any information at all about application
functionality. That approach prevents users from easily understanding and
discussing application capabilities. While it is not possible for all users to
always make fully informed decisions, the Android permissions model makes
information about applications easily accessible to a wide range of users. For
example, unexpected permissions requests can prompt more sophisticated users to
ask critical questions about application functionality and share their concerns
in places such as <a href="htts://play.google.com">Google Play</a> where they
are visible to all users.</p>
<table>
<tr>
<td><strong>Permissions at Application Install -- Google Maps</strong></td>
<td><strong>Permissions of an Installed Application -- Gmail</strong></td>
</tr>
<tr>
<td><img alt="Permissions at Application Install -- Google Maps" width=250
src="../images/image_install.png" /></td>
<td><img alt="Permissions of an Installed Application -- Gmail" width=250
src="../images/image_gmail_installed.png" id="figure1" /></td>
</tr>
</table>
<p class="img-caption">
<strong>Figure 1.</strong> Display of permissions for applications
</p>
<h2 id="interprocess-communication">Interprocess Communication</h2>
<p>Processes can communicate using any of the traditional UNIX-type mechanisms.
Examples include the filesystem, local sockets, or signals. However, the Linux
permissions still apply.</p>
<p>Android also provides new IPC mechanisms:</p>
<ul>
<li>
<p><strong>Binder</strong>: A lightweight capability-based remote procedure call mechanism
designed for high performance when performing in-process and cross-process
calls. Binder is implemented using a custom Linux driver. See <a href="https://developer
.android.com/reference/android/os/Binder.html">https://developer.android.com/reference/android/os/Binder.html</a>.</p>
</li>
<li>
<p><strong>Services</strong>: Services (discussed above) can provide interfaces directly
accessible using binder.</p>
</li>
<li>
<p><strong>Intents</strong>: An Intent is a simple message object that represents an
"intention" to do something. For example, if your application wants to display
a web page, it expresses its "Intent" to view the URL by creating an Intent
instance and handing it off to the system. The system locates some other piece
of code (in this case, the Browser) that knows how to handle that Intent, and
runs it. Intents can also be used to broadcast interesting events (such as a
notification) system-wide. See
<a href="https://developer.android.com/reference/android/content/Intent.html">https://developer.android.com/reference/android/content/Intent.html</a>.</p>
</li>
<li>
<p><strong>ContentProviders</strong>: A ContentProvider is a data storehouse that provides
access to data on the device; the classic example is the ContentProvider that
is used to access the user's list of contacts. An application can access data
that other applications have exposed via a ContentProvider, and an application
can also define its own ContentProviders to expose data of its own. See <a href="https://developer.android.com/reference/android/content/ContentProvider.html">https://developer.android.com/reference/android/content/ContentProvider.html</a>.</p>
</li>
</ul>
<p>While it is possible to implement IPC using other mechanisms such as network
sockets or world-writable files, these are the recommended Android IPC
frameworks. Android developers will be encouraged to use best practices around
securing users' data and avoiding the introduction of security vulnerabilities.</p>
<h2 id="cost-sensitive-apis">Cost-Sensitive APIs</h2>
<p>A cost sensitive API is any function that might generate a cost for the user or
the network. The Android platform has placed cost sensitive APIs in the list of
protected APIs controlled by the OS. The user will have to grant explicit
permission to third-party applications requesting use of cost sensitive APIs.
These APIs include:</p>
<ul>
<li>Telephony</li>
<li>SMS/MMS</li>
<li>Network/Data</li>
<li>In-App Billing</li>
<li>NFC Access</li>
</ul>
<p> Android 4.2 adds further control on the use of SMS. Android will provide a
notification if an application attempts to send SMS to a short code that uses
premium services which might cause additional charges. The user can choose
whether to allow the application to send the message or block it. </p>
<h2 id="sim-card-access">SIM Card Access</h2>
<p>Low level access to the SIM card is not available to third-party apps. The OS
handles all communications with the SIM card including access to personal
information (contacts) on the SIM card memory. Applications also cannot access
AT commands, as these are managed exclusively by the Radio Interface Layer
(RIL). The RIL provides no high level APIs for these commands.</p>
<h2 id="personal-information">Personal Information</h2>
<p>Android has placed APIs that provide access to user data into the set of
protected APIs. With normal usage, Android devices will also accumulate user
data within third-party applications installed by users. Applications that
choose to share this information can use Android OS permission checks to
protect the data from third-party applications.</p>
<img alt="Access to sensitive user data available only through protected
APIs" src="../images/permissions_check.png" id="figure2" />
<p class="img-caption">
<strong>Figure 2.</strong> Access to sensitive user data is available only through protected APIs
</p>
<p>System content providers that are likely to contain personal or personally
identifiable information such as contacts and calendar have been created with
clearly identified permissions. This granularity provides the user with clear
indication of the types of information that may be provided to the application.
During installation, a third-party application may request permission to
access these resources. If permission is granted, the application can be
installed and will have access to the data requested at any time when it is
installed.</p>
<p>Any applications which collect personal information will, by default, have that
data restricted only to the specific application. If an application chooses to
make the data available to other applications though IPC, the application
granting access can apply permissions to the IPC mechanism that are enforced by
the operating system.</p>
<h2 id="sensitive-data-input-devices">Sensitive Data Input Devices</h2>
<p>Android devices frequently provide sensitive data input devices that allow
applications to interact with the surrounding environment, such as camera,
microphone or GPS. For a third-party application to access these devices, it
must first be explicitly provided access by the user through the use of Android
OS Permissions. Upon installation, the installer will prompt the user
requesting permission to the sensor by name.</p>
<p>If an application wants to know the user's location, the application requires a
permission to access the user's location. Upon installation, the installer will
prompt the user asking if the application can access the user's location. At
any time, if the user does not want any application to access their location,
then the user can run the "Settings" application, go to "Location &amp; Security",
and uncheck the "Use wireless networks" and "Enable GPS satellites". This will
disable location based services for all applications on the user's device.</p>
<h2 id="device-metadata">Device Metadata</h2>
<p>Android also strives to restrict access to data that is not intrinsically
sensitive, but may indirectly reveal characteristics about the user, user
preferences, and the manner in which they use a device.</p>
<p>By default applications do not have access to operating system logs,
browser history, phone number, or hardware / network identification
information. If an application requests access to this information at install
time, the installer will prompt the user asking if the application can access
the information. If the user does not grant access, the application will not be
installed.</p>
<h2 id="certificate-authorities">Certificate authorities</h2>
<p>
Android includes a set of installed system Certificate Authorities, which are
trusted system-wide. Prior to Android 7.0, device manufacturers could modify the
set of CAs shipped on their devices. However, devices running 7.0 and above will
have a uniform set of system CAs as modification by device manufacturers is no
longer permitted.
</p>
<p>
To be added as a new public CA to the Android stock set, the CA must complete
the <a href="https://wiki.mozilla.org/CA:How_to_apply">Mozilla CA Inclusion
Process</a> and then file a feature request against Android (<a
href="https://code.google.com/p/android/issues/entry">https://code.google.com/p/android/issues/entry</a>)
to have the CA added to the stock Android CA set in the <a
href="https://android.googlesource.com/">Android Open Source Project</a>
(AOSP).
</p>
<p>
There are still CAs that are device-specific and should not be included in the
core set of AOSP CAs, like carriers’ private CAs that may be needed to securely
access components of the carrier’s infrastructure, such as SMS/MMS gateways.
Device manufacturers are encouraged to include the private CAs only in the
components/apps that need to trust these CAs. See <a
href="https://developer.android.com/preview/features/security-config.html">Network
Security Configuration</a> for more details.
</p>
<h2 id="application-signing">Application Signing</h2>
<p><a href="/security/apksigning/index.html">Code signing</a>
allows developers to identify the author of the application and to
update their application without creating complicated interfaces and
permissions. Every application that is run on the Android platform must be
signed by the developer. Applications that attempt to install without being
signed will rejected by either Google Play or the package installer on
the Android device.</p>
<p>On Google Play, application signing bridges the trust Google has with the
developer and the trust the developer has with their application. Developers
know their application is provided, unmodified to the Android device; and
developers can be held accountable for behavior of their application.</p>
<p>On Android, application signing is the first step to placing an application in
its Application Sandbox. The signed application certificate defines which user
id is associated with which application; different applications run under
different user IDs. Application signing ensures that one application cannot
access any other application except through well-defined IPC.</p>
<p>When an application (APK file) is installed onto an Android device, the Package
Manager verifies that the APK has been properly signed with the certificate
included in that APK. If the certificate (or, more accurately, the public key
in the certificate) matches the key used to sign any other APK on the device,
the new APK has the option to specify in the manifest that it will share a UID
with the other similarly-signed APKs.</p>
<p>Applications can be signed by a third-party (OEM, operator, alternative market)
or self-signed. Android provides code signing using self-signed certificates
that developers can generate without external assistance or permission.
Applications do not have to be signed by a central authority. Android currently
does not perform CA verification for application certificates.</p>
<p>Applications are also able to declare security permissions at the Signature
protection level, restricting access only to applications signed with the same
key while maintaining distinct UIDs and Application Sandboxes. A closer
relationship with a shared Application Sandbox is allowed via the <a href="https://developer.android.com/guide/topics/manifest/manifest-element.html#uid">shared UID
feature</a> where two or more applications signed with same developer key can
declare a shared UID in their manifest.</p>
<h2 id="app-verification">Application Verification</h2>
<p> Android 4.2 and later support application verification. Users can choose to
enable “Verify Apps" and have applications evaluated by an application verifier
prior to installation. App verification can alert the user if they try to
install an app that might be harmful; if an application is especially bad, it
can block installation. </p>
<h2 id="digital-rights-management">Digital Rights Management</h2>
<p>The Android platform provides an extensible DRM framework that lets
applications manage rights-protected content according to the license
constraints that are associated with the content. The DRM framework supports
many DRM schemes; which DRM schemes a device supports is left to the device
manufacturer.</p>
<p>The <a href="https://developer.android.com/reference/android/drm/package-summary.html">Android DRM
framework</a> is implemented in two architectural layers (see figure below):</p>
<ul>
<li>
<p>A DRM framework API, which is exposed to applications through the Android
application framework and runs through the Dalvik VM for standard applications.</p>
</li>
<li>
<p>A native code DRM manager, which implements the DRM framework and exposes an
interface for DRM plug-ins (agents) to handle rights management and decryption
for various DRM schemes</p>
</li>
</ul>
<p><img alt="Architecture of Digital Rights Management on Android
platform" src="/devices/images/ape_fwk_drm_2.png" id="figure3" /></p>
<p class="img-caption">
<strong>Figure 3.</strong> Architecture of Digital Rights Management on Android platform
</p>
</body>
</html>

389
android/docs/source.android.com/en/security/overview/implement.html Normal file
View file

@ -0,0 +1,389 @@
<html devsite>
<head>
<title>Implementing Security</title>
<meta name="project_path" value="/_project.yaml" />
<meta name="book_path" value="/_book.yaml" />
</head>
<body>
<!--
Copyright 2017 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
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
-->
<p>The Android Security Team regularly receives requests for information about
preventing potential security issues on Android devices. We also occasionally
spot check devices and let device manufacturers and affected partners know of
potential issues.</p>
<p>This page provides security best practices based on our experiences,
extending the
<a href="http://developer.android.com/guide/practices/security.html">Designing
for Security</a> documentation we've provided for developers and includes
details unique to building or installing system-level software on devices.</p>
<p>To facilitate adoption of these best practices, where possible the Android
Security Team incorporates tests into the
<a href="/compatibility/cts">Android Compatibility Test Suite</a> (CTS) and
<a href="http://tools.android.com/tips/lint">Android Lint</a>. We encourage
device implementers to contribute tests that can help other Android users (view
security-related tests at
<code>root/cts/tests/tests/security/src/android/security/cts</code>).</p>
<h2 id="dev-process">Development process</h2>
<p>Use the following best practices in your development processes and
environment.</p>
<h3 id="sec-review">Reviewing source code</h3>
<p> Source code review can detect a broad range of security issues, including
those identified in this document. Android strongly encourages both manual and
automated source code review. Best practices:</p>
<ul>
<li>Run <a href="http://tools.android.com/tips/lint">Android Lint</a> on all
application code using the Android SDK and correct any identified issues.</li>
<li>Native code should be analyzed using an automated tool that can detect
memory management issues such as buffer overflows and off-by-one errors.</li>
<li>The Android build system has support for many of the LLVM sanitizers,
such as AddressSanitizer and UndefinedBehaviorSanitizer which can be used
for this purpose.</li>
</ul>
<h3 id="auto-test">Using automated testing</h3>
<p>Automated testing can detect a broad range of security issues, including
several issues discussed below. Best practices:</p>
<ul>
<li>CTS is regularly updated with security tests; run the most recent version of
CTS to verify compatibility.</li>
<li>Run CTS regularly throughout the development process to detect problems
early and reduce time to correction. Android uses CTS as part of continuous
integration in our automated build process, which builds multiple times per day.
</li>
<li>Device manufacturers should automate security testing of interfaces,
including testing with malformed inputs (fuzz testing).</li>
</ul>
<h3 id="sign-sysimg">Signing system images</h3>
<p>The signature of the system image is critical for determining the integrity
of the device. Best practices:</p>
<ul>
<li>Devices must not be signed with a key that is publicly known.</li>
<li>Keys used to sign devices should be managed in a manner consistent with
industry standard practices for handling sensitive keys, including a hardware
security module (HSM) that provides limited, auditable access.</li>
</ul>
<h3 id="sign-apk">Signing applications (APKs)</h3>
<p>Application signatures play an important role in device security and are used
for permissions checks as well as software updates. When selecting a key to use
for signing applications, it is important to consider whether an application
will be available only on a single device or common across multiple devices.
Best practices:</p>
<ul>
<li>Applications must not be signed with a key that is publicly known.</li>
<li>Keys used to sign applications should be managed in a manner consistent with
industry standard practices for handling sensitive keys, including an HSM that
provides limited, auditable access.</li>
<li>Applications should not be signed with the platform key.</li>
<li>Applications with the same package name should not be signed with different
keys. This often occurs when creating an application for different devices,
especially when using the platform key. If the application is
device-independent, use the same key across devices. If the application is
device-specific, create unique package names per device and key.</li>
</ul>
<h3 id="apps-pub">Publishing applications</h3>
<p>Google Play provides device manufacturers the ability to update applications
without performing a complete system update. This can expedite response to
security issues and delivery of new features, as well as provide a way to ensure
your application has a unique package name. Best practices:</p>
<ul>
<li>Upload your applications to Google Play to allow automated updates without
requiring a full over-the-air (OTA) update. Applications that are uploaded but
unpublished are not directly downloadable by users but the applications are
still updated. Users who have previously installed the app can re-install it
and/or install on other devices.</li>
<li>Create an application package name that is clearly associated with your
company, such as by using a company trademark.</li>
<li>Applications published by device manufacturers should be uploaded on the
Google Play store to avoid package name impersonation by third-party users. If
a device manufacturer installs an app on a device without publishing the app on
the Play store, another developer could upload the same app, use the same
package name, and change the metadata for the app. When the app is presented to
the user, this unrelated metadata could create confusion.</li>
</ul>
<h3 id="incident-response">Responding to incidents</h3>
<p>External parties must have the ability to contact device manufacturers about
device-specific security issues. We recommend creating a publicly accessible
email address for managing security incidents. Best practices:</p>
<ul>
<li>Create a <em>security@your-company.com</em> or similar address and publicize
it.</li>
<li>If you become aware of a security issue affecting Android OS or Android
devices from multiple device manufacturers, you should contact the Android
Security Team by filing a
<a href="https://code.google.com/p/android/issues/entry?template=Security%20bug%20report">Security
bug report</a>.</li>
</ul>
<h2 id="prod-implement">Product implementation</h2>
<p>Use the following best practices when implementing a product.</p>
<h3 id="root-processes">Isolating root processes</h3>
<p>Root processes are the most frequent target of privilege escalation attacks,
so reducing the number of root processes reduces risk of privilege escalation.
CTS includes an informational test that lists root processes. Best practices:</p>
<ul>
<li>Devices should run the minimum necessary code as root. Where possible, use a
regular Android process rather than a root process. The ICS Galaxy Nexus has
only six root processes: vold, inetd, zygote, tf_daemon, ueventd, and init. If a
process must run as root on a device, document the process in an AOSP feature
request so it can be publicly reviewed.</li>
<li>Where possible, root code should be isolated from untrusted data and
accessed via IPC. For example, reduce root functionality to a small Service
accessible via Binder and expose the Service with signature permission to an
application with low or no privileges to handle network traffic.</li>
<li>Root processes must not listen on a network socket.</li>
<li>Root processes must not provide a general-purpose runtime for applications
(e.g. a Java VM).</li>
</ul>
<h3 id="sys-apps">Isolating system apps</h3>
<p>In general, pre-installed apps should not run with the shared system UID. If
is it necessary, however, for an app to use the shared UID of system or another
privileged service (i.e., phone), the app should not export any services,
broadcast receivers, or content providers that can be accessed by third-party
apps installed by users. Best practices:</p>
<ul>
<li>Devices should run the minimum necessary code as system. Where possible, use
an Android process with its own UID rather than reusing the system UID.</li>
<li>Where possible, system code should be isolated from untrusted data and
expose IPC only to other trusted processes.</li>
<li>System processes must not listen on a network socket.</li>
</ul>
<h3 id="process-isolate">Isolating processes</h3>
<p>The Android Application Sandbox provides applications with an expectation of
isolation from other processes on the system, including root processes and
debuggers. Unless debugging is specifically enabled by the application and the
user, no application should violate that expectation. Best practices:</p>
<ul>
<li>Root processes must not access data within individual application data
folders, unless using a documented Android debugging method.</li>
<li>Root processes must not access memory of applications, unless using a
documented Android debugging method.</li>
<li>Devices must not include any application that accesses data or memory of
other applications or processes.</li>
</ul>
<h3 id="suid-files">Securing SUID files</h3>
<p>New setuid programs should not be accessible by untrusted programs. Setuid
programs have frequently been the location of vulnerabilities that can be used
to gain root access, so strive to minimize the availability of the setuid
program to untrusted applications. Best practices:</p>
<ul>
<li>SUID processes must not provide a shell or backdoor that can be used to
circumvent the Android security model.</li>
<li>SUID programs must not be writable by any user.</li>
<li>SUID programs should not be world readable or executable. Create a group,
limit access to the SUID binary to members of that group, and place any
applications that should be able to execute the SUID program into that group.
</li>
<li>SUID programs are a common source of user rooting of devices. To reduce
this risk, SUID programs should not be executable by the shell user.</li>
</ul>
<p>CTS verifier includes an informational test listing SUID files; some
setuid files are not permitted per CTS tests.</p>
<h3 id="listening-sockets">Securing listening sockets</h3>
<p>CTS tests fail when a device is listening on any port, on any interface. In
the event of a failure, Android verifies the following best practices are in
use:</p>
<ul>
<li>There should be no listening ports on the device.</li>
<li>Listening ports must be able to be disabled without an OTA. This can be
either a server or user-device configuration change.</li>
<li>Root processes must not listen on any port.</li>
<li>Processes owned by the system UID must not listen on any port.</li>
<li>For local IPC using sockets, applications must use a UNIX Domain Socket with
access limited to a group. Create a file descriptor for the IPC and make it +RW
for a specific UNIX group. Any client applications must be within that UNIX
group.</li>
<li>Some devices with multiple processors (e.g. a radio/modem separate from the
application processor) use network sockets to communicate between processors.
In such instances, the network socket used for inter-processor communication
must use an isolated network interface to prevent access by unauthorized
applications on the device (i.e. use iptables to prevent access by other
applications on the device).</li>
<li>Daemons that handle listening ports must be robust against malformed data.
Google may conduct fuzz-testing against the port using an unauthorized client,
and, where possible, authorized client. Any crashes will be filed as bugs with
an appropriate severity.</li>
</ul>
<h3 id="logging">Logging data</h3>
<p>Logging data increases the risk of exposure of that data and reduces system
performance. Multiple public security incidents have occurred as the result of
logging sensitive user data by applications installed by default on Android
devices. Best practices:</p>
<ul>
<li>Applications or system services should not log data provided from
third-party applications that might include sensitive information.</li>
<li>Applications must not log any Personally Identifiable Information (PII) as
part of normal operation.</li>
</ul>
<p>CTS includes tests that check for the presence of potentially sensitive
information in the system logs.</p>
<h3 id="directories">Limiting directory access</h3>
<p>World-writable directories can introduce security weaknesses and enable an
application to rename trusted files, substitute files, or conduct symlink-based
attacks (attackers may use a symlink to a file to trick a trusted program into
performing actions it shouldn't). Writable directories can also prevent the
uninstall of an application from properly cleaning up all files associated with
an application.</p>
<p>As a best practice, directories created by the system or root users should
not be world writable. CTS tests help enforce this best practice by testing
known directories.</p>
<h3 id="config-files">Securing configuration files</h3>
<p>Many drivers and services rely on configuration and data files stored in
directories such as <code>/system/etc</code> and <code>/data</code>. If these
files are processed by a privileged process and are world writable, it is
possible for an app to exploit a vulnerability in the process by crafting
malicious contents in the world-writable file. Best practices:</p>
<ul>
<li>Configuration files used by privileged processes should not be world
readable.</li>
<li>Configuration files used by privileged processes must not be world
writable.</li>
</ul>
<h3 id="native-code">Storing native code libraries</h3>
<p>Any code used by privileged device manufacturer processes must be in
<code>/vendor</code> or <code>/system</code>; these filesystems are mounted
read-only on boot. As a best practice, libraries used by system or other
highly-privileged apps installed on the phone should also be in these
filesystems. This can prevent a security vulnerability that could allow an
attacker to control the code that a privileged process executes.</p>
<h3 id="device-drivers">Limiting device driver access</h3>
<p>Only trusted code should have direct access to drivers. Where possible, the
preferred architecture is to provide a single-purpose daemon that proxies calls
to the driver and restricts driver access to that daemon. As a best practice,
driver device nodes should not be world readable or writable. CTS tests help
enforce this best practice by checking for known instances of exposed drivers.
</p>
<h3 id="adb">Disabling ADB</h3>
<p>Android debug bridge (adb) is a valuable development and debugging tool, but
is designed for use in controlled, secure environments and should not be enabled
for general use. Best practices:</p>
<ul>
<li>ADB must be disabled by default.</li>
<li>ADB must require the user to turn it on before accepting connections.</li>
</ul>
<h3 id="unlockable-bootloaders">Unlocking bootloaders</h3>
<p>Many Android devices support unlocking, enabling the device owner to modify
the system partition and/or install a custom operating system. Common use
cases include installing a third-party ROM and performing systems-level
development on the device. For example, a Google Nexus device owner can run
<code>fastboot oem unlock</code> to start the unlocking process, which presents
the following message to the user:</p>
<div style="background-color: #B2EBF2; padding: 10px;margin-right:25px">
<p><strong>Unlock bootloader?</strong></p>
<p>If you unlock the bootloader, you will be able to install custom operating
system software on this phone.</p>
<p>A custom OS is not subject to the same testing as the original OS, and can
cause your phone and installed applications to stop working properly.</p>
<p>To prevent unauthorized access to your personal data, unlocking the
bootloader will also delete all personal data from your phone (a "factory data
reset").</p>
<p>Press the Volume Up/Down buttons to select Yes or No. Then press the Power
button to continue.</p>
<p><strong>Yes</strong>: Unlock bootloader (may void warranty)</p>
<p><strong>No</strong>: Do not unlock bootloader and restart phone.</p>
</div>
<br>
<p>As a best practice, unlockable Android devices must securely erase all user
data prior to being unlocked. Failure to properly delete all data on
unlocking may allow a physically proximate attacker to gain unauthorized access
to confidential Android user data. To prevent the disclosure of user data, a
device that supports unlocking must implement it properly (we've seen numerous
instances where device manufacturers improperly implemented unlocking). A
properly implemented unlocking process has the following properties:</p>
<ul>
<li>When the unlocking command is confirmed by the user, the device must start
an immediate data wipe. The <code>unlocked</code> flag must not be set until
after the secure deletion is complete.</li>
<li>If a secure deletion cannot be completed, the device must stay in a locked
state.</li>
<li>If supported by the underlying block device,
<code>ioctl(BLKSECDISCARD)</code> or equivalent should be used. For eMMC
devices, this means using a Secure Erase or Secure Trim command. For eMMC 4.5
and later, this means using a normal Erase or Trim followed by a Sanitize
operation.</li>
<li>If <code>BLKSECDISCARD</code> is not supported by the underlying block
device, <code>ioctl(BLKDISCARD)</code> must be used instead. On eMMC devices,
this is a normal Trim operation.</li>
<li>If <code>BLKDISCARD</code> is not supported, overwriting the block devices
with all zeros is acceptable.</li>
<li>An end user must have the option to require that user data be wiped prior to
flashing a partition. For example, on Nexus devices, this is done via the
<code>fastboot oem lock</code> command.</li>
<li>A device may record, via efuses or similar mechanism, whether a device was
unlocked and/or relocked.</li>
</ul>
<p>These requirements ensure that all data is destroyed upon the completion of
an unlock operation. Failure to implement these protections is considered a
moderate level security vulnerability.</p>
<p>A device that is unlocked may be subsequently relocked using the
<code>fastboot oem lock</code> command. Locking the bootloader provides the same
protection of user data with the new custom OS as was available with the
original device manufacturer OS (e.g. user data will be wiped if the device is
unlocked again).</p>
</body>
</html>

219
android/docs/source.android.com/en/security/overview/kernel-security.html Normal file
View file

@ -0,0 +1,219 @@
<html devsite>
<head>
<title>System and kernel security</title>
<meta name="project_path" value="/_project.yaml" />
<meta name="book_path" value="/_book.yaml" />
</head>
<body>
<!--
Copyright 2017 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
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
-->
<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 an exploitation of an
application vulnerability, the system is designed to prevent the rogue
application from harming other applications, the Android system, or the device
itself. See
<a href="/devices/tech/config/kernel.html">Kernel Configuration</a>
for measures you can take to strengthen the kernel on your devices. See the
<a href="/compatibility/cdd.html">Android Compatibility Definition
Document (CDD)</a> for required settings.</p>
<h2 id="linux-security">Linux Security</h2>
<p>The foundation of the Android platform is the Linux kernel. The Linux kernel
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
professionals.</p>
<p>As the base for a mobile computing environment, the Linux kernel provides
Android with several key security features, including:</p>
<ul>
<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>
</ul>
<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>
<ul>
<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,
Bluetooth)</li>
</ul>
<h2 id="the-application-sandbox">The Application Sandbox</h2>
<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>Because 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, such as 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 in one application may
lead to corruption in other applications housed in the same memory space,
resulting in a complete compromise of the security of the device. Because all
applications and their resources are sandboxed at the OS level, a memory
corruption error will allow arbitrary code execution only 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 Linux kernel.</p>
<h2 id="system-partition-and-safe-mode">System Partition and Safe Mode</h2>
<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,
third-party applications may be launched manually by the device owner but are
not launched by default.</p>
<h2 id="filesystem-permissions">Filesystem Permissions</h2>
<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 shares files with other
applications, files created by one application cannot be read or altered by
another application.</p>
<h2 id="se-linux">Security-Enhanced Linux</h2>
<p>Android uses Security-Enhanced
Linux (SELinux) to apply access control policies and establish
mandatory access control (mac) on processes. See
<a href="/security/selinux/index.html">Security-Enhanced Linux in
Android</a> for details.</p>
<h2 id="verified-boot">Verified boot</h2>
<p>
Android 6.0 and later supports verified boot and device-mapper-verity. Verified
boot guarantees the integrity of the device software starting from a hardware
root of trust up to the system partition. During boot, each stage
cryptographically verifies the integrity and authenticity of the next stage
before executing it.
</p>
<p>
Android 7.0 and later supports strictly enforced verified boot, which means
compromised devices cannot boot.
</p>
<p>
See <a href="/security/verifiedboot/index.html">Verified boot</a> for
more details.
</p>
<h2 id="crypto">Cryptography</h2>
<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="http://developer.android.com/reference/android/security/KeyChain.html">KeyChain</a>
class to allow applications to use the system credential storage for private
keys and certificate chains. </p>
<h2 id="rooting-devices">Rooting of Devices</h2>
<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,
or 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>
<h2 id="user-security">User Security Features</h2>
<h3 id="filesystem-encryption">Filesystem Encryption</h3>
<p>Android 3.0 and later provides full filesystem encryption, so all user data can
be encrypted in the kernel.</p>
<p>
Android 5.0 and later supports
<a href="/security/encryption/full-disk.html">full-disk encryption</a>.
Full-disk encryption uses a single key—protected with the user’s device
password—to protect the whole of a device’s userdata partition. Upon boot,
users must provide their credentials before any part of the disk is accessible.
</p>
<p>
Android 7.0 and later supports
<a href="/security/encryption/file-based.html">file-based encryption</a>.
File-based encryption allows different files to be encrypted with different
keys that can be unlocked independently.
</p>
<p>More details on implementation of filesystem encryption are available in the
<a href="/security/encryption/index.html">Encryption</a> section.</p>
<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
administrator.</p>
<h2 id="device-administration">Device Administration</h2>
<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
href="https://developer.android.com/guide/topics/admin/device-admin.html">Device
Administration</a>.</p>
</body>
</html>

359
android/docs/source.android.com/en/security/overview/updates-resources.html Normal file
View file

@ -0,0 +1,359 @@
<html devsite>
<head>
<title>Security Updates and Resources</title>
<meta name="project_path" value="/_project.yaml" />
<meta name="book_path" value="/_book.yaml" />
</head>
<body>
<!--
Copyright 2017 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
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
-->
<p>The Android security team is responsible for managing security vulnerabilities
discovered in the Android platform and many of the core Android apps bundled
with Android devices.</p>
<p>The Android security team finds security vulnerabilities through internal
research and also responds to bugs reported by third parties. Sources of
external bugs include issues reported through the <a
href="https://issuetracker.google.com/issues/new?component=190951">Android
Security Issue template</a>, published and pre-published academic research,
upstream open source project maintainers, notifications from our device
manufacturer partners, and publicly disclosed issues posted on blogs or social
media.</p>
<h2 id="report-issues">Reporting security issues</h2>
<p>Any developer, Android user, or security researcher can notify the Android
security team of potential security issues through the <a
href="https://issuetracker.google.com/issues/new?component=190951">
Android Security Issue template</a>.</p>
<p>Bugs marked as security issues are not externally visible, but they may
eventually be made visible after the issue is evaluated or resolved. If you
plan to submit a patch or Compatibility Test Suite (CTS) test to resolve a
security issue, please attach it to the bug report and wait for a response
before uploading the code to AOSP.</p>
<h2 id="triaging_bugs">Triaging bugs</h2>
<p>The first task in handling a security vulnerability is to identify the severity
of the bug and which component of Android is affected. The severity determines
how the issue is prioritized, and the component determines who fixes the bug,
who is notified, and how the fix gets deployed to users.</p>
<h3 id="process_types">Process types</h3>
<p>This table covers the definitions of process types. The process type can be
defined by the type of application or process or the area in which it runs.
This table is ordered from least to most privileged.</p>
<table>
<col width="30%">
<col width="70%">
<tr>
<th>Process type</th>
<th>Type definition</th>
</tr>
<tr>
<td>Constrained process</td>
<td>A process that runs in a highly limited SELinux domain.<br />
OR<br />
A process that is significantly more limited than a normal application.</td>
</tr>
<tr>
<td>Unprivileged process</td>
<td>A third-party application or process.<br />
OR<br />
An application or process that runs in the SELinux <code>untrusted_app</code>
domain.</td>
</tr>
<tr>
<td>Privileged process</td>
<td>An application or process with capabilities that are restricted by
SELinux <code>untrusted_app</code> domain.<br />
OR<br />
An application or process with important privileges that a third-party
application cannot obtain.</td>
</tr>
<tr>
<td>Trusted Computing Base (TCB)</td>
<td>Functionality that is part of the kernel, runs in the same CPU context as
the kernel (such as device drivers), has direct access to kernel memory (such as
hardware components on the device), or is one of a handful of user services
that is considered kernel equivalent: <code>init</code>, <code>ueventd</code>,
and <code>vold</code>.</td>
</tr>
<tr>
<td>Trusted Execution Environment (TEE)</td>
<td> A component that is designed to be protected from even a hostile kernel.</td>
</tr>
</table>
<h3 id="severity">Severity</h3>
<p>The severity of a bug generally reflects the potential harm that could occur if
a bug was successfully exploited. Use the following criteria to determine the
severity:</p>
<table>
<tr>
<th>Rating</th>
<th>Consequence of successful exploitation</th>
</tr>
<tr>
<td><strong>Critical</strong></td>
<td>
<ul>
<li>Arbitrary code execution in the TEE</li>
<li>Remote arbitrary code execution in a privileged process or the TCB</li>
<li>Remote permanent denial of service (device inoperability: completely
permanent or requiring re-flashing the entire operating system)</li>
<li>Remote bypass of user interaction requirements on package installation or
equivalent behavior</li>
<li>Secure Boot bypass</li>
</ul>
</td>
</tr>
<tr>
<td><strong>High</strong></td>
<td>
<ul>
<li>Remote arbitrary code execution in an unprivileged process</li>
<li>Arbitrary local code execution in a privileged process or the TCB</li>
<li>Unauthorized access to data secured by the TEE</li>
<li>Remote access to protected data (data normally accessible only to locally
installed apps that request permission, or that is limited to a privileged
process)</li>
<li>Local permanent denial of service (device inoperability: completely
permanent or requiring re-flashing the entire operating system)</li>
<li>Remote temporary device denial of service (remote hang or reboot)</li>
<li>Remote bypass of user interaction requirements (access to functionality that
would normally require either user initiation or user permission)</li>
<li>Local bypass of user interaction requirements for any developer or security
settings modifications</li>
<li>A general bypass for operating system protections that isolate application
data from other applications</li>
<li>A general bypass for operating system protections that isolate users or
profiles from one another</li>
<li>Cryptographic Vulnerability in Standard TLS that allows for
man-in-the-middle attacks</li>
<li>Lockscreen bypass</li>
</ul>
</td>
</tr>
<tr>
<td><strong>Moderate</strong></td>
<td>
<ul>
<li>Remote arbitrary code execution in a constrained process</li>
<li>Local arbitrary code execution in an unprivileged process</li>
<li>A general bypass for a defense in depth or exploit mitigation technology in
a privileged process, the TCB, or the TEE</li>
<li>Bypass of restrictions on a constrained process</li>
<li>Remote access to unprotected data (data normally accessible to any locally
installed app)</li>
<li>Local access to protected data (data normally accessible only to locally
installed apps that request permission, or that is limited to a privileged
process)</li>
<li>Local bypass of user interaction requirements (access to functionality that
would normally require either user initiation or user permission)</li>
<li>Local permanent denial of service (device requires a factory reset)</li>
<li>Cryptographic Vulnerability in standard crypto primitives that allows
leaking of plaintext (not primitives used in TLS)</li>
<li>Bypass of Device Protection/ Factory Reset Protection</li>
<li>Bypass of Carrier Restrictions</li>
<li>Targeted prevention of access to emergency services</li>
</ul>
</td>
</tr>
<tr>
<td><strong>Low</strong></td>
<td>
<ul>
<li>Local arbitrary code execution in a constrained process</li>
<li>Cryptographic Vulnerability in non-standard usage</li>
<li>A general bypass for a user level defense in depth or exploit
mitigation technology in an unprivileged process</li>
</ul>
</td>
</tr>
<tr>
<td><strong>No Security Impact (NSI)</strong></td>
<td>
<ul>
<li>A vulnerability whose impact has been mitigated by one or more rating
modifiers or version-specific architecture changes such that the effective
severity is below Low, although the underlying code issue may remain</li>
</ul>
</td>
</tr>
</table>
<h4 id="local_vs_remote">Local vs. remote</h4>
<p>A remote attack vector indicates the bug could be exploited without installing
an app or without physical access to the device. This includes bugs that could
be triggered by browsing to a web page, reading an email, receiving an SMS
message, or connecting to a hostile network. For the purpose of our severity
ratings, the Android security team also considers "proximal" attack vectors as
remote. These include bugs that can be exploited only by an attacker who is
physically near the target device, for example a bug that requires sending
malformed Wi-Fi or Bluetooth packets.</p>
<p>Local attacks require the victim to install an app. For the purpose of severity
ratings, the Android security team also considers physical attack vectors as
local. These include bugs that can be exploited only by an attacker who has
physical access to the device, for example a bug in a lock screen or one that
requires plugging in a USB cable. The Android security team also considers
NFC-based attacks as local.</p>
<h3 id="rating_modifiers">Rating modifiers</h3>
<p>While the severity of security vulnerabilities is often easy to identify,
ratings may change based on circumstances.</p>
<table>
<tr>
<th>Reason</th>
<th>Effect</th>
</tr>
<tr>
<td>Requires running as a privileged process to execute the attack</td>
<td>-1 Severity</td>
</tr>
<tr>
<td>Vulnerability-specific details limit the impact of the issue</td>
<td>-1 Severity</td>
</tr>
<tr>
<td>Compiler or platform configurations mitigate a vulnerability in the
source code</td>
<td>Moderate Severity if the underlying vulnerability is Moderate or higher</td>
</tr>
<tr>
<td>Requires tamper-evident physical access</td>
<td>-2 Severity</td>
</tr>
<tr>
<td>If no SELinux domain can conduct the operation under the Google-provided
SEPolicy</td>
<td>No Security Impact</td>
</tr>
</table>
<p class="note">
<strong>Note</strong>: A CVE may not be issued for issues assessed as Low or NSI.
</p>
<h3 id="affected_component">Affected component</h3>
<p>The development team responsible for fixing the bug depends on which component
the bug is in. It could be a core component of the Android platform, a kernel
driver supplied by an original equipment manufacturer (OEM), or one of the
pre-loaded apps on Nexus devices.</p>
<p>Bugs in AOSP code are fixed by the Android engineering team. Low-severity bugs,
bugs in certain components, or bugs that are already publicly known may be
fixed directly in the publicly available AOSP master branch; otherwise they're
fixed in our internal repositories first.</p>
<p>The component is also a factor in how users get updates. A bug in the framework
or kernel will require an over-the-air (OTA) firmware update that each OEM will
need to push. A bug in an app or library published in Google Play (e.g., Gmail,
Google Play Services, WebView in Lollipop and later versions) can be sent to
Android users as an update from Google Play.</p>
<h2 id="notifying_partners">Notifying partners</h2>
<p>When a security vulnerability in AOSP is fixed in an Android Security
Bulletin, we'll notify Android partners of issue details and provide patches.
The Android security team currently provides patches for Android versions 4.4
(KitKat) and above. This list of backport-supported versions changes with each
new Android release.</p>
<h2 id="releasing_code_to_aosp">Releasing code to AOSP</h2>
<p>If the security bug is in an AOSP component, the fix will be pushed out to AOSP
after the OTA is released to users. Fixes for low-severity issues may be
submitted directly to the AOSP master branch before a fix is available.</p>
<h2 id="android_updates">Receiving Android updates</h2>
<p>Updates to the Android system are generally delivered to devices through
OTA update packages. These updates may come from the OEM who
produced the device or the carrier who provides service to the device. Google
Nexus device updates come from the Google Nexus team after going through a
carrier technical acceptance (TA) testing procedure. Google also publishes <a
href="https://developers.google.com/android/nexus/images">Nexus factory
images</a> that can be side-loaded to devices.</p>
<h2 id="updating_google_services">Updating Google services</h2>
<p>In addition to providing patches for security bugs, the Android security team
also review security bugs to determine if there are other ways to protect
users. For example, Google Play scans all applications and will remove any
application that attempts to exploit a security bug. For applications installed
from outside of Google Play, devices with Google Play Services may also use the
<a href="https://support.google.com/accounts/answer/2812853">Verify Apps</a>
feature to warn users about applications that may be potentially harmful.</p>
<h2 id="other_resources">Other resources</h2>
<p>Information for Android application developers: <a
href="https://developer.android.com">https://developer.android.com</a></p>
<p>Security information exists throughout the Android Open Source and Developer
sites. Good places to start:<br>
<a href="/security/index.html">https://source.android.com/security/index.html</a><br>
<a href="https://developer.android.com/training/articles/security-tips.html">https://developer.android.com/training/articles/security-tips.html</a></p>
<h3 id="reports">Reports</h3>
<p>Sometimes the Android Security team publishes reports or whitepapers. Here are some of the most recent.</p>
<ul>
<li><a href="/security/reports/Google_Android_Security_2016_Report_Final.pdf">
Android Security 2016 Year In Review</a></li>
<li><a href="/security/reports/Google_Android_Security_2015_Report_Final.pdf">
Android Security 2015 Year In Review</a></li>
<li><a href="/security/reports/Google_Android_Security_2014_Report_Final.pdf">
Android Security 2014 Year In Review</a></li>
<li><a href="/security/reports/Android_WhitePaper_Final_02092016.pdf">
Android Security white paper</a></li>
<li><a href="/security/reports/Google_Android_Security_PHA_classifications.pdf">
Classifications for Potentially Harmful Applications</a></li>
</ul>
<h3 id=slides>Presentations</h3>
<p>The Android Security team presents at various conferences and talks. Here are some of their slides:</p>
<ul>
<li><a href="/security/reports/Android-Bootcamp-2016-Verified-Boot-and-Encryption.pdf">
Verified boot and encryption</a></li>
<li><a href="/security/reports/Android-Bootcamp-2016-SafetyNet.pdf">
SafetyNet</a></li>
<li><a href="/security/reports/Android-Bootcamp-2016-New-App-Lifecycle-for-Encryption.pdf">
New app life cycle for encryption</a></li>
<li><a href="/security/reports/Android-Bootcamp-2016-Keeping-Google-Play-safe.pdf">
Keeping Google Play safe</a></li>
<li><a href="/security/reports/Android-Bootcamp-2016-Defense-in-depth-efforts.pdf">
Defense in depth efforts</a></li>
<li><a href="/security/reports/Android-Bootcamp-2016-Android-Keystore-Attestation.pdf">
Keystore attestation</a></li>
<li><a href="/security/reports/Android-Bootcamp-2016-Android-Attack-Team.pdf">
Android attack team</a></li>
</ul>
</body>
</html>