از 27 مارس 2025، توصیه می کنیم از android-latest-release به جای aosp-main برای ساختن و کمک به AOSP استفاده کنید. برای اطلاعات بیشتر، به تغییرات AOSP مراجعه کنید.
سندباکس برنامه
با مجموعه‌ها، منظم بمانید
ذخیره و طبقه‌بندی محتوا براساس اولویت‌های شما.
پلتفرم اندروید از محافظت مبتنی بر کاربر لینوکس برای شناسایی و جداسازی منابع برنامه بهره می برد. این برنامه ها را از یکدیگر جدا می کند و از برنامه ها و سیستم در برابر برنامه های مخرب محافظت می کند. برای انجام این کار، اندروید یک شناسه کاربری (UID) منحصر به فرد را به هر برنامه اندروید اختصاص می دهد و آن را در فرآیند خودش اجرا می کند.
Android از UID برای راه اندازی یک Application Sandbox در سطح هسته استفاده می کند. هسته امنیت بین برنامه‌ها و سیستم را در سطح فرآیند از طریق امکانات استاندارد لینوکس مانند شناسه‌های کاربر و گروهی که به برنامه‌ها تخصیص داده می‌شود، اعمال می‌کند. به طور پیش فرض، برنامه ها نمی توانند با یکدیگر تعامل داشته باشند و دسترسی محدودی به سیستم عامل دارند. اگر برنامه A سعی کند کار مخربی انجام دهد، مانند خواندن داده های برنامه B یا شماره گیری تلفن بدون اجازه، از انجام این کار جلوگیری می شود زیرا دارای امتیازات پیش فرض کاربر مناسب نیست. سندباکس ساده، قابل ممیزی است و بر اساس چندین دهه جداسازی کاربر به سبک یونیکس از فرآیندها و مجوزهای فایل است.
از آنجایی که Application Sandbox در هسته قرار دارد، این مدل امنیتی هم به کدهای بومی و هم برنامه های سیستم عامل گسترش می یابد. همه نرم افزارهای بالای هسته، مانند کتابخانه های سیستم عامل، چارچوب برنامه، زمان اجرای برنامه و همه برنامه ها در Application Sandbox اجرا می شوند. در برخی از پلتفرم‌ها، توسعه‌دهندگان به یک چارچوب توسعه خاص، مجموعه‌ای از APIها یا زبان محدود می‌شوند. در اندروید، هیچ محدودیتی در مورد نحوه نوشتن یک برنامه وجود ندارد که برای اجرای امنیت لازم است. از این نظر، کد بومی به اندازه کد تفسیر شده جعبه‌بندی شده است.
حفاظت ها
به طور کلی، برای خارج شدن از Application Sandbox در دستگاهی که به درستی پیکربندی شده است، باید امنیت هسته لینوکس را به خطر انداخت. با این حال، مانند سایر ویژگی‌های امنیتی، حفاظت‌های فردی که جعبه ایمنی برنامه را اعمال می‌کنند، آسیب‌ناپذیر نیستند، بنابراین دفاع عمیق برای جلوگیری از آسیب‌پذیری‌های منفرد از به خطر افتادن سیستم‌عامل یا سایر برنامه‌ها مهم است.
اندروید برای اجرای سندباکس برنامه به تعدادی حفاظت متکی است. این اعمال در طول زمان معرفی شده اند و به طور قابل توجهی جعبه ایمنی کنترل دسترسی اختیاری مبتنی بر UID (DAC) را تقویت کرده اند. نسخه های قبلی اندروید شامل محافظت های زیر بود:
- در اندروید 5.0، SELinux جداسازی اجباری کنترل دسترسی (MAC) را بین سیستم و برنامه‌ها فراهم کرد. با این حال، همه برنامه‌های شخص ثالث در یک زمینه SELinux اجرا می‌شدند، بنابراین جداسازی بین برنامه‌ای عمدتاً توسط UID DAC اعمال شد.
- در اندروید 6.0، جعبه شنی SELinux برای ایزوله کردن برنامه‌ها در سراسر مرز فیزیکی هر کاربر گسترش یافت. علاوه بر این، اندروید پیش‌فرض‌های ایمن‌تری را برای داده‌های برنامه نیز تنظیم می‌کند: برای برنامه‌های دارای
targetSdkVersion >= 24 ، مجوزهای پیش‌فرض DAC در صفحه اصلی برنامه از 751 به 700 تغییر کرده است. این پیش‌فرض پیش‌فرض امن‌تری را برای داده‌های برنامه خصوصی فراهم می‌کند (اگرچه برنامه‌ها می‌توانند این پیش‌فرض‌ها را لغو کنند). - در اندروید 8.0، همه برنامه‌ها با فیلتر
seccomp-bpf اجرا می‌شدند که سیستم‌های سیستمی را که برنامه‌ها مجاز به استفاده از آنها بودند محدود می‌کرد، بنابراین مرز برنامه/کرنل را تقویت می‌کرد. - در Android 9 همه برنامه‌های غیرمجاز با
targetSdkVersion >= 28 باید در جعبه‌های sandbox SELinux جداگانه اجرا شوند و MAC را بر اساس هر برنامه ارائه کنند. این محافظت جداسازی برنامه‌ها را بهبود می‌بخشد، از نادیده گرفتن پیش‌فرض‌های ایمن جلوگیری می‌کند و (به‌طور قابل توجهی) از دسترسی برنامه‌ها به دنیای داده‌هایشان جلوگیری می‌کند. - در اندروید 10، برنامه‌ها دید خام محدودی از سیستم فایل دارند، بدون دسترسی مستقیم به مسیرهایی مانند /sdcard/DCIM. با این حال، برنامه‌ها دسترسی خام کامل به مسیرهای بسته خاص خود را حفظ می‌کنند، همانطور که با هر روش قابل اجرا، مانند Context.getExternalFilesDir() بازگردانده می‌شوند.
راهنمایی برای اشتراک گذاری فایل ها
تنظیم داده‌های برنامه به‌عنوان قابل دسترسی جهانی، یک عمل امنیتی ضعیف است. دسترسی به همه اعطا می شود و نمی توان دسترسی را فقط به گیرنده(های) مورد نظر محدود کرد. این عمل منجر به افشای اطلاعات و آسیب‌پذیری‌های گیج‌شده معاون شده است و هدف مورد علاقه بدافزارهایی است که برنامه‌هایی را با داده‌های حساس (مانند کلاینت‌های ایمیل) هدف قرار می‌دهند. در اندروید 9 و بالاتر، اشتراک‌گذاری فایل‌ها به این روش برای برنامه‌های دارای targetSdkVersion>=28 به صراحت مجاز نیست.
به جای اینکه داده های برنامه را در دسترس جهانی قرار دهید، هنگام به اشتراک گذاری فایل ها از دستورالعمل های زیر استفاده کنید:
- اگر برنامه شما نیاز به اشتراک گذاری فایل ها با برنامه دیگری دارد، از یک ارائه دهنده محتوا استفاده کنید. ارائه‌دهندگان محتوا داده‌ها را با جزئیات مناسب و بدون جنبه‌های منفی بسیاری از مجوزهای یونیکس در دسترس جهان به اشتراک می‌گذارند (برای جزئیات، به اصول ارائه‌دهنده محتوا مراجعه کنید).
- اگر برنامه شما فایل‌هایی دارد که واقعاً باید در دسترس جهانیان باشد (مانند عکس‌ها)، آنها باید مختص رسانه باشند (فقط عکس‌ها، ویدیوها و فایل‌های صوتی) و با استفاده از کلاس MediaStore ذخیره شوند. (برای جزئیات بیشتر در مورد نحوه افزودن یک مورد رسانه، به دسترسی به فایل‌های رسانه از فضای ذخیره‌سازی مشترک مراجعه کنید.)
مجوز زمان اجرا Storage دسترسی به مجموعه‌های با تایپ قوی را از طریق MediaStore کنترل می‌کند. برای دسترسی به فایل‌هایی با تایپ ضعیف مانند PDF و کلاس MediaStore.Downloads ، برنامه‌ها باید از هدف‌هایی مانند هدف ACTION_OPEN_DOCUMENT استفاده کنند.
برای فعال کردن رفتار Android 10، از ویژگی مانیفست requestLegacyExternalStorage استفاده کنید و بهترین شیوه‌های مجوزهای برنامه را دنبال کنید.
- مقدار پیش‌فرض پرچم مانیفست برای برنامه‌هایی که اندروید ۹ و پایین‌تر را هدف قرار می‌دهند
true است. - مقدار پیش‌فرض برای برنامه‌هایی که Android 10 را هدف قرار می‌دهند نادرست است. برای انصراف موقت از نمای فضای ذخیره‌سازی فیلتر شده در برنامه‌هایی که Android 10 را هدف قرار می‌دهند، مقدار پرچم مانیفست را روی
true تنظیم کنید. - نصب‌کننده با استفاده از مجوزهای محدود، برنامه‌های مجاز را برای ذخیره‌سازی غیرباکس‌دار فهرست‌بندی می‌کند. برنامه های غیر مجاز در جعبه ایمنی قرار دارند.
محتوا و نمونه کدها در این صفحه مشمول پروانههای توصیفشده در پروانه محتوا هستند. جاوا و OpenJDK علامتهای تجاری یا علامتهای تجاری ثبتشده Oracle و/یا وابستههای آن هستند.
تاریخ آخرین بهروزرسانی 2025-07-29 بهوقت ساعت هماهنگ جهانی.
[[["درک آسان","easyToUnderstand","thumb-up"],["مشکلم را برطرف کرد","solvedMyProblem","thumb-up"],["غیره","otherUp","thumb-up"]],[["اطلاعاتی که نیاز دارم وجود ندارد","missingTheInformationINeed","thumb-down"],["بیشازحد پیچیده/ مراحل بسیار زیاد","tooComplicatedTooManySteps","thumb-down"],["قدیمی","outOfDate","thumb-down"],["مشکل ترجمه","translationIssue","thumb-down"],["مشکل کد / نمونهها","samplesCodeIssue","thumb-down"],["غیره","otherDown","thumb-down"]],["تاریخ آخرین بهروزرسانی 2025-07-29 بهوقت ساعت هماهنگ جهانی."],[],[],null,["# Application Sandbox\n\nThe Android platform takes advantage of the Linux user-based protection to\nidentify and isolate app resources. This isolates apps from each other and\nprotects apps and the system from malicious apps. To do this, Android assigns a\nunique user ID (UID) to each Android app and runs it in its own\nprocess.\n\nAndroid uses the UID to set up a kernel-level Application Sandbox. The\nkernel enforces security between apps and the system at the process level\nthrough standard Linux facilities such as user and group IDs that are assigned\nto apps. By default, apps can't interact with each other and have limited\naccess to the OS. If app A tries to do something malicious, such as read\napp B's data or dial the phone without permission, it's prevented from\ndoing so because it doesn't have the appropriate default user privileges. The\nsandbox is simple, auditable, and based on decades-old UNIX-style user\nseparation of processes and file permissions.\n\nBecause the Application Sandbox is in the kernel, this security model\nextends to both native code and OS apps. All of the software above the\nkernel, such as OS libraries, app framework, app runtime, and\nall apps, run within the Application Sandbox. On some platforms,\ndevelopers are constrained to a specific development framework, set of APIs, or\nlanguage. On Android, there are no restrictions on how an app can be\nwritten that are required to enforce security; in this respect, native code is\nas sandboxed as interpreted code.\n\nProtections\n-----------\n\n\nGenerally, to break out of the Application Sandbox in a properly configured\ndevice, one must compromise the security of the Linux kernel. However, similar\nto other security features, individual protections enforcing the app\nsandbox are not invulnerable, so defense-in-depth is important to prevent\nsingle vulnerabilities from leading to compromise of the OS or other apps.\n\n\nAndroid relies on a number of protections to enforce the app\nsandbox. These enforcements have been introduced over time and have\nsignificantly strengthened the original UID-based discretionary access control\n(DAC) sandbox. Previous Android releases included the following\nprotections:\n\n- In Android 5.0, SELinux provided mandatory access control (MAC) separation between the system and apps. However, all third-party apps ran within the same SELinux context so inter-app isolation was primarily enforced by UID DAC.\n- In Android 6.0, the SELinux sandbox was extended to isolate apps across the per-physical-user boundary. In addition, Android also set safer defaults for app data: For apps with `targetSdkVersion \u003e= 24`, default DAC permissions on an app's home dir changed from 751 to 700. This provided safer default for private app data (although apps can override these defaults).\n- In Android 8.0, all apps were set to run with a `seccomp-bpf` filter that limited the syscalls that apps were allowed to use, thus strengthening the app/kernel boundary.\n- In Android 9 all nonprivileged apps with `targetSdkVersion \u003e=\n 28` must run in individual SELinux sandboxes, providing MAC on a per-app basis. This protection improves app separation, prevents overriding safe defaults, and (most significantly) prevents apps from making their data world accessible.\n- In Android 10 apps have a limited raw view of the filesystem, with no direct access to paths like /sdcard/DCIM. However, apps retain full raw access to their package-specific paths, as returned by any applicable methods, such as [Context.getExternalFilesDir()](https://developer.android.com/reference/android/content/Context.html#getExternalFilesDir(jav%20a.lang.String)).\n\nGuidelines for sharing files\n----------------------------\n\nSetting app data as world accessible is a poor security practice. Access\nis granted to everyone and it's not possible to limit access to only the intended\nrecipient(s). This practice has led to information disclosure leaks and confused\ndeputy vulnerabilities, and is a favorite target for malware that targets apps\nwith sensitive data (such as email clients). In Android 9 and higher, sharing\nfiles this way is explicitly disallowed for apps with\n`targetSdkVersion\u003e=28`.\n\n\nInstead of making app data world-accessible, use the following guidelines\nwhen sharing files:\n\n- If your app needs to share files with another app, use a [content provider](https://developer.android.com/guide/topics/providers/content-provider-basics.html). Content providers share data with the proper granularity and without the many downsides of world-accessible UNIX permissions (for details, refer to [Content provider basics](https://developer.android.com/guide/topics/providers/content-provider-basics.html)).\n- If 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](https://developer.android.com/reference/android/provider/MediaStore) class. (For more details on how to add a media item, see [Access media files from shared storage](https://developer.android.com/training/data-storage/shared/media#add-item).)\n\nThe **Storage** runtime permission controls access\nto strongly-typed collections through **MediaStore** .\nFor accessing weakly typed files such as PDFs and the [MediaStore.Downloads](https://developer.android.com/reference/android/provider/MediaStore.Downloads) class, apps must use\nintents like the [`ACTION_OPEN_DOCUMENT`](https://developer.android.com/reference/android/content/Intent.html#ACTION_OPEN_DOCUMENT) intent.\n\nTo enable Android 10 behavior, use the\n[requestLegacyExternalStorage](https://developer.android.com/training/data-storage/files/external-scoped#opt-out-of-%20filtered-view) manifest\nattribute, and follow [App permissions best practices](https://developer.android.com/training/permissions/usage-notes).\n\n- The manifest flag default value is `true` for apps targeting Android 9 and lower.\n- The default value is false for apps targeting Android 10. To temporarily opt out of the filtered storage view in apps targeting Android 10, set the manifest flag's value to `true`.\n- Using restricted permissions, the installer allowlists apps permitted for nonsandboxed storage. Nonallowlisted apps are sandboxed."]]
