Android/frameworks_base
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

am 143e6109: DO NOT MERGE Clarify the explanation of Android\'s security design.

Browse Source 
Merge commit '143e61097e3aa2f6fd2951c707f35c35d3be25e3' into gingerbread-plus-aosp

* commit '143e61097e3aa2f6fd2951c707f35c35d3be25e3':
  DO NOT MERGE Clarify the explanation of Android's security design.
This commit is contained in:
Chris Palmer
2010-09-27 14:18:15 -07:00
committed by Android Git Automerger
parent 191a25e1da 143e61097e
commit d4f1436d6a
1 changed files with 41 additions and 33 deletions
Download Patch File Download Diff File Expand all files Collapse all files

74
docs/html/guide/topics/security/security.jd
View File

@@ -21,14 +21,15 @@ page.title=Security and Permissions
</div> </div>
</div> </div>
<p>Android is a multi-process system, in which each application (and parts of the <p>Android is a privilege-separated operating system, in which each
system) runs in its own process. Most security between applications and application runs with a distinct system identity (Linux user ID and group
the system is enforced at the process level through standard Linux facilities, ID). Parts of the system are also separated into distinct identities.
such as user and group IDs that are assigned to applications. Linux thereby isolates applications from each other and from the system.</p>
Additional finer-grained security features are provided
through a "permission" mechanism that enforces restrictions on the specific <p>Additional finer-grained security features are provided through a
operations that a particular process can perform, and per-URI permissions "permission" mechanism that enforces restrictions on the specific operations
for granting ad-hoc access to specific pieces of data.</p> that a particular process can perform, and per-URI permissions for granting
ad-hoc access to specific pieces of data.</p>
<a name="arch"></a> <a name="arch"></a>
<h2>Security Architecture</h2> <h2>Security Architecture</h2>
@@ -38,39 +39,46 @@ application, by default, has permission to perform any operations that would
adversely impact other applications, the operating system, or the user. This adversely impact other applications, the operating system, or the user. This
includes reading or writing the user's private data (such as contacts or includes reading or writing the user's private data (such as contacts or
e-mails), reading or writing another application's files, performing e-mails), reading or writing another application's files, performing
network access, keeping the device awake, etc.<p> network access, keeping the device awake, etc.</p>
<p>An application's process runs in a security sandbox. The sandbox is designed <p>Because the kernel sandboxes applications from each other, applications
to prevent applications from disrupting each other, except by explicitly must explicitly share resources and data. They do this by declaring the
declaring the <em>permissions</em> they need for additional capabilities not <em>permissions</em> they need for additional capabilities not provided by
provided by the basic sandbox. The system handles requests for permissions the basic sandbox. Applications statically declare the permissions they
in various ways, typically by automatically allowing or disallowing based on require, and the Android system prompts the user for consent at the time the
certificates or by prompting the user. The permissions required by an application is installed. Android has no mechanism for granting permissions
application are declared statically in that application, so they can be known dynamically (at run-time) because it complicates the user experience to the
up-front at install time and will not change after that.</p> detriment of security.</p>
<p>The kernel is solely responsible for sandboxing applications from each
other. In particular the Dalvik VM is not a security boundary, and any app
can run native code (see <a href="/sdk/ndk/index.html">the Android NDK</a>).
All types of applications &mdash; Java, native, and hybrid &mdash; are
sandboxed in the same way and have the same degree of security from each
other.</p>
<a name="signing"></a> <a name="signing"></a>
<h2>Application Signing</h2> <h2>Application Signing</h2>
<p>All Android applications (.apk files) must be signed with a certificate whose <p>All Android applications (.apk files) must be signed with a certificate
private key is held by their developer. This certificate identifies the author whose private key is held by their developer. This certificate identifies
of the application. The certificate does <em>not</em> need to be signed by the author of the application. The certificate does <em>not</em> need to be
a certificate authority: it is perfectly allowable, and typical, for Android signed by a certificate authority: it is perfectly allowable, and typical,
applications to use self-signed certificates. The certificate is used only for Android applications to use self-signed certificates. The purpose of
to establish trust relationships between applications, not for wholesale certificates in Android is to distinguish application authors. This allows
control over whether an application can be installed. The most significant the system to grant or deny applications access to <a
ways that signatures impact security is by determining who can access href="/guide/topics/manifest/permission-element.html#plevel">signature-level
signature-based permissions and who can share user IDs.</p> permissions</a> and to grant or deny an application's <a
href="/guide/topics/manifest/manifest-element.html#uid">request to be given
the same Linux identity</a> as another application.</p>
<a name="userid"></a> <a name="userid"></a>
<h2>User IDs and File Access</h2> <h2>User IDs and File Access</h2>
<p>Each Android package (.apk) file installed on the device is given its <p>At install time, Android gives each package a distinct Linux user ID. The
own unique Linux user ID, creating a sandbox for it and preventing it from touching identity remains constant for the duration of the package's life on that
other applications (or other applications from touching it). This user ID is device. On a different device, the same package may have a different UID;
assigned to it when the application is installed on the device, and what matters is that each package has a distinct UID on a given device.</p>
remains constant for the duration of its life on that device.</p>
<p>Because security enforcement happens at the <p>Because security enforcement happens at the
process level, the code of any two packages can not normally process level, the code of any two packages can not normally
@@ -150,7 +158,7 @@ activities of other applications.</li>
<li>Both sending and receiving broadcasts, to control who can receive <li>Both sending and receiving broadcasts, to control who can receive
your broadcast or who can send a broadcast to you.</li> your broadcast or who can send a broadcast to you.</li>
<li>When accessing and operating on a content provider.</li> <li>When accessing and operating on a content provider.</li>
<li>Binding or starting a service.</li> <li>Binding to or starting a service.</li>
</ul> </ul>