از 27 مارس 2025، توصیه می کنیم از android-latest-release به جای aosp-main برای ساختن و کمک به AOSP استفاده کنید. برای اطلاعات بیشتر، به تغییرات AOSP مراجعه کنید.

این صفحه به‌وسیله ‏Cloud Translation API‏ ترجمه شده است.

سازگاری با خط مشی، سازگاری با سیاست، سازگاری با سیاست، سازگاری با سیاست

این صفحه نحوه مدیریت مشکلات سازگاری سیاست‌ها توسط اندروید با به‌روزرسانی‌های OTA پلتفرم را شرح می‌دهد، که در آن‌ها تنظیمات SELinux پلتفرم جدید ممکن است با تنظیمات SELinux فروشنده قدیمی متفاوت باشد.

مالکیت و برچسب‌گذاری اشیاء

مالکیت باید برای هر شیء به وضوح تعریف شود تا سیاست‌های پلتفرم و فروشنده از هم جدا بمانند. برای مثال، اگر سیاست فروشنده برچسب /dev/foo و سیاست پلتفرم برچسب /dev/foo را در یک OTA بعدی داشته باشد، رفتار نامشخصی مانند یک انکار غیرمنتظره یا مهم‌تر از آن، یک خرابی بوت وجود خواهد داشت. برای SELinux، این به عنوان یک تصادم برچسب‌گذاری ظاهر می‌شود. گره دستگاه فقط می‌تواند یک برچسب واحد داشته باشد که به برچسبی که آخرین بار اعمال می‌شود، تبدیل می‌شود. در نتیجه:

فرآیندهایی که نیاز به دسترسی به برچسب اعمال شده ناموفق دارند، دسترسی به منبع را از دست می‌دهند.
فرآیندهایی که به فایل دسترسی پیدا می‌کنند ممکن است به دلیل ایجاد گره دستگاه اشتباه، با مشکل مواجه شوند.

تداخل بین برچسب‌های پلتفرم و فروشنده می‌تواند برای هر شیء که دارای برچسب SELinux است، از جمله ویژگی‌ها، سرویس‌ها، فرآیندها، فایل‌ها و سوکت‌ها، رخ دهد. برای جلوگیری از این مشکلات، مالکیت این اشیاء را به وضوح تعریف کنید.

فاصله‌گذاری نام نوع/ویژگی

علاوه بر تداخل برچسب‌ها، نام‌های نوع و ویژگی SELinux نیز می‌توانند با هم تداخل داشته باشند. SELinux اجازه تعریف چندگانه از انواع و ویژگی‌های یکسان را نمی‌دهد. سیاستی با تعریف‌های تکراری، کامپایل نمی‌شود. برای جلوگیری از تداخل نام نوع و ویژگی، اکیداً توصیه می‌شود که تمام تعریف‌های فروشنده با پیشوند vendor_ شروع شوند. به عنوان مثال، فروشندگان باید به جای type foo type vendor_foo, domain; type foo, domain; استفاده کنند.

مالکیت فایل

جلوگیری از تصادم برای فایل‌ها چالش‌برانگیز است زیرا سیاست‌های پلتفرم و فروشنده معمولاً برای همه سیستم فایل‌ها برچسب‌هایی ارائه می‌دهند. برخلاف نامگذاری نوع، فضای نام فایل‌ها عملی نیست زیرا بسیاری از آنها توسط هسته ایجاد می‌شوند. برای جلوگیری از این تصادم‌ها، راهنمای نامگذاری برای سیستم فایل‌ها را در این بخش دنبال کنید. برای اندروید ۸.۰، این توصیه‌ها بدون الزام فنی هستند. در آینده، این توصیه‌ها توسط مجموعه تست فروشنده (VTS) اجرا خواهند شد.

سیستم (/سیستم)

فقط تصویر سیستم باید از طریق file_contexts ، service_contexts و غیره برچسب‌هایی برای اجزای /system ارائه دهد. اگر برچسب‌هایی برای اجزای /system در سیاست فروشنده اضافه شود، ممکن است به‌روزرسانی OTA فقط برای چارچوب امکان‌پذیر نباشد.

فروشنده (/فروشنده)

سیاست AOSP SELinux از قبل بخش‌هایی از پارتیشن vendor را که پلتفرم با آن تعامل دارد، برچسب‌گذاری می‌کند، که امکان نوشتن قوانین SELinux را برای فرآیندهای پلتفرم فراهم می‌کند تا بتوانند با بخش‌هایی از پارتیشن vendor صحبت کنند یا به آنها دسترسی داشته باشند. مثال‌ها:

/مسیر فروشنده	برچسب ارائه شده توسط پلتفرم	فرآیندهای پلتفرم بسته به برچسب
`/vendor(/. * )?`	`vendor_file`	همه کلاینت‌های HAL در framework، `ueventd` و غیره
`/vendor/framework(/. * )?`	`vendor_framework_file`	`dex2oat` ، `appdomain` و غیره.
`/vendor/app(/. * )?`	`vendor_app_file`	`dex2oat` ، `installd` ، `idmap` و غیره.
`/vendor/overlay(/. * )`	`vendor_overlay_file`	`system_server` ، `zygote` ، `idmap` و غیره.

در نتیجه، هنگام برچسب‌گذاری فایل‌های اضافی در پارتیشن vendor ، باید قوانین خاصی رعایت شود (که از طریق neverallows اعمال می‌شوند):

vendor_file باید برچسب پیش‌فرض برای همه فایل‌های موجود در پارتیشن vendor باشد. سیاست پلتفرم برای دسترسی به پیاده‌سازی‌های HAL عبوری، این را الزامی می‌کند.
تمام exec_types جدیدی که از طریق سیاست vendor به پارتیشن vendor اضافه می‌شوند، باید دارای ویژگی vendor_file_type باشند. این امر از طریق neverallows اعمال می‌شود.
برای جلوگیری از تداخل با به‌روزرسانی‌های آتی پلتفرم/فریم‌ورک، از برچسب‌گذاری فایل‌هایی غیر از exec_types در پارتیشن vendor خودداری کنید.
تمام وابستگی‌های کتابخانه‌ای برای HALهای فرآیند یکسان که توسط AOSP شناسایی می‌شوند، باید با برچسب same_process_hal_file.

پروسس‌ها (/proc)

فایل‌های موجود در /proc را می‌توان فقط با استفاده از برچسب genfscon برچسب‌گذاری کرد. در اندروید ۷.۰، هم سیاست پلتفرم و هم سیاست فروشنده genfscon برای برچسب‌گذاری فایل‌های موجود در procfs استفاده می‌کردند.

توصیه: فقط برچسب‌های سیاست پلتفرم /proc . اگر فرآیندهای فروشنده نیاز به دسترسی به فایل‌هایی در /proc دارند که در حال حاضر با برچسب پیش‌فرض ( proc ) برچسب‌گذاری شده‌اند، سیاست فروشنده نباید صریحاً آنها را برچسب‌گذاری کند و در عوض باید از نوع عمومی proc برای اضافه کردن قوانین برای دامنه‌های فروشنده استفاده کند. این امر به به‌روزرسانی‌های پلتفرم اجازه می‌دهد تا رابط‌های هسته آینده را که از طریق procfs در معرض دید قرار می‌گیرند، در خود جای دهند و در صورت نیاز آنها را صریحاً برچسب‌گذاری کنند.

اشکال‌زدایی (/sys/kernel/debug)

Debugfs می‌توان هم در file_contexts و هم genfscon برچسب‌گذاری کرد. در اندروید ۷.۰ تا اندروید ۱۰، هم برای پلتفرم و هم برای فروشنده برچسب debugfs وجود دارد.

در اندروید ۱۱، debugfs قابل دسترسی یا نصب روی دستگاه‌های تولیدی نیستند. تولیدکنندگان دستگاه‌ها باید debugfs حذف کنند.

Tracefs (/sys/kernel/debug/tracing)

Tracefs می‌توان هم در file_contexts و هم genfscon برچسب‌گذاری کرد. در اندروید ۷.۰، فقط پلتفرم tracefs برچسب‌گذاری می‌کند.

توصیه: فقط پلتفرم می‌تواند tracefs برچسب‌گذاری کند.

سیستم‌ها (/sys)

فایل‌های موجود در /sys می‌توانند با استفاده از هر دو file_contexts و genfscon برچسب‌گذاری شوند. در اندروید ۷.۰، هم پلتفرم و هم فروشنده از genfscon برای برچسب‌گذاری فایل‌ها در sysfs استفاده می‌کنند.

توصیه: پلتفرم ممکن است گره‌های sysfs را که مختص دستگاه نیستند، برچسب‌گذاری کند. در غیر این صورت، فقط فروشنده می‌تواند فایل‌ها را برچسب‌گذاری کند.

tmpfs (/dev)

فایل‌های موجود در /dev ممکن است در file_contexts برچسب‌گذاری شوند. در اندروید ۷.۰، هم برچسب پلتفرم و هم برچسب فروشنده در اینجا قرار می‌گیرند.

توصیه: فروشنده می‌تواند فقط فایل‌های موجود در /dev/vendor را برچسب‌گذاری کند (برای مثال، /dev/vendor/foo ، /dev/vendor/socket/bar ).

ریشه‌ها (/)

فایل‌های موجود در / ممکن است در file_contexts برچسب‌گذاری شوند. در اندروید ۷.۰، هم فایل‌ها با برچسب پلتفرم و هم با برچسب فروشنده در اینجا قرار می‌گیرند.

توصیه: فقط سیستم می‌تواند فایل‌های موجود در / را برچسب‌گذاری کند.

داده‌ها (/داده‌ها)

داده‌ها از طریق ترکیبی از file_contexts و seapp_contexts برچسب‌گذاری می‌شوند.

توصیه: برچسب‌گذاری فروشنده خارج از /data/vendor را مجاز نکنید. فقط پلتفرم می‌تواند بخش‌های دیگر /data را برچسب‌گذاری کند.

نسخه برچسب‌های Genfs

با شروع از API سطح 202504 مربوط به فروشنده ، برچسب‌های جدیدتر SELinux که با genfscon در system/sepolicy/compat/plat_sepolicy_genfs_ ver .cil اختصاص داده شده‌اند، برای پارتیشن‌های vendor قدیمی‌تر اختیاری هستند. این امر به پارتیشن‌های vendor قدیمی‌تر اجازه می‌دهد تا پیاده‌سازی SEPolicy موجود خود را حفظ کنند. این امر توسط متغیر Makefile BOARD_GENFS_LABELS_VERSION که در /vendor/etc/selinux/genfs_labels_version.txt ذخیره می‌شود، کنترل می‌شود.

مثال:

در سطح API فروشنده ۲۰۲۴۰۴، گره /sys/class/udc به طور پیش‌فرض با برچسب sysfs مشخص شده است.
با شروع از سطح API فروشنده ۲۰۲۵۰۴، فایل /sys/class/udc با برچسب sysfs_udc نمایش داده می‌شود.

با این حال، ممکن است /sys/class/udc توسط پارتیشن‌های vendor که از سطح API 202404 استفاده می‌کنند، چه با برچسب پیش‌فرض sysfs و چه با برچسب مخصوص فروشنده، در حال استفاده باشد. برچسب‌گذاری بی‌قید و شرط /sys/class/udc به عنوان sysfs_udc می‌تواند سازگاری با این پارتیشن‌های vendor را از بین ببرد. با بررسی BOARD_GENFS_LABELS_VERSION ، پلتفرم همچنان از برچسب‌ها و مجوزهای قبلی برای پارتیشن‌های vendor قدیمی‌تر استفاده می‌کند.

BOARD_GENFS_LABELS_VERSION می‌تواند بزرگتر یا مساوی سطح API فروشنده باشد. برای مثال، پارتیشن‌های vendor که از سطح API 202404 استفاده می‌کنند، می‌توانند BOARD_GENFS_LABELS_VERSION روی 202504 تنظیم کنند تا برچسب‌های جدیدی که در 202504 معرفی شده‌اند را بپذیرند. لیست برچسب‌های genfs مخصوص 202504 را ببینید.

هنگام برچسب‌گذاری گره‌های genfscon ، پلتفرم باید پارتیشن‌های قدیمی‌تر vendor را در نظر بگیرد و در صورت نیاز، مکانیزم‌های جایگزین را برای سازگاری پیاده‌سازی کند. پلتفرم می‌تواند از کتابخانه‌های مخصوص پلتفرم برای جستجوی نسخه برچسب‌ها genfs استفاده کند.

در حالت native، از libgenfslabelsversion استفاده کنید. برای فایل هدر libgenfslabelsversion به genfslabelsversion.h مراجعه کنید.
در جاوا، از android.os.SELinux.getGenfsLabelsVersion() استفاده کنید.

سیاست عمومی پلتفرم

سیاست SELinux پلتفرم به دو بخش خصوصی و عمومی تقسیم می‌شود. سیاست عمومی-پلتفرم شامل انواع و ویژگی‌هایی است که همیشه برای سطح API فروشنده در دسترس هستند و به عنوان یک API بین پلتفرم و فروشنده عمل می‌کنند. این سیاست در اختیار نویسندگان سیاست فروشنده قرار می‌گیرد تا فروشندگان بتوانند فایل‌های سیاست فروشنده را بسازند که در صورت ترکیب با سیاست خصوصی-پلتفرم، منجر به یک سیاست کاملاً کاربردی برای یک دستگاه می‌شود. سیاست عمومی-پلتفرم در system/sepolicy/public تعریف شده است.

برای مثال، نوع vendor_init که نشان‌دهنده‌ی فرآیند init در چارچوب vendor است، در system/sepolicy/public/vendor_init.te تعریف شده است:

type vendor_init, domain;

فروشندگان می‌توانند برای نوشتن قوانین سیاست سفارشی به نوع vendor_init مراجعه کنند:

# Allow vendor_init to set vendor_audio_prop in vendor's init scripts
set_prop(vendor_init, vendor_audio_prop)

ویژگی‌های سازگاری

سیاست SELinux تعاملی بین انواع منبع و هدف برای کلاس‌ها و مجوزهای خاص شیء است. هر شیء (به عنوان مثال، فرآیندها، فایل‌ها) که تحت تأثیر سیاست SELinux قرار می‌گیرد، می‌تواند فقط یک نوع داشته باشد، اما آن نوع ممکن است چندین ویژگی داشته باشد.

این سیاست عمدتاً بر اساس انواع موجود نوشته شده است. در اینجا، هم vendor_init و هم debugfs از نوع هستند:

allow vendor_init debugfs:dir { mounton };

این روش به این دلیل کار می‌کند که این سیاست با آگاهی از همه نوع‌ها نوشته شده است. با این حال، اگر سیاست فروشنده و سیاست پلتفرم از انواع خاصی استفاده کنند و برچسب یک شیء خاص فقط در یکی از این سیاست‌ها تغییر کند، دیگری ممکن است حاوی سیاستی باشد که قبلاً به آن دسترسی پیدا کرده یا از دست داده است. به عنوان مثال، فرض کنید که سیاست پلتفرم، گره‌های sysfs را به عنوان sysfs برچسب‌گذاری می‌کند:

/sys(/.*)? u:object_r:sysfs:s0

سیاست فروشنده، دسترسی به /sys/usb را که با عنوان sysfs مشخص شده است، اعطا می‌کند:

allow vendor_init sysfs:chr_file rw_file_perms;

اگر سیاست پلتفرم به گونه‌ای تغییر کند که /sys/usb را به عنوان sysfs_usb برچسب‌گذاری کند، سیاست فروشنده ثابت می‌ماند، اما vendor_init به دلیل عدم وجود سیاست برای نوع جدید sysfs_usb ، دسترسی به /sys/usb را از دست می‌دهد:

/sys/usb u:object_r:sysfs_usb:s0

برای حل این مشکل، اندروید مفهومی به نام ویژگی‌های نسخه‌بندی‌شده (versioned attributes) را معرفی می‌کند. در زمان کامپایل، سیستم ساخت (build system) به طور خودکار انواع عمومی پلتفرم مورد استفاده در سیاست فروشنده (vendor policy) را به این ویژگی‌های نسخه‌بندی‌شده (versioned attributes) ترجمه می‌کند. این ترجمه با نگاشت فایل‌هایی که یک ویژگی نسخه‌بندی‌شده را با یک یا چند نوع عمومی از پلتفرم مرتبط می‌کنند، فعال می‌شود.

برای مثال، فرض کنید که /sys/usb در سیاست پلتفرم 202504 به عنوان sysfs برچسب گذاری شده باشد، و سیاست فروشنده 202504 به vendor_init دسترسی به /sys/usb را اعطا کند. در این حالت:

سیاست فروشنده یک قانون allow vendor_init sysfs:chr_file rw_file_perms; می‌نویسد، زیرا /sys/usb در سیاست پلتفرم 202504 به عنوان sysfs برچسب‌گذاری شده است. هنگامی که سیستم ساخت، سیاست فروشنده را کامپایل می‌کند، به طور خودکار این قانون را به allow vendor_init _202504 sysfs _202504 :chr_file rw_file_perms; ترجمه می‌کند. ویژگی‌های vendor_init_202504 و sysfs_202504 با انواع vendor_init و sysfs مطابقت دارند که انواع تعریف شده توسط پلتفرم هستند.
سیستم ساخت، یک فایل نگاشت هویت /system/etc/selinux/mapping/202504.cil ایجاد می‌کند. از آنجایی که هر دو پارتیشن system و vendor از نسخه یکسان 202504 استفاده می‌کنند، فایل نگاشت شامل نگاشت‌های هویت از type_202504 به type است. برای مثال، vendor_init_202504 به vendor_init و sysfs_202504 به sysfs نگاشت می‌شود:
```
(typeattributeset sysfs_202504 (sysfs))
(typeattributeset vendor_init_202504 (vendor_init))
...
```

وقتی نسخه از 202504 به 202604 ارتقا می‌یابد، یک فایل نگاشت جدید برای پارتیشن‌های vendor مدل 202504 در مسیر system/sepolicy/private/compat/202504/202504.cil ایجاد می‌شود که برای پارتیشن‌های system مدل 202604 یا جدیدتر در مسیر /system/etc/selinux/mapping/202504.cil نصب می‌شود. در ابتدا، این فایل نگاشت، همانطور که قبلاً توضیح داده شد، حاوی نگاشت‌های هویت است. اگر یک برچسب جدید sysfs_usb برای /sys/usb به سیاست پلتفرم 202604 اضافه شود، فایل نگاشت برای نگاشت sysfs_202504 به sysfs_usb به‌روزرسانی می‌شود:

(typeattributeset sysfs_202504 (sysfs sysfs_usb))
(typeattributeset vendor_init_202504 (vendor_init))
...

این به‌روزرسانی به قانون سیاست فروشنده تبدیل‌شده allow vendor_init_202504 sysfs_202504:chr_file rw_file_perms; می‌دهد تا به‌طور خودکار vendor_init دسترسی به نوع جدید sysfs_usb اعطا کند.

برای حفظ سازگاری با پارتیشن‌های قدیمی‌تر vendor ، هر زمان که یک نوع عمومی جدید اضافه می‌شود، آن نوع باید حداقل به یکی از ویژگی‌های نسخه‌بندی‌شده در فایل نگاشت system/sepolicy/private/compat/ ver / ver .cil نگاشت شود، یا در زیر system/sepolicy/private/compat/ ver / ver .ignore.cil فهرست شود تا بیان شود که هیچ نوع تطبیقی در نسخه‌های قبلی فروشنده وجود ندارد.

ترکیب سیاست پلتفرم، سیاست فروشنده و فایل نگاشت به سیستم اجازه می‌دهد بدون به‌روزرسانی سیاست فروشنده، به‌روزرسانی شود. همچنین تبدیل به ویژگی‌های نسخه‌بندی‌شده به‌طور خودکار اتفاق می‌افتد، بنابراین سیاست فروشنده نیازی به مراقبت از نسخه‌بندی ندارد و از انواع عمومی به همان صورت استفاده می‌کند.

نکته: برخلاف انواع عمومی که قبلاً ذکر شد، ویژگی‌های عمومی نسخه‌بندی نمی‌شوند. ویژگی‌ها انواع مشخصی نیستند و مجوزهای اعطا شده به ویژگی‌ها به طور خودکار به تمام انواعی که به آن ویژگی نگاشت می‌شوند، اعمال می‌شوند. برای مثال، اگر یک سیاست فروشنده، مجوزهایی را به appdomain اعطا کند، این مجوزها به طور خودکار به تمام برنامه‌ها، از جمله برنامه‌های سیستمی جدیدتر که هنگام نوشتن سیاست وجود نداشتند، اعمال می‌شوند.

سیاست عمومی و عمومی محصول system_ext

از اندروید ۱۱ به بعد، پارتیشن‌های system_ext و product مجاز به صادر کردن انواع عمومی تعیین‌شده‌ی خود به پارتیشن vendor هستند. مانند سیاست عمومی پلتفرم، سیاست vendor از انواع و قوانینی استفاده می‌کند که به‌طور خودکار به ویژگی‌های نسخه‌بندی‌شده ترجمه می‌شوند، به‌عنوان مثال، از type به type_ ver ، که در آن ver سطح API فروشنده‌ی پارتیشن vendor است.

وقتی پارتیشن‌های system_ext و product بر اساس نسخه پلتفرم ver یکسانی باشند، سیستم ساخت، فایل‌های نگاشت پایه را به system_ext/etc/selinux/mapping/ ver .cil و product/etc/selinux/mapping/ ver .cil تولید می‌کند که شامل نگاشت‌های هویت از type به type_ ver هستند. سیاست فروشنده می‌تواند با ویژگی نسخه‌بندی شده type_ ver type دسترسی پیدا کند.

در صورتی که فقط پارتیشن‌های system_ext و product به‌روزرسانی شوند، مثلاً ver به ver+1 (یا بالاتر)، در حالی که پارتیشن vendor در ver باقی بماند، ممکن است سیاست فروشنده دسترسی به انواع پارتیشن‌های system_ext و product را از دست بدهد. برای جلوگیری از خرابی، پارتیشن‌های system_ext و product باید فایل‌های نگاشت را از انواع عینی به ویژگی‌های type_ ver ارائه دهند. هر شریک مسئول نگهداری فایل‌های نگاشت است، اگر از پارتیشن ver vendor با پارتیشن‌های system_ext و product نسخه ver+1 (یا بالاتر) پشتیبانی کند.

برای نصب فایل‌های نگاشت به system_ext و پارتیشن‌های product ، از پیاده‌سازی‌کنندگان دستگاه یا فروشندگان انتظار می‌رود:

فایل‌های نگاشت پایه تولید شده را از پارتیشن‌های ver system_ext و product به درخت منبع آنها کپی کنید.
در صورت نیاز، فایل‌های نقشه‌برداری را اصلاح کنید.
فایل‌های نگاشت را در پارتیشن‌های system_ext و product ver+1 (یا بالاتر) نصب کنید.

برای مثال، فرض کنید پارتیشن system_ext شماره ۲۰۲۵۰۴ یک نوع عمومی به نام foo_type دارد. سپس system_ext/etc/selinux/mapping/202504.cil در پارتیشن system_ext شماره ۲۰۲۵۰۴ به صورت زیر خواهد بود:

(typeattributeset foo_type_202504 (foo_type))
(expandtypeattribute foo_type_202504 true)
(typeattribute foo_type_202504)

اگر bar_type به system_ext 202604 اضافه شود، و اگر bar_type باید برای پارتیشن vendor 202504 به foo_type نگاشت شود، 202504.cil می‌تواند از (typeattributeset foo_type_202504 (foo_type)) به (typeattributeset foo_type_202504 (foo_type bar_type)) به‌روزرسانی شود و سپس در پارتیشن system_ext 202604 نصب شود. پارتیشن vendor 202504 می‌تواند به دسترسی به foo_type و bar_type مربوط به system_ext 202604 ادامه دهد.

تغییرات ویژگی‌ها برای اندروید ۹

دستگاه‌هایی که به اندروید ۹ ارتقا می‌یابند می‌توانند از ویژگی‌های زیر استفاده کنند، اما دستگاه‌هایی که با اندروید ۹ عرضه می‌شوند، نباید از این ویژگی‌ها استفاده کنند.

ویژگی‌های نقض‌کننده

اندروید ۹ شامل این ویژگی‌های مرتبط با دامنه است:

data_between_core_and_vendor_violators . ویژگی برای همه دامنه‌هایی که الزام عدم اشتراک‌گذاری فایل‌ها از طریق مسیر بین دامنه‌های vendor و coredomains را نقض می‌کنند. فرآیندهای پلتفرم و فروشنده نباید از فایل‌های روی دیسک برای برقراری ارتباط استفاده کنند (ABI ناپایدار). توصیه:
- کد فروشنده باید از /data/vendor استفاده کند.
- سیستم نباید از /data/vendor استفاده کند.
system_executes_vendor_violators . ویژگی برای همه دامنه‌های سیستم (به جز دامنه‌های init و shell domains ) که الزام عدم اجرای فایل‌های باینری فروشنده را نقض می‌کنند. اجرای فایل‌های باینری فروشنده دارای API ناپایدار است. پلتفرم نباید فایل‌های باینری فروشنده را مستقیماً اجرا کند. توصیه:
- چنین وابستگی‌های پلتفرمی به فایل‌های باینری فروشنده باید پشت HALهای HIDL باشند.
  یا
- coredomains که نیاز به دسترسی به فایل‌های باینری فروشنده دارند باید به پارتیشن vendor منتقل شوند و بنابراین، دیگر coredomain نباشند.

ویژگی‌های غیرقابل اعتماد

برنامه‌های غیرقابل اعتمادی که میزبان کد دلخواه هستند، نباید به سرویس‌های HwBinder دسترسی داشته باشند، مگر آن‌هایی که برای دسترسی از طریق چنین برنامه‌هایی به اندازه کافی امن در نظر گرفته شده‌اند (به سرویس‌های امن در زیر مراجعه کنید). دو دلیل اصلی برای این امر عبارتند از:

سرورهای HwBinder احراز هویت کلاینت را انجام نمی‌دهند زیرا HIDL در حال حاضر اطلاعات UID تماس‌گیرنده را افشا نمی‌کند. حتی اگر HIDL چنین داده‌هایی را افشا می‌کرد، بسیاری از سرویس‌های HwBinder یا در سطحی پایین‌تر از برنامه‌ها (مانند HALها) عمل می‌کردند یا نباید برای مجوز به هویت برنامه متکی باشند. بنابراین، برای حفظ امنیت، فرض پیش‌فرض این است که هر سرویس HwBinder با تمام کلاینت‌های خود به طور یکسان به عنوان افرادی که مجاز به انجام عملیات ارائه شده توسط سرویس هستند، رفتار می‌کند.
سرورهای HAL (زیرمجموعه‌ای از سرویس‌های HwBinder) حاوی کدی با نرخ بروز بالاتر مشکلات امنیتی نسبت به اجزای system/core هستند و به لایه‌های پایین‌تر پشته (تا سخت‌افزار) دسترسی دارند و در نتیجه فرصت‌های دور زدن مدل امنیتی اندروید را افزایش می‌دهند.

خدمات ایمن

خدمات ایمن شامل موارد زیر است:

same_process_hwservice . این سرویس‌ها (طبق تعریف) در فرآیند کلاینت اجرا می‌شوند و بنابراین دسترسی یکسانی با دامنه کلاینتی که فرآیند در آن اجرا می‌شود، دارند.
coredomain_hwservice . این سرویس‌ها خطرات مرتبط با دلیل شماره ۲ را ایجاد نمی‌کنند.
hal_configstore_ISurfaceFlingerConfigs . این سرویس به طور خاص برای استفاده توسط هر دامنه‌ای طراحی شده است.
hal_graphics_allocator_hwservice . این عملیات همچنین توسط سرویس surfaceflinger Binder ارائه می‌شود که برنامه‌ها مجاز به دسترسی به آن هستند.
hal_omx_hwservice . این یک نسخه HwBinder از سرویس mediacodec Binder است که برنامه‌ها مجاز به دسترسی به آن هستند.
hal_codec2_hwservice . این نسخه جدیدتری از hal_omx_hwservice است.

ویژگی‌های قابل استفاده

تمام hwservices که امن در نظر گرفته نمی‌شوند، دارای ویژگی untrusted_app_visible_hwservice هستند. سرورهای HAL مربوطه دارای ویژگی untrusted_app_visible_halserver هستند. دستگاه‌هایی که با اندروید ۹ راه‌اندازی می‌شوند، نباید از هیچ یک از ویژگی‌های untrusted استفاده کنند.

توصیه:

برنامه‌های غیرقابل اعتماد باید در عوض با یک سرویس سیستمی که با فروشنده HIDL HAL در ارتباط است، صحبت کنند. برای مثال، برنامه‌ها می‌توانند با binderservicedomain صحبت کنند، سپس mediaserver (که یک binderservicedomain است) به نوبه خود با hal_graphics_allocator صحبت می‌کند.
یا
برنامه‌هایی که نیاز به دسترسی مستقیم به HALهای vendor دارند، باید دامنه‌ی سیاست جداگانه‌ی تعریف‌شده توسط فروشنده‌ی خود را داشته باشند.

تست‌های ویژگی‌های فایل

اندروید ۹ شامل تست‌های زمان ساخت است که تضمین می‌کند همه فایل‌ها در مکان‌های خاص دارای ویژگی‌های مناسب هستند (مانند اینکه همه فایل‌های موجود در sysfs دارای ویژگی sysfs_type مورد نیاز هستند).

برچسب‌گذاری زمینه‌های SELinux

برای پشتیبانی از تمایز بین سیاست جداگانه پلتفرم و فروشنده، سیستم فایل‌های زمینه SELinux را به طور متفاوتی می‌سازد تا آنها را از هم جدا نگه دارد.

زمینه‌های فایل

اندروید ۸.۰ تغییرات زیر را برای file_contexts معرفی کرد:

برای جلوگیری از سربار کامپایل اضافی روی دستگاه هنگام بوت شدن، file_contexts دیگر به شکل دودویی وجود ندارند. در عوض، آنها به صورت فایل متنی عبارات منظم و قابل خواندن مانند {property, service}_contexts (همانطور که قبل از نسخه ۷.۰ بودند) هستند.
file_contexts بین دو فایل تقسیم شده است:
- plat_file_contexts
  - file_context پلتفرم اندروید که هیچ برچسب مخصوص دستگاه ندارد، به جز برچسب‌گذاری بخش‌هایی از پارتیشن /vendor که باید دقیقاً برچسب‌گذاری شوند تا عملکرد صحیح فایل‌های sepolicy تضمین شود.
  - باید در پارتیشن system در آدرس /system/etc/selinux/plat_file_contexts روی دستگاه قرار داشته باشد و توسط init در ابتدا به همراه vendor file_context بارگذاری شود.
- vendor_file_contexts
  - file_context مختص دستگاه که با ترکیب file_contexts موجود در دایرکتوری‌های مورد اشاره BOARD_SEPOLICY_DIRS در فایل‌های Boardconfig.mk دستگاه ساخته شده است.
  - باید در مسیر /vendor/etc/selinux/vendor_file_contexts در پارتیشن vendor نصب شود و توسط init در ابتدا به همراه file_context پلتفرم بارگذاری شود.

زمینه‌های مالکیت

در اندروید ۸.۰، property_contexts بین دو فایل تقسیم شده است:

plat_property_contexts
- property_context پلتفرم اندروید که هیچ برچسب مخصوص دستگاهی ندارد.
- باید در پارتیشن system در /system/etc/selinux/plat_property_contexts قرار داشته باشد و توسط init در ابتدا به همراه vendor property_contexts بارگذاری شود.
vendor_property_contexts
- property_context مختص دستگاه که با ترکیب property_contexts موجود در دایرکتوری‌های مورد اشاره BOARD_SEPOLICY_DIRS در فایل‌های Boardconfig.mk دستگاه ساخته شده است.
- باید در پارتیشن vendor در /vendor/etc/selinux/vendor_property_contexts قرار داشته باشد و در ابتدا به همراه property_context پلتفرم توسط init بارگذاری شود.

زمینه‌های خدمات

در اندروید ۸.۰، service_contexts بین فایل‌های زیر تقسیم شده است:

plat_service_contexts
- service_context مختص پلتفرم اندروید برای servicemanager . service_context هیچ برچسب مختص دستگاهی ندارد.
- باید در پارتیشن system در /system/etc/selinux/plat_service_contexts قرار داشته باشد و در ابتدا توسط servicemanager به همراه service_contexts فروشنده بارگذاری شود.
vendor_service_contexts
- service_context مختص دستگاه که با ترکیب service_contexts موجود در دایرکتوری‌های مورد اشاره BOARD_SEPOLICY_DIRS در فایل‌های Boardconfig.mk دستگاه ساخته شده است.
- باید در پارتیشن vendor در /vendor/etc/selinux/vendor_service_contexts قرار داشته باشد و در ابتدا به همراه service_contexts پلتفرم توسط servicemanager بارگذاری شود.
- اگرچه servicemanager در زمان بوت به دنبال این فایل می‌گردد، اما برای یک دستگاه کاملاً سازگار با TREBLE ، vendor_service_contexts نباید وجود داشته باشد. دلیل این امر این است که تمام تعاملات بین فرآیندهای vendor و system باید از طریق hwservicemanager / hwbinder انجام شود.
plat_hwservice_contexts
- پلتفرم اندروید hwservice_context برای hwservicemanager که هیچ برچسب مخصوص دستگاهی ندارد.
- باید در پارتیشن system در /system/etc/selinux/plat_hwservice_contexts قرار داشته باشد و در ابتدا به همراه vendor_hwservice_contexts توسط hwservicemanager بارگذاری شود.
vendor_hwservice_contexts
- hwservice_context مختص دستگاه که با ترکیب hwservice_contexts موجود در دایرکتوری‌های مورد اشاره BOARD_SEPOLICY_DIRS در فایل‌های Boardconfig.mk دستگاه ساخته شده است.
- باید در پارتیشن vendor در /vendor/etc/selinux/vendor_hwservice_contexts قرار داشته باشد و در ابتدا به همراه plat_service_contexts توسط hwservicemanager بارگذاری شود.
vndservice_contexts
- service_context مختص دستگاه برای vndservicemanager که با ترکیب vndservice_contexts موجود در دایرکتوری‌های مورد اشاره BOARD_SEPOLICY_DIRS در Boardconfig.mk دستگاه ساخته شده است.
- این فایل باید در پارتیشن vendor در مسیر /vendor/etc/selinux/vndservice_contexts قرار داشته باشد و در ابتدا توسط vndservicemanager بارگذاری شود.

زمینه‌های سی‌اپ

در اندروید ۸.۰، seapp_contexts بین دو فایل تقسیم شده است:

plat_seapp_contexts
- پلتفرم اندروید seapp_context که هیچ تغییر خاصی در دستگاه ندارد.
- باید در پارتیشن system در /system/etc/selinux/plat_seapp_contexts.
vendor_seapp_contexts
- افزونه‌ی مختص دستگاه برای پلتفرم seapp_context که با ترکیب seapp_contexts موجود در دایرکتوری‌های مورد اشاره BOARD_SEPOLICY_DIRS در فایل‌های Boardconfig.mk دستگاه ساخته شده است.
- باید در پارتیشن vendor در /vendor/etc/selinux/vendor_seapp_contexts قرار داشته باشد.

مجوزهای مک

در اندروید ۸.۰، فایل mac_permissions.xml بین دو فایل تقسیم شده است:

mac_permissions.xml پلتفرم
- فایل mac_permissions.xml پلتفرم اندروید که هیچ تغییر خاصی در دستگاه ندارد.
- باید در پارتیشن system در /system/etc/selinux/.
mac_permissions.xml غیر پلتفرمی
- افزونه‌ی مختص دستگاه به پلتفرم mac_permissions.xml که از mac_permissions.xml ساخته شده و در دایرکتوری‌هایی که BOARD_SEPOLICY_DIRS در فایل‌های Boardconfig.mk دستگاه به آنها اشاره می‌کند، یافت می‌شود.
- باید در پارتیشن vendor در /vendor/etc/selinux/.