389 lines
19 KiB
HTML
389 lines
19 KiB
HTML
<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>
|