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

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

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

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

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

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

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

علاوه بر تداخل برچسب‌ها، نام‌های نوع و ویژگی SELinux نیز می‌توانند با هم تداخل داشته باشند. SELinux اجازه تعریف چندگانه از انواع و ویژگی‌های یکسان را نمی‌دهد. سیاستی با تعریف‌های تکراری، کامپایل نمی‌شود. برای جلوگیری از تداخل نام نوع و ویژگی، اکیداً توصیه می‌شود که تمام تعریف‌های فروشنده با پیشوند vendor_ شروع شوند. به عنوان مثال، فروشندگان باید به جای 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 و غیره.

* برای مثال‌های بیشتر، به system/sepolicy/private/file_contexts مراجعه کنید.

در نتیجه، هنگام برچسب‌گذاری فایل‌های اضافی در پارتیشن 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 ، از پیاده‌سازی‌کنندگان دستگاه یا فروشندگان انتظار می‌رود:

1. فایل‌های نگاشت پایه تولید شده را از پارتیشن‌های ver system_ext و product به درخت منبع آنها کپی کنید.
2. در صورت نیاز، فایل‌های نقشه‌برداری را اصلاح کنید.
3. فایل‌های نگاشت را در پارتیشن‌های 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 . ویژگی برای همه دامنه‌های سیستم (به جز shell domains init و shell) که الزام عدم اجرای فایل‌های باینری فروشنده را نقض می‌کنند. اجرای فایل‌های باینری فروشنده دارای API ناپایدار است. پلتفرم نباید فایل‌های باینری فروشنده را مستقیماً اجرا کند. توصیه:
  • چنین وابستگی‌های پلتفرمی به فایل‌های باینری فروشنده باید پشت HALهای HIDL باشند.

    یا

  • coredomains که نیاز به دسترسی به فایل‌های باینری فروشنده دارند باید به پارتیشن vendor منتقل شوند و بنابراین، دیگر coredomain نباشند.

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

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

1. سرورهای HwBinder احراز هویت کلاینت را انجام نمی‌دهند زیرا HIDL در حال حاضر اطلاعات UID تماس‌گیرنده را افشا نمی‌کند. حتی اگر HIDL چنین داده‌هایی را افشا می‌کرد، بسیاری از سرویس‌های HwBinder یا در سطحی پایین‌تر از برنامه‌ها (مانند HALها) عمل می‌کردند یا نباید برای مجوز به هویت برنامه متکی باشند. بنابراین، برای حفظ امنیت، فرض پیش‌فرض این است که هر سرویس HwBinder با تمام کلاینت‌های خود به طور یکسان به عنوان افرادی که مجاز به انجام عملیات ارائه شده توسط سرویس هستند، رفتار می‌کند.
2. سرورهای 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/.

تغییرات حافظه مشترک برای اندروید ۱۷

با شروع از اندروید ۱۷، دستگاه‌هایی که با ویژگی‌های زیر راه‌اندازی می‌شوند، باید قابلیت خط‌مشی memfd_class را فعال کنند و خط‌مشی مربوط به حافظه مشترک خود را برای پشتیبانی از اشیاء کلاس memfd_file به‌روزرسانی کنند:

• رابط برنامه‌نویسی کاربردی فروشنده سطح 202604 یا بالاتر برای ارائه به فروشندگان و تولیدکنندگان اصلی تجهیزات (OEMs) تا بتوانند سیاست‌های فروشنده خود را برای پشتیبانی memfd به‌روزرسانی کنند. همچنین به دستگاه‌های موجود اجازه می‌دهد بدون نیاز به به‌روزرسانی پارتیشن فروشنده خود، به نسخه‌های بالاتر اندروید ارتقا دهند.
• کرنل android16-6.12 یا بالاتر، زیرا این کرنل‌ها از ویژگی memfd_class پشتیبانی می‌کنند که برای پیاده‌سازی سیاست دقیق برای memfd مورد نیاز است.

توجه: آزمایش‌های انطباق با VTS تأیید می‌کنند که قابلیت سیاست memfd_class در دستگاه‌هایی که الزامات قبلی را برآورده می‌کنند، فعال است.

قابلیت سیاست memfd_class را فعال کنید

تا همین اواخر، SELinux یک memfd به عنوان فایلی با همان نوع سیستم فایل پشتیبان خود - tmpfs - برچسب‌گذاری می‌کرد. این امر تشخیص یک memfd از فایل دیگر در tmpfs mount را از دیدگاه سیاست غیرممکن می‌کرد. اکنون، SELinux یک memfd را با زمینه امنیتی فرآیند تخصیص برچسب‌گذاری می‌کند و memfds به عنوان اشیاء کلاس memfd_file در نظر گرفته می‌شوند. این قابلیت توسط قابلیت سیاست memfd_class محافظت می‌شود تا سازگاری با محیط‌های فضای کاربری قدیمی‌تر حفظ شود.

برای فعال کردن قابلیت سیاست memfd_class ، یک فایل policy_capabilities در زیر BOARD_VENDOR_SEPOLICY_DIRS ایجاد کنید. این فایل باید شامل ورودی زیر باشد:

# $BOARD_VENDOR_SEPOLICY_DIRS/*/policy_capabilities
policycap memfd_class;

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

تأیید کنید که قابلیت سیاست memfd_class فعال شده است

برای بررسی وضعیت قابلیت سیاست memfd_class از دستور زیر استفاده کنید:

adb shell 'cat /sys/fs/selinux/policy_capabilities/memfd_class'

اگر نتیجه 1 باشد، قابلیت سیاست memfd_class فعال است. در غیر این صورت، فعال نیست.

انتقال سیاست موجود به memfd

برخی از فرآیندها از ماکروی tmpfs_domain() در سیاست خود برای دسترسی و نام‌گذاری memfds خود استفاده می‌کردند، برای مثال:

# foo.te
tmpfs_domain(foo)

این به این ترجمه می‌شود:

# foo.te
type_transition foo tmpfs:file foo_tmpfs;
allow foo foo_tmpfs:file { read write getattr map };

و اجازه دهید process bar به process foo مربوط به memfds به این صورت دسترسی پیدا کند:

# bar.te
allow bar foo_tmpfs:file { read write getattr map };

با فعال شدن قابلیت سیاست memfd_class ، دیگر نیازی به ماکروی tmpfs_domain() نیست، زیرا سیاست پلتفرم به‌روزرسانی شده است تا به هر فرآیندی اجازه دهد memfds خود را ایجاد و استفاده کند، همانطور که در اینجا مشاهده می‌شود:

# system/sepolicy/private/domain.te
allow domain self:memfd_file { create read write getattr map };

و memfds ایجاد شده توسط process foo به این صورت توسط process bar قابل دسترسی هستند:

# bar.te
allow bar foo:memfd_file { read write getattr map };

سیاست پلتفرم به‌روزرسانی شده است تا کاربردهای فعلی memfd را در نظر بگیرد. با این حال، سیاست خاص فروشنده و دستگاه که از برچسب‌های tmpfs استفاده می‌کند، باید برای استفاده memfd_file به‌روزرسانی شود. اگر این سیاست بین SoCها یا دستگاه‌هایی که API سطح 202604 فروشنده یا بالاتر ندارند، به اشتراک گذاشته شود، توصیه می‌شود که سیاست قدیمی tmpfs در کنار سیاست جدید memfd_file برای سازگاری حفظ شود.

شناسایی انکارهای AVC مربوط به memfd

با استفاده از دستور زیر می‌توان رد درخواست‌های مربوط به Memfd را بازیابی کرد:

adb shell logcat -d -b events | grep memfd

انکارهای avc با هدف tmpfs

مثال زیر یک انسداد avc را نشان می‌دهد که توسط فرآیندی که سعی در نوشتن در یک memfd داشته و مجوز نوشتن در آن را نداشته، با آن مواجه شده است:

audit(0.0:539): avc:  denied  { write } for  comm="binder:665_1" name="memfd:MessageQueue"
dev="tmpfs" ino=8324 scontext=u:r:mediacodec:s0 tcontext=u:object_r:tmpfs:s0 tclass=file
permissive=0

وقتی قابلیت سیاست memfd_class فعال باشد، زمینه هدف یک memfd ، زمینه امنیتی فرآیند تخصیص‌دهنده است، نه tmpfs ، و کلاس هدف memfd_file است، نه file . بنابراین، اگر شاهد انکارهای avc مربوط به memfd هستید، که در آن memfd مورد نظر به عنوان یک فایل tmpfs برچسب‌گذاری شده است، قابلیت سیاست memfd_class فعال نیست.

انکارهای avc با memfd_file به عنوان کلاس هدف

مثال زیر یک رد درخواست avc را نشان می‌دهد که توسط فرآیندی که سعی در نوشتن در یک memfd که مجوز نوشتن در آن را نداشته است، و قابلیت سیاست memfd_class فعال بوده است، با آن مواجه شده است، و همچنین یک خط اضافی که logd پس از رد درخواست با همان مهر زمانی منتشر می‌کند:

audit(0.0:86): avc: denied { read } for
path=2F6D656D66643A4D6564696142756666657247726F7570202864656C6574656429 ino=512 dev=""
scontext=u:r:mediaserver:s0 tcontext=u:object_r:mediaextractor:s0 tclass=memfd_file

auditd  : Decoded path for audit(0.0:86): /memfd:MediaBufferGroup (deleted)

مهر زمانی منطبق نشان می‌دهد که Decoded path for … log مربوط به انکار avc با مهر زمانی 0.0.86 است. این لاگ رشته هگزادسیمال را از مقدار مسیر در انکار avc رمزگشایی می‌کند و نام ناحیه حافظه memfd را ارائه می‌دهد که می‌تواند برای درک اینکه کدام بافر به اشتراک گذاشته شده است مفید باشد. زمینه منبع و زمینه هدف برای درک اینکه چه فرآیندهایی نیاز به اشتراک گذاری حافظه دارند مفید هستند. از مثال قبلی، مشخص است که فرآیند mediaserver باید بتواند به memfds مربوط به mediaextractor دسترسی داشته باشد. بنابراین، سیاست مناسب عبارت است از:

# mediaserver.te
allow mediaserver mediaextractor:memfd_file { getattr read write map };

به‌روزرسانی‌های دامنه امنیتی در اندروید ۱۷

رابط برنامه‌نویسی کاربردی (API ASharedMemory_create() در اندروید ۱۷، منطق شرطی را برای انتخاب بین درایور قدیمی ashmem و چارچوب memfd برای تخصیص حافظه مشترک پیاده‌سازی می‌کند.

برای دستگاه‌هایی که الزامات memfd را برآورده می‌کنند (سطح API فروشنده 202604 یا بالاتر و هسته android16-6.12 یا جدیدتر)، API targetSdkVersion ) برنامه فراخوانی را ارزیابی می‌کند. اگر نسخه SDK هدف 37 یا بالاتر باشد، یک memfd اختصاص داده می‌شود. این به توسعه‌دهندگان اجازه می‌دهد تا مشکلاتی را که هنگام ارتقاء نسخه SDK هدف خود با آنها مواجه می‌شوند، برطرف کنند.

اگر دستگاه پیش‌نیازهای memfd's نداشته باشد، ASharedMemory به ashmem برمی‌گردد. این کار سازگاری را برای دستگاه‌های ارتقا یافته با پارتیشن‌ها یا هسته‌های قدیمی‌تر حفظ می‌کند.

برای اجرای این انتقال، سیاست SELinux پلتفرم، برنامه‌هایی را که SDK نسخه ۳۷ یا بالاتر را در دامنه‌های امنیتی platform_app ، priv_app و untrusted_app هدف قرار می‌دهند، از باز کردن /dev/ashmem و فراخوانی دستورات ashmem ioctl در memfd منع می‌کند. این امر با تقسیم این دامنه‌های برنامه بر اساس نسخه SDK هدف محقق می‌شود. این امر دامنه‌های امنیتی platform_app_36 ، priv_app_36 و untrusted_app_34 را معرفی می‌کند که به همراه سایر دامنه‌های برنامه، مجوزهای باز ashmem و امکان فراخوانی دستورات ashmem ioctl در memfds را حفظ می‌کنند.

In a future Android release, the set of apps that retain permissions to open the ashmem device and invoke ashmem ioctl commands on memfds are reduced to just platform_app_36 , priv_app_36 , and untrusted_app_34 and untrusted app domains for older SDK versions.

سیاست‌های سفارشی SELinux فروشنده یا تولیدکننده اصلی برای برنامه‌هایی که نسخه SDK هدف خود را پین می‌کنند، باید به‌روزرسانی شوند تا با این تغییرات دامنه هماهنگ شوند، همانطور که در بخش‌های بعدی به تفصیل توضیح داده شده است.

به‌روزرسانی‌های دامنه SELinux برای platform_app

دامنه platform_app بر اساس targetSdkVersion برنامه تقسیم می‌شود. برنامه‌های پلتفرمی که SDK نسخه ۳۷ یا بالاتر را هدف قرار می‌دهند، دامنه platform_app به آنها اختصاص داده می‌شود، در حالی که برنامه‌هایی که SDK نسخه ۳۶ یا پایین‌تر را هدف قرار می‌دهند، platform_app_36 استفاده می‌کنند. دامنه platform_app_36 قابلیت باز کردن /dev/ashmem را برای سازگاری معکوس حفظ می‌کند. برای ساده‌سازی مدیریت سیاست‌ها در هر دو دامنه، از ویژگی platform_app_all استفاده کنید.

حالتی را در نظر بگیرید که برنامه‌ی پلتفرم sample-plat-app نیاز به خواندن و نوشتن از و به /dev/foo_device داشته باشد. سیاست SELinux فروشنده‌ی موجود ممکن است به این شکل باشد:

# This will only allow sample-plat-app to access the device if it
# is placed in the platform_app domain (i.e. target SDK version is 37 or higher).
allow platform_app foo_device:chr_file rw_file_perms;

با این حال، اگر sample-plat-app به SDK نسخه ۳۶ هدف پین شده باشد، در دامنه platform_app_36 قرار می‌گیرد و سیاست SELinux قبلی اعمال نخواهد شد و خطای عدم پذیرش AVC زیر مشاهده می‌شود:

auditd  : type=1400 audit(0.0:11): avc:  denied  { read write } for  comm="sample-plat-app" path="/dev/foo_device" dev="tmpfs" ino=1609 scontext=u:r:platform_app_36:s0:c512,c768 tcontext=u:object_r:foo_device:s0 tclass=chr_file permissive=0

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

# This allows sample-plat-app to access the device independent of
# target SDK version.
allow platform_app_all foo_device:chr_file rw_file_perms;

ممکن است موقعیت‌هایی وجود داشته باشد که در آن‌ها platform_app_all کار نکند. برای مثال، اگر ماکروی hal_client_domain() با platform_app_all استفاده شود، این سیاست کامپایل نمی‌شود. دلیل این امر این است که platform_app_all یک ویژگی است و hal_client_domain() سعی می‌کند ویژگی دیگری را به آن اضافه کند، که این امر امکان‌پذیر نیست:

# platform_app.te
hal_client_domain(platform_app, hal_foo)

در این سناریوها، لازم است مستقیماً از نوع platform_app_36 استفاده شود، بنابراین خط‌مشی شما محتوای زیر را دارد:

# platform_app.te
hal_client_domain(platform_app, hal_foo)

# platform_app_36.te
hal_client_domain(platform_app_36, hal_foo)

به‌روزرسانی‌های دامنه SELinux با priv_app

دامنه priv_app بر اساس targetSdkVersion برنامه تقسیم می‌شود. برنامه‌های ممتاز که SDK نسخه ۳۷ یا بالاتر را هدف قرار می‌دهند، دامنه priv_app به آنها اختصاص داده می‌شود، در حالی که برنامه‌هایی که SDK نسخه ۳۶ یا پایین‌تر را هدف قرار می‌دهند، priv_app_36 استفاده می‌کنند. دامنه priv_app_36 قابلیت باز کردن /dev/ashmem را برای سازگاری معکوس حفظ می‌کند. برای ساده‌سازی مدیریت سیاست‌ها در هر دو دامنه، از ویژگی priv_app_all استفاده کنید.

حالتی را در نظر بگیرید که برنامه‌ی پلتفرم sample-priv-app نیاز به خواندن و نوشتن از و به /dev/foo_device داشته باشد. سیاست SELinux فروشنده‌ی موجود ممکن است به این شکل باشد:

# This will only allow sample-priv-app to access the device if it
# is placed in the priv_app domain (i.e. target SDK version is 37 or higher).
allow priv_app foo_device:chr_file rw_file_perms;

با این حال، اگر sample-priv-app در SDK نسخه ۳۶ هدف پین شده باشد، در دامنه priv_app_36 قرار می‌گیرد و سیاست SELinux قبلی اعمال نخواهد شد و رد AVC زیر مشاهده می‌شود:

auditd  : type=1400 audit(0.0:11): avc:  denied  { read write } for  comm="sample-priv-app" path="/dev/foo_device" dev="tmpfs" ino=1609 scontext=u:r:priv_app_36:s0:c512,c768 tcontext=u:object_r:foo_device:s0 tclass=chr_file permissive=0

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

# This allows sample-priv-app to access the device independent of
# target SDK version.
allow priv_app_all foo_device:chr_file rw_file_perms;

ممکن است موقعیت‌هایی وجود داشته باشد که priv_app_all کار نکند. برای مثال، اگر ماکروی hal_client_domain() با priv_app_all استفاده شود، این سیاست کامپایل نخواهد شد. دلیل این امر این است که priv_app_all یک ویژگی است و hal_client_domain() سعی می‌کند ویژگی دیگری را به آن اضافه کند، که این امر امکان‌پذیر نیست:

# priv_app.te
hal_client_domain(priv_app, hal_foo)

In those scenarios, it is required to use the priv_app_36 type directly, so your policy files will look something like this:

# priv_app.te
hal_client_domain(priv_app, hal_foo)

# priv_app_36.te
hal_client_domain(priv_app_36, hal_foo)

untrusted_app SELinux domain updates

The untrusted_app domain is split based on the app's targetSdkVersion . Untrusted apps targeting SDK 37 version or higher are assigned the untrusted_app domain, while those targeting SDK versions 34-36 inclusive are assigned the new untrusted_app_34 domain. The untrusted_app_34 domain, as well as the untrusted_app_X domains, where `X` is an older target SDK version, retain the ability to open `/dev/ashmem` for backward compatibility.