Android is a multi-process system, in which each application (and parts of the -system) runs in its own process. Most security between applications and -the system is enforced at the process level through standard Linux facilities, -such as user and group IDs that are assigned to applications. -Additional finer-grained security features are provided -through a "permission" mechanism that enforces restrictions on the specific -operations that a particular process can perform, and per-URI permissions -for granting ad-hoc access to specific pieces of data.
+Android is a privilege-separated operating system, in which each +application runs with a distinct system identity (Linux user ID and group +ID). Parts of the system are also separated into distinct identities. +Linux thereby isolates applications from each other and from the system.
+ +Additional finer-grained security features are provided through a +"permission" mechanism that enforces restrictions on the specific operations +that a particular process can perform, and per-URI permissions for granting +ad-hoc access to specific pieces of data.
+network access, keeping the device awake, etc.
-An application's process runs in a security sandbox. The sandbox is designed -to prevent applications from disrupting each other, except by explicitly -declaring the permissions they need for additional capabilities not -provided by the basic sandbox. The system handles requests for permissions -in various ways, typically by automatically allowing or disallowing based on -certificates or by prompting the user. The permissions required by an -application are declared statically in that application, so they can be known -up-front at install time and will not change after that.
+Because the kernel sandboxes applications from each other, applications +must explicitly share resources and data. They do this by declaring the +permissions they need for additional capabilities not provided by +the basic sandbox. Applications statically declare the permissions they +require, and the Android system prompts the user for consent at the time the +application is installed. Android has no mechanism for granting permissions +dynamically (at run-time) because it complicates the user experience to the +detriment of security.
+ +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 the Android NDK). +All types of applications — Java, native, and hybrid — are +sandboxed in the same way and have the same degree of security from each +other.
All Android applications (.apk files) must be signed with a certificate whose -private key is held by their developer. This certificate identifies the author -of the application. The certificate does not need to be signed by -a certificate authority: it is perfectly allowable, and typical, for Android -applications to use self-signed certificates. The certificate is used only -to establish trust relationships between applications, not for wholesale -control over whether an application can be installed. The most significant -ways that signatures impact security is by determining who can access -signature-based permissions and who can share user IDs.
- +All Android applications (.apk files) must be signed with a certificate +whose private key is held by their developer. This certificate identifies +the author of the application. The certificate does not need to be +signed by a certificate authority: it is perfectly allowable, and typical, +for Android applications to use self-signed certificates. The purpose of +certificates in Android is to distinguish application authors. This allows +the system to grant or deny applications access to signature-level +permissions and to grant or deny an application's request to be given +the same Linux identity as another application.
Each Android package (.apk) file installed on the device is given its -own unique Linux user ID, creating a sandbox for it and preventing it from touching -other applications (or other applications from touching it). This user ID is -assigned to it when the application is installed on the device, and -remains constant for the duration of its life on that device.
+At install time, Android gives each package a distinct Linux user ID. The +identity remains constant for the duration of the package's life on that +device. On a different device, the same package may have a different UID; +what matters is that each package has a distinct UID on a given device.
Because security enforcement happens at the process level, the code of any two packages can not normally @@ -150,7 +158,7 @@ activities of other applications.