پس از اینکه سطح پایه عملکرد SELinux را ادغام کردید و نتایج را به طور کامل تجزیه و تحلیل کردید، می‌توانید تنظیمات خط‌مشی خود را برای پوشش سفارشی‌سازی‌های خود به سیستم عامل Android اضافه کنید. این خط‌مشی‌ها همچنان باید الزامات برنامه سازگاری Android را برآورده کنند و نباید تنظیمات پیش‌فرض SELinux را حذف کنند.
تولیدکنندگان نباید خط مشی SELinux موجود را حذف کنند. در غیر این صورت، آنها در معرض خطر شکست اجرای Android SELinux و برنامه‌های تحت کنترل آن هستند. این شامل برنامه های شخص ثالثی می شود که احتمالاً برای سازگاری و عملیاتی شدن نیاز به بهبود دارند. برنامه‌ها برای ادامه عملکرد در دستگاه‌های دارای SELinux نباید به هیچ تغییری نیاز داشته باشند.
هنگام شروع سفارشی سازی SELinux، به یاد داشته باشید:
- خط مشی SELinux را برای همه دیمون های جدید بنویسید
- در صورت لزوم از دامنه های از پیش تعریف شده استفاده کنید
- یک دامنه به هر فرآیندی که به عنوان سرویس
initایجاد می شود اختصاص دهید - قبل از نوشتن خط مشی با ماکروها آشنا شوید
- تغییرات را در خط مشی اصلی به AOSP ارسال کنید
و به یاد داشته باشید که نباید:
- ایجاد خط مشی ناسازگار
- سفارشی سازی خط مشی کاربر نهایی را مجاز کنید
- سفارشی سازی خط مشی MDM مجاز است
- کاربران را با نقض خط مشی بترسانید
- درهای پشتی را اضافه کنید
برای نیازهای خاص، بخش ویژگی‌های امنیتی هسته سند تعریف سازگاری Android را ببینید.
SELinux از یک رویکرد لیست سفید استفاده می کند، به این معنی که تمام دسترسی ها باید به صراحت در خط مشی مجاز باشد تا اعطا شود. از آنجایی که خط‌مشی پیش‌فرض SELinux Android از پروژه منبع باز Android پشتیبانی می‌کند، به هیچ وجه نیازی به تغییر تنظیمات SELinux ندارید. اگر تنظیمات SELinux را سفارشی می کنید، بسیار مراقب باشید که برنامه های موجود را خراب نکنید. برای شروع:
- از جدیدترین هسته اندروید استفاده کنید.
- اصل کمترین امتیاز را بپذیرید.
- فقط موارد اضافه شده خود را به اندروید آدرس دهید. خط مشی پیش فرض با پایگاه کد پروژه منبع باز Android به طور خودکار کار می کند.
- اجزای نرم افزار را به ماژول هایی تقسیم کنید که وظایف منحصر به فردی را انجام می دهند.
- خط مشی های SELinux را ایجاد کنید که آن وظایف را از توابع نامرتبط جدا می کند.
- این خط مشی ها را در فایل های
*.te(پسوند فایل های منبع خط مشی SELinux) در دایرکتوری/device/ manufacturer / device-name /sepolicyقرار دهید و از متغیرهایBOARD_SEPOLICYبرای گنجاندن آنها در ساخت خود استفاده کنید. - در ابتدا دامنه های جدید را مجاز کنید. این کار با استفاده از یک اعلان مجاز در فایل
.teدامنه انجام می شود. - نتایج را تجزیه و تحلیل کنید و تعاریف دامنه خود را اصلاح کنید.
- زمانی که هیچ انکار دیگری در بیلدهای userdebug ظاهر نشد، اعلان مجاز را حذف کنید.
بعد از اینکه تغییر خط مشی SELinux خود را یکپارچه کردید، یک مرحله به گردش کار توسعه خود اضافه کنید تا از سازگاری SELinux در آینده اطمینان حاصل کنید. در یک فرآیند توسعه نرم افزار ایده آل، سیاست SELinux تنها زمانی تغییر می کند که مدل نرم افزار تغییر کند و نه پیاده سازی واقعی.
همانطور که شروع به سفارشی سازی SELinux می کنید، ابتدا موارد اضافه شده خود را به اندروید بررسی کنید. اگر مؤلفه‌ای اضافه کرده‌اید که عملکرد جدیدی را انجام می‌دهد، قبل از روشن کردن حالت اجرا، مطمئن شوید که مؤلفه با خط‌مشی امنیتی Android و همچنین هر خط‌مشی مرتبط ساخته شده توسط OEM مطابقت دارد.
برای جلوگیری از مشکلات غیر ضروری، بهتر است بیش از حد گسترده و بیش از حد سازگار باشد تا بیش از حد محدود کننده و ناسازگار، که منجر به خرابی عملکرد دستگاه می شود. برعکس، اگر تغییرات شما به نفع دیگران باشد، باید اصلاحات را در خط مشی پیش‌فرض SELinux به عنوان یک وصله ارسال کنید. اگر وصله روی خط‌مشی امنیتی پیش‌فرض اعمال می‌شود، نیازی نیست این تغییر را با هر نسخه جدید اندروید انجام دهید.
نمونه بیانیه های خط مشی
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، سوکت‌های دیتاگرام و سوکت‌های جریان یونیکس با یکدیگر ارتباط برقرار کنند. DHCP ممکن است فقط از سوکت های دیتاگرام و سوکت های جریان یونیکس بخواند و بنویسد و آنها را ایجاد یا باز نکند.
کنترل های موجود
| کلاس | اجازه |
|---|---|
| فایل | 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 SELinux رفتاری را که هرگز نباید رخ دهد ممنوع می کند. با تست سازگاری ، قوانین SELinux neverallow اکنون در سراسر دستگاه ها اجرا می شوند.
دستورالعمل‌های زیر برای کمک به تولیدکنندگان برای جلوگیری از خطاهای مربوط به قوانین neverallow در طول سفارشی‌سازی در نظر گرفته شده است. اعداد قوانین استفاده شده در اینجا با Android 5.1 مطابقت دارد و ممکن است با انتشار تغییر کند.
قانون 48: neverallow { domain -debuggerd -vold -dumpstate -system_server } self:capability sys_ptrace;
برای ptrace به صفحه man مراجعه کنید. قابلیت 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 و بالاتر سفارشی کنید
این بخش دستورالعمل‌هایی را برای خط‌مشی SELinux فروشنده در اندروید 8.0 و بالاتر ارائه می‌کند، از جمله جزئیات مربوط به SEPolicy و برنامه‌های افزودنی SEPolicy پروژه منبع باز Android (AOSP). برای اطلاعات بیشتر در مورد نحوه سازگار نگه داشتن خط مشی 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سروکار دارد در اینجا قرار دارد. - سیستم / سیاست / خصوصی. شامل خط مشی لازم برای عملکرد تصویر سیستم است، اما خط مشی تصویر فروشنده نباید از آن اطلاعی داشته باشد.
- سیستم/سیاست/فروشنده. شامل خط‌مشی برای مؤلفه‌هایی است که در
/vendorمی‌روند اما در درخت پلتفرم اصلی (نه دایرکتوری‌های خاص دستگاه) وجود دارند. این یک مصنوع از تمایز سیستم ساخت بین دستگاه ها و اجزای جهانی است. از نظر مفهومی این بخشی از خط مشی دستگاه خاص است که در زیر توضیح داده شده است. - دستگاه / manufacturer / device-name / سیاست. شامل خط مشی دستگاه خاص است. همچنین شامل سفارشی‌سازی‌های دستگاه برای خط‌مشی است که در Android نسخه ۸.۰ و بالاتر با خط‌مشی اجزای موجود در تصویر فروشنده مطابقت دارد.
در Android 11 و بالاتر، پارتیشن‌های system_ext و product همچنین می‌توانند شامل خط‌مشی‌های خاص پارتیشن باشند. سیاست‌های system_ext و محصول نیز به عمومی و خصوصی تقسیم می‌شوند و فروشندگان می‌توانند از خط‌مشی‌های عمومی 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. شامل خط مشی لازم برای عملکرد تصویر محصول است، اما خط مشی تصویر فروشنده نباید از آن اطلاعی داشته باشد. روی پارتیشن محصول نصب شده است.
سناریوهای سیاست پشتیبانی شده
در دستگاه‌هایی که با Android 8.0 و بالاتر راه‌اندازی می‌شوند، تصویر فروشنده باید با تصویر سیستم OEM و تصویر سیستم مرجع AOSP ارائه شده توسط Google کار کند (و CTS را روی این تصویر مرجع ارسال کند). این الزامات جدایی تمیز بین چارچوب و کد فروشنده را تضمین می کند. چنین دستگاه هایی از سناریوهای زیر پشتیبانی می کنند.
پسوندهای فقط تصویر فروشنده
مثال: افزودن یک سرویس جدید به vndservicemanager از تصویر فروشنده که از فرآیندهای تصویر فروشنده پشتیبانی می کند.
مانند دستگاه‌هایی که با نسخه‌های قبلی اندروید راه‌اندازی می‌شوند، سفارشی‌سازی خاص دستگاه را در device/ manufacturer / device-name /sepolicy اضافه کنید. خط مشی جدیدی که بر نحوه تعامل اجزای فروشنده با (فقط) سایر مؤلفه‌های فروشنده نظارت می‌کند ، باید شامل انواعی باشد که فقط در device/ manufacturer / device-name /sepolicy وجود دارد. خط مشی نوشته شده در اینجا به کد روی فروشنده اجازه می دهد تا کار کند، به عنوان بخشی از OTA فقط چارچوب به روز نمی شود و در خط مشی ترکیبی دستگاهی با تصویر سیستم AOSP مرجع وجود دارد.
پشتیبانی از تصویر فروشنده برای کار با AOSP
مثال: افزودن یک فرآیند جدید (ثبت شده در hwservicemanager از تصویر فروشنده) که یک HAL تعریف شده توسط AOSP را پیاده سازی می کند.
همانند دستگاه‌هایی که با نسخه‌های قبلی اندروید راه‌اندازی می‌شوند، سفارشی‌سازی خاص دستگاه را در device/ manufacturer / device-name /sepolicy انجام دهید. خط مشی صادر شده به عنوان بخشی از system/sepolicy/public/ برای استفاده در دسترس است و به عنوان بخشی از خط مشی فروشنده ارسال می شود. انواع و ویژگی‌های خط‌مشی عمومی ممکن است در قوانین جدید استفاده شود که تعاملات با بیت‌های خاص فروشنده جدید را دیکته می‌کنند، مشروط به محدودیت‌های neverallow . مانند مورد فقط فروشنده، خط‌مشی جدید در اینجا به‌عنوان بخشی از OTA فقط چارچوب به‌روزرسانی نمی‌شود و در خط‌مشی ترکیبی دستگاهی با تصویر سیستم AOSP مرجع وجود دارد.
پسوندهای فقط تصویر سیستم
مثال: افزودن یک سرویس جدید (ثبت شده در servicemanager) که فقط توسط سایر فرآیندها از تصویر سیستم قابل دسترسی است.
این سیاست را به system/sepolicy/private اضافه کنید. می‌توانید فرآیندها یا اشیاء اضافی را برای فعال کردن عملکرد در تصویر سیستم شریک اضافه کنید، مشروط بر اینکه این بیت‌های جدید نیازی به تعامل با اجزای جدید روی تصویر فروشنده نداشته باشند (به طور خاص، چنین فرآیندها یا اشیایی باید به طور کامل بدون خط‌مشی از تصویر فروشنده کار کنند) . خط مشی صادر شده توسط system/sepolicy/public در اینجا نیز در دسترس است، همانطور که برای برنامه‌های افزودنی فقط تصویر فروشنده است. این خط‌مشی بخشی از تصویر سیستم است و می‌تواند در یک OTA فقط چارچوبی به‌روزرسانی شود، اما هنگام استفاده از تصویر سیستم مرجع AOSP وجود نخواهد داشت.
پسوندهای تصویر فروشنده که مولفه های AOSP توسعه یافته را ارائه می کنند
مثال: یک HAL جدید و غیر AOSP برای استفاده توسط مشتریان توسعه یافته که در تصویر سیستم AOSP نیز وجود دارد (مانند یک system_server توسعه یافته).
خط مشی تعامل بین سیستم و فروشنده باید در دایرکتوری 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-extensions ، خط مشی برای تعاملات بین سیستم و فروشنده باید در دایرکتوری 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 نسخه ۸.۰ و بالاتر راه‌اندازی می‌شوند، سناریو و نمونه‌های خط‌مشی زیر را پشتیبانی نمی‌کنند.
افزونه‌های اضافی برای تصویر سیستم که پس از OTA فقط برای چارچوب، به مجوز مؤلفه‌های تصویر فروشنده جدید نیاز دارند.
مثال: یک فرآیند جدید سیستم غیر AOSP، که به دامنه خاص خود نیاز دارد، در نسخه بعدی اندروید اضافه شده است و نیاز به دسترسی به HAL جدید غیر AOSP دارد.
مشابه سیستم جدید (غیر AOSP) و تعامل اجزای فروشنده ، به جز اینکه نوع سیستم جدید در یک OTA فقط چارچوبی معرفی شده است. اگرچه نوع جدید را می‌توان به خط‌مشی در 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 فقط چارچوبی تغییر دهند.