اعتبارًا من 27 آذار (مارس) 2025، ننصحك باستخدام android-latest-release بدلاً من aosp-main لإنشاء AOSP والمساهمة فيه. لمزيد من المعلومات، يُرجى الاطّلاع على التغييرات في AOSP.

تمت ترجمة هذه الصفحة بواسطة Cloud Translation API‏.

تنفيذ SELinux

تم إعداد SELinux على وضع الرفض التلقائي، ما يعني أنّه يجب السماح صراحةً بكل عملية وصول يتضمّنها الخطاف في النواة، وذلك من خلال السياسة. وهذا يعني أنّ ملف السياسة يتضمّن قدرًا كبيرًا من المعلومات حول القواعد والأنواع والفئات والأذونات وغير ذلك. لا يتناول هذا المستند موضوع SELinux بشكل كامل، ولكن أصبح من الضروري الآن فهم كيفية كتابة قواعد السياسات عند إعداد أجهزة Android جديدة. تتوفّر حاليًا معلومات كثيرة حول SELinux. يمكنك الاطّلاع على المستندات الداعمة للحصول على مراجع مقترَحة.

الملفات الرئيسية

لتفعيل SELinux، عليك دمج أحدث نواة Android ثم دمج الملفات التي تم العثور عليها في الدليل system/sepolicy. وعند تجميعها، تشكّل هذه الملفات سياسة أمان نواة SELinux وتغطي نظام التشغيل Android الأساسي.

بشكل عام، لا يجب تعديل ملفات system/sepolicy مباشرةً. بدلاً من ذلك، يمكنك إضافة ملفات سياسات خاصة بجهازك أو تعديلها في الدليل /device/manufacturer/device-name/sepolicy. في الإصدار 8.0 من نظام التشغيل Android والإصدارات الأحدث، من المفترض أن تؤثّر التغييرات التي تجريها على هذه الملفات في السياسة في دليل المورّد فقط. لمزيد من التفاصيل حول فصل سياسة الأمان المحسّن لنظام التشغيل Android (SEPolicy) العامة في الإصدار 8.0 والإصدارات الأحدث، يُرجى الاطّلاع على تخصيص سياسة الأمان المحسّن لنظام التشغيل Android في الإصدار 8.0 والإصدارات الأحدث. وبغض النظر عن إصدار Android، ستظل تعدّل هذه الملفات:

ملفات السياسات

الملفات التي تنتهي بـ *.te هي ملفات مصدر لسياسة SELinux، وهي تحدّد النطاقات وتصنيفاتها. قد تحتاج إلى إنشاء ملفات سياسات جديدة في /device/manufacturer/device-name/sepolicy، ولكن ننصحك بمحاولة تعديل الملفات الحالية حيثما أمكن ذلك.

ملفات السياق

ملفات السياق هي المكان الذي تحدّد فيه تصنيفات للعناصر.

تُستخدَم file_contexts لتعيين تصنيفات للملفات، وتستخدِمها العديد من مكونات مساحة المستخدم. أثناء إنشاء سياسات جديدة، أنشئ هذا الملف أو عدِّله لتعيين تصنيفات جديدة للملفات. لتطبيق file_contexts جديد، عليك إعادة إنشاء صورة نظام الملفات أو تنفيذ restorecon على الملف الذي تريد إعادة تصنيفه. عند إجراء ترقيات، يتم تطبيق التغييرات على file_contexts تلقائيًا على قسمَي النظام وبيانات المستخدم كجزء من عملية الترقية. يمكن أيضًا تطبيق التغييرات تلقائيًا عند الترقية إلى أقسام أخرى من خلال إضافة طلبات restorecon_recursive إلى ملف init.board.rc بعد تثبيت القسم في وضع القراءة والكتابة.
تُعيّن genfs_contexts تصنيفات لأنظمة الملفات، مثل proc أو vfat التي لا تتوافق مع السمات الموسّعة. يتم تحميل هذا الإعداد كجزء من سياسة النواة، ولكن قد لا يتم تطبيق التغييرات على عقد البيانات الأساسية في الذاكرة، ما يتطلّب إعادة التشغيل أو إلغاء تحميل نظام الملفات وإعادة تحميله لتطبيق التغيير بالكامل. يمكن أيضًا تعيين تصنيفات محدّدة لأقراص معيّنة، مثل vfat باستخدام الخيار context=mount.
تُعيّن property_contexts تصنيفات لسمات نظام التشغيل Android من أجل التحكّم في العمليات التي يمكنها ضبطها. يتم قراءة هذا الإعداد من خلال عملية init أثناء بدء التشغيل.
تُعيّن service_contexts تصنيفات لخدمات Android binder من أجل التحكّم في العمليات التي يمكنها إضافة (تسجيل) مرجع binder للخدمة والعثور عليه (البحث عنه). يتم قراءة هذا الإعداد من خلال عملية servicemanager أثناء بدء التشغيل.
تُعيّن seapp_contexts تصنيفات لعمليات التطبيق وأدلة /data/data. يتم قراءة هذا الإعداد من خلال عملية zygote عند كل عملية تشغيل للتطبيق ومن خلال installd أثناء بدء التشغيل.
تُعيِّن mac_permissions.xml علامة seinfo للتطبيقات استنادًا إلى توقيعها واسم الحزمة اختياريًا. يمكن بعد ذلك استخدام العلامة seinfo كمفتاح في الملف seapp_contexts لتعيين تصنيف معيّن لجميع التطبيقات التي تتضمّن العلامة seinfo. يتم قراءة هذا الإعداد من خلال system_server أثناء بدء التشغيل.
تُعيّن keystore2_key_contexts تصنيفات لمساحات أسماء Keystore 2. يتم فرض مساحات الاسم هذه من خلال البرنامج الخفي keystore2. لطالما وفّرت خدمة Keystore مساحات أسماء مستندة إلى UID/AID. يفرض الإصدار 2 من Keystore أيضًا مساحات الأسماء المحدّدة في sepolicy. يمكنك الاطّلاع على وصف تفصيلي لتنسيق هذا الملف وقواعده هنا.

ملف BoardConfig.mk makefile

بعد تعديل ملفات السياسة والسياق أو إضافتها، عليك تعديل ملف /device/manufacturer/device-name/BoardConfig.mk makefile للإشارة إلى الدليل الفرعي sepolicy وكل ملف سياسة جديد. لمزيد من المعلومات عن المتغيّرات BOARD_SEPOLICY، يُرجى الاطّلاع على ملف system/sepolicy/README.

BOARD_SEPOLICY_DIRS += \
        <root>/device/manufacturer/device-name/sepolicy

BOARD_SEPOLICY_UNION += \
        genfs_contexts \
        file_contexts \
        sepolicy.te

بعد إعادة الإنشاء، سيتم تفعيل SELinux على جهازك. يمكنك الآن إما تخصيص سياسات SELinux لتناسب إضافاتك إلى نظام التشغيل Android كما هو موضّح في التخصيص أو التحقّق من الإعداد الحالي كما هو موضّح في التحقّق.

عند توفّر ملفات السياسة الجديدة وتعديلات BoardConfig.mk، يتم تلقائيًا إنشاء إعدادات السياسة الجديدة في ملف سياسة النواة النهائي. لمزيد من المعلومات حول طريقة إنشاء sepolicy على الجهاز، يمكنك الاطّلاع على إنشاء sepolicy.

التنفيذ

لبدء استخدام SELinux، اتّبِع الخطوات التالية:

فعِّل SELinux في النواة: CONFIG_SECURITY_SELINUX=y
غيِّر المَعلمة kernel_cmdline أو bootconfig على النحو التالي:
```
BOARD_KERNEL_CMDLINE := androidboot.selinux=permissive
```
أو
```
BOARD_BOOTCONFIG := androidboot.selinux=permissive
```
يتم استخدام هذا الخيار فقط لتطوير السياسة الأولية للجهاز. بعد توفّر سياسة إعداد أوّلي، عليك إزالة هذه المَعلمة لكي يفرض جهازك السياسة أو يتعذّر عليه اجتياز اختبار التوافق مع نظام التشغيل Android.
شغِّل النظام في الوضع المتساهل واطّلِع على الأذونات المرفوضة عند التشغيل:
على Ubuntu 14.04 أو إصدار أحدث:
```
adb shell su -c dmesg | grep denied | audit2allow -p out/target/product/BOARD/root/sepolicy
```
على نظام التشغيل Ubuntu 12.04:
```
adb pull /sys/fs/selinux/policy
adb logcat -b all | audit2allow -p policy
```
قيِّم الناتج بحثًا عن تحذيرات مشابهة لما يلي: init: Warning! Service name needs a SELinux domain defined; please fix! راجِع قسم التحقّق من الصحة للاطّلاع على التعليمات والأدوات.
تحديد الأجهزة والملفات الجديدة الأخرى التي تحتاج إلى تصنيف
استخدِم تصنيفات حالية أو جديدة للعناصر. اطّلِع على ملفات *_contexts لمعرفة كيفية تصنيف الملفات سابقًا، واستخدِم معرفتك بمعاني التصنيفات لتعيين تصنيف جديد. من المفترض أن يكون هذا التصنيف حاليًا ومناسبًا للسياسة، ولكن في بعض الأحيان، يكون هناك حاجة إلى تصنيف جديد، كما يجب وضع قواعد للوصول إلى هذا التصنيف. أضِف التصنيفات إلى ملفات السياق المناسبة.
تحديد النطاقات/العمليات التي يجب أن يكون لها نطاقات أمان خاصة بها من المحتمل أنّك بحاجة إلى كتابة سياسة جديدة تمامًا لكلّ منهما. يجب أن يكون لكل الخدمات التي تم إنشاؤها من init، على سبيل المثال، معرّفها الخاص. تساعد الأوامر التالية في الكشف عن الخدمات التي لا تزال قيد التشغيل (ولكن يجب تطبيق هذا الإجراء على جميع الخدمات):
```
adb shell su -c ps -Z | grep init
```
```
adb shell su -c dmesg | grep 'avc: '
```
راجِع init.device.rc لتحديد أي نطاقات ليس لها نوع نطاق. يجب منحهم نطاقًا في مرحلة مبكرة من عملية التطوير لتجنُّب إضافة قواعد إلى init أو حدوث أي التباس بشأن عمليات الوصول إلى init مع تلك التي تتضمّنها سياستهم.
إعداد BOARD_CONFIG.mk لاستخدام متغيّرات BOARD_SEPOLICY_* يُرجى الاطّلاع على ملف README في system/sepolicy لمعرفة تفاصيل حول كيفية إعداد هذه الميزة.
افحص ملف init.device.rc وملف fstab.device وتأكَّد من أنّ كل استخدام لـ mount يتوافق مع نظام ملفات مصنَّف بشكل سليم أو أنّه تم تحديد الخيار context= mount.
راجِع كل رفض وأنشئ سياسة SELinux للتعامل مع كل رفض بشكلٍ صحيح. يمكنك الاطّلاع على الأمثلة في التخصيص.

يجب البدء بالسياسات الواردة في AOSP ثم البناء عليها لإجراء التخصيصات الخاصة بك. لمزيد من المعلومات حول استراتيجية السياسة وإلقاء نظرة فاحصة على بعض هذه الخطوات، راجِع كتابة سياسة SELinux.

حالات الاستخدام

في ما يلي أمثلة محدّدة على الثغرات الأمنية التي يجب مراعاتها عند تصميم برامجك وسياسات SELinux المرتبطة بها:

الروابط الرمزية: بما أنّ الروابط الرمزية تظهر كملفات، يتم غالبًا قراءتها كملفات، ما قد يؤدي إلى استغلالها. على سبيل المثال، تغيّر بعض المكوّنات ذات الامتيازات، مثل init، أذونات ملفات معيّنة، وأحيانًا تكون الأذونات مفتوحة بشكل مفرط.

وقد يستبدل المهاجمون بعد ذلك هذه الملفات بروابط رمزية تؤدي إلى رموز يتحكّمون فيها، ما يسمح لهم بالكتابة فوق ملفات عشوائية. ولكن إذا كنت تعلم أنّ تطبيقك لا يتنقّل مطلقًا عبر رابط رمزي، يمكنك منعه من إجراء ذلك باستخدام SELinux.

ملفات النظام: يجب مراعاة فئة ملفات النظام التي يجب أن يعدّلها خادم النظام فقط. ومع ذلك، بما أنّ netd وinit وvold تعمل كجذر، يمكنها الوصول إلى ملفات النظام هذه. لذلك، إذا تم اختراق netd، يمكن أن يؤدي ذلك إلى اختراق هذه الملفات وربما خادم النظام نفسه.

باستخدام SELinux، يمكنك تحديد هذه الملفات كملفات بيانات خادم النظام. لذلك، النطاق الوحيد الذي لديه إذن القراءة والكتابة هو خادم النظام. حتى إذا تم اختراق netd، لن يتمكّن من التبديل إلى نطاق خادم النظام والوصول إلى ملفات النظام هذه على الرغم من أنّه يعمل كجذر.

بيانات التطبيق: مثال آخر هو فئة الدوال التي يجب تشغيلها كجذر ولكن لا يجب أن تتمكّن من الوصول إلى بيانات التطبيق. وهذا مفيد للغاية، إذ يمكن تقديم تأكيدات واسعة النطاق، مثل حظر وصول نطاقات معيّنة غير مرتبطة ببيانات التطبيق إلى الإنترنت.

setattr: بالنسبة إلى أوامر مثل chmod وchown، يمكنك تحديد مجموعة الملفات التي يمكن للنطاق المرتبط بها تنفيذ setattr فيها. أي شيء خارج هذا النطاق قد يكون محظورًا من هذه التغييرات، حتى من خلال الجذر. لذا، قد يعرض التطبيق الإعلانين chmod وchown للمستخدمين الذين تم تصنيفهم على أنّهم app_data_files، ولكن ليس للمستخدمين الذين تم تصنيفهم على أنّهم shell_data_files أو system_data_files.