از 27 مارس 2025، توصیه می کنیم از android-latest-release به جای aosp-main برای ساختن و کمک به AOSP استفاده کنید. برای اطلاعات بیشتر، به تغییرات AOSP مراجعه کنید.
با مجموعهها، منظم بمانید
ذخیره و طبقهبندی محتوا براساس اولویتهای شما.
به عنوان بخشی از مدل امنیتی اندروید، اندروید از لینوکس تقویتشده با امنیت (SELinux) برای اعمال کنترل دسترسی اجباری (MAC) بر روی همه فرآیندها، حتی فرآیندهایی که با امتیازات روت/ابر کاربر (قابلیتهای لینوکس) اجرا میشوند، استفاده میکند. بسیاری از شرکتها و سازمانها در پیادهسازی SELinux اندروید مشارکت داشتهاند. با SELinux، Android میتواند بهتر از خدمات سیستم محافظت و محدود کند، دسترسی به دادههای برنامه و گزارشهای سیستم را کنترل کند، اثرات نرمافزارهای مخرب را کاهش دهد و از کاربران در برابر نقصهای احتمالی در کد دستگاههای تلفن همراه محافظت کند.
SELinux بر اساس اصل انکار پیش فرض عمل می کند: هر چیزی که به صراحت مجاز نباشد رد می شود. SELinux می تواند در دو حالت جهانی کار کند:
حالت مجاز ، که در آن رد مجوز ثبت می شود اما اجرا نمی شود.
حالت اجرایی ، که در آن رد مجوزها هم ثبت و هم اجرا میشوند.
Android شامل SELinux در حالت اعمال و یک خط مشی امنیتی مربوطه است که به طور پیش فرض در سراسر AOSP کار می کند. در حالت اجرا، از اقدامات غیرمجاز جلوگیری میشود و تمام تلاشهای نقض شده توسط هسته در dmesg و logcat ثبت میشوند. هنگام توسعه، باید از این خطاها برای اصلاح نرمافزار و سیاستهای SELinux قبل از اجرای آنها استفاده کنید. برای جزئیات بیشتر، به پیاده سازی SELinux مراجعه کنید.
SELinux همچنین از یک حالت مجاز برای هر دامنه پشتیبانی می کند که در آن دامنه های خاص (فرآیندها) می توانند مجاز شوند در حالی که بقیه سیستم را در حالت اجرای جهانی قرار می دهند. دامنه صرفاً برچسبی است که یک فرآیند یا مجموعه ای از فرآیندها را در خط مشی امنیتی شناسایی می کند، که در آن تمام فرآیندهای برچسب گذاری شده با همان دامنه توسط خط مشی امنیتی یکسان برخورد می شود. حالت مجاز به ازای هر دامنه، کاربرد تدریجی SELinux را در بخش روزافزونی از سیستم و توسعه خط مشی برای سرویسهای جدید را امکانپذیر میسازد (در حالی که بقیه سیستم را در حال اجرا نگه میدارد).
زمینه
مدل امنیتی اندروید تا حدی بر اساس مفهوم جعبههای ایمنی برنامهها است. هر برنامه در جعبه شنی مخصوص به خود اجرا می شود. قبل از اندروید 4.3، این sandboxها با ایجاد یک UID لینوکس منحصر به فرد برای هر برنامه در زمان نصب تعریف می شدند. Android نسخه 4.3 و بالاتر از SELinux برای تعریف بیشتر مرزهای جعبه ایمنی برنامه Android استفاده می کند.
در اندروید 5.0 و جدیدتر، SELinux به طور کامل اجرا میشود که بر اساس انتشار آسان اندروید 4.3 و اجرای جزئی اندروید 4.4 است. با این تغییر، اندروید از اجرای مجموعه محدودی از دامنه های حیاتی ( installd ، netd ، vold و zygote ) به همه چیز (بیش از 60 دامنه) تغییر مکان داد. به طور مشخص:
همه چیز در اندروید 5.x و بالاتر در حالت اعمال است.
هیچ فرآیند دیگری به جز init نباید در دامنه init اجرا شود.
هرگونه انکار عمومی (برای block_device ، socket_device ، default_service ) نشان می دهد که دستگاه به یک دامنه خاص نیاز دارد.
Android 6.0 سیستم را با کاهش مجاز بودن خطمشی ما سختتر کرد تا شامل ایزولهسازی بهتر بین کاربران، فیلتر IOCTL، کاهش خطر سرویسهای در معرض خطر، سختتر شدن بیشتر دامنههای SELinux و دسترسی بسیار محدود /proc باشد.
Android 7.0 پیکربندی SELinux را برای قفل کردن بیشتر سندباکس برنامه و کاهش سطح حمله به روز کرد. این نسخه همچنین پشته مدیا سرور یکپارچه را به فرآیندهای کوچکتر تقسیم کرد تا دامنه مجوزهای آنها کاهش یابد. برای جزئیات بیشتر، به محافظت از اندروید با دفاع بیشتر هسته لینوکس و سخت کردن پشته رسانه مراجعه کنید.
Android 8.0 SELinux را برای کار با Treble به روز کرد که کد فروشنده سطح پایین را از چارچوب سیستم Android جدا می کند. این نسخه خطمشی SELinux را بهروزرسانی کرد تا به سازندگان دستگاه و فروشندگان SOC اجازه دهد بخشهای خطمشی خود را بهروزرسانی کنند، تصاویر خود را بسازند ( vendor.img ، boot.img ، و غیره)، سپس آن تصاویر را مستقل از پلتفرم بهروزرسانی کنند یا برعکس.
در حالی که این امکان وجود دارد که نسخه (فریم ورک) بالاتر/جدیدتری روی دستگاه اجرا شود، حالت مخالف پشتیبانی نمیشود. تصاویر فروشنده ( vendor.img/odm.img ) نمی توانند نسخه جدیدتری نسبت به پلتفرم ( system.img ) داشته باشند. بنابراین، یک نسخه پلتفرم جدیدتر ممکن است مشکلات سازگاری SELinux را ایجاد کند زیرا خط مشی پلتفرم SELinux در نسخه جدیدتر از بخش های SELinux فروشنده این خط مشی است. مدل Android 8.0 روشی را برای حفظ سازگاری برای جلوگیری از OTAهای غیرضروری ارائه می دهد.
منابع اضافی
برای کمک به ایجاد خط مشی های مفید SELinux، به منابع زیر مراجعه کنید.
نوت بوک SELinux ، مرجع به روز برای SELinux. این سند حاوی جزئیات بیشتر در مورد زبان خط مشی، معنای هر یک از کلمات کلیدی و نحوه محاسبه زمینه های امنیتی است.
محتوا و نمونه کدها در این صفحه مشمول پروانههای توصیفشده در پروانه محتوا هستند. جاوا و 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,["# Security-Enhanced Linux in Android\n\nAs part of the Android [security model](/docs/security), Android uses Security-Enhanced Linux (SELinux) to enforce\nmandatory access control (MAC) over all processes, even processes running with\nroot/superuser privileges (Linux capabilities). Many companies and organizations\nhave contributed to Android's\n[SELinux\nimplementation](https://android.googlesource.com/platform/external/selinux/). With SELinux, Android can better protect and confine system\nservices, control access to application data and system logs, reduce the effects\nof malicious software, and protect users from potential flaws in code on mobile\ndevices.\n\nSELinux operates on the principle of default denial: Anything not explicitly\nallowed is denied. SELinux can operate in two global modes:\n\n- *Permissive* mode, in which permission denials are logged but not enforced.\n- *Enforcing* mode, in which permissions denials are both logged **and** enforced.\n\nAndroid includes SELinux in enforcing mode and a corresponding security\npolicy that works by default across AOSP. In enforcing mode, disallowed\nactions are prevented and all attempted violations are logged by the kernel to\n`dmesg` and `logcat`. When developing, you should\nuse these errors to refine your software and SELinux policies before enforcing\nthem. For more details, see [Implementing\nSELinux](/docs/security/features/selinux/implement).\n\nSELinux also supports a *per-domain permissive* mode in which specific\ndomains (processes) can be made permissive while placing the rest of the system\nin global enforcing mode. A domain is simply a label identifying a process or\nset of processes in the security policy, where all processes labeled with the\nsame domain are treated identically by the security policy. Per-domain\npermissive mode enables incremental application of SELinux to an ever-increasing\nportion of the system and policy development for new services (while keeping\nthe rest of the system enforcing).\n\nBackground\n----------\n\nThe Android security model is based in part on the concept of\n[application sandboxes](/docs/security/app-sandbox). Each application\nruns in its own sandbox. Prior to Android 4.3, these sandboxes were defined by\nthe creation of a unique Linux UID for each application at time of installation.\nAndroid 4.3 and later uses SELinux to further define the boundaries of the\nAndroid application sandbox.\n\nIn Android 5.0 and later, SELinux is fully enforced, building on the\npermissive release of Android 4.3 and the partial enforcement of Android 4.4.\nWith this change, Android shifted from enforcement on a limited set of crucial\ndomains (`installd`, `netd`, `vold` and\n`zygote`) to everything (more than 60 domains). Specifically:\n\n- Everything is in enforcing mode in Android 5.x and higher.\n- No processes other than `init` should run in the `init` domain.\n- Any generic denial (for a `block_device`, `socket_device`, `default_service`) indicates that device needs a special domain.\n\nAndroid 6.0 hardened the system by reducing the permissiveness of our\npolicy to include better isolation between users, IOCTL filtering, reduced\nthreat of exposed services, further tightening of SELinux domains, and\nextremely limited `/proc` access.\n\nAndroid 7.0 updated SELinux configuration to further lock down the\napplication sandbox and reduce attack surface. This release also broke up the\nmonolithic mediaserver stack into smaller processes to reduce the scope of\ntheir permissions. For more details, see\n[Protecting\nAndroid with more Linux kernel defenses](https://android-developers.googleblog.com/2016/07/protecting-android-with-more-linux.html) and\n[Hardening the media stack](https://android-developers.googleblog.com/2016/05/hardening-media-stack.html).\n\nAndroid 8.0 updated SELinux to work with [Treble](/docs/core/architecture#hidl), which separates the lower-level\nvendor code from the Android system framework. This release updated SELinux\npolicy to allow device manufacturers and SOC vendors to update their parts of\nthe policy, build their images (`vendor.img`, `boot.img`,\netc.), then update those images independent of the platform or vice versa.\n\nWhile it is possible to have higher/newer platform (framework) version\nrunning on the device, the opposite case is not supported; the vendor images\n(`vendor.img/odm.img`) cannot have a newer version than the platform\n(`system.img`). So, a newer platform version might introduce SELinux\ncompatibility issues because the platform SELinux policy is at a newer version\nthan vendor SELinux parts of the policy. The Android 8.0 model provides a method\nto [retain compatibility](/docs/security/features/selinux/compatibility) to prevent\nunnecessary simultaneous OTAs.\n\nAdditional resources\n--------------------\n\nFor help constructing useful SELinux policies, refer to the following\nresources.\n\n| **Note:** Some SELinux concepts are not used by Android. For further details, see [Specificity](/docs/security/features/selinux/concepts#specificity).\n\n\u003cbr /\u003e\n\n- [The SELinux Notebook](https://github.com/SELinuxProject/selinux-notebook), up-to-date reference for SELinux. This document contains further details on the policy language, the meaning of each of the keywords and how security contexts are computed.\n- [Your visual how-to guide for SELinux policy enforcement](https://opensource.com/business/13/11/selinux-policy-guide)\n- [Security Enhancements for Linux](https://events.static.linuxfound.org/sites/events/files/slides/abs2014_seforandroid_smalley.pdf)\n- [Security Enhanced (SE) Android: Bringing Flexible MAC to Android](http://www.cs.columbia.edu/~lierranli/coms6998-7Spring2014/papers/SEAndroid-NDSS2013.pdf)\n- [Implementing SELinux as a Linux Security Module](https://www.nsa.gov/resources/everyone/digital-media-center/publications/research-papers/assets/files/implementing-selinux-as-linux-security-module-report.pdf)\n- [Configuring the SELinux Policy](https://www.nsa.gov/resources/everyone/digital-media-center/publications/research-papers/assets/files/configuring-selinux-policy-report.pdf)"]]