اعتبارًا من 27 آذار (مارس) 2025، ننصحك باستخدام android-latest-release بدلاً من aosp-main لإنشاء AOSP والمساهمة فيه. لمزيد من المعلومات، يُرجى الاطّلاع على التغييرات في AOSP.
تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
كجزء من
نموذج أمان Android، يستخدم نظام التشغيل Android Security-Enhanced Linux (SELinux) لفرض
التحكّم الإجباري في الوصول (MAC) على جميع العمليات، حتى العمليات التي تعمل باستخدام
امتيازات المستخدم الجذر/المشرف (إمكانات Linux). ساهمت العديد من الشركات والمؤسسات في
تنفيذ SELinux في نظام التشغيل Android. باستخدام SELinux، يمكن لنظام Android حماية خدمات النظام والحد من وصولها بشكل أفضل، والتحكّم في الوصول إلى بيانات التطبيقات وسجلات النظام، والحد من تأثيرات البرامج الضارّة، وحماية المستخدمين من العيوب المحتمَلة في الرموز البرمجية على الأجهزة المتحرّكة.
يعمل SELinux وفقًا لمبدأ الرفض التلقائي: أيّ عملية ليست مُسموحة بشكلٍ صريح
تُرفض. يمكن أن يعمل SELinux في وضعَين عامَّين:
وضع السماح، الذي يتم فيه تسجيل عمليات رفض الأذونات ولكن لا يتم
فرضها
وضع فرض، الذي يتم فيه تسجيل عمليات رفض الأذونات
و فرضها
يتضمّن نظام التشغيل Android تنسيق SELinux في وضع التنفيذ وسياسة أمان
مقابلة تعمل تلقائيًا على مستوى AOSP. في وضع التنفيذ، يتم منع
الإجراءات غير المسموح بها، ويُسجِّل نظام التشغيل جميع المخالفات التي تمّت محاولة تنفيذها فيملفَي dmesg وlogcat. عند التطوير، يجب
استخدام هذه الأخطاء لتحسين البرامج وسياسات SELinux قبل فرض
هذه السياسات. لمزيد من التفاصيل، يُرجى الاطّلاع على مقالة Implementing
SELinux.
يتيح SELinux أيضًا وضع السماح لكل نطاق الذي يمكن فيه السماح
ببعض النطاقات (العمليات) مع وضع بقية النظام
في وضع التنفيذ العام. النطاق هو ببساطة تصنيف يحدِّد عملية أو
مجموعة من العمليات في سياسة الأمان، حيث تتعامل سياسة الأمان مع جميع العمليات المصنَّفة باستخدام
النطاق نفسه بشكلٍ متطابق. يتيح الوضع المتساهل على مستوى النطاق
تطبيق SELinux بشكل تدريجي على جزء متزايد باستمرار
من النظام وتطوير السياسات للخدمات الجديدة (مع إبقاء
بقية النظام ساريًا).
الخلفية
يستند نموذج أمان Android جزئيًا إلى مفهوم
أحياء التطبيقات المحمية. يتم تشغيل كل تطبيق
في بيئة الحماية الخاصة به. قبل الإصدار 4.3 من نظام التشغيل Android، كان يتم تحديد هذه البيئات المحمية من خلال
إنشاء معرّف مستخدم فريد لنظام التشغيل Linux لكل تطبيق في وقت التثبيت.
يستخدم الإصدار 4.3 من Android والإصدارات الأحدث تنسيق SELinux لتحديد حدود
وضع الحماية لتطبيقات Android بشكل أفضل.
في الإصدار Android 5.0 والإصدارات الأحدث، يتم فرض سياسة SELinux بالكامل، استنادًا إلى الإصدار
المتساهل من Android 4.3 والفرض الجزئي لسياسة Android 4.4.
وبفضل هذا التغيير، توقّف Android عن فرض الامتثال على مجموعة محدودة من
النطاقات المهمة (installd وnetd وvold و
zygote) وأصبح يفرض الامتثال على كل النطاقات (أكثر من 60 نطاقًا). وعلى وجه التحديد:
يتم فرض كل الإعدادات في الإصدار 5.x من نظام التشغيل Android والإصدارات الأحدث.
يجب عدم تشغيل أي عمليات أخرى غير init في نطاق
init.
يشير أي رفض عام (للأجهزة التي تعمل بنظام التشغيل block_device أو
socket_device أو default_service) إلى أنّه
يحتاج الجهاز إلى نطاق خاص.
في الإصدار 6.0 من Android، تم تحسين أمان النظام من خلال تقليل تساهل
سياستنا لتشمل عزلًا أفضل بين المستخدمين، وفلترة IOCTL، وخفض
التهديدات التي تواجه الخدمات المكشوفة، وتعزيز إجراءات الأمان في نطاقات SELinux، ومحاولة محدودة للغاية للوصول إلى /proc.
عدّل نظام Android 8.0 أمان SELinux للعمل مع Treble، الذي يفصل رمز المورّد من المستوى الأدنى عن إطار عمل نظام Android. عدّل هذا الإصدار سياسة ملف تعريف أمان نظام التشغيل (SELinux)
للسماح لمصنعي الأجهزة ومورّدي شرائح المعالجة المركزية (SOC) بتعديل أجزاءهم من
السياسة وإنشاء صورهم (vendor.img وboot.img وغيرها)، ثم تعديل هذه الصور بغض النظر عن النظام الأساسي أو العكس.
على الرغم من أنّه من الممكن استخدام إصدار أحدث من النظام الأساسي (إطار العمل)
على الجهاز، لا يمكن استخدام إصدار أقدم من إصدار النظام الأساسي
(system.img) في صور المورّد
(vendor.img/odm.img). وبالتالي، قد يؤدي استخدام إصدار أحدث من النظام الأساسي إلى حدوث مشاكل في توافق SELinux
لأنّ سياسة SELinux للنظام الأساسي تكون في إصدار أحدث
من أجزاء SELinux الخاصة بالمورّد من السياسة. يقدّم نموذج Android 8.0 طريقة
للحفاظ على التوافق لمنع
عمليات التحديثات التلقائية المتزامنة غير الضرورية.
مصادر إضافية
للحصول على مساعدة في إنشاء سياسات SELinux مفيدة، يُرجى الرجوع إلى المراجع التالية:
دفتر ملاحظات SELinux، وهو مرجع حديث لنظام SELinux يحتوي هذا المستند على
تفاصيل إضافية حول لغة السياسة ومعنى كل كلمة رئيسية وكيفية محاسبة
السياقات الأمنية.
يخضع كل من المحتوى وعيّنات التعليمات البرمجية في هذه الصفحة للتراخيص الموضحّة في ترخيص استخدام المحتوى. إنّ Java وOpenJDK هما علامتان تجاريتان مسجَّلتان لشركة Oracle و/أو الشركات التابعة لها.
تاريخ التعديل الأخير: 2025-07-27 (حسب التوقيت العالمي المتفَّق عليه)
[[["يسهُل فهم المحتوى.","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-27 (حسب التوقيت العالمي المتفَّق عليه)"],[],[],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)"]]
