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

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

تخصيص SELinux
تنظيم صفحاتك في مجموعات يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.

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

يجب ألا تزيل الشركات المصنّعة سياسة SELinux الحالية. وبخلاف ذلك، فإنّه يمكن أن يؤدي ذلك إلى إيقاف تنفيذ أمان نظام التشغيل Linux (SELinux) في Android والتطبيقات التي يحكمها. ويشمل ذلك التطبيقات التابعة لجهات خارجية التي يُحتمَل أن تحتاج إلى تحسين لتصبح متوافقة وقابلة للتشغيل. يجب ألا تتطلّب التطبيقات تعديلاً لمواصلة عملها على الأجهزة التي تم تفعيل SELinux عليها.

عند بدء تخصيص SELinux، تذكَّر ما يلي:

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

ويجب عدم إجراء ما يلي:

إنشاء سياسة غير متوافقة
السماح بتخصيص سياسة المستخدم النهائي
السماح بتخصيصات سياسة إدارة جهاز الجوّال
تخويف المستخدمين من خلال إبلاغهم بانتهاكات السياسة
إضافة أبواب خلفية

راجِع قسم ميزات أمان النواة في مستند تحديد التوافق مع Android لمعرفة المتطلبات المحدّدة.

يستخدم SELinux أسلوب القائمة البيضاء، ما يعني أنّه يجب السماح بجميع عمليات الوصول بشكلٍ صريح في السياسة من أجل منحها. بما أنّ سياسة SELinux الافتراضية في Android تتوافق مع "المشروع مفتوح المصدر لنظام Android"، ليس عليك تعديل إعدادات SELinux بأي شكل من الأشكال. في حال تخصيص إعدادات SELinux، يجب الانتباه جيدًا إلى عدم إيقاف التطبيقات الحالية. للبدء:

استخدام أحدث ملف برمجي لنظام التشغيل Android
اتّبِع مبدأ الحد الأدنى من الأذونات المميّزة.
يجب عدم الإشارة إلا إلى الإضافات التي أجريتها بنفسك على Android. تعمل السياسة التلقائية مع رمز المصدر في مشروع Android Open Source تلقائيًا.
تقسيم مكونات البرنامج إلى وحدات تُنفِّذ مهام فردية
أنشئ سياسات SELinux التي تعزل هذه المهام عن الدوال غير ذات الصلة.
ضَع هذه السياسات في ملفات *.te (إضافة لملفات مصدر سياسة SELinux) ضمن الدليل /device/manufacturer/device-name/sepolicy واستخدِم متغيّرات BOARD_SEPOLICY لتضمينها في عملية الإنشاء.
اجعل النطاقات الجديدة مسموحًا بها في البداية. ويتم ذلك باستخدام بيان إذن في ملف .te الخاص بالنطاق.
تحليل النتائج وتحسين تعريفات النطاقات
أزِل البيان المسموح به عندما لا تظهر أي عمليات رفض أخرى في عمليات الإنشاء التي تستخدم علامة userdebug

بعد دمج تغيير سياسة SELinux، أضِف خطوة إلى سير عمل التطوير لضمان توافق SELinux من الآن فصاعدًا. في عملية تطوير البرامج المثالية، لا تتغيّر سياسة SELinux إلا عند تغيّر نموذج البرنامج وليس التنفيذ الفعلي.

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

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

أمثلة على عبارات السياسات

يستند SELinux إلى لغة الكمبيوتر M4 ، وبالتالي يتوافق مع مجموعة متنوعة من وحدات الماكرو لتوفير الوقت.

في المثال التالي، يتم منح جميع النطاقات إذن الوصول للقراءة من /dev/null أو الكتابة إليها والقراءة من /dev/zero.

# Allow read / write access to /dev/null
allow domain null_device:chr_file { getattr open read ioctl lock append write};

# Allow read-only access to /dev/zero
allow domain zero_device:chr_file { getattr open read ioctl lock };

يمكن كتابة هذا البيان نفسه باستخدام *_file_perms ماكروات SELinux (الاختصار):

# Allow read / write access to /dev/null
allow domain null_device:chr_file rw_file_perms;

# Allow read-only access to /dev/zero
allow domain zero_device:chr_file r_file_perms;

مثال على السياسة

في ما يلي مثال كامل على سياسة بروتوكول إدارة حزم البيانات (DHCP)، وسنفحصها أدناه:

type dhcp, domain;
permissive dhcp;
type dhcp_exec, exec_type, file_type;
type dhcp_data_file, file_type, data_file_type;

init_daemon_domain(dhcp)
net_domain(dhcp)

allow dhcp self:capability { setgid setuid net_admin net_raw net_bind_service
};
allow dhcp self:packet_socket create_socket_perms;
allow dhcp self:netlink_route_socket { create_socket_perms nlmsg_write };
allow dhcp shell_exec:file rx_file_perms;
allow dhcp system_file:file rx_file_perms;
# For /proc/sys/net/ipv4/conf/*/promote_secondaries
allow dhcp proc_net:file write;
allow dhcp system_prop:property_service set ;
unix_socket_connect(dhcp, property, init)

type_transition dhcp system_data_file:{ dir file } dhcp_data_file;
allow dhcp dhcp_data_file:dir create_dir_perms;
allow dhcp dhcp_data_file:file create_file_perms;

allow dhcp netd:fd use;
allow dhcp netd:fifo_file rw_file_perms;
allow dhcp netd:{ dgram_socket_class_set unix_stream_socket } { read write };
allow dhcp netd:{ netlink_kobject_uevent_socket netlink_route_socket
netlink_nflog_socket } { read write };

لنحلِّل المثال:

في السطر الأول، بيان النوع، يكتسب الخادم الدائم لبروتوكول DHCP الإعدادات من سياسة الأمان الأساسية (domain). من المثالين السابقين لعبارة الإعداد، يمكن لبروتوكول DHCP القراءة من /dev/null والكتابة إليها.

في السطر الثاني، يتم تحديد بروتوكول DHCP على أنّه نطاق مسموح به.

في سطر init_daemon_domain(dhcp)، تنص السياسة على أنّه تم إنشاء بروتوكول DHCP من init ويُسمح له بالتواصل معه.

في سطر net_domain(dhcp)، تسمح السياسة لخدمة DHCP باستخدام وظائف الشبكة الشائعة من نطاق net، مثل قراءة حِزم بروتوكول TCP وكتابتها والتواصل عبر مآخذ التوصيل وتنفيذ requests لنظام أسماء النطاقات.

في السطر allow dhcp proc_net:file write;، تنص السياسة على أنّه يمكن لبروتوكول DHCP الكتابة في ملفات معيّنة في /proc. يوضّح هذا السطر تصنيف الملفات الدقيق في SELinux. ويستخدم التصنيف proc_net لحصر إذن الوصول للكتابة بالملفات ضمن /proc/sys/net فقط.

يوضّح الجزء الأخير من المثال الذي يبدأ برمز allow dhcp netd:fd use; كيفية السماح للتطبيقات بالتفاعل مع بعضها. تنص السياسة على أنّه يمكن لبروتوكول DHCP وnetd التواصل معًا من خلال أوصاف الملفات وملفات FIFO وفتحات البيانات وفتحات تدفق UNIX. لا يمكن لبروتوكول DHCP قراءة البيانات من وإلى مآخذ بيانات البث ومآخذ UNIX stream فقط، ولا يمكنه إنشاء هذه المآخذ أو فتحها.

عناصر التحكّم المتاحة

الفئة	الإذن
ملف	ioctl read write create getattr setattr lock relabelfrom relabelto append unlink link rename execute swapon quotaon mounton
دليل	add_name remove_name reparent search rmdir open audit_access execmod
مقبس	ioctl read write create getattr setattr lock relabelfrom relabelto append bind connect listen accept getopt setopt shutdown recvfrom sendto recv_msg send_msg name_bind
نظام الملفات	mount remount unmount getattr relabelfrom relabelto transition associate quotamod quotaget
عملية	fork transition sigchld sigkill sigstop signull signal ptrace getsched setsched getsession getpgid setpgid getcap setcap share getattr setexec setfscreate noatsecure siginh setrlimit rlimitinh dyntransition setcurrent execmem execstack execheap setkeycreate setsockcreate
الضمان	compute_av compute_create compute_member check_context load_policy compute_relabel compute_user setenforce setbool setsecparam setcheckreqprot read_policy
الإمكانية	chown dac_override dac_read_search fowner fsetid kill setgid setuid setpcap linux_immutable net_bind_service net_broadcast net_admin net_raw ipc_lock ipc_owner sys_module sys_rawio sys_chroot sys_ptrace sys_pacct sys_admin sys_boot sys_nice sys_resource sys_time sys_tty_config mknod lease audit_write audit_control setfcap
توسيع	والمزيد

قواعد neverallow

تحظر قواعد neverallow SELinux السلوك الذي لا يجب أن يحدث أبدًا. من خلال اختبار التوافق، يتم الآن فرض قواعد neverallowSELinux على جميع الأجهزة.

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

القاعدة 48: neverallow { domain -debuggerd -vold -dumpstate -system_server } self:capability sys_ptrace;
اطّلِع على صفحة man الخاصة بـ ptrace. تمنح sys_ptrace القدرة على ptrace أي عملية، ما يتيح قدرًا كبيرًا من التحكّم في العمليات الأخرى، ويجب أن تنتمي فقط إلى مكونات النظام المحدّدة والموضّحة في القاعدة. غالبًا ما تشير الحاجة إلى هذه الميزة إلى توفّر عنصر غير مخصّص للإصدارات الموجّهة للمستخدمين أو وظيفة غير مطلوبة. أزِل المكوّن غير الضروري.

القاعدة 76: neverallow { domain -appdomain -dumpstate -shell -system_server -zygote } { file_type -system_file -exec_type }:file execute;
تهدف هذه القاعدة إلى منع تنفيذ رمز عشوائي على النظام. وعلى وجه التحديد، يؤكد هذا الإجراء أنّه لا يتم تنفيذ سوى الرمز البرمجي على /system، ما يضمن الأمان بفضل آليات مثل ميزة "التشغيل المتحقّق منه". غالبًا ما يكون أفضل حلّ عند مواجهة مشكلة في قاعدة neverallow هذه هو نقل الرمز البرمجي المسيء إلى القسم /system.

تخصيص سياسة SEPolicy في الإصدار 8.0 من نظام التشغيل Android والإصدارات الأحدث

يوفّر هذا القسم إرشادات حول سياسة SELinux الخاصة بالمورّدين في الإصدار 8.0 من نظام التشغيل Android والإصدارات الأحدث، بما في ذلك تفاصيل حول سياسة SELinux وملف التمديدات الخاصة بها في "المشروع المفتوح المصدر لنظام Android" ‏ (AOSP). لمزيد من المعلومات عن كيفية الحفاظ على سياسة SELinux متوافقة على مستوى الأقسام وإصدارات Android، يُرجى الاطّلاع على التوافق.

موضع السياسة

في الإصدار 7.0 من Android والإصدارات الأقدم، كان بإمكان الشركات المصنّعة للأجهزة إضافة سياسة إلى BOARD_SEPOLICY_DIRS، بما في ذلك السياسة المخصّصة لتعزيز سياسة AOSP على مستوى أنواع الأجهزة المختلفة. في Android 8.0 والإصدارات الأحدث، تؤدي إضافة سياسة إلى BOARD_SEPOLICY_DIRS إلى وضع السياسة في ملف صورة المورّد فقط.

في الإصدار 8.0 من نظام التشغيل Android والإصدارات الأحدث، تتوفّر السياسة في المواقع التالية في AOSP:

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

في الإصدار 11 من نظام التشغيل Android والإصدارات الأحدث، يمكن أن تتضمّن أيضًا قسمَي system_ext وproduct سياسات خاصة بالقسم. وينقسم قسمَا system_ext وproduct أيضًا إلى سياسات عامة وخاصة، ويمكن للمورّدين استخدام ملفَي system_ext وproduct السياسيَين العامَين، مثل سياسة النظام.

SYSTEM_EXT_PUBLIC_SEPOLICY_DIRS. تتضمّن السياسة التي تم تصديرها للاستخدام في السياسة الخاصة بالمورّد. تم تثبيته على قسم system_ext.
SYSTEM_EXT_PRIVATE_SEPOLICY_DIRS: تتضمّن السياسة اللازمة لتشغيل صورة system_ext، ولكن يجب ألا تكون سياسة صورة المورّد على دراية بها. تم تثبيته على قسم system_ext.
PRODUCT_PUBLIC_SEPOLICY_DIRS. تتضمّن السياسة التي تم تصديرها للاستخدام في السياسة الخاصة بالمورّد. تم تثبيته على قسم المنتج.
PRODUCT_PRIVATE_SEPOLICY_DIRS. تتضمّن السياسة اللازمة ل عمل صورة المنتج، ولكن يجب ألا يكون لدى سياسة صور المورّد أيّ معرفة بها. تم تثبيته على قسم المنتج.

ملاحظة: عند استخدام ميزة GSI، لن يتم تركيب قسمَي system_ext وproduct الخاصَين بجهة التصنيع. تصبح القواعد في سياسة أمان المورّد التي تستخدِم system_ext الخاصة بالمصنّع الأصلي للجهاز وسياسة المنتج العامة NOP لأنّه لا تتوفّر تعريفات الأنواع الخاصة بالمصنّع الأصلي للجهاز.

ملاحظة: يجب توخي الحذر الشديد عند استخدام السياسات العامة لنظام التشغيل وتلك الخاصة بالمنتجات. تعمل السياسات العامة كواجهة برمجة تطبيقات تم تصديرها بين system_ext/product والبائع. من المفترض أن يدير الشركاء مشاكل التوافق بأنفسهم.

سيناريوهات السياسات المتوافقة

على الأجهزة التي تعمل بالإصدار 8.0 من نظام التشغيل Android والإصدارات الأحدث، يجب أن تعمل صورة المورّد مع صورة نظام المصنّع الأصلي للجهاز وصورة نظام AOSP المرجعية التي تقدّمها Google (ويجب أن تجتاز هذه الصورة المرجعية اختبار CTS). تضمن هذه المتطلبات وجود فاصل واضح بين الإطار ورمز المورّد. تتيح هذه الأجهزة السيناريوهات التالية.

إضافات صور المورّد فقط

مثال: إضافة خدمة جديدة إلى vndservicemanager من صورة المورّد التي تتيح العمليات من صورة المورّد

كما هو الحال مع الأجهزة التي تعمل بإصدارات Android سابقة، أضِف ميزة تخصيص خاصة بالجهاز في device/manufacturer/device-name/sepolicy. يجب أن تشمل السياسة الجديدة التي تحكم كيفية تفاعل مكونات المورّد مع مكونات مورّد آخرين (فقط) أنواعًا متوفّرة في device/manufacturer/device-name/sepolicy فقط. تسمح السياسة المكتوبة هنا للرمز البرمجي الخاص بالمورّد بالعمل، ولن يتم تعديله كجزء من تحديث OTA للإطار فقط، وهو متوفّر في السياسة المجمّعة على جهاز مع صورة نظام AOSP المرجعية.

إتاحة استخدام صورة المورّد مع AOSP

مثال: إضافة عملية جديدة (مسجَّلة باستخدام hwservicemanager من صورة المورِّد) تنفِّذ واجهة HAL محدَّدة من AOSP

كما هو الحال مع الأجهزة التي تعمل بإصدارات Android سابقة، يمكنك إجراء التخصيص الخاص بالجهاز في device/manufacturer/device-name/sepolicy. إنّ السياسة التي تم تصديرها كجزء من system/sepolicy/public/ متاحة للاستخدام، ويتم شحنها كجزء من سياسة المورّد. يمكن استخدام الأنواع والسمات من السياسة العامة في قواعد جديدة تحدّد التفاعلات مع ملف التعريف الجديد المخصّص للمورّد، مع مراعاة neverallow القيود المقدّمة. كما هو الحال مع حالة المورّد فقط، لن يتم تعديل السياسة الجديدة هنا كجزء من تحديث OTA للإطار فقط، وستظهر في السياسة المجمّعة على جهاز يتضمّن صورة نظام AOSP المرجعية.

الإضافات المخصّصة لصور النظام فقط

مثال: إضافة خدمة جديدة (مسجَّلة في servicemanager) لا يمكن الوصول إليها إلا من خلال عمليات أخرى من صورة النظام

أضِف هذه السياسة إلى system/sepolicy/private. يمكنك إضافة عمليات أو عناصر إضافية لتفعيل الوظائف في صورة نظام الشريك، شرط أن لا تحتاج هذه الأجزاء الجديدة إلى التفاعل مع المكوّنات الجديدة في صورة المورّد (على وجه التحديد، يجب أن تعمل هذه العمليات أو العناصر بالكامل بدون سياسة من صورة المورّد). تتوفّر السياسة التي تم تصديرها من خلال system/sepolicy/public هنا تمامًا كما هي متوفّرة للإضافات التي تتضمّن صور المورّدين فقط. هذه السياسة هي جزء من صورة النظام ويمكن تعديلها في تحديث OTA للإطار فقط، ولكن لن تكون متوفّرة عند استخدام صورة نظام AOSP المرجعية.

إضافات صور المصنّعين التي توفّر مكوّنات AOSP الموسّعة

مثال: واجهة HAL جديدة غير تابعة لمشروع AOSP لاستخدامها من قِبل العملاء الموسّعِين الذين يتوفرون أيضًا في صورة نظام AOSP (مثل نظام_الخادم الموسّع).

يجب تضمين سياسة التفاعل بين النظام والمورّد في الدليل device/manufacturer/device-name/sepolicy الذي يتم إرساله على قسم المورّد. يشبه ذلك السيناريو أعلاه لإضافة ميزة توافق صورة المورّد للعمل مع صورة AOSP المرجعية، باستثناء أنّ مكونات AOSP المعدَّلة قد تحتاج أيضًا إلى سياسة إضافية للعمل بشكل صحيح مع بقية القسم النظام (وهو أمر جيد ما دامت لا تزال تحمل تصنيفات نوع AOSP العلني ).

يجب أن تكون سياسة التفاعل بين مكوّنات AOSP المتاحة للجميع وامتدادات ملف صورة النظام فقط في system/sepolicy/private.

إضافات صور النظام التي لا تحصل إلا على واجهات AOSP

مثال: يجب أن تصل عملية نظام جديدة غير تابعة لمشروع AOSP إلى HAL الذي يعتمد عليه AOSP.

يشبه ذلك مثال التمديد الذي يعرض صورة النظام فقط، باستثناء أنّ مكونات النظام الجديدة قد تتفاعل مع واجهة system/vendor. يجب أن تكون سياسة مكوّن النظام الجديد في system/sepolicy/private، وهو أمر مقبول شرط أن يتم من خلال واجهة أنشأها AOSP في system/sepolicy/public (أي أن تكون الأنواع والسمات المطلوبة ل الوظيفة متوفّرة). على الرغم من أنّه يمكن تضمين السياسة في سياسة الخاصة بالجهاز، لن يتمكّن التطبيق من استخدام أنواع system/sepolicy/private أخرى أو تغييرها (بأي طريقة تؤثّر في السياسة) نتيجةً لتحديث الإطار فقط. قد يتم تغيير السياسة في تحديث OTA للإطار فقط، ولكن لن تكون متوفرة عند استخدام صورة نظام AOSP (التي لن تتضمّن أيضًا المكوّن الجديد للنظام).

إضافات صور المورّدين التي تعرِض مكونات نظام جديدة

مثال: إضافة HAL جديدة غير تابعة لمشروع AOSP لاستخدامها من خلال عملية العميل بدون نظير AOSP (وبالتالي تتطلّب نطاقًا خاصًا بها).

على غرار مثال "إضافات AOSP"، يجب وضع سياسة التفاعلات بين النظام والمورّد في ملف ‎ device/manufacturer/device-name/sepolicy الذي يتم إرساله في قسم المورّد (لضمان عدم معرفة سياسة النظام بالتفاصيل الخاصة بالمورّد). يمكنك إضافة أنواع عامة جديدة تُوسع نطاق السياسة في system/sepolicy/public، ولكن يجب عدم إجراء ذلك إلا بالإضافة إلى سياسة AOSP الحالية، أي عدم إزالة السياسة العامة لنظام التشغيل AOSP. يمكن بعد ذلك استخدام الأنواع الجديدة للعميل العام في السياسة في system/sepolicy/private وفي device/manufacturer/device-name/sepolicy.

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

سيناريوهات السياسات غير المتوافقة

لا تتيح الأجهزة التي تعمل بالإصدار 8.0 من نظام التشغيل Android والإصدارات الأحدث استخدام المثالين التاليين للسياسات.

إضافات إضافية لصورة النظام تحتاج إلى إذن لمكونات صورة المورّد الجديدة بعد تحديث عبر شبكة غير سلكية للإطار فقط

مثال: تمت إضافة عملية نظام جديدة غير تابعة لمشروع AOSP، وتتطلّب نطاقًا خاصًا بها، في إصدار Android التالي وتحتاج إلى الوصول إلى واجهة برمجة تطبيقات HAL جديدة غير تابعة لمشروع AOSP.

يشبه ذلك تفاعل مكونات النظام والمورّد (غير AOSP) الجديدة، باستثناء أنّ نوع النظام الجديد يتم تقديمه في تحديث عبر شبكة غير سلكية للإطار فقط. على الرغم من إمكانية إضافة النوع الجديد إلى السياسة في system/sepolicy/public، لا تتضمّن سياسة المورّد الحالية معرفة بالنوع الجديد لأنّها تتتبّع السياسة العامة لنظام Android 8.0 فقط. يعالج إطار عمل AOSP هذه المشكلة من خلال عرض الموارد المقدَّمة من المورّد من خلال سمة (مثل سمة hal_foo)، ولكن بما أنّه لا يمكن استخدام الإضافات الخاصة بالشركاء في السمات في system/sepolicy/public، لا تتوفّر هذه الطريقة لتطبيق سياسة المورّد. يجب أن يتم توفير إمكانية الوصول من خلال نوع متاح للجميع كان متوفّرًا في السابق.

مثال: يجب أن يؤدي التغيير في عملية النظام (AOSP أو غير AOSP) إلى تغيير طريقة تفاعلها مع مكوّن المورّد الجديد غير المعتمد على AOSP.

يجب كتابة السياسة في صورة النظام بدون معرفة تعديلات المورّد المحدّدة. وبالتالي، يتم عرض السياسة المتعلّقة بواجهات معيّنة في AOSP من خلال السمات في system/sepolicy/public لكي تتمكّن سياسة المورّد من الموافقة على سياسة النظام المستقبلية التي تستخدِم هذه السمات. ومع ذلك، لا يمكن استخدام الإضافات الخاصة بالسمات في system/sepolicy/public، لذا يجب أن تكون جميع السياسات التي تحدّد كيفية تفاعل مكوّنات النظام مع مكوّنات المورّدين الجديدة (والتي لا تتعامل معها السمات المتوفّرة في AOSP system/sepolicy/public) في device/manufacturer/device-name/sepolicy. وهذا يعني أنّه لا يمكن تغيير أنواع الأنظمة أو الوصول المسموح به لأنواع المورّدين كجزء من عملية OTA للإطار فقط.

تخصيص SELinux تنظيم صفحاتك في مجموعات يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.