تخصيص SELinux

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

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

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

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

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

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

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

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

1. استخدِم أحدث ملف برمجي لنظام التشغيل Android.
2. اتّبِع مبدأ الحد الأدنى من الأذونات المميّزة.
3. يجب عدم الإشارة إلا إلى الإضافات التي أجريتها بنفسك على Android. تعمل السياسة التلقائية مع رمز المصدر في مشروع Android Open Source تلقائيًا.
4. تقسيم مكونات البرنامج إلى وحدات تُنفِّذ مهام فردية
5. أنشئ سياسات SELinux التي تعزل هذه المهام عن الدوال غير ذات الصلة.
6. ضَع هذه السياسات في ملفات *.te (إضافة لملفات مصدر سياسة SELinux) ضمن الدليل /device/manufacturer/device-name/sepolicy واستخدِم متغيّرات BOARD_SEPOLICY لتضمينها في عملية الإنشاء.
7. جعل النطاقات الجديدة متساهلة في البداية. ويتم ذلك باستخدام بيان إذن في ملف .te الخاص بالنطاق.
8. تحليل النتائج وتحسين تعريفات نطاقك
9. أزِل البيان المسموح به عندما لا تظهر أي عمليات رفض أخرى في عمليات التجميع التي تستخدم علامة 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 };

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

# 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 وعدم إنشائها أو فتحها.

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

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 والإصدارات الأحدث مع سياسة المكوّنات في صورة المورّد.

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

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

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

في الأجهزة التي تعمل بنظام التشغيل Android 8.0 والإصدارات الأحدث، يجب أن تتوافق صورة البائع مع صورة نظام المصنّع الأصلي للجهاز وصورة نظام 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 المرجعية.

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

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

أضِف هذه السياسة إلى 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-image فقط، باستثناء أنّ مكوّنات النظام الجديدة قد تتفاعل في واجهة 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. وهذا يعني أن أنواع الأنظمة لا يمكنها تغيير الوصول المسموح به لأنواع الموردين كجزء من التحديث عبر الهواء المستند إلى إطار العمل فقط.