You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
389 lines
19 KiB
389 lines
19 KiB
<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>
|
|
|