تخصيص SELinux

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

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

عند الشروع في تخصيص SELinux، تذكر أن:

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

وتذكر ألا تفعل:

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

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

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

  1. استخدم أحدث نواة أندرويد .
  2. اعتماد مبدأ الامتيازات الأقل .
  3. معالجة فقط الإضافات الخاصة بك إلى Android. تعمل السياسة الافتراضية مع قاعدة بيانات Android Open Source Project تلقائيًا.
  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، والاتصال عبر مآخذ التوصيل، وإجراء طلبات DNS.

في السطر 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

أكثر

و اكثر

لا تسمح أبدًا بالقواعد

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

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

القاعدة 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 .

تخصيص سياسة SEPO في Android 8.0+

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

وضع السياسة

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

في Android 8.0 والإصدارات الأحدث، توجد السياسة في المواقع التالية في AOSP:

  • النظام/السياسة/العامة . يتضمن السياسة المصدرة للاستخدام في السياسة الخاصة بالمورد. كل شيء يدخل في البنية التحتية للتوافق مع Android 8.0. من المفترض أن تستمر السياسة العامة عبر الإصدارات حتى تتمكن من تضمين أي شيء /public في سياستك المخصصة. ولهذا السبب، يكون نوع السياسة التي يمكن وضعها في /public أكثر تقييدًا. خذ بعين الاعتبار واجهة برمجة التطبيقات (API) للسياسة المصدرة للنظام الأساسي: أي شيء يتعامل مع الواجهة بين /system و /vendor ينتمي هنا.
  • النظام/السياسة/الخاص . يتضمن السياسة اللازمة لتشغيل صورة النظام، ولكن لا ينبغي أن يكون لدى سياسة صورة البائع أي معرفة بها.
  • النظام/sepolicy/البائع . يتضمن سياسة للمكونات التي تدخل إلى /vendor ولكنها موجودة في شجرة النظام الأساسي الأساسية (وليست الدلائل الخاصة بالجهاز). يعد هذا نتيجة لتمييز نظام البناء بين الأجهزة والمكونات العالمية؛ من الناحية النظرية، يعد هذا جزءًا من السياسة الخاصة بالجهاز الموضحة أدناه.
  • الجهاز/ manufacturer / device-name / سياسة الخصوصية . يتضمن سياسة خاصة بالجهاز. يتضمن أيضًا تخصيصات الجهاز للسياسة، والتي تتوافق في 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 . يتضمن السياسة اللازمة لتشغيل صورة المنتج، ولكن لا ينبغي أن يكون لدى سياسة صورة البائع أي معرفة بها. تم التثبيت على قسم المنتج.
ملاحظة: عند استخدام GSI، لن يتم تثبيت أقسام النظام والمنتج الخاصة بشركة OEM. تصبح القواعد الموجودة في سياسة البائع التي تستخدم System_ext والسياسة العامة للمنتج الخاصة بـ OEM NOP لأن تعريفات النوع الخاصة بـ OEM مفقودة.
ملاحظة: كن حذرًا للغاية عند استخدام system_ext والسياسات العامة للمنتج. تعمل السياسات العامة كواجهة برمجة تطبيقات مُصدَّرة بين system_ext/product والمورد. من المفترض أن يقوم الشركاء بإدارة مشكلات التوافق بأنفسهم.

سيناريوهات السياسة المدعومة

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

ملحقات صورة النظام فقط

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

أضف هذه السياسة إلى system/sepolicy/private . يمكنك إضافة عمليات أو كائنات إضافية لتمكين الوظائف في صورة نظام شريك، بشرط ألا تحتاج تلك البتات الجديدة إلى التفاعل مع المكونات الجديدة في صورة البائع (على وجه التحديد، يجب أن تعمل هذه العمليات أو الكائنات بشكل كامل بدون سياسة من صورة البائع) . السياسة التي تم تصديرها بواسطة system/sepolicy/public متاحة هنا تمامًا كما هي الحال مع ملحقات صورة البائع فقط. تعد هذه السياسة جزءًا من صورة النظام ويمكن تحديثها في إطار عمل عبر الهواء فقط، ولكنها لن تكون موجودة عند استخدام صورة نظام 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 .

سيناريوهات السياسة غير المدعومة

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

ملحقات إضافية لصورة النظام التي تحتاج إلى إذن لمكونات صورة البائع الجديدة بعد OTA لإطار العمل فقط

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

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

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

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