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

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

التوافق مع السياسة

توضّح هذه الصفحة كيفية تعامل نظام التشغيل Android مع مشاكل توافق السياسات مع تحديثات النظام الأساسي عبر الأثير (OTA)، حيث قد تختلف إعدادات SELinux الجديدة للنظام الأساسي عن إعدادات SELinux القديمة الخاصة بالمورّد.

ملكية العناصر وتصنيفها

يجب تحديد الملكية بوضوح لكل عنصر للحفاظ على فصل سياسات المنصة والمورّد. على سبيل المثال، إذا كانت تصنيفات سياسة المورّد /dev/foo وتصنيفات سياسة المنصة /dev/foo في تحديث لاحق عبر الأثير، سيحدث سلوك غير محدّد، مثل رفض غير متوقّع، أو بشكل أكثر خطورة، تعذُّر بدء التشغيل. بالنسبة إلى SELinux، يظهر ذلك على شكل تعارض في التصنيف. يمكن أن تحتوي عقدة الجهاز على تصنيف واحد فقط يتم تحديده حسب التصنيف الذي تم تطبيقه آخر مرة. نتيجة لذلك:

تفقد العمليات التي تحتاج إلى إذن الوصول إلى التصنيف الذي لم يتم تطبيقه بنجاح إذن الوصول إلى المورد.
قد تتعطّل العمليات التي تصل إلى الملف بسبب إنشاء عقدة جهاز غير صحيحة.

يمكن أن تحدث تعارضات بين تصنيفات المنصة وتصنيفات المورّد لأي عنصر يتضمّن تصنيف SELinux، بما في ذلك الخصائص والخدمات والعمليات والملفات والمآخذ. لتجنُّب هذه المشاكل، حدِّد بوضوح ملكية هذه العناصر.

تحديد مساحة الاسم للنوع/السمة

بالإضافة إلى تعارضات التصنيفات، يمكن أن تتعارض أيضًا أسماء أنواع وسمات SELinux. لا يسمح SELinux بتعريفات متعددة للأنواع والسمات نفسها. لا يمكن تجميع سياسة تتضمّن بيانات مكرّرة. لتجنُّب حدوث تعارضات في النوع واسم السمة، ننصح بشدة بأن تبدأ جميع بيانات المورّدين بالبادئة vendor_. على سبيل المثال، يجب أن يستخدم البائعون type vendor_foo, domain; بدلاً من type foo, domain;.

ملكية الملف

يصعب منع حدوث تعارضات في الملفات لأنّ سياسة النظام الأساسي وسياسة المورّد توفّران عادةً تصنيفات لجميع أنظمة الملفات. على عكس تسمية الأنواع، لا يمكن تطبيق مساحة الاسم على الملفات لأنّ النواة هي التي تنشئ العديد منها. لتجنُّب هذه التصادمات، اتّبِع إرشادات التسمية لأنظمة الملفات الواردة في هذا القسم. بالنسبة إلى الإصدار 8.0 من نظام التشغيل Android، هذه مجرد اقتراحات بدون فرض فني. في المستقبل، سيتم فرض هذه الاقتراحات من خلال مجموعة اختبارات المورّد (VTS).

النظام (/system)

يجب أن توفّر صورة النظام فقط تصنيفات لمكوّنات /system من خلال file_contexts وservice_contexts وما إلى ذلك. وإذا تمت إضافة تصنيفات لمكوّنات /system في سياسة المورّد، قد لا يكون من الممكن إجراء تحديث عبر اتصال لاسلكي (OTA) لإطار العمل فقط.

المورّد (/vendor)

تضع سياسة AOSP SELinux تصنيفات على أجزاء من قسم vendor التي تتفاعل معها المنصة، ما يتيح كتابة قواعد SELinux لعمليات المنصة كي تتمكّن من التفاعل مع أجزاء من قسم vendor أو الوصول إليها. أمثلة:

/vendor path	التصنيف المقدَّم من المنصة	عمليات المنصة حسب التصنيف
`/vendor(/.*)?`	`vendor_file`	جميع عملاء HAL في إطار العمل، `ueventd`، وما إلى ذلك
`/vendor/framework(/.*)?`	`vendor_framework_file`	‫`dex2oat` و`appdomain` وما إلى ذلك
`/vendor/app(/.*)?`	`vendor_app_file`	`dex2oat`، `installd`، `idmap`، إلخ
`/vendor/overlay(/.*)`	`vendor_overlay_file`	`system_server`، `zygote`، `idmap`، إلخ

نتيجةً لذلك، يجب اتّباع قواعد محدّدة (يتم فرضها من خلال neverallows) عند تصنيف ملفات إضافية في القسم vendor:

يجب أن يكون vendor_file هو التصنيف التلقائي لجميع الملفات في القسم vendor. تتطلّب سياسة النظام الأساسي توفُّر ذلك للوصول إلى عمليات تنفيذ HAL الخاصة بميزة "نقل الصوت".
يجب أن تتضمّن جميع سمات exec_types الجديدة التي تمت إضافتها في القسم vendor من خلال سياسة المورّد السمة vendor_file_type. ويتم فرض ذلك من خلال neverallows.
لتجنُّب حدوث تعارضات مع تحديثات المنصة/إطار العمل المستقبلية، تجنَّب تصنيف الملفات الأخرى غير exec_types في القسم vendor.
يجب تصنيف جميع تبعيات المكتبة الخاصة بطبقات HAL التي تم تحديدها على أنّها عمليات متطابقة في AOSP على أنّها same_process_hal_file.

Procfs (/proc)

يمكن تصنيف الملفات في /proc باستخدام التصنيف genfscon فقط. في نظام التشغيل Android 7.0، استخدمت كل من سياسة النظام الأساسي وسياسة المورّد الرمز genfscon لتصنيف الملفات في procfs.

اقتراح: تصنيفات سياسات المنصات فقط /proc. إذا كانت عمليات المورّد تتطلّب الوصول إلى ملفات في /proc مصنّفة حاليًا بالتصنيف التلقائي (proc)، يجب ألا تصنّف سياسة المورّد هذه الملفات بشكل صريح، بل يجب أن تستخدم النوع العام proc لإضافة قواعد لنطاقات المورّد. يتيح ذلك تعديل منصة التحديثات لتتوافق مع واجهات النواة المستقبلية التي يتم عرضها من خلال procfs وتصنيفها بشكل صريح حسب الحاجة.

Debugfs (/sys/kernel/debug)

يمكن تصنيف Debugfs في كل من file_contexts وgenfscon. في الإصدارات من Android 7.0 إلى Android 10، يتم عرض كل من تصنيف النظام الأساسي وتصنيف المورّد debugfs.

في نظام التشغيل Android 11، لا يمكن الوصول إلى debugfs أو ربطه على الأجهزة المخصّصة للإنتاج. على الشركات المصنّعة للأجهزة إزالة debugfs.

Tracefs (/sys/kernel/debug/tracing)

يمكن تصنيف Tracefs في كل من file_contexts وgenfscon. في نظام التشغيل Android 7.0، تظهر تصنيفات المنصة tracefs فقط.

اقتراح: يمكن للمنصة فقط تصنيف tracefs.

Sysfs (/sys)

يمكن تصنيف الملفات في /sys باستخدام كل من file_contexts وgenfscon. في نظام التشغيل Android 7.0، تستخدم كل من المنصة والمورّد genfscon لتصنيف الملفات في sysfs.

الاقتراح: قد تصنّف المنصة عقد sysfs غير مخصّصة لجهاز معيّن. وفي ما عدا ذلك، يمكن للمورّد فقط تصنيف الملفات.

tmpfs (/dev)

قد يتم تصنيف الملفات في /dev ضمن file_contexts. في نظام التشغيل Android 7.0، يتم تخزين ملفات تصنيف المنصة والمورّد هنا.

اقتراح: يمكن للمورّد تصنيف الملفات بتنسيق /dev/vendor فقط (مثل /dev/vendor/foo و/dev/vendor/socket/bar).

Rootfs (/)

قد يتم تصنيف الملفات في / ضمن file_contexts. في نظام التشغيل Android 7.0، يتوفّر كل من ملفات تصنيف النظام الأساسي والمورّد هنا.

اقتراح: يمكن للنظام فقط تصنيف الملفات في /.

البيانات (/data)

يتم تصنيف البيانات من خلال مزيج من file_contexts وseapp_contexts.

اقتراح: عدم السماح للبائعين بإضافة تصنيفات خارج /data/vendor. يمكن للمنصة فقط تصنيف الأجزاء الأخرى من /data.

إصدار تصنيفات Genfs

اعتبارًا من مستوى واجهة برمجة التطبيقات الخاصة بالمورّد 202504، ستصبح تصنيفات SELinux الأحدث التي تم تعيينها باستخدام genfscon في system/sepolicy/compat/plat_sepolicy_genfs_ver.cil اختيارية لأقسام vendor الأقدم. ويسمح ذلك للأقسام القديمة vendor بالاحتفاظ بتنفيذ SEPolicy الحالي. يتم التحكّم في ذلك من خلال المتغير BOARD_GENFS_LABELS_VERSION في ملف Makefile، المخزَّن في /vendor/etc/selinux/genfs_labels_version.txt.

مثال:

في مستوى واجهة برمجة التطبيقات للمورّد 202404، يتم تصنيف العُقدة /sys/class/udc على أنّها sysfs تلقائيًا.
اعتبارًا من مستوى واجهة برمجة التطبيقات الخاصة بالمورّد 202504، سيتم تصنيف /sys/class/udc على أنّه sysfs_udc.

ومع ذلك، قد يتم استخدام /sys/class/udc من خلال أقسام vendor تستخدِم مستوى واجهة برمجة التطبيقات 202404، إما مع التصنيف التلقائي sysfs أو تصنيف خاص بمورّد معيّن. قد يؤدي تصنيف /sys/class/udc على أنّه sysfs_udc بشكل غير مشروط إلى حدوث مشاكل في التوافق مع أقسام vendor هذه. من خلال وضع علامة في المربّع BOARD_GENFS_LABELS_VERSION، تواصل المنصة استخدام التصنيفات والأذونات السابقة لأقسام vendor القديمة.

يمكن أن يكون BOARD_GENFS_LABELS_VERSION أكبر من أو يساوي مستوى واجهة برمجة التطبيقات الخاصة بالمورّد. على سبيل المثال، يمكن لأقسام vendor التي تستخدم المستوى 202404 من واجهة برمجة التطبيقات ضبط BOARD_GENFS_LABELS_VERSION على 202504 لاستخدام التصنيفات الجديدة التي تم طرحها في 202504. اطّلِع على قائمة تصنيفات genfs الخاصة بـ 202504.

عند تصنيف عقد genfscon، يجب أن تأخذ المنصة في الاعتبار الأقسام القديمة vendor وتنفّذ آليات احتياطية لتحقيق التوافق عند الحاجة. يمكن للمنصة استخدام مكتبات خاصة بالمنصة فقط للاستعلام عن إصدار تصنيفات genfs.

في الإعلانات المدمجة مع المحتوى، استخدِم libgenfslabelsversion. يمكنك الاطّلاع على genfslabelsversion.h لمعرفة ملف العنوان الخاص بـ libgenfslabelsversion.
في Java، استخدِم android.os.SELinux.getGenfsLabelsVersion().

السياسة العامة على مستوى المنصة

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

على سبيل المثال، يتم تحديد النوع vendor_init، الذي يمثّل عملية init في سياق المورّد، ضمن system/sepolicy/public/vendor_init.te:

type vendor_init, domain;

يمكن للمورّدين الرجوع إلى النوع vendor_init لكتابة قواعد سياسة مخصّصة:

# Allow vendor_init to set vendor_audio_prop in vendor's init scripts
set_prop(vendor_init, vendor_audio_prop)

سمات التوافق

سياسة SELinux هي تفاعل بين أنواع المصدر والهدف لفئات وأذونات كائنات معيّنة. يمكن أن يكون لكل عنصر (مثل العمليات والملفات) متأثر بسياسة SELinux نوع واحد فقط، ولكن قد يتضمّن هذا النوع سمات متعددة.

تتم كتابة السياسة في الغالب من حيث الأنواع الحالية. في ما يلي، يمثّل كل من vendor_init وdebugfs نوعًا:

allow vendor_init debugfs:dir { mounton };

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

/sys(/.*)? u:object_r:sysfs:s0

تمنح سياسة المورّد إذن الوصول إلى /sys/usb، والمصنّفة على النحو التالي: sysfs:

allow vendor_init sysfs:chr_file rw_file_perms;

إذا تم تغيير سياسة المنصة إلى تصنيف /sys/usb على أنّه sysfs_usb، ستبقى سياسة المورّد كما هي، ولكن سيتم حظر وصول vendor_init إلى /sys/usb بسبب عدم توفّر سياسة لنوع sysfs_usb الجديد:

/sys/usb u:object_r:sysfs_usb:s0

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

على سبيل المثال، لنفترض أنّ /sys/usb مصنّف على أنّه sysfs في سياسة المنصة 202504، وأنّ سياسة المورّد 202504 تمنح vendor_init إذن الوصول إلى /sys/usb. وفي هذه الحالة:

تكتب سياسة المورّد قاعدة allow vendor_init sysfs:chr_file rw_file_perms;، لأنّ /sys/usb مصنّف على أنّه sysfs في سياسة المنصّة 202504. عندما يجمع نظام الإنشاء سياسة المورّد، يترجم القاعدة تلقائيًا إلى allow vendor_init_202504 sysfs_202504:chr_file rw_file_perms;. تتوافق السمتان vendor_init_202504 وsysfs_202504 مع النوعين vendor_init وsysfs، وهما النوعان اللذان يحددهما النظام الأساسي.
ينشئ نظام الإنشاء ملف ربط بتنسيق CSV لتحديد الهوية /system/etc/selinux/mapping/202504.cil. بما أنّ كلتا القسمَين system وvendor تستخدمان الإصدار 202504 نفسه، يحتوي ملف الربط على عمليات ربط الهوية من type_202504 إلى type. على سبيل المثال، يتم ربط vendor_init_202504 بـ vendor_init، ويتم ربط sysfs_202504 بـ sysfs:
```
(typeattributeset sysfs_202504 (sysfs))
(typeattributeset vendor_init_202504 (vendor_init))
...
```

عندما يتم تغيير الإصدار من 202504 إلى 202604، يتم إنشاء ملف ربط جديد لأقسام 202504 vendor ضمن system/sepolicy/private/compat/202504/202504.cil، ويتم تثبيته في /system/etc/selinux/mapping/202504.cil لأقسام 202604 أو الأحدث system. في البداية، يحتوي ملف الربط هذا على عمليات ربط المعرّفات، كما هو موضّح سابقًا. في حال تمت إضافة تصنيف جديد sysfs_usb لـ /sys/usb إلى سياسة المنصة 202604، سيتم تعديل ملف الربط لربط sysfs_202504 بـ sysfs_usb:

(typeattributeset sysfs_202504 (sysfs sysfs_usb))
(typeattributeset vendor_init_202504 (vendor_init))
...

يتيح هذا التعديل لقاعدة سياسة المورّد المحوَّلة allow vendor_init_202504 sysfs_202504:chr_file rw_file_perms; منح vendor_init إذن الوصول تلقائيًا إلى النوع الجديد sysfs_usb.

للحفاظ على التوافق مع أقسام vendor القديمة، يجب ربط أي نوع عام جديد يتم إضافته بسمة واحدة على الأقل من السمات التي تتضمّن رقم الإصدار في ملف الربط system/sepolicy/private/compat/ver/ver.cil، أو إدراجه ضمن system/sepolicy/private/compat/ver/ver.ignore.cil لتوضيح أنّه لا يوجد نوع مطابق في إصدارات المورّد السابقة.

تتيح مجموعة سياسات النظام الأساسي وسياسات المورّد وملف التعيين للنظام إجراء التحديث بدون تعديل سياسات المورّد. بالإضافة إلى ذلك، يتم التحويل إلى السمات التي تتضمّن أرقام إصدارات تلقائيًا، لذا لا تحتاج سياسة المورّد إلى الاهتمام بتحديد الإصدارات، بل يمكنها مواصلة استخدام الأنواع العامة كما هي.

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

سياسة system_ext العامة وسياسة المنتجات العامة

بدءًا من Android 11، يُسمح للقسمَين system_ext وproduct بتصدير الأنواع العامة المحدّدة إلى القسم vendor. وكما هو الحال مع السياسة العامة للمنصة، تستخدم سياسة المورّد أنواعًا وقواعد يتم ترجمتها تلقائيًا إلى السمات التي تتضمّن أرقام الإصدارات، مثلاً من type إلى type_ver، حيث ver هو مستوى واجهة برمجة التطبيقات للمورّد في قسم vendor.

عندما يستند كل من القسمين system_ext وproduct إلى إصدار النظام الأساسي نفسه ver، ينشئ نظام الإنشاء ملفات ربط أساسية لكل من system_ext/etc/selinux/mapping/ver.cil وproduct/etc/selinux/mapping/ver.cil، والتي تحتوي على عمليات ربط تعريفية من type إلى type_ver. يمكن أن تصل سياسة المورّد إلى type باستخدام السمة التي تتضمّن رقم الإصدار type_ver.

في حال تعديل القسمَين system_ext وproduct فقط، مثلاً من ver إلى ver+1 (أو إصدار أحدث)، مع بقاء القسم vendor على الإصدار ver، قد تفقد سياسة المورّد إذن الوصول إلى أنواع القسمَين system_ext وproduct. لمنع حدوث أي مشاكل، يجب أن يوفّر القسمان system_ext وproduct ملفات ربط من الأنواع المحدّدة إلى سمات type_ver. يكون كل شريك مسؤولاً عن صيانة ملفات الربط، إذا كان يتيح قسم ver vendor مع أقسام ver+1 (أو إصدار أحدث) وsystem_ext وproduct.

لتثبيت ملفات الربط في القسمَين system_ext وproduct، يُتوقّع من مطوّري الأجهزة أو المورّدين إجراء ما يلي:

انسخ ملفات ربط قاعدة البيانات التي تم إنشاؤها من الأقسام ver وsystem_ext وproduct إلى شجرة المصدر .
عدِّل ملفات التعيين حسب الحاجة.
ثبِّت ملفات الربط في الأقسام ver+1 (أو إصدار أحدث) system_ext وproduct.

على سبيل المثال، لنفترض أنّ القسم 202504 system_ext يحتوي على نوع عام واحد باسم foo_type. بعد ذلك، system_ext/etc/selinux/mapping/202504.cil يبدو القسم system_ext 202504 على النحو التالي:

(typeattributeset foo_type_202504 (foo_type))
(expandtypeattribute foo_type_202504 true)
(typeattribute foo_type_202504)

إذا تمت إضافة bar_type إلى القسم system_ext الذي يحمل الاسم 202604، وإذا كان من المفترض ربط bar_type بـ foo_type للقسم vendor الذي يحمل الاسم 202504، يمكن تعديل 202504.cil من (typeattributeset foo_type_202504 (foo_type)) إلى (typeattributeset foo_type_202504 (foo_type bar_type))، ثم تثبيته في القسم system_ext الذي يحمل الاسم 202604. يمكن أن يستمر قسم 202504 vendor في الوصول إلى foo_type وbar_type في قسم 202604 system_ext.

تغييرات السمات في Android 9

يمكن للأجهزة التي يتم ترقيتها إلى Android 9 استخدام السمات التالية، ولكن لا يجب أن تستخدمها الأجهزة التي يتم تشغيلها لأول مرة بنظام Android 9.

سمات المخالف

يتضمّن نظام التشغيل Android 9 السمات التالية ذات الصلة بالنطاق:

data_between_core_and_vendor_violators. تمثّل هذه السمة جميع النطاقات التي تخالف شرط عدم مشاركة الملفات حسب المسار بين vendor وcoredomains. يجب ألا تستخدم عمليات المنصّة والمورّد ملفات على القرص للتواصل (واجهة ثنائية غير ثابتة لتطبيق البرامج). التوصية:
- يجب أن يستخدم رمز المورّد /data/vendor.
- يجب ألا يستخدم النظام /data/vendor.
استبدِل system_executes_vendor_violators. بالسمة لجميع نطاقات النظام (باستثناء init وshell domains) التي تخالف شرط عدم تنفيذ ملفات ثنائية خاصة بمورّدين. تنفيذ ملفات ثنائية خاصة بمورّدين تتضمّن واجهة برمجة تطبيقات غير ثابتة يجب ألا تنفّذ المنصة ملفات ثنائية خاصة بالمورّد مباشرةً. التوصية:
- يجب أن تكون عمليات الربط بين المنصات وثنائيات المورّدين البرمجية معتمدة على طبقات تجريد الأجهزة (HAL) المستندة إلى لغة تعريف واجهة HIDL.
  أو
- يجب نقل coredomains التي تحتاج إلى الوصول إلى ملفات ثنائية خاصة بالمورّد إلى قسم vendor، وبالتالي التوقف عن كونها coredomain.

السمات غير الموثوق بها

يجب ألا تتمكّن التطبيقات غير الموثوق بها التي تستضيف رموزًا برمجية عشوائية من الوصول إلى خدمات HwBinder، باستثناء الخدمات التي تُعتبر آمنة بدرجة كافية للوصول إليها من هذه التطبيقات (راجِع الخدمات الآمنة أدناه). في ما يلي السببان الرئيسيان لذلك:

لا تنفّذ خوادم HwBinder مصادقة العميل لأنّ HIDL لا تعرض حاليًا معلومات UID الخاصة بالمتصل. وحتى إذا كان HIDL يعرض مثل هذه البيانات، فإنّ العديد من خدمات HwBinder إما تعمل على مستوى أقل من مستوى التطبيقات (مثل طبقات تجريد الأجهزة) أو يجب ألا تعتمد على هوية التطبيق في عملية التفويض. وبالتالي، ولتجنُّب أي مشاكل، يتم تلقائيًا افتراض أنّ كل خدمة HwBinder تعامل جميع عملائها على أنّهم مخوّلون بالتساوي لإجراء العمليات التي تقدّمها الخدمة.
تحتوي خوادم HAL (مجموعة فرعية من خدمات HwBinder) على رمز يتضمّن معدل حدوث أعلى للمشاكل الأمنية مقارنةً بمكوّنات system/core، كما يمكنها الوصول إلى الطبقات السفلية من الحزمة (وصولاً إلى الأجهزة)، ما يزيد من فرص تجاوز نموذج أمان Android.

الخدمات الآمنة

تشمل الخدمات الآمنة ما يلي:

same_process_hwservice. تعمل هذه الخدمات (بحكم تعريفها) في عملية العميل، وبالتالي يكون لها إذن الوصول نفسه إلى نطاق العميل الذي تعمل فيه العملية.
coredomain_hwservice. لا تشكّل هذه الخدمات أي مخاطر مرتبطة بالسبب رقم 2.
hal_configstore_ISurfaceFlingerConfigs، وهي خدمة مصمّمة خصيصًا ليستخدمها أي نطاق.
hal_graphics_allocator_hwservice. تقدّم خدمة surfaceflinger Binder هذه العمليات أيضًا، ويُسمح للتطبيقات بالوصول إليها.
‫hal_omx_hwservice: هذا هو إصدار HwBinder من خدمة mediacodec Binder التي يُسمح للتطبيقات بالوصول إليها.
‫hal_codec2_hwservice: هذا إصدار أحدث من hal_omx_hwservice.

السمات القابلة للاستخدام

تحتوي جميع hwservices التي لا تُعتبر آمنة على السمة untrusted_app_visible_hwservice. تحتوي خوادم HAL المقابلة على السمة untrusted_app_visible_halserver. يجب ألا تستخدم الأجهزة التي تعمل بالإصدار 9 من نظام التشغيل Android السمة untrusted.

اقتراح:

بدلاً من ذلك، يجب أن تتواصل التطبيقات غير الموثوق بها مع خدمة تابعة لنظام التشغيل تتواصل مع طبقة HAL الخاصة بمورّد HIDL. على سبيل المثال، يمكن للتطبيقات التحدّث إلى binderservicedomain، ثم يتحدّث mediaserver (وهو binderservicedomain) بدوره إلى hal_graphics_allocator.
أو
يجب أن تتضمّن التطبيقات التي تحتاج إلى الوصول المباشر إلى vendor HALs نطاق sepolicy خاصًا بها محدّدًا من قِبل المورّد.

اختبارات سمات الملفات

يتضمّن نظام التشغيل Android 9 اختبارات وقت الإنشاء تضمن احتواء جميع الملفات في مواقع جغرافية معيّنة على السمات المناسبة (مثل احتواء جميع الملفات في sysfs على السمة sysfs_type المطلوبة).

تصنيف سياقات SELinux

لدعم التمييز بين سياسة SELinux الخاصة بالمنصة وسياسة SELinux الخاصة بالمورّد، ينشئ النظام ملفات سياق SELinux بشكل مختلف لإبقائها منفصلة.

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

قدّم نظام التشغيل Android 8.0 التغييرات التالية على file_contexts:

لتجنُّب زيادة الحمل الزائد للتجميع على الجهاز أثناء التشغيل، يجب ألا يكون file_contexts موجودًا في شكل ثنائي. بدلاً من ذلك، يمكن قراءتها، وهي عبارة عن ملف نصي بتعبير عادي مثل {property, service}_contexts (كما كانت قبل الإصدار 7.0).
يتم تقسيم file_contexts بين ملفَين:
- plat_file_contexts
  - نظام التشغيل Android file_context الذي لا يحتوي على تصنيفات خاصة بالجهاز، باستثناء تصنيف أجزاء من قسم /vendor الذي يجب تصنيفه بدقة لضمان عمل ملفات sepolicy بشكل سليم
  - يجب أن يكون في القسم system في /system/etc/selinux/plat_file_contexts على الجهاز وأن يتم تحميله بواسطة init في البداية مع file_context المورّد.
- vendor_file_contexts
  - file_context الخاص بالجهاز، والذي يتم إنشاؤه من خلال الجمع بين file_contexts الموجود في الأدلة التي يشير إليها BOARD_SEPOLICY_DIRS في ملفات Boardconfig.mk الخاصة بالجهاز.
  - يجب تثبيته في /vendor/etc/selinux/vendor_file_contexts في القسم vendor وتحميله بواسطة init عند البدء مع file_context النظام الأساسي.

سياقات المواقع

في نظام التشغيل Android 8.0، يتم تقسيم property_contexts بين ملفين:

plat_property_contexts
- نظام التشغيل Android property_context الذي لا يتضمّن تصنيفات خاصة بالجهاز
- يجب أن يكون في القسم system في /system/etc/selinux/plat_property_contexts وأن يتم تحميله بواسطة init في البداية مع property_contexts.
vendor_property_contexts
- يتم إنشاء property_context الخاص بالجهاز من خلال الجمع بين property_contexts الموجود في الأدلة التي يشير إليها BOARD_SEPOLICY_DIRS في ملفات Boardconfig.mk الجهاز.
- يجب أن يكون في القسم vendor في /vendor/etc/selinux/vendor_property_contexts وأن يتم تحميله بواسطة init في البداية مع property_context

سياقات الخدمة

في نظام التشغيل Android 8.0، يتم تقسيم service_contexts بين الملفات التالية:

plat_service_contexts
- service_context المخصّص لنظام Android الأساسي servicemanager لا يحتوي service_context على تصنيفات خاصة بالجهاز.
- يجب أن يكون في القسم system في /system/etc/selinux/plat_service_contexts وأن يتم تحميله بواسطة servicemanager في البداية مع service_contexts.
vendor_service_contexts
- service_context الخاص بالجهاز، والذي يتم إنشاؤه من خلال الجمع بين service_contexts الموجود في الأدلة التي يشير إليها BOARD_SEPOLICY_DIRS في ملفات Boardconfig.mk الجهاز.
- يجب أن يكون في القسم vendor في /vendor/etc/selinux/vendor_service_contexts وأن يتم تحميله بواسطة servicemanager في البداية مع service_contexts.
- على الرغم من أنّ servicemanager يبحث عن هذا الملف عند بدء التشغيل، يجب ألا يكون الملف vendor_service_contexts متوفّرًا في جهاز TREBLE متوافق تمامًا. ويرجع ذلك إلى أنّ جميع التفاعلات بين العمليتَين vendor وsystem يجب أن تمر عبر hwservicemanager/hwbinder.
plat_hwservice_contexts
- نظام التشغيل Android hwservice_context الذي hwservicemanager لا يحتوي على تصنيفات خاصة بالجهاز.
- يجب أن يكون في القسم system في /system/etc/selinux/plat_hwservice_contexts وأن يتم تحميله بواسطة hwservicemanager في البداية مع vendor_hwservice_contexts.
vendor_hwservice_contexts
- hwservice_context الخاص بالجهاز، والذي يتم إنشاؤه من خلال الجمع بين hwservice_contexts الموجود في الأدلة التي يشير إليها BOARD_SEPOLICY_DIRS في ملفات Boardconfig.mk الجهاز.
- يجب أن يكون في القسم vendor في /vendor/etc/selinux/vendor_hwservice_contexts وأن يتم تحميله بواسطة hwservicemanager في البداية مع plat_service_contexts.
vndservice_contexts
- service_context الخاصة بالجهاز vndservicemanager التي تم إنشاؤها من خلال الجمع بين vndservice_contexts الموجودة في الأدلة التي تشير إليها BOARD_SEPOLICY_DIRS في Boardconfig.mk.
- يجب أن يكون هذا الملف في القسم vendor في /vendor/etc/selinux/vndservice_contexts وأن يتم تحميله بواسطة vndservicemanager في البداية.

سياقات Seapp

في نظام التشغيل Android 8.0، يتم تقسيم seapp_contexts بين ملفين:

plat_seapp_contexts
- نظام التشغيل Android seapp_context الذي لم يتم إجراء أي تغييرات خاصة بالجهاز عليه.
- يجب أن يكون مقيمًا في القسم system في /system/etc/selinux/plat_seapp_contexts.
vendor_seapp_contexts
- إضافة خاصة بالجهاز إلى النظام الأساسي seapp_context تم إنشاؤها من خلال الجمع بين seapp_contexts الموجودة في الدلائل التي يشير إليها BOARD_SEPOLICY_DIRS في ملفات Boardconfig.mk الخاصة بالجهاز.
- يجب أن تكون مقيمًا في القسم vendor في /vendor/etc/selinux/vendor_seapp_contexts.

أذونات MAC

في نظام التشغيل Android 8.0، يتم تقسيم mac_permissions.xml بين ملفين:

النظام الأساسي mac_permissions.xml
- نظام التشغيل Android mac_permissions.xml الذي لم يتم إجراء أي تغييرات خاصة بالجهاز عليه
- يجب أن يكون مقيمًا في القسم system في /system/etc/selinux/.
غير تابع للمنصة mac_permissions.xml
- إضافة خاصة بالجهاز إلى النظام الأساسي mac_permissions.xml تم إنشاؤها من mac_permissions.xml تم العثور عليها في الدلائل التي يشير إليها BOARD_SEPOLICY_DIRS في ملفات Boardconfig.mk الجهاز.
- يجب أن يكون مقيمًا في القسم vendor في /vendor/etc/selinux/.