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

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

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

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

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

يجب تحديد الملكية بوضوح لكل عنصر للحفاظ على فصل سياسات المنصة والمورّد. على سبيل المثال، إذا كانت تصنيفات سياسة المورّد /dev/foo وتصنيفات سياسة المنصة /dev/foo في تحديث لاحق عبر الأثير (OTA)، سيحدث سلوك غير محدّد، مثل رفض غير متوقّع، أو بشكل أكثر خطورة، تعذُّر بدء التشغيل. بالنسبة إلى 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 إلى القسم 202604 system_ext، وإذا كان من المفترض ربط bar_type بـ foo_type للقسم 202504 vendor، يمكن تعديل 202504.cil من (typeattributeset foo_type_202504 (foo_type)) إلى (typeattributeset foo_type_202504 (foo_type bar_type))، ثم تثبيته في القسم 202604 system_ext. يمكن أن يستمر قسم 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. يجب ألا تستخدم الأجهزة التي تعمل بنظام التشغيل Android 9 السمة 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/.