{ "id": "757e42af-9da7-413c-bab8-d2914eb76841", "created_at": "2026-04-06T00:08:22.692333Z", "updated_at": "2026-04-10T13:12:52.938786Z", "deleted_at": null, "sha1_hash": "54c574f3f8756d9417a5bdd75a76aa70fe04bbda", "title": "Application Sandbox", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 47572, "plain_text": "Application Sandbox\r\nArchived: 2026-04-05 17:56:52 UTC\r\nThe Android platform takes advantage of the Linux user-based protection to identify and isolate app resources.\r\nThis isolates apps from each other and protects apps and the system from malicious apps. To do this, Android\r\nassigns a unique user ID (UID) to each Android app and runs it in its own process.\r\nAndroid uses the UID to set up a kernel-level Application Sandbox. The kernel enforces security between apps\r\nand the system at the process level through standard Linux facilities such as user and group IDs that are assigned\r\nto apps. By default, apps can't interact with each other and have limited access to the OS. If app A tries to do\r\nsomething malicious, such as read app B's data or dial the phone without permission, it's prevented from doing so\r\nbecause it doesn't have the appropriate default user privileges. The sandbox is simple, auditable, and based on\r\ndecades-old UNIX-style user separation of processes and file permissions.\r\nBecause the Application Sandbox is in the kernel, this security model extends to both native code and OS apps.\r\nAll of the software above the kernel, such as OS libraries, app framework, app runtime, and all apps, run within\r\nthe Application Sandbox. On some platforms, developers are constrained to a specific development framework,\r\nset of APIs, or language. On Android, there are no restrictions on how an app can be written that are required to\r\nenforce security; in this respect, native code is as sandboxed as interpreted code.\r\nProtections\r\nGenerally, to break out of the Application Sandbox in a properly configured device, one must compromise the\r\nsecurity of the Linux kernel. However, similar to other security features, individual protections enforcing the app\r\nsandbox are not invulnerable, so defense-in-depth is important to prevent single vulnerabilities from leading to\r\ncompromise of the OS or other apps.\r\nAndroid relies on a number of protections to enforce the app sandbox. These enforcements have been introduced\r\nover time and have significantly strengthened the original UID-based discretionary access control (DAC)\r\nsandbox. Previous Android releases included the following protections:\r\nIn Android 5.0, SELinux provided mandatory access control (MAC) separation between the system and\r\napps. However, all third-party apps ran within the same SELinux context so inter-app isolation was\r\nprimarily enforced by UID DAC.\r\nIn Android 6.0, the SELinux sandbox was extended to isolate apps across the per-physical-user boundary.\r\nIn addition, Android also set safer defaults for app data: For apps with targetSdkVersion \u003e= 24 , default\r\nDAC permissions on an app's home dir changed from 751 to 700. This provided safer default for private\r\napp data (although apps can override these defaults).\r\nIn Android 8.0, all apps were set to run with a seccomp-bpf filter that limited the syscalls that apps were\r\nallowed to use, thus strengthening the app/kernel boundary.\r\nIn Android 9 all nonprivileged apps with targetSdkVersion \u003e= 28 must run in individual SELinux\r\nsandboxes, providing MAC on a per-app basis. This protection improves app separation, prevents\r\nhttps://source.android.com/docs/security/app-sandbox\r\nPage 1 of 2\n\noverriding safe defaults, and (most significantly) prevents apps from making their data world accessible.\r\nIn Android 10 apps have a limited raw view of the filesystem, with no direct access to paths like\r\n/sdcard/DCIM. However, apps retain full raw access to their package-specific paths, as returned by any\r\napplicable methods, such as Context.getExternalFilesDir().\r\nGuidelines for sharing files\r\nSetting app data as world accessible is a poor security practice. Access is granted to everyone and it's not possible\r\nto limit access to only the intended recipient(s). This practice has led to information disclosure leaks and confused\r\ndeputy vulnerabilities, and is a favorite target for malware that targets apps with sensitive data (such as email\r\nclients). In Android 9 and higher, sharing files this way is explicitly disallowed for apps with\r\ntargetSdkVersion\u003e=28 .\r\nInstead of making app data world-accessible, use the following guidelines when sharing files:\r\nIf your app needs to share files with another app, use a content provider. Content providers share data with\r\nthe proper granularity and without the many downsides of world-accessible UNIX permissions (for details,\r\nrefer to Content provider basics).\r\nIf your app has files that genuinely should be accessible to the world (such as photos), they must be media-specific (photos, videos, and audio files only) and stored using the MediaStore class. (For more details on\r\nhow to add a media item, see Access media files from shared storage.)\r\nThe Storage runtime permission controls access to strongly-typed collections through MediaStore. For accessing\r\nweakly typed files such as PDFs and the MediaStore.Downloads class, apps must use intents like the\r\nACTION_OPEN_DOCUMENT intent.\r\nTo enable Android 10 behavior, use the requestLegacyExternalStorage manifest attribute, and follow App\r\npermissions best practices.\r\nThe manifest flag default value is true for apps targeting Android 9 and lower.\r\nThe default value is false for apps targeting Android 10. To temporarily opt out of the filtered storage view\r\nin apps targeting Android 10, set the manifest flag's value to true .\r\nUsing restricted permissions, the installer allowlists apps permitted for nonsandboxed storage.\r\nNonallowlisted apps are sandboxed.\r\nSource: https://source.android.com/docs/security/app-sandbox\r\nhttps://source.android.com/docs/security/app-sandbox\r\nPage 2 of 2", "extraction_quality": 1, "language": "EN", "sources": [ "MITRE" ], "origins": [ "web" ], "references": [ "https://source.android.com/docs/security/app-sandbox" ], "report_names": [ "app-sandbox" ], "threat_actors": [ { "id": "aa73cd6a-868c-4ae4-a5b2-7cb2c5ad1e9d", "created_at": "2022-10-25T16:07:24.139848Z", "updated_at": "2026-04-10T02:00:04.878798Z", "deleted_at": null, "main_name": "Safe", "aliases": [], "source_name": "ETDA:Safe", "tools": [ "DebugView", "LZ77", "OpenDoc", "SafeDisk", "TypeConfig", "UPXShell", "UsbDoc", "UsbExe" ], "source_id": "ETDA", "reports": null } ], "ts_created_at": 1775434102, "ts_updated_at": 1775826772, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/54c574f3f8756d9417a5bdd75a76aa70fe04bbda.pdf", "text": "https://archive.orkl.eu/54c574f3f8756d9417a5bdd75a76aa70fe04bbda.txt", "img": "https://archive.orkl.eu/54c574f3f8756d9417a5bdd75a76aa70fe04bbda.jpg" } }