Android Sandbox (sandbox)



In the study of Android systems, sometimes the sandbox (sandbox) concept is encountered. The sandbox concept itself is not too novel, but it's not always clear how Android implements what it calls "sandbox". Many people on the web say that the use of virtual machines is the application of the sandbox, has been skeptical of this claim.

Recently found on the Android Web site updated some of the documents, including the sandbox explanation, this is to understand the meaning of the Android sandbox.

The "sandbox" of Android is an improvement on the use of UID based on the process management of Linux. Applications launched in normal Linux are usually associated with logged-in users, with the same UID for the same user. But in Android, different applications are given different UID, so that different apps will not be able to access resources with each other. For applications, this is more closed and secure. Although this phenomenon has long been understood, but has not known that this is the so-called "sandbox" Android.

See below for explanations of English:

The application Sandbox
the Android platform takes advantage of the Linux user-based protection as a means of identi Fying and isolating application resources. The Android system assigns a unique user ID (UID) to each Android application and runs it as, user in a separate proce Ss. This approach are different from other operating systems (including the traditional Linux configuration), where multiple APs Plications run with the same user permissions.

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, s Uch as user and group IDs that is assigned to applications. By default, applications cannot interact and applications has limited access to the operating system. IF application A tries to does something malicious like read application B ' s data or dial the phone without permission (whic H is a separate application) and then the operating system protects against this because application a does not having the APPR Opriate user privileges. The sandbox is simple, auditable, and based on Decades-old unix-style user separation of processes and file permissions.

Since The application Sandbox is on the kernel, this security model extends to native code and to operating system APPL Ications. All of the software above the kernel in Figure 1, including operating system libraries, application framework, application runtime, and all applications run within the application Sandbox. On some platforms, developers is constrained to a specific development framework, set of APIs, or language in order to EN Force Security. On Android, there is no restrictions on what an application can is written that is required to enforce security; In this respect, native code is just as secure as interpreted code.

In some operating systems, memory corruption errors generally leads to completely compromising the security of the device. This isn't the case in Android due to all applications and their resources being sandboxed at the OS level. A Memory corruption error would only allow arbitrary code execution in the context of that particular application, with the Permissions established by the operating system.

Like all security features, the application Sandbox isn't unbreakable. However, to break out of

Android Sandbox (sandbox)