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

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

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

این صفحه توضیح می‌دهد که Android چگونه مشکلات سازگاری خط‌مشی را با به‌روزرسانی‌های فرا-هوای پلتفرم (OTA) مدیریت می‌کند، جایی که تنظیمات SELinux پلتفرم جدید ممکن است با تنظیمات SELinux فروشنده قدیمی متفاوت باشد.

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

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

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

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

فاصله نام تایپ/ویژگی

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

مالکیت فایل

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

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

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

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

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

/مسیر فروشنده	برچسب ارائه شده توسط پلتفرم	فرآیندهای پلت فرم بسته به برچسب
`/vendor(/. * )?`	`vendor_file`	همه کلاینت های HAL در فریم ورک، `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_file_type داشته باشند. این از طریق neverallows اجرا می شود.
برای جلوگیری از درگیری با به‌روزرسانی‌های پلتفرم/چارچوب آینده، از برچسب‌گذاری فایل‌های غیر از exec_types در پارتیشن vendor خودداری کنید.
همه وابستگی‌های کتابخانه برای HAL‌های فرآیندی شناسایی‌شده توسط AOSP باید به‌عنوان same_process_hal_file.

Procfs (/proc)

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

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

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

Debugfs می توان هم در file_contexts و هم genfscon برچسب گذاری کرد. در اندروید 7.0 تا اندروید 10، هم پلتفرم و هم برچسب فروشنده debugfs .

در اندروید 11، debugfs قابل دسترسی نیست یا روی دستگاه های تولیدی نصب می شود. سازندگان دستگاه باید debugfs حذف کنند.

Tracefs (/sys/kernel/debug/tracing)

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

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

Sysfs (/sys)

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

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

tmpfs (/dev)

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

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

Rootfs (/)

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

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

داده (/داده)

داده ها از طریق ترکیبی از 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 سطح 202404، گره /sys/class/udc به طور پیش‌فرض برچسب sysfs دارد.
با شروع API فروشنده 202504، /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 labels استفاده کند.

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

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

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

به عنوان مثال، یک نوع vendor_init که فرآیند init را در زمینه فروشنده نشان می‌دهد، تحت 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

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

برای مثال، فرض کنید که /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/etc/selinux/mapping/202504.cil نصب می شود system پارتیشن ها در ابتدا، این فایل نگاشت حاوی نگاشت هویت است، همانطور که قبلا توضیح داده شد. اگر یک برچسب جدید 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 قرار گیرد تا بیان شود که هیچ نوع منطبقی با نوع vendor قبلی وجود ندارد.

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

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

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

از Android 11، پارتیشن‌های system_ext و product مجازند انواع عمومی تعیین‌شده خود را به پارتیشن 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 با ویژگی نسخه شده type_ ver دسترسی داشته باشد.

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

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

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

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

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

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

تغییرات ویژگی برای اندروید 9

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

صفات ناقض

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

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

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

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

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

خدمات ایمن

خدمات ایمن عبارتند از:

same_process_hwservice . این سرویس‌ها (طبق تعریف) در فرآیند مشتری اجرا می‌شوند و بنابراین دسترسی یکسانی به دامنه مشتری دارند که فرآیند در آن اجرا می‌شود.
coredomain_hwservice . این خدمات خطرات مرتبط با دلیل شماره 2 را ایجاد نمی کنند.
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 هستند. دستگاه‌هایی که با Android 9 راه‌اندازی می‌شوند نباید از هیچ یک از ویژگی‌های untrusted استفاده کنند.

توصیه:

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

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

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

برچسب زدن زمینه های SELinux

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

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

اندروید 8.0 تغییرات زیر را برای file_contexts ارائه کرد:

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

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

در اندروید 8.0، property_contexts بین دو فایل تقسیم می‌شود:

plat_property_contexts
- property_context پلتفرم Android که برچسب مخصوص دستگاه ندارد.
- باید در پارتیشن 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 قرار داشته باشد و در ابتدا توسط init به همراه property_context پلت فرم بارگذاری شود.

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

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

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

زمینه های Seapp

در اندروید 8.0، seapp_contexts بین دو فایل تقسیم می‌شود:

plat_seapp_contexts
- پلتفرم Android 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

در اندروید 8.0، mac_permissions.xml بین دو فایل تقسیم می‌شود:

پلتفرم mac_permissions.xml
- پلتفرم Android 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/.