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

تنفيذ SELinux

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

الملفات الأساسية

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

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

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

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

ملفات السياق

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

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

ملف makefile BoardConfig.mk

بعد تعديل أو إضافة ملفات النهج والسياق، حدِّث /device/manufacturer/device-name/BoardConfig.mk للإشارة إلى الدليل الفرعي 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 في النواة kernel: CONFIG_SECURITY_SELINUX=y
يمكنك تغيير المعلمة kernel_cmdline أو Bootconfig بحيث:
```
BOARD_KERNEL_CMDLINE := androidboot.selinux=permissive
```
أو
```
BOARD_BOOTCONFIG := androidboot.selinux=permissive
```
وهذا فقط من أجل التطوير الأولي لسياسة الجهاز. بعد سياسة تمهيد أولي، أزِل هذه المعلمة حتى يصبح الجهاز الذي سيتم فرضه وإلا لن ينجح CTS.
شغِّل النظام متساهلًا وتحقَّق من عمليات الرفض التي تحدث أثناء التشغيل:
على نظام التشغيل 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_* المتغيرات. يمكنك الاطّلاع على قراءة في 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.