Kompatibilitas kebijakan

Halaman ini menjelaskan cara Android menangani masalah kompatibilitas kebijakan dengan update over-the-air (OTA) platform, yang mana setelan SELinux platform baru mungkin berbeda dengan setelan SELinux vendor lama.

Kepemilikan dan pelabelan objek

Kepemilikan harus ditentukan dengan jelas untuk setiap objek agar kebijakan platform dan vendor tetap terpisah. Misalnya, jika label kebijakan vendor /dev/foo dan label kebijakan platform /dev/foo dalam OTA berikutnya, akan ada perilaku yang tidak ditentukan seperti penolakan yang tidak terduga, atau yang lebih parah, kegagalan booting. Untuk SELinux, hal ini muncul sebagai konflik pemberian label. Node perangkat hanya dapat memiliki satu label yang diselesaikan ke label mana pun yang diterapkan terakhir. Akibatnya:

  • Proses yang memerlukan akses ke label yang gagal diterapkan akan kehilangan akses ke resource.
  • Proses yang mendapatkan akses ke file dapat terganggu karena node perangkat yang salah dibuat.

Konflik antara label platform dan vendor dapat terjadi untuk objek apa pun yang memiliki label SELinux, termasuk properti, layanan, proses, file, dan soket. Untuk menghindari masalah ini, tentukan kepemilikan objek ini dengan jelas.

Namespace jenis/atribut

Selain konflik label, nama atribut dan jenis SELinux juga dapat berkonflik. SELinux tidak mengizinkan beberapa deklarasi jenis dan atribut yang sama. Kebijakan dengan pernyataan duplikat gagal dikompilasi. Untuk menghindari bentrokan nama atribut dan jenis, sebaiknya semua deklarasi vendor dimulai dengan awalan vendor_. Misalnya, vendor harus menggunakan type vendor_foo, domain;, bukan type foo, domain;.

Kepemilikan file

Mencegah tabrakan untuk file merupakan hal yang sulit karena kebijakan platform dan vendor umumnya memberikan label untuk semua sistem file. Tidak seperti penamaan jenis, pemberian namespace pada file tidak praktis karena banyak di antaranya dibuat oleh kernel. Untuk mencegah tabrakan ini, ikuti panduan penamaan untuk sistem file di bagian ini. Untuk Android 8.0, ini adalah rekomendasi tanpa penerapan teknis. Ke depannya, rekomendasi ini akan diterapkan oleh Vendor Test Suite (VTS).

Sistem (/system)

Hanya image sistem yang harus memberikan label untuk komponen /system melalui file_contexts, service_contexts, dll. Jika label untuk komponen /system ditambahkan dalam kebijakan vendor, update OTA khusus framework mungkin tidak dapat dilakukan.

Vendor (/vendor)

Kebijakan SELinux AOSP telah memberi label pada bagian partisi vendor yang berinteraksi dengan platform, sehingga memungkinkan penulisan aturan SELinux untuk proses platform agar dapat berkomunikasi atau mengakses bagian partisi vendor. Contoh:

/vendor path Label yang disediakan platform Proses platform bergantung pada label
/vendor(/.*)? vendor_file Semua klien HAL dalam framework, ueventd, dll.
/vendor/framework(/.*)? vendor_framework_file dex2oat, appdomain, dll.
/vendor/app(/.*)? vendor_app_file dex2oat, installd, idmap, dll.
/vendor/overlay(/.*) vendor_overlay_file system_server, zygote, idmap, dll.

Oleh karena itu, aturan khusus harus diikuti (diterapkan melalui neverallows) saat memberi label pada file tambahan di partisi vendor:

  • vendor_file harus menjadi label default untuk semua file di partisi vendor. Kebijakan platform mewajibkan hal ini untuk mengakses implementasi HAL teruskan.
  • Semua exec_types baru yang ditambahkan di partisi vendor melalui kebijakan vendor harus memiliki atribut vendor_file_type. Hal ini diterapkan melalui neverallows.
  • Untuk menghindari konflik dengan update platform/framework pada masa mendatang, hindari memberi label pada file selain exec_types di partisi vendor.
  • Semua dependensi library untuk HAL proses yang sama yang diidentifikasi AOSP harus diberi label sebagai same_process_hal_file.

Procfs (/proc)

File dalam /proc hanya dapat diberi label menggunakan label genfscon. Di Android 7.0, kebijakan platform dan vendor menggunakan genfscon untuk memberi label pada file di procfs.

Rekomendasi: Hanya label kebijakan platform /proc. Jika proses vendor memerlukan akses ke file di /proc yang saat ini diberi label default (proc), kebijakan vendor tidak boleh memberi label secara eksplisit dan harus menggunakan jenis proc generik untuk menambahkan aturan bagi domain vendor. Hal ini memungkinkan update platform mengakomodasi antarmuka kernel mendatang yang diekspos melalui procfs dan melabelinya secara eksplisit sesuai kebutuhan.

Debugfs (/sys/kernel/debug)

Debugfs dapat diberi label di file_contexts dan genfscon. Di Android 7.0 hingga Android 10, label platform dan vendor debugfs.

Di Android 11, debugfs tidak dapat diakses atau di-mount di perangkat produksi. Produsen perangkat harus menghapus debugfs.

Tracefs (/sys/kernel/debug/tracing)

Tracefs dapat diberi label di file_contexts dan genfscon. Di Android 7.0, hanya label platform tracefs.

Rekomendasi: Hanya platform yang dapat memberi label tracefs.

Sysfs (/sys)

File di /sys dapat diberi label menggunakan file_contexts dan genfscon. Di Android 7.0, platform dan vendor menggunakan genfscon untuk memberi label pada file di sysfs.

Rekomendasi: Platform dapat memberi label pada node sysfs yang tidak spesifik untuk perangkat. Jika tidak, hanya vendor yang dapat memberi label pada file.

tmpfs (/dev)

File di /dev dapat diberi label di file_contexts. Di Android 7.0, file label platform dan vendor ada di sini.

Rekomendasi: Vendor hanya dapat memberi label pada file di /dev/vendor (misalnya, /dev/vendor/foo, /dev/vendor/socket/bar).

Rootfs (/)

File di / dapat diberi label di file_contexts. Di Android 7.0, file label platform dan vendor ada di sini.

Rekomendasi: Hanya sistem yang dapat memberi label pada file di /.

Data (/data)

Data diberi label melalui kombinasi file_contexts dan seapp_contexts.

Rekomendasi: Jangan izinkan pemberian label vendor di luar /data/vendor. Hanya platform yang dapat memberi label pada bagian lain dari /data.

Versi label Genfs

Mulai dari level API vendor 202504, label SELinux baru yang ditetapkan dengan genfscon di system/sepolicy/compat/plat_sepolicy_genfs_ver.cil bersifat opsional untuk partisi vendor yang lebih lama. Hal ini memungkinkan partisi vendor yang lebih lama mempertahankan penerapan SEPolicy yang ada. Hal ini dikontrol oleh variabel Makefile BOARD_GENFS_LABELS_VERSION yang disimpan di /vendor/etc/selinux/genfs_labels_version.txt.

Contoh:

  • Di level API vendor 202404, node /sys/class/udc diberi label sysfs secara default.
  • Mulai dari level API vendor 202504, /sys/class/udc diberi label sysfs_udc.

Namun, /sys/class/udc mungkin digunakan oleh partisi vendor yang menggunakan level API 202404, baik dengan label sysfs default maupun label khusus vendor. Memberi label /sys/class/udc sebagai sysfs_udc tanpa syarat dapat merusak kompatibilitas dengan partisi vendor ini. Dengan mencentang BOARD_GENFS_LABELS_VERSION, platform akan terus menggunakan label dan izin sebelumnya untuk partisi vendor yang lebih lama.

BOARD_GENFS_LABELS_VERSION dapat lebih besar dari atau sama dengan level API vendor. Misalnya, partisi vendor yang menggunakan level API 202404 dapat menetapkan BOARD_GENFS_LABELS_VERSION ke 202504 untuk menerapkan label baru yang diperkenalkan pada 202504. Lihat daftar label genfs khusus 202504.

Saat memberi label pada node genfscon, platform harus mempertimbangkan partisi vendor yang lebih lama dan menerapkan mekanisme penggantian untuk kompatibilitas jika diperlukan. Platform dapat menggunakan library khusus platform untuk membuat kueri versi label genfs.

Kebijakan publik platform

Kebijakan SELinux platform dibagi menjadi pribadi dan publik. Kebijakan platform-public terdiri dari jenis dan atribut yang selalu tersedia untuk tingkat API vendor, yang bertindak sebagai API antara platform dan vendor. Kebijakan ini diekspos ke penulis kebijakan vendor agar vendor dapat membuat file kebijakan vendor, yang jika digabungkan dengan kebijakan khusus platform, akan menghasilkan kebijakan yang berfungsi penuh untuk perangkat. Kebijakan platform-public ditentukan di system/sepolicy/public.

Misalnya, jenis vendor_init, yang merepresentasikan proses inisialisasi dalam konteks vendor, ditentukan di bagian system/sepolicy/public/vendor_init.te: 

type vendor_init, domain;

Vendor dapat merujuk ke jenis vendor_init untuk menulis aturan kebijakan kustom: 

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

Atribut kompatibilitas

Kebijakan SELinux adalah interaksi antara jenis sumber dan target untuk izin dan class objek tertentu. Setiap objek (misalnya, proses, file) yang terpengaruh oleh kebijakan SELinux hanya dapat memiliki satu jenis, tetapi jenis tersebut mungkin memiliki beberapa atribut.

Kebijakan ini sebagian besar ditulis dalam istilah jenis yang ada. Di sini, vendor_init dan debugfs adalah jenis: 

allow vendor_init debugfs:dir { mounton };

Hal ini berfungsi karena kebijakan ditulis dengan pengetahuan tentang semua jenis. Namun, jika kebijakan vendor dan kebijakan platform menggunakan jenis tertentu, dan label objek tertentu berubah hanya dalam salah satu kebijakan tersebut, kebijakan lainnya mungkin berisi kebijakan yang sebelumnya memperoleh atau kehilangan akses yang diandalkan. Misalnya, anggaplah bahwa kebijakan platform melabeli node sysfs sebagai sysfs: 

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

Kebijakan vendor memberikan akses ke /sys/usb, yang diberi label sebagai sysfs: 

allow vendor_init sysfs:chr_file rw_file_perms;

Jika kebijakan platform diubah untuk memberi label /sys/usb sebagai sysfs_usb, kebijakan vendor tetap sama, tetapi vendor_init kehilangan akses ke /sys/usb karena tidak ada kebijakan untuk jenis sysfs_usb baru: 

/sys/usb u:object_r:sysfs_usb:s0

Untuk mengatasi masalah ini, Android memperkenalkan konsep atribut berversi. Pada waktu kompilasi, sistem build secara otomatis menerjemahkan jenis publik platform yang digunakan dalam kebijakan vendor ke dalam atribut berversi ini. Terjemahan ini diaktifkan dengan memetakan file yang mengaitkan atribut berversi dengan satu atau beberapa jenis publik dari platform.

Misalnya, anggap /sys/usb diberi label sebagai sysfs dalam kebijakan platform 202504, dan kebijakan vendor 202504 memberikan vendor_init akses ke /sys/usb. Dalam hal ini:

  • Kebijakan vendor menulis aturan allow vendor_init sysfs:chr_file rw_file_perms;, karena /sys/usb diberi label sebagai sysfs dalam kebijakan platform 202504. Saat sistem build mengompilasi kebijakan vendor, sistem akan otomatis menerjemahkan aturan ke allow vendor_init_202504 sysfs_202504:chr_file rw_file_perms;. Atribut vendor_init_202504 dan sysfs_202504 sesuai dengan jenis vendor_init dan sysfs, yang merupakan jenis yang ditentukan oleh platform.
  • Sistem build menghasilkan file pemetaan identitas /system/etc/selinux/mapping/202504.cil. Karena partisi system dan vendor menggunakan versi 202504 yang sama, file pemetaan berisi pemetaan identitas dari type_202504 ke type. Misalnya, vendor_init_202504 dipetakan ke vendor_init, dan sysfs_202504 dipetakan ke sysfs: 
    (typeattributeset sysfs_202504 (sysfs))
(typeattributeset vendor_init_202504 (vendor_init))
...

Saat versi diubah dari 202504 menjadi 202604, file pemetaan baru untuk partisi vendor 202504 dibuat di system/sepolicy/private/compat/202504/202504.cil, yang diinstal ke /system/etc/selinux/mapping/202504.cil untuk partisi system 202604 atau yang lebih baru. Awalnya, file pemetaan ini berisi pemetaan identitas, seperti yang dijelaskan sebelumnya. Jika label baru sysfs_usb untuk /sys/usb ditambahkan ke kebijakan platform 202604, file pemetaan diperbarui untuk memetakan sysfs_202504 ke sysfs_usb: 

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

Dengan update ini, aturan kebijakan vendor yang dikonversi allow vendor_init_202504 sysfs_202504:chr_file rw_file_perms; dapat otomatis memberikan akses vendor_init ke jenis sysfs_usb baru.

Untuk mempertahankan kompatibilitas dengan partisi vendor yang lebih lama, setiap kali jenis publik baru ditambahkan, jenis tersebut harus dipetakan ke setidaknya salah satu atribut versi dalam file pemetaan system/sepolicy/private/compat/ver/ver.cil, atau dicantumkan di bagian system/sepolicy/private/compat/ver/ver.ignore.cil untuk menyatakan bahwa tidak ada jenis yang cocok dalam versi vendor sebelumnya.

Kombinasi kebijakan platform, kebijakan vendor, dan file pemetaan memungkinkan sistem melakukan update tanpa mengupdate kebijakan vendor. Selain itu, konversi ke atribut berversi terjadi secara otomatis, sehingga kebijakan vendor tidak perlu menangani pembuatan versi, tetap menggunakan jenis publik apa adanya.

Kebijakan publik dan produk publik system_ext

Mulai Android 11, partisi system_ext dan product diizinkan untuk mengekspor jenis publik yang ditetapkan ke partisi vendor. Seperti kebijakan publik platform, kebijakan vendor menggunakan jenis dan aturan yang otomatis diterjemahkan ke dalam atribut versi, misalnya, dari type menjadi type_ver, dengan ver adalah tingkat API vendor partisi vendor.

Jika partisi system_ext dan product didasarkan pada versi platform ver yang sama, sistem build akan menghasilkan file pemetaan dasar ke system_ext/etc/selinux/mapping/ver.cil dan product/etc/selinux/mapping/ver.cil, yang berisi pemetaan identitas dari type ke type_ver. Kebijakan vendor dapat mengakses type dengan atribut berversi type_ver.

Jika hanya partisi system_ext dan product yang diupdate, misalnya ver ke ver+1 (atau yang lebih baru), sementara partisi vendor tetap di ver, kebijakan vendor mungkin kehilangan akses ke jenis partisi system_ext dan product. Untuk mencegah kerusakan, partisi system_ext dan product harus menyediakan file pemetaan dari jenis konkret ke atribut type_ver. Setiap partner bertanggung jawab untuk memelihara file pemetaan, jika mereka mendukung partisi ver vendor dengan partisi ver+1 (atau yang lebih baru) system_ext dan product.

Untuk menginstal file pemetaan ke partisi system_ext dan product, pelaksana atau vendor perangkat diharapkan untuk:

  1. Salin file pemetaan dasar yang dihasilkan dari partisi ver system_ext dan product ke pohon sumbernya.
  2. Ubah file pemetaan sesuai kebutuhan.
  3. Instal file pemetaan ke partisi ver+1 (atau yang lebih baru) system_ext dan product.

Misalnya, partisi 202504 system_ext memiliki satu jenis publik bernama foo_type. Kemudian system_ext/etc/selinux/mapping/202504.cil di partisi 202504 system_ext akan terlihat seperti ini: 

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

Jika bar_type ditambahkan ke system_ext 202604, dan jika bar_type harus dipetakan ke foo_type untuk partisi vendor 202504, 202504.cil dapat diupdate dari (typeattributeset foo_type_202504 (foo_type)) ke (typeattributeset foo_type_202504 (foo_type bar_type)) lalu diinstal ke partisi system_ext 202604. Partisi 202504 vendor dapat terus mengakses foo_type dan bar_type 202604 system_ext.

Perubahan atribut untuk Android 9

Perangkat yang diupgrade ke Android 9 dapat menggunakan atribut berikut, tetapi perangkat yang diluncurkan dengan Android 9 tidak boleh.

Atribut pelanggar

Android 9 menyertakan atribut terkait domain berikut:

  • data_between_core_and_vendor_violators. Atribut untuk semua domain yang melanggar persyaratan untuk tidak membagikan file menurut jalur antara vendor dan coredomains. Proses platform dan vendor tidak boleh menggunakan file di disk untuk berkomunikasi (ABI tidak stabil). Rekomendasi:
    • Kode vendor harus menggunakan /data/vendor.
    • Sistem tidak boleh menggunakan /data/vendor.
  • Atribut system_executes_vendor_violators. untuk semua domain sistem (kecuali init dan shell domains) yang melanggar persyaratan untuk tidak mengeksekusi biner vendor. Eksekusi biner vendor memiliki API yang tidak stabil. Platform tidak boleh menjalankan biner vendor secara langsung. Rekomendasi:
    • Dependensi platform tersebut pada biner vendor harus berada di belakang HAL HIDL.

      ATAU

    • coredomains yang memerlukan akses ke biner vendor harus dipindahkan ke partisi vendor dan dengan demikian, berhenti menjadi coredomain.

Atribut tidak tepercaya

Aplikasi tidak tepercaya yang menghosting kode arbitrer tidak boleh memiliki akses ke layanan HwBinder, kecuali yang dianggap cukup aman untuk diakses dari aplikasi tersebut (lihat layanan aman di bawah). Dua alasan utama untuk hal ini adalah:

  1. Server HwBinder tidak melakukan autentikasi klien karena saat ini HIDL tidak mengekspos informasi UID pemanggil. Meskipun HIDL mengekspos data tersebut, banyak layanan HwBinder beroperasi di tingkat yang lebih rendah daripada aplikasi (seperti, HAL) atau tidak boleh mengandalkan identitas aplikasi untuk otorisasi. Oleh karena itu, agar aman, asumsi defaultnya adalah bahwa setiap layanan HwBinder memperlakukan semua kliennya sebagai memiliki otorisasi yang sama untuk melakukan operasi yang ditawarkan oleh layanan.
  2. Server HAL (subset layanan HwBinder) berisi kode dengan tingkat insiden masalah keamanan yang lebih tinggi daripada komponen system/core dan memiliki akses ke lapisan bawah stack (hingga ke hardware), sehingga meningkatkan peluang untuk melewati model keamanan Android.

Layanan yang aman

Layanan yang aman meliputi:

  • same_process_hwservice. Layanan ini (menurut definisi) berjalan dalam proses klien dan dengan demikian memiliki akses yang sama dengan domain klien tempat proses berjalan.
  • coredomain_hwservice. Layanan ini tidak menimbulkan risiko yang terkait dengan alasan #2.
  • hal_configstore_ISurfaceFlingerConfigs. Layanan ini dirancang khusus untuk digunakan oleh domain mana pun.
  • hal_graphics_allocator_hwservice. Operasi ini juga ditawarkan oleh layanan Binder surfaceflinger, yang aksesnya diizinkan untuk aplikasi.
  • hal_omx_hwservice. Ini adalah layanan Binder mediacodec versi HwBinder, yang diizinkan untuk diakses oleh aplikasi.
  • hal_codec2_hwservice. Ini adalah versi yang lebih baru dari hal_omx_hwservice.

Atribut yang dapat digunakan

Semua hwservices yang tidak dianggap aman memiliki atribut untrusted_app_visible_hwservice. Server HAL yang sesuai memiliki atribut untrusted_app_visible_halserver. Perangkat yang diluncurkan dengan Android 9 TIDAK BOLEH menggunakan atribut untrusted.

Rekomendasi:

  • Aplikasi yang tidak tepercaya harus berkomunikasi dengan layanan sistem yang berkomunikasi dengan HAL HIDL vendor. Misalnya, aplikasi dapat berkomunikasi dengan binderservicedomain, lalu mediaserver (yang merupakan binderservicedomain) pada gilirannya berkomunikasi dengan hal_graphics_allocator.

    ATAU

  • Aplikasi yang memerlukan akses langsung ke HAL vendor harus memiliki domain sepolicy yang ditentukan vendor sendiri.

Pengujian atribut file

Android 9 menyertakan pengujian waktu build yang memastikan semua file di lokasi tertentu memiliki atribut yang sesuai (misalnya, semua file di sysfs memiliki atribut sysfs_type yang diperlukan).

Pelabelan konteks SELinux

Untuk mendukung perbedaan antara sepolicy platform dan vendor, sistem membangun file konteks SELinux secara berbeda agar tetap terpisah.

Konteks file

Android 8.0 memperkenalkan perubahan berikut untuk file_contexts:

  • Untuk menghindari overhead kompilasi tambahan di perangkat selama booting, file_contexts tidak ada lagi dalam bentuk biner. Sebagai gantinya, file tersebut dapat dibaca, file teks ekspresi reguler seperti {property, service}_contexts (seperti sebelum versi 7.0).
  • file_contexts dibagi menjadi dua file:
    • plat_file_contexts
      • Platform Android file_context yang tidak memiliki label khusus perangkat, kecuali untuk memberi label pada bagian partisi /vendor yang harus diberi label secara tepat untuk memastikan fungsi file sepolicy yang tepat.
      • Harus berada di partisi system di /system/etc/selinux/plat_file_contexts di perangkat dan dimuat oleh init di awal bersama dengan file_context vendor.
    • vendor_file_contexts
      • file_context spesifik per perangkat dibuat dengan menggabungkan file_contexts yang ditemukan di direktori yang ditunjukkan oleh BOARD_SEPOLICY_DIRS dalam file Boardconfig.mk perangkat.
      • Harus diinstal di /vendor/etc/selinux/vendor_file_contexts di partisi vendor dan dimuat oleh init di awal bersama dengan file_context platform.

Konteks properti

Di Android 8.0, property_contexts dibagi menjadi dua file:

  • plat_property_contexts
    • Platform Android property_context yang tidak memiliki label khusus perangkat.
    • Harus berada di partisi system di /system/etc/selinux/plat_property_contexts dan dimuat oleh init di awal bersama dengan property_contexts vendor.
  • vendor_property_contexts
    • property_context khusus perangkat yang dibuat dengan menggabungkan property_contexts yang ditemukan di direktori yang ditunjukkan oleh BOARD_SEPOLICY_DIRS dalam file Boardconfig.mk perangkat.
    • Harus berada di partisi vendor di /vendor/etc/selinux/vendor_property_contexts dan dimuat oleh init di awal bersama dengan property_context platform

Konteks layanan

Di Android 8.0, service_contexts dibagi antara file berikut:

  • plat_service_contexts
    • service_context khusus platform Android untuk servicemanager. service_context tidak memiliki label khusus perangkat.
    • Harus berada di partisi system di /system/etc/selinux/plat_service_contexts dan dimuat oleh servicemanager di awal bersama dengan service_contexts vendor.
  • vendor_service_contexts
    • service_context spesifik per perangkat dibuat dengan menggabungkan service_contexts yang ditemukan di direktori yang ditunjukkan oleh BOARD_SEPOLICY_DIRS dalam file Boardconfig.mk perangkat.
    • Harus berada di partisi vendor pada /vendor/etc/selinux/vendor_service_contexts dan dimuat oleh servicemanager di awal bersama dengan service_contexts platform.
    • Meskipun servicemanager mencari file ini saat waktu booting, untuk perangkat TREBLE yang sepenuhnya mematuhi, maka vendor_service_contexts TIDAK BOLEH ada. Hal ini karena semua interaksi antara vendor dan system proses HARUS melalui hwservicemanager/hwbinder.
  • plat_hwservice_contexts
    • Platform Android hwservice_context untuk hwservicemanager yang tidak memiliki label khusus perangkat.
    • Harus berada di partisi system di /system/etc/selinux/plat_hwservice_contexts dan dimuat oleh hwservicemanager di awal bersama dengan vendor_hwservice_contexts.
  • vendor_hwservice_contexts
    • hwservice_context spesifik per perangkat dibuat dengan menggabungkan hwservice_contexts yang ditemukan di direktori yang ditunjukkan oleh BOARD_SEPOLICY_DIRS dalam file Boardconfig.mk perangkat.
    • Harus berada di partisi vendor di /vendor/etc/selinux/vendor_hwservice_contexts dan dimuat oleh hwservicemanager di awal bersama dengan plat_service_contexts.
  • vndservice_contexts
    • service_context khusus perangkat untuk vndservicemanager yang dibuat dengan menggabungkan vndservice_contexts yang ditemukan di direktori yang ditunjukkan oleh BOARD_SEPOLICY_DIRS di Boardconfig.mk perangkat.
    • File ini harus berada di partisi vendor di /vendor/etc/selinux/vndservice_contexts dan dimuat oleh vndservicemanager saat memulai.

Konteks Seapp

Di Android 8.0, seapp_contexts dibagi menjadi dua file:

  • plat_seapp_contexts
    • seapp_context platform Android yang tidak memiliki perubahan khusus perangkat.
    • Harus berada di partisi system pada /system/etc/selinux/plat_seapp_contexts.
  • vendor_seapp_contexts
    • Ekstensi khusus perangkat ke seapp_context platform yang dibuat dengan menggabungkan seapp_contexts yang ditemukan di direktori yang ditunjukkan oleh BOARD_SEPOLICY_DIRS dalam file Boardconfig.mk perangkat.
    • Harus berada di partisi vendor pada /vendor/etc/selinux/vendor_seapp_contexts.

Izin MAC

Di Android 8.0, mac_permissions.xml dibagi menjadi dua file:

  • Platform mac_permissions.xml
    • mac_permissions.xml platform Android yang tidak memiliki perubahan khusus perangkat.
    • Harus berada di partisi system pada /system/etc/selinux/.
  • Non-Platform mac_permissions.xml
    • Ekstensi khusus perangkat ke platform mac_permissions.xml yang dibangun dari mac_permissions.xml yang ditemukan di direktori yang ditunjukkan oleh BOARD_SEPOLICY_DIRS dalam file Boardconfig.mk perangkat.
    • Harus berada di partisi vendor pada /vendor/etc/selinux/.