تخصيص SELinux

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

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

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

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

وتذكر عدم:

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

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

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

  1. يمكنك استخدام أحدث إصدار من نظام التشغيل Android kernel.
  2. استخدام مبادئ بأقل امتياز.
  3. تعامل مع إضافاتك الخاصة فقط إلى Android. تعمل السياسة التلقائية مع برنامج Android المفتوح المصدر مشروع قاعدة الرموز تلقائيًا.
  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 البرنامج الخفي لـ DHCP من سياسة الأمان الأساسية (domain). من البيان السابق الأمثلة، يمكن لبروتوكول DHCP القراءة من /dev/null والكتابة إليه.

في السطر الثاني، يتم تعريف DHCP على أنه نطاق متساهل.

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

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

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

يبدأ الجزء الأخير من المثال يعرض allow dhcp netd:fd use; كيفية السماح للتطبيقات التفاعل مع بعضها البعض. تنص السياسة على أنّ بروتوكول DHCP والشبكة المتصلة بالإنترنت قد تتواصل مع بعضها البعض باستخدام واصفات الملفات وملفات 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

توسيع

وغير ذلك

قواعد NOTallow

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

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

القاعدة 48: neverallow { domain -debuggerd -vold -dumpstate -system_server } self:capability sys_ptrace;
الاطّلاع على صفحة الدليل الخاصة بـ "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 في Android 8.0 والإصدارات الأحدث

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

موضع الإعلان بموجب السياسة

في نظام Android 7.0 والإصدارات الأقدم، يمكن للشركات المصنّعة للأجهزة إضافة سياسة إلى 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_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 للمصنّع الأصلي للجهاز وأقسام المنتج يمكن تثبيته. أن القواعد في سياسة البائع تصبح السياسة العامة للمنتج NOP لأن تعريفات النوع الخاصة بالمُصنّع الأصلي مفقود.
ملاحظة: يجب توخّي الحذر عند استخدام System_ext والسياسات العامة للمنتج. تعمل السياسات العامة كواجهة برمجة تطبيقات تم تصديرها بين System_ext/product والمورد. من المفترض أن يدير الشركاء مشاكل التوافق بأنفسهم.

السيناريوهات المتاحة للسياسات

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

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

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

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

دعم صورة الموردين للعمل مع بروتوكول AOSP

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

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

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

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

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

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

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

يجب إدراج سياسة التفاعل بين النظام والمورد في 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 الأخرى الأنواع أو التغييرات (بأي طريقة تؤثر في السياسة) نتيجةً لإيجاد إطار عمل فقط تحديث. يمكن إجراء تغيير على السياسة في التحديث عبر الهواء المستند إلى إطار العمل فقط، ولكن لن يتم ذلك تظهر عند استخدام صورة نظام 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 التالي ويحتاج إلى الوصول إلى التي لا تتبع AOSP.

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

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

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