Docs: Add Security to top tab, create its nav file
Bug: 24908502
Change-Id: I70037156111410d7b54be11995c4e3fa50ea4acc
diff --git a/src/security/overview/acknowledgements.jd b/src/security/overview/acknowledgements.jd
new file mode 100644
index 0000000..13b4f68
--- /dev/null
+++ b/src/security/overview/acknowledgements.jd
@@ -0,0 +1,338 @@
+page.title=Android Security Acknowledgements
+@jd:body
+
+<!--
+ Copyright 2015 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.
+-->
+<div id="qv-wrapper">
+ <div id="qv">
+ <h2>In this document</h2>
+ <ol id="auto-toc">
+ </ol>
+ </div>
+</div>
+
+<p>The Android Security Team would like to thank the following people and
+parties for helping to improve Android security. They have done this either by
+finding and responsibly reporting security vulnerabilities to <a
+href="mailto:security@android.com">security@android.com</a> or by committing code
+that has a positive impact on Android security, including code that qualifies
+for the <a href="https://www.google.com/about/appsecurity/patch-rewards/">Patch
+Rewards</a> program.</p>
+
+<h2 id=2015>2015</h2>
+
+<div style="LINE-HEIGHT:25px;">
+
+<p>
+<a href="mailto:jgor@utexas.edu">jgor</a> of <a href="http://security.utexas.edu">The University of Texas at Austin</a> (<a href="https://twitter.com/indiecom">@indiecom</a>)
+</p>
+
+<p><a href="mailto:higongguang@gmail.com">Guang Gong</a> of <a href="http://www.360safe.com/">Qihoo 360 Technology Co. Ltd</a> (<a href="https://twitter.com/oldfresher">@oldfresher</a>)</p>
+
+<p>Stephan Huber of Testlab Mobile Security, <a
+href="https://www.sit.fraunhofer.de/">Fraunhofer SIT</a> (<a
+href="mailto:Stephan.Huber@sit.fraunhofer.de">Stephan.Huber@sit.fraunhofer.de</a>)
+</p>
+
+<p><a
+href="http://www.ec-spride.tu-darmstadt.de/en/research-groups/secure-software-engineering-group/staff/siegfried-rasthofer/">Siegfried
+Rasthofer</a> of <a href="http://sseblog.ec-spride.de/">Secure Software
+Engineering Group</a>, EC SPRIDE Technische Universität Darmstadt (<a
+href="mailto:siegfried.rasthofer@gmail.com">siegfried.rasthofer@gmail.com</a>)</p>
+
+<p><a href="mailto:laginimaineb@gmail.com">Gal Beniamini</a> (<a href="http://bits-please.blogspot.com">http://bits-please.blogspot.com</a>)</p>
+
+<p>Michael Peck of <a href="https://www.mitre.org">The MITRE Corporation</a>
+(<a href="mailto:mpeck@mitre.org">mpeck@mitre.org</a>)</p>
+
+</div>
+
+<h2 id=2014>2014</h2>
+
+<div style="LINE-HEIGHT:25px;">
+<p>Jeff Forristal of <a href="http://www.bluebox.com/blog/">Bluebox
+Security</a></p>
+
+<p>Aaron Mangel of <a href="https://banno.com/">Banno</a> (<a
+href="mailto:amangel@gmail.com">amangel@gmail.com</a>)</p>
+
+<p><a href="http://www.linkedin.com/in/tonytrummer/">Tony Trummer</a> of <a
+href="http://www.themeninthemiddle.com">The Men in the Middle</a> <br>(<a
+href="https://twitter.com/SecBro1">@SecBro1</a>)</p>
+
+<p><a href="http://www.samsung.com">Samsung Mobile</a></p>
+
+<p>Henry Hoggard of <a href="https://labs.mwrinfosecurity.com/">MWR Labs</a> (<a
+href="https://twitter.com/henryhoggard">@HenryHoggard</a>)</p>
+
+<p><a href="http://www.androbugs.com">Yu-Cheng Lin 林禹成</a> (<a
+href="https://twitter.com/AndroBugs">@AndroBugs</a>)</p>
+
+<p><a
+href="http://www.ec-spride.tu-darmstadt.de/en/research-groups/secure-software-engineering-group/staff/siegfried-rasthofer/">Siegfried
+Rasthofer</a> of <a href="http://sseblog.ec-spride.de/">Secure Software
+Engineering Group</a>, EC SPRIDE Technische Universität Darmstadt (<a
+href="mailto:siegfried.rasthofer@gmail.com">siegfried.rasthofer@gmail.com</a>)</p>
+
+<p>Steven Arzt of <a href="http://sseblog.ec-spride.de/">Secure Software
+Engineering Group</a>, EC SPRIDE Technische Universität Darmstadt (<a
+href="mailto:Steven.Arzt@ec-spride.de">Steven.Arzt@ec-spride.de</a>)</p>
+
+<p><a href="http://blog.redfern.me/">Joseph Redfern</a> of <a
+href="https://labs.mwrinfosecurity.com/">MWR Labs</a> <br>(<a
+href="https://twitter.com/JosephRedfern">@JosephRedfern</a>)</p>
+
+<p><a href="https://plus.google.com/u/0/109528607786970714118">Valera
+Neronov</a></p>
+
+<p><a href="https://github.com/michalbednarski">Michał Bednarski</a></p>
+
+<p><a href="http://www.linkedin.com/in/luander">Luander Michel Ribeiro</a> (<a
+href="https://twitter.com/luanderock">@luanderock</a>)</p>
+
+<p>Stephan Huber of Testlab Mobile Security, <a
+href="https://www.sit.fraunhofer.de/">Fraunhofer SIT</a> (<a
+href="mailto:Stephan.Huber@sit.fraunhofer.de">Stephan.Huber@sit.fraunhofer.de</a>)
+</p>
+
+<p><a href="http://www.corkami.com">Ange Albertini</a> (<a
+href="https://twitter.com/angealbertini">@angealbertini</a>)</p>
+
+<p><a href="https://www.linkedin.com/in/tdalvi">Tushar Dalvi</a> (<a
+href="https://twitter.com/tushardalvi">@tushardalvi</a>)</p>
+
+<p>Axelle Apvrille of Fortinet, FortiGuards Labs</p>
+
+<p>Tongxin Li of Peking University (<a
+href="mailto:litongxin1991@gmail.com">litongxin1991@gmail.com</a>)</p>
+
+<p><a href="https://www.facebook.com/zhou.xiaoyong">Xiaoyong Zhou</a> of <a
+href="http://www.cs.indiana.edu/~zhou/">Indiana University Bloomington</a> <br>(<a
+href="https://twitter.com/xzhou">@xzhou</a>, <a
+href="mailto:zhou.xiaoyong@gmail.com">zhou.xiaoyong@gmail.com</a>)</p>
+
+<p><a href="http://homes.soic.indiana.edu/luyixing">Luyi Xing</a> of Indiana
+University Bloomington (<a
+href="mailto:xingluyi@gmail.com">xingluyi@gmail.com</a>)</p>
+
+<p>Yeonjoon Lee of Indiana University Bloomington (<a
+href="mailto:luc2yj@gmail.com">luc2yj@gmail.com</a>)</p>
+
+<p><a href="http://www.informatics.indiana.edu/xw7/">Xiaofeng Wang</a> of
+Indiana University Bloomington (<a
+href="mailto:xw7@indiana.edu">xw7@indiana.edu</a>)</p>
+
+<p>Xinhui Han of Peking University (<a
+href="mailto:hanxinhui@pku.edu.cn">hanxinhui@pku.edu.cn</a>)</p>
+
+<p><a href="http://thejh.net/">Jann Horn</a> <a href="https://android-review.googlesource.com/#/c/98197/">
+<img style="vertical-align:middle;" src="../images/tiny-robot.png"
+alt="Green Droid Patch Symbol"
+title="This person contributed code that improved Android security">
+</a></p>
+
+<p>Robert Craig of <a href="https://www.nsa.gov/research/ia_research/">
+Trusted Systems Research Group</a>, US National Security Agency
+<a href="https://android-review.googlesource.com/#/q/owner:%22Robert+Craig+%253Crpcraig%2540tycho.ncsc.mil%253E%22+status:merged">
+<img style="vertical-align:middle" src="../images/tiny-robot.png" alt="Patch Symbol"
+title="This person contributed code that improved Android security"></a></p>
+
+<p>Stephen Smalley of <a href="https://www.nsa.gov/research/ia_research/">
+Trusted Systems Research Group</a>, US National Security Agency
+<a href=
+"https://android-review.googlesource.com/#/q/owner:%22Stephen+Smalley+%253Csds%2540tycho.nsa.gov%253E%22+status:merged">
+<img style="vertical-align:middle" src="../images/tiny-robot.png"
+alt="Patch Symbol" title="This person contributed code that improved Android security"></a></p>
+
+<p><a href="http://www.linkedin.com/in/billcroberts">
+William Roberts</a> (<a href="mailto:bill.c.roberts@gmail.com">bill.c.roberts@gmail.com</a>)
+<a href=
+"https://android-review.googlesource.com/#/q/owner:bill.c.roberts%2540gmail.com+status:merged">
+<img style="vertical-align:middle" src="../images/tiny-robot.png"
+alt="Patch Symbol" title="This person contributed code that improved Android security"></a></p>
+
+<p>Scotty Bauer of University of Utah (<a href="mailto:sbauer@eng.utah.edu">sbauer@eng.utah.edu</a>)</p>
+
+<p><a href="http://www.cs.utah.edu/~rsas/">Raimondas Sasnauskas</a> of University of Utah</p>
+
+<p><a href="http://www.subodh.io">Subodh Iyengar</a> of <a href="https://www.facebook.com">Facebook</a></p>
+
+<p><a href="http://www.shackleton.io/">Will Shackleton</a> of <a href="https://www.facebook.com">Facebook</a></p>
+
+<p>Kunal Patel of <a href="https://www.samsungknox.com/">Samsung KNOX Security Team</a> (<a href="mailto:kunal.patel1@samsung.com">kunal.patel1@samsung.com</a>)</p>
+
+<p>Sebastian Brenza</p>
+
+<p>Wang Tao of <a href="http://xteam.baidu.com">Baidu X-Team</a> (<a href="mailto:wintao@gmail.com">wintao@gmail.com</a>)</p>
+
+<p><a href="http://www.linkedin.com/in/danamodio">Dan Amodio</a> of <a href="https://www.aspectsecurity.com/">Aspect Security</a> (<a href="https://twitter.com/DanAmodio">@DanAmodio</a>)</p>
+
+<p><a href="http://davidmurdoch.com">David Murdoch</a></p>
+
+<p>Alexandru Gheorghita</p>
+
+<p>Mathew Solnik (<a href="https://twitter.com/msolnik">@msolnik</a>)</p>
+
+<p>Marc Blanchou (<a href="https://twitter.com/marcblanchou">@marcblanchou</a>)</p>
+
+<p>Wang Yu of <a href="http://xteam.baidu.com">Baidu X-Team</a> (<a href="https://twitter.com/xi4oyu">@xi4oyu</a>)</p>
+
+<p>Zhang Dong Hui of <a href="http://xteam.baidu.com">Baidu X-Team</a> (<a href="http://weibo.com/shineastdh">shineastdh</a>)</p>
+
+<p>Alex Park (<a href="https://twitter.com/saintlinu">@saintlinu</a>)</p>
+
+<p><a href="http://www.sonymobile.com">Sony Mobile</a></p>
+
+<p><a href="https://twitter.com/isciurus">Andrey Labunets</a> of <a href="https://www.facebook.com">Facebook</a></p>
+
+<p>Imre Rad of <a href="http://www.search-lab.hu/">Search-Lab Ltd.</a></p>
+
+</div>
+
+<h2 id=2013>2013</h2>
+
+<div style="LINE-HEIGHT:25px;">
+
+<p>Jon Sawyer of <a href="http://appliedcybersecurity.com/">Applied Cybersecurity LLC
+</a> (<a href="mailto:jon@cunninglogic.com">jon@cunninglogic.com</a>)</p>
+
+<p>Joshua J. Drake of <a href="http://www.accuvant.com/">Accuvant LABS
+</a> (<a href="https://twitter.com/jduck">@jduck</a>)
+<a href="https://android-review.googlesource.com/#/q/change:72228+OR+change:72229">
+<img style="vertical-align:middle" src="../images/patchreward.png"
+alt="Patch Rewards Symbol" title="This person qualified for the Patch Rewards program!"></a></p>
+
+<p>Ruben Santamarta of IOActive
+(<a href="https://twitter.com/reversemode">@reversemode</a>)</p>
+
+<p>Lucas Yang (amadoh4ck) of
+<a href="http://raonsecurity.com/">RaonSecurity</a>
+(<a href="mailto:amadoh4ck@gmail.com">amadoh4ck@gmail.com</a>)</p>
+
+<p><a href="https://tsarstva.bg/sh/">Ivaylo Marinkov</a>
+of <a href="http://www.ecommera.com/">eCommera</a> <br>
+(<a href="mailto:ivo@tsarstva.bg">ivo@tsarstva.bg</a>)</p>
+
+<p><a href="http://roeehay.blogspot.com/">Roee Hay</a>
+<br>(<a href="https://twitter.com/roeehay">@roeehay</a>,
+<a href="mailto:roeehay@gmail.com">roeehay@gmail.com</a>)</p>
+
+<p>Qualcomm Product Security Initiative</p>
+
+<p><a href="https://lacklustre.net/">Mike Ryan</a> of
+<a href="https://isecpartners.com/">iSEC Partners</a>
+<br>(<a href="https://twitter.com/mpeg4codec">@mpeg4codec</a>,
+<a href="mailto:mikeryan@isecpartners.com">mikeryan@isecpartners.com
+</a>)</p>
+
+<p><a href="http://cryptoonline.com/">Muhammad Naveed</a>
+of <a href="http://illinois.edu/">University of Illinois
+at Urbana-Champaign</a>
+<br>(<a href="mailto:naveed2@illinois.edu">naveed2@illinois.edu</a>)</p>
+
+<p>Robert Craig of <a href="https://www.nsa.gov/research/ia_research/">
+Trusted Systems Research Group</a>, US National Security Agency
+<a href="https://android-review.googlesource.com/#/q/owner:%22Robert+Craig+%253Crpcraig%2540tycho.ncsc.mil%253E%22+status:merged">
+<img style="vertical-align:middle" src="../images/tiny-robot.png" alt="Patch Symbol"
+title="This person contributed code that improved Android security"></a></p>
+
+<p>Stephen Smalley of <a href="https://www.nsa.gov/research/ia_research/">
+Trusted Systems Research Group</a>, US National Security Agency
+<a href=
+"https://android-review.googlesource.com/#/q/owner:%22Stephen+Smalley+%253Csds%2540tycho.nsa.gov%253E%22+status:merged">
+<img style="vertical-align:middle" src="../images/tiny-robot.png"
+alt="Patch Symbol" title="This person contributed code that improved Android security"></a></p>
+
+<p><a href="http://www.linkedin.com/in/billcroberts">
+William Roberts</a> (<a href="mailto:bill.c.roberts@gmail.com">bill.c.roberts@gmail.com</a>)
+<a href=
+"https://android-review.googlesource.com/#/q/owner:bill.c.roberts%2540gmail.com+status:merged">
+<img style="vertical-align:middle" src="../images/tiny-robot.png"
+alt="Patch Symbol" title="This person contributed code that improved Android security"></a></p>
+
+<p><a href="http://roeehay.blogspot.com/">Roee Hay</a>
+<br>(<a href="https://twitter.com/roeehay">@roeehay</a>,
+<a href="mailto:roeehay@gmail.com">roeehay@gmail.com</a>)</p>
+
+<p><a href="http://homes.soic.indiana.edu/luyixing">Luyi Xing</a> of Indiana
+University Bloomington (<a
+href="mailto:xingluyi@gmail.com">xingluyi@gmail.com</a>)</p>
+
+<p>Xiaorui Pan of Indiana University Bloomington (<a href="mailto:eagle200467@gmail.com">eagle200467@gmail.com</a>)<p>
+
+<p>XiaoFeng Wang of Indiana University Bloomington (<a href="mailto:xw7@indiana.edu">xw7@indiana.edu</a>)</p>
+
+<p>Kan Yuan</p>
+
+</div>
+<h2 id=2012>2012</h2>
+
+<div style="LINE-HEIGHT:25px;">
+
+<p>Robert Craig of <a href="https://www.nsa.gov/research/ia_research/">
+Trusted Systems Research Group</a>, US National Security Agency
+<a href="https://android-review.googlesource.com/#/q/owner:%22Robert+Craig+%253Crpcraig%2540tycho.ncsc.mil%253E%22+status:merged">
+<img style="vertical-align:middle" src="../images/tiny-robot.png" alt="Patch Symbol"
+title="This person contributed code that improved Android security"></a></p>
+
+<p>Stephen Smalley of <a href="https://www.nsa.gov/research/ia_research/">
+Trusted Systems Research Group</a>, US National Security Agency
+<a href=
+"https://android-review.googlesource.com/#/q/owner:%22Stephen+Smalley+%253Csds%2540tycho.nsa.gov%253E%22+status:merged">
+<img style="vertical-align:middle" src="../images/tiny-robot.png"
+alt="Patch Symbol" title="This person contributed code that improved Android security"></a></p>
+
+<p><a href="http://www.linkedin.com/in/billcroberts">
+William Roberts</a> (<a href="mailto:bill.c.roberts@gmail.com">bill.c.roberts@gmail.com</a>)
+<a href=
+"https://android-review.googlesource.com/#/q/owner:bill.c.roberts%2540gmail.com+status:merged">
+<img style="vertical-align:middle" src="../images/tiny-robot.png"
+alt="Patch Symbol" title="This person contributed code that improved Android security"></a></p>
+
+<p><a href="http://thejh.net/">Jann Horn</a></p>
+
+<p>Ravishankar Borgaonkar of TU Berlin
+(<a href="https://twitter.com/raviborgaonkar">@raviborgaonkar</a>)</p>
+
+<p><a href="http://roeehay.blogspot.com/">Roee Hay</a>
+<br>(<a href="https://twitter.com/roeehay">@roeehay</a>,
+<a href="mailto:roeehay@gmail.com">roeehay@gmail.com</a>)</p>
+
+<p>David Weinstein of <a href="https://viaforensics.com/">viaForensics</a> (<a href="https://twitter.com/insitusec">@insitusec</a>)</p>
+
+</div>
+
+<h2 id=2011>2011</h2>
+
+<div style="LINE-HEIGHT:25px;">
+
+<p>Collin Mulliner of <a href="http://www.mulliner.org/collin/academic">MUlliNER.ORG</a> (<a href="https://twitter.com/collinrm">@collinrm</a>)</p>
+
+</div>
+
+<h2 id=2009>2009</h2>
+
+<div style="LINE-HEIGHT:25px;">
+
+<p>Collin Mulliner of <a href="http://www.mulliner.org/collin/academic">MUlliNER.ORG</a> (<a href="https://twitter.com/collinrm">@collinrm</a>)</p>
+
+<p>Charlie Miller (<a href="https://twitter.com/0xcharlie">@0xcharlie</a>)</p>
+
+</div>
+
+<br>
+<p><small>If you have reported a vulnerability prior to 2014 and want to be
+included on this list, or to report a vulnerability in Android, contact <a href="mailto:security@android.com">security@android.com</a></small></p>
diff --git a/src/security/overview/app-security.jd b/src/security/overview/app-security.jd
new file mode 100644
index 0000000..f25f067
--- /dev/null
+++ b/src/security/overview/app-security.jd
@@ -0,0 +1,345 @@
+page.title=Application security
+@jd:body
+
+<!--
+ Copyright 2014 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ 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.
+-->
+<div id="qv-wrapper">
+ <div id="qv">
+ <h2>In this document</h2>
+ <ol id="auto-toc"></ol>
+ </div>
+</div>
+
+<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/manifes
+t-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.htm
+l">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/Broad
+castReceiver.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 Application Sandbox, described earlier in this document.
+ 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
+ [https://developer.android.com/reference/android/content/Intent.html](https://developer.android.com/reference/android/content/Intent.html.</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 & 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="application-signing">Application Signing</h2>
+<p>Code signing 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="../../../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>
diff --git a/src/security/overview/index.jd b/src/security/overview/index.jd
new file mode 100644
index 0000000..6b00c55
--- /dev/null
+++ b/src/security/overview/index.jd
@@ -0,0 +1,80 @@
+page.title=Security overview
+@jd:body
+<!--
+ Copyright 2014 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ 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.
+-->
+<div id="qv-wrapper">
+ <div id="qv">
+ <h2>In this document</h2>
+ <ol id="auto-toc"></ol>
+ </div>
+</div>
+
+<h2 id="android-security-program-overview">Security Program Overview</h2>
+<p>Early on in development, the core Android development team recognized that a
+ robust security model was required to enable a vigorous ecosystem of
+ applications and devices built on and around the Android platform and supported
+ by cloud services. As a result, through its entire development lifecycle,
+ Android has been subjected to a professional security program. The Android team
+ has had the opportunity to observe how other mobile, desktop, and server platforms
+ prevented and reacted to security issues and built a security
+ program to address weak points observed in other offerings.</p>
+<p>The key components of the Android Security Program include:</p>
+<ul>
+ <li><strong>Design Review</strong>: The Android security process begins early in the
+ development lifecycle with the creation of a rich and configurable security
+ model and design. Each major feature of the platform is reviewed by engineering
+ and security resources, with appropriate security controls integrated into the
+ architecture of the system.</li>
+ <li><strong>Penetration Testing and Code Review</strong>: During the development of the
+ platform, Android-created and open source components are subject to vigorous
+ security reviews. These reviews are performed by the Android Security Team,
+ Google’s Information Security Engineering team, and independent security
+ consultants. The goal of these reviews is to identify weaknesses and possible
+ vulnerabilities well before the platform is open sourced, and to simulate the
+ types of analysis that will be performed by external security experts upon
+ release.</li>
+ <li><strong>Open Source and Community Review</strong>: The Android Open Source Project enables
+ broad security review by any interested party. Android also uses open source
+ technologies that have undergone significant external security review,
+ such as the Linux kernel. Google Play provides a forum for users and companies
+ to provide information about specific applications directly to users.</li>
+ <li><strong>Incident Response</strong>: Even with all of these precautions, security issues
+ may occur after shipping, which is why the Android project has created a
+ comprehensive security response process. A full-time Android security team
+ constantly monitors Android-specific and the general security community for
+ discussion of potential vulnerabilities. Upon the discovery of legitimate
+ issues, the Android team has a response process that enables the rapid
+ mitigation of vulnerabilities to ensure that potential risk to all Android
+ users is minimized. These cloud-supported responses can include updating the
+ Android platform (over-the-air updates), removing applications from Google
+ Play, and removing applications from devices in the field.</li>
+</ul>
+<h2 id="android-platform-security-architecture">Platform Security Architecture</h2>
+<p>Android seeks to be the most secure and usable operating system for mobile
+ platforms by re-purposing traditional operating system security controls to:</p>
+<ul>
+ <li>Protect user data</li>
+ <li>Protect system resources (including the network)</li>
+ <li>Provide application isolation</li>
+</ul>
+<p>To achieve these objectives, Android provides these key security features:</p>
+<ul>
+ <li>Robust security at the OS level through the Linux kernel</li>
+ <li>Mandatory application sandbox for all applications</li>
+ <li>Secure interprocess communication</li>
+ <li>Application signing</li>
+ <li>Application-defined and user-granted permissions</li>
+</ul>
diff --git a/src/security/overview/kernel-security.jd b/src/security/overview/kernel-security.jd
new file mode 100644
index 0000000..326ac18
--- /dev/null
+++ b/src/security/overview/kernel-security.jd
@@ -0,0 +1,188 @@
+page.title=System and kernel security
+@jd:body
+
+<!--
+ Copyright 2014 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ 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.
+-->
+<div id="qv-wrapper">
+ <div id="qv">
+ <h2>In this document</h2>
+ <ol id="auto-toc"></ol>
+ </div>
+</div>
+
+<p>At the operating system level, the Android platform provides the security of
+ the Linux kernel, as well as a secure inter-process communication (IPC)
+ facility to enable secure communication between applications running in
+ different processes. These security features at the OS level ensure that even
+ native code is constrained by the Application Sandbox. Whether that code is
+ the result of included application behavior or a exploitation of an application
+ vulnerability, the system would prevent the rogue application from harming
+ other applications, the Android system, or the device itself.</p>
+<h3 id="linux-security">Linux Security</h3>
+<p>The foundation of the Android platform is the Linux kernel. The Linux kernel
+ itself has been in widespread use for years, and is used in millions of
+ security-sensitive environments. Through its history of constantly being
+ researched, attacked, and fixed by thousands of developers, Linux has become a
+ stable and secure kernel trusted by many corporations and security
+ 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>
+<h3 id="the-application-sandbox">The Application Sandbox</h3>
+<p>The Android platform takes advantage of the Linux user-based protection as a
+ means of identifying and isolating application resources. The Android system
+ assigns a unique user ID (UID) to each Android application and runs it as that user
+ in a separate process. This approach is different from other operating systems
+ (including the traditional Linux configuration), where multiple applications
+ run with the same user permissions.</p>
+<p>This sets up a kernel-level Application Sandbox. The kernel enforces security
+ between applications and the system at the process level through standard Linux
+ facilities, such as user and group IDs that are assigned to applications. By
+ default, applications cannot interact with each other and applications have
+ limited access to the operating system. If application A tries to do something
+ malicious like read application B's data or dial the phone without permission
+ (which is a separate application), then the operating system protects against
+ this because application A does not have the appropriate user privileges. The
+ sandbox is simple, auditable, and based on decades-old UNIX-style user
+ separation of processes and file permissions.</p>
+<p>Since the Application Sandbox is in the kernel, this security model extends to
+ native code and to operating system applications. All of the software above the
+ kernel in <em>Figure 1</em>, including operating system libraries, application
+ framework, application runtime, and all applications run within the Application
+ Sandbox. On some platforms, developers are constrained to a specific
+ development framework, set of APIs, or language in order to enforce security.
+ On Android, there are no restrictions on how an application can be written that
+ are required to enforce security; in this respect, native code is just as
+ secure as interpreted code.</p>
+<p>In some operating systems, memory corruption errors generally lead to
+ completely compromising the security of the device. This is not the case in
+ Android due to all applications and their resources being sandboxed at the OS
+ level. A memory corruption error will only allow arbitrary code execution in
+ the context of that particular application, with the permissions established by
+ the operating system.</p>
+<p>Like all security features, the Application Sandbox is not unbreakable.
+ However, to break out of the Application Sandbox in a properly configured
+ device, one must compromise the security of the the Linux kernel.</p>
+<h3 id="system-partition-and-safe-mode">System Partition and Safe Mode</h3>
+<p>The system partition contains Android's kernel as well as the operating system
+ libraries, application runtime, application framework, and applications. This
+ partition is set to read-only. When a user boots the device into Safe Mode,
+ only core Android applications are available. This ensures that the user can
+ boot their phone into an environment that is free of third-party software.</p>
+<h3 id="filesystem-permissions">Filesystem Permissions</h3>
+<p>In a UNIX-style environment, filesystem permissions ensure that one user cannot
+ alter or read another user's files. In the case of Android, each application
+ runs as its own user. Unless the developer explicitly exposes files to other
+ applications, files created by one application cannot be read or altered by
+ another application.</p>
+<h3 id="se-linux">Security-Enhanced Linux</h3>
+<p>Android uses Security-Enhanced
+ Linux (SELinux) to apply access control policies and establish an environment of
+ mandatory access control (mac). See <a
+href="{@docRoot}security/selinux/index.html">Validating
+ Security-Enhanced Linux in
+ Android</a> for details.</p>
+<h3 id="crypto">Cryptography</h3>
+<p> Android provides a set of cryptographic APIs for use by applications. These
+ include implementations of standard and commonly used cryptographic primitives
+ such as AES, RSA, DSA, and SHA. Additionally, APIs are provided for higher level
+ protocols such as SSL and HTTPS. </p>
+<p> Android 4.0 introduced the <a href="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>
+<h3>Rooting of Devices</h3>
+<p> By default, on Android only the kernel and a small subset of the core
+ applications run with root permissions. Android does not prevent a user or
+ application with root permissions from modifying the operating system, kernel,
+ and any other application. In general, root has full access to all
+ applications and all application data. Users that change the permissions on an
+ Android device to grant root access to applications increase the security
+ exposure to malicious applications and potential application flaws. </p>
+<p> The ability to modify an Android device they own is important to developers
+ working with the Android platform. On many Android devices users have the
+ ability to unlock the bootloader in order to allow installation of an alternate
+ operating system. These alternate operating systems may allow an owner to gain
+ root access for purposes of debugging applications and system components or to
+ access features not presented to applications by Android APIs. </p>
+<p> On some devices, a person with physical control of a device and a USB cable is
+ able to install a new operating system that provides root privileges to the
+ user. To protect any existing user data from compromise the bootloader unlock
+ mechanism requires that the bootloader erase any existing user data as part of
+ the unlock step. Root access gained via exploiting a kernel bug or security
+ hole can bypass this protection. </p>
+<p> Encrypting data with a key stored on-device does not protect the application
+ data from root users. Applications can add a layer of data protection using
+ encryption with a key stored off-device, such as on a server or a user
+ password. This approach can provide temporary protection while the key is not
+ present, but at some point the key must be provided to the application and it
+ then becomes accessible to root users. </p>
+<p> A more robust approach to protecting data from root users is through the use of
+ hardware solutions. OEMs may choose to implement hardware solutions that limit
+ access to specific types of content such as DRM for video playback, or the
+ NFC-related trusted storage for Google wallet. </p>
+<p> In the case of a lost or stolen device, full filesystem encryption on Android
+ devices uses the device password to protect the encryption key, so modifying
+ the bootloader or operating system is not sufficient to access user data
+ without the user’s device password. </p>
+<h3>User Security Features</h3>
+<h4 id="filesystem-encryption">Filesystem Encryption</h4>
+<p>Android 3.0 and later provides full filesystem encryption, so all user data can
+ be encrypted in the kernel using the dmcrypt implementation of AES128 with CBC
+ and ESSIV:SHA256. The encryption key is protected by AES128 using a key
+ derived from the user password, preventing unauthorized access to stored data
+ without the user device password. To provide resistance against systematic
+ password guessing attacks (e.g. “rainbow tables” or brute force), the
+ password is combined with a random salt and hashed repeatedly with SHA1 using
+ the standard PBKDF2 algorithm prior to being used to decrypt the filesystem
+ key. To provide resistance against dictionary password guessing attacks,
+ Android provides password complexity rules that can be set by the device
+ administrator and enforced by the operating system. Filesystem encryption
+ requires the use of a user password, pattern-based screen lock is not supported.</p>
+<p>More details on implementation of filesystem encryption are available at <a
+href="{@docRoot}security/encryption/index.html">Encryption</a>.</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>
+<h3 id="device-administration">Device Administration</h3>
+<p>Android 2.2 and later provide the Android Device Administration API, which
+ provides device administration features at the system level. For example, the
+ built-in Android Email application uses the APIs to improve Exchange support.
+ Through the Email application, Exchange administrators can enforce password
+ policies — including alphanumeric passwords or numeric PINs — across
+ devices. Administrators can also remotely wipe (that is, restore factory
+ defaults on) lost or stolen handsets.</p>
+<p>In addition to use in applications included with the Android system, these APIs
+ are available to third-party providers of Device Management solutions. Details
+ on the API are provided at <a
+href="https://developer.android.com/guide/topics/admin/device-admin.html">Device
+Administration</a>.</p>
diff --git a/src/security/overview/updates-resources.jd b/src/security/overview/updates-resources.jd
new file mode 100644
index 0000000..8c8d047
--- /dev/null
+++ b/src/security/overview/updates-resources.jd
@@ -0,0 +1,258 @@
+page.title= Security updates and resources
+@jd:body
+
+<!--
+ Copyright 2015 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.
+-->
+<div id="qv-wrapper">
+ <div id="qv">
+ <h2>In this document</h2>
+ <ol id="auto-toc"></ol>
+ </div>
+</div>
+
+<h2 id=android_security_bug_lifecycle>Android security bug lifecycle</h2>
+
+<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://code.google.com/p/android/issues/list">Android Open Source
+Project (AOSP) bug tracker</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 AOSP bug tracker <a
+href="https://code.google.com/p/android/issues/entry?template=Security%20bug%20report">Security
+bug report</a> template.</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>
+
+<p>If you need to reach the Android security team for a purpose other than
+reporting a vulnerability, please contact <a
+href="mailto:security@android.com">security@android.com</a>. The Android
+security team has a <a
+href="https://developer.android.com/security_at_android_dot_com.txt">PGP
+key</a> if you need to encrypt your message.</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=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>
+<p class="table-caption" id="severity-criteria">
+ <strong>Table 1.</strong> Severity ratings and associated consequences</p>
+<table>
+ <tr>
+ <th>Rating</th>
+ <th>Consequence of successful exploitation</th>
+ </tr>
+ <tr>
+ <td><strong>Critical</strong></td>
+ <td>
+<ul>
+<li>Remote privileged code execution (execution at a privilege level that
+third-party apps cannot obtain)
+<li>Local permanent device compromise (device cannot be repaired without
+re-flashing the entire operating system, such as a verified boot or Trusted
+Execution Environment/TEE compromise)
+<li>Remote permanent denial of service (inoperability, either completely permanent
+or requiring re-flashing the device)
+</ul>
+</td>
+ </tr>
+ <tr>
+ <td><strong>High</strong></td>
+ <td>
+<ul>
+<li>Remote unprivileged code execution (execution at a privilege level that
+third-party apps can obtain through installation)
+<li>Local access to system/signature-level permission data or capabilities without
+permission
+<li>Local permanent denial-of-service (inoperability, either completely permanent
+or requiring re-flashing the device)
+<li>Remote temporary denial-of-service (remote hang or reboot)
+</ul>
+</td>
+ </tr>
+ <tr>
+ <td><strong>Moderate</strong></td>
+ <td>
+<ul>
+<li>Access to "<a
+href="http://developer.android.com/guide/topics/manifest/permission-element.html#plevel">dangerous</a>"
+level permission data or capabilities without permission with an app installed
+on the device
+<li>Local temporary denial-of-service (can be resolved only through a factory
+reset)
+</ul>
+</td>
+ </tr>
+ <tr>
+ <td><strong>Low</strong></td>
+ <td>
+<ul>
+<li>Access to "<a
+href="http://developer.android.com/guide/topics/manifest/permission-element.html#plevel">normal</a>"
+level permission capabilities without permission with an app installed on the
+device
+<li>Local temporary denial-of-service (can be resolved by booting the device into
+Safe Mode and removing the problem application)
+</ul>
+</td>
+ </tr>
+</table>
+
+<p>Though there are many types of software bugs outside of the security
+vulnerabilities detailed above, bugs reported are evaluated on a
+case-by-base basis to determine what security impact they have.</p>
+
+<p>The Android security team may also adjust the severity of a vulnerability if it
+is determined the risk to users is higher or lower than the guidelines suggest.
+For example, if a certain piece of data is available only to apps with "system"
+level access but the data itself is not sensitive, the Android security
+team may consider it only a low-severity vulnerability.</p>
+
+<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>
+
+<h4 id=high_privilege_levels>Severity of vulnerabilities that affect high privilege levels</h4>
+
+<p>The Android security team will usually drop the severity rating for a bug that
+already requires executing code at a high privilege level. For example, a bug
+in a kernel driver accessible only from a privileged service that
+requires first compromising the service. In this case, the Android security
+team may drop the severity from "high" to "moderate."</p>
+
+<h4 id=severity_of_kernel_compromises>Severity of kernel compromises</h4>
+
+<p>Whether a vulnerability that compromises the kernel is considered "high" or
+"critical" depends on the device and the version of Android. On devices with a
+TEE (or TrustZone) and <a
+href="{@docRoot}security/verifiedboot/index.html">verified
+boot</a>, a kernel compromise is considered "high" because exploiting it won't
+allow permanently affecting the operation of the device unless a vulnerability is
+discovered in the TEE or verified boot implementation. In general, if the
+result of a compromise can be remediated with a factory reset, it's "high" or
+lower.</p>
+
+<p>However, on older devices without verified boot, a kernel compromise can result
+in permanent device compromise if SELinux is disabled and the system partition
+is modified. On that device, a kernel compromise is considered "critical"
+because remediation requires re-flashing the device's firmware image.</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 moderate or higher severity security vulnerability in AOSP is fixed,
+we'll notify <a href="http://www.openhandsetalliance.com/">Open Handset
+Alliance</a> members with the details of the issue and provide patches for the
+most recent three Android releases. The Android security team currently
+provides patches for Android versions 4.4 (KitKat), 5.0 (Lollipop), and 5.1
+(Lollipop MR1). 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>The Android security team can be reached at <a
+href="mailto:security@android.com">security@android.com</a>. Our PGP key: <a
+href="https://developer.android.com/security_at_android_dot_com.txt">https://developer.android.com/security_at_android_dot_com.txt</a></p>
+
+<p>Security information exists throughout the Android Open Source and Developer
+sites. Good places to start:<br>
+<a href="http://source.android.com/security/index.html">{@docRoot}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>
+
+<p>Community resource for discussion about Android security: <a
+href="https://groups.google.com/forum/?fromgroups#!forum/android-security-discuss">https://groups.google.com/forum/?fromgroups#!forum/android-security-discuss</a></p>