Kompatibilitas Kebijakan

Artikel ini menjelaskan cara Android menangani masalah kompatibilitas kebijakan dengan OTA platform, di mana setelan SELinux platform baru mungkin berbeda dari vendor lama Setelan SELinux.

Desain kebijakan SELinux berbasis Treble mempertimbangkan perbedaan biner antara kebijakan platform dan vendor; skema menjadi lebih rumit jika partisi vendor menghasilkan dependensi, seperti platform < vendor < oem.

Di Android 8.0 dan yang lebih tinggi, kebijakan global SELinux dibagi menjadi komponen publik. Komponen publik terdiri dari kebijakan dan komponen infrastruktur IT, yang dijamin akan tersedia untuk versi platform. Kebijakan ini akan diekspos ke penulis kebijakan vendor untuk memungkinkan vendor membangun file kebijakan vendor, yang jika dikombinasikan dengan kebijakan yang disediakan platform, menghasilkan kebijakan yang berfungsi penuh pada perangkat.

  • Untuk pembuatan versi, kebijakan platform-publik yang diekspor akan ditulis sebagai atribut.
  • Untuk memudahkan penulisan kebijakan, jenis yang diekspor akan diubah menjadi atribut berversi sebagai bagian dari proses pembuatan kebijakan. Publik juga dapat digunakan secara langsung dalam keputusan pelabelan yang disediakan oleh konteks file.

Android mempertahankan pemetaan antara jenis konkret yang diekspor di platform kebijakan dan atribut berversi yang sesuai untuk setiap platform versi. Ini memastikan bahwa ketika objek diberi label dengan suatu jenis, tidak melanggar perilaku yang dijamin oleh kebijakan platform-publik dalam . Pemetaan ini dipelihara dengan terus memperbarui file pemetaan untuk setiap versi platform, yang menyimpan informasi keanggotaan atribut untuk setiap versi yang diekspor dalam kebijakan publik.

Kepemilikan dan pelabelan objek

Saat menyesuaikan kebijakan di Android 8.0 dan yang lebih baru, kepemilikan harus didefinisikan dengan jelas untuk setiap objek agar kebijakan platform dan vendor tetap terpisah. Misalnya, jika vendor memberi label /dev/foo dan platform kemudian memberi label /dev/foo di OTA berikutnya, akan ada perilaku yang tidak ditentukan. Sebagai SELinux, ini muncul sebagai tumbukan label. {i>Node<i} perangkat hanya dapat memiliki satu label yang memutuskan label mana yang terakhir kali diterapkan. Akibatnya:

  • Proses yang memerlukan akses ke label yang tidak berhasil diterapkan akan kehilangan akses ke sumber daya.
  • Proses mendapatkan akses ke file dapat terganggu karena kesalahan node perangkat telah dibuat.

Properti sistem juga memiliki potensi untuk tumbukan penamaan yang dapat mengakibatkan perilaku yang tidak terdefinisi pada sistem (serta untuk pelabelan SELinux). Tabrakan antara label platform dan vendor dapat terjadi untuk objek apa pun yang memiliki label, termasuk properti, layanan, proses, file, dan soket. Untuk menghindari masalah ini, tentukan dengan jelas kepemilikan objek ini.

Selain konflik label, nama atribut/jenis SELinux juga dapat bertabrakan. Tabrakan jenis/nama atribut akan selalu mengakibatkan error compiler kebijakan.

Ruang nama jenis/atribut

SELinux tidak mengizinkan beberapa deklarasi jenis/atribut yang sama. Kebijakan dengan deklarasi duplikat akan gagal dikompilasi. Untuk menghindari jenis dan konflik nama atribut, semua deklarasi vendor harus diberi namespace diawali dengan vendor_. 

type foo, domain; → type vendor_foo, domain;

Properti sistem dan proses pelabelan kepemilikan

Menghindari konflik pelabelan dapat diselesaikan dengan menggunakan namespace properti. Kepada mengidentifikasi properti platform dengan mudah dan menghindari konflik nama saat mengganti nama atau menambahkan properti platform yang diekspor, pastikan semua properti vendor awalan itu sendiri:

Jenis properti Awalan yang dapat diterima
properti kontrol ctl.vendor.
ctl.start$vendor.
ctl.stop$vendor.
init.svc.vendor.
dapat dibaca vendor.
hanya-baca ro.vendor.
ro.boot.
ro.hardware.
persisten persist.vendor.

Vendor dapat terus menggunakan ro.boot.* (yang berasal dari kernel cmdline) dan ro.hardware.* (properti terkait hardware yang jelas).

Semua layanan vendor dalam file rc init harus memiliki vendor. untuk layanan dalam file rc init dari partisi non-sistem. Aturan serupa adalah diterapkan ke label SELinux untuk properti vendor (vendor_ untuk properti vendor).

Kepemilikan file

Mencegah bentrokan pada file merupakan pekerjaan yang sulit karena platform dan vendor kebijakan itu biasanya memberikan label untuk semua sistem file. Tidak seperti penamaan jenis, pengaturan nama file tidak praktis karena banyak di antaranya dibuat oleh {i>kernel<i}. Untuk mencegah konflik ini, ikuti panduan penamaan untuk sistem file pada bagian ini. Untuk Android 8.0, ini adalah rekomendasi tanpa persyaratan teknis penegakan kebijakan. Ke depannya, rekomendasi ini akan diberlakukan oleh Paket Pengujian Vendor (VTS).

Sistem (/sistem)

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

Vendor (/vendor)

Kebijakan SELinux AOSP sudah memberi label pada bagian-bagian partisi vendor berinteraksi dengan platform, yang memungkinkan penulisan aturan SELinux untuk platform proses untuk dapat berbicara dan/atau mengakses bagian dari vendor partisi. Contoh:

/vendor jalur Label yang disediakan platform Proses platform tergantung 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 file tambahan di vendor partisi:

  • vendor_file harus menjadi label default untuk semua file di Partisi vendor. Kebijakan platform mengharuskan ini untuk mengakses implementasi HAL passthrough.
  • Semua exec_types baru ditambahkan di partisi vendor melalui SEPolicy vendor harus memiliki atribut vendor_file_type. Ini diberlakukan melalui hal yang tidak diizinkan.
  • Untuk menghindari konflik dengan update platform/framework di masa mendatang, hindari pelabelan file selain exec_types dalam partisi vendor.
  • Semua dependensi library untuk HAL proses yang sama yang diidentifikasi oleh AOSP harus diberi label sebagai same_process_hal_file.

Procfs (/proc)

File di /proc dapat diberi label hanya menggunakan genfscon label. Di Android 7.0, platform dan vendor kebijakan 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 dengan label default (proc), kebijakan vendor tidak boleh melabelinya secara eksplisit dan justru harus menggunakan Jenis proc untuk menambahkan aturan bagi domain vendor. Hal ini memungkinkan platform untuk mengakomodasi antarmuka {i> kernel<i} yang akan diekspos melalui procfs dan beri label 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 dipasang di perangkat produksi. Produsen perangkat seharusnya hapus debugfs.

Tracef (/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, baik platform maupun vendor file_contexts dan genfscon untuk memberi label pada file di sysfs.

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

tmpfs (/dev)

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

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

Rootf (/)

File di / dapat diberi label di file_contexts. Di Android 7.0, baik file label platform dan vendor 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: Larang pelabelan vendor di luar /data/vendor. Hanya platform yang dapat memberi label pada bagian lain dari /data.

Atribut kompatibilitas

Kebijakan SELinux adalah interaksi antara jenis sumber dan target untuk izin akses dan class objek. Setiap objek (proses, file, dll.) yang terpengaruh oleh kebijakan SELinux mungkin hanya memiliki satu jenis, tetapi jenis itu mungkin memiliki beberapa .

Kebijakan sebagian besar ditulis dalam jenis yang sudah ada: 

allow source_type target_type:target_class permission(s);

Hal ini berlaku karena kebijakan tersebut ditulis dengan pengetahuan tentang semua jenis. Namun, apakah kebijakan vendor dan kebijakan platform menggunakan jenis tertentu, dan label objek tertentu hanya berubah di salah satu kebijakan tersebut, kebijakan lainnya mungkin berisi kebijakan yang memperoleh atau kehilangan akses yang sebelumnya diandalkan. Contoh: 

File_contexts:
/sys/A   u:object_r:sysfs:s0
Platform: allow p_domain sysfs:class perm;
Vendor: allow v_domain sysfs:class perm;

Dapat diubah menjadi: 

File_contexts:
/sys/A   u:object_r:sysfs_A:s0

Meskipun kebijakan vendor akan tetap sama, v_domain akan kehilangan akses karena tidak adanya kebijakan untuk sysfs_A baru .

Dengan menentukan kebijakan dari segi atribut, kita dapat memberikan objek dasar yang memiliki atribut sesuai dengan kebijakan untuk platform dan kode vendor. Hal ini dapat dilakukan bagi semua jenis untuk membuat sebuah attribute-policy di mana jenis konkret tidak pernah digunakan. Dalam praktiknya, bagian ini hanya diperlukan untuk bagian kebijakan yang tumpang-tindih di antara platform dan vendor, yang ditetapkan dan disediakan sebagai kebijakan publik platform yang dibuat sebagai bagian dari kebijakan vendor.

Mendefinisikan kebijakan publik karena atribut berversi memenuhi dua kebijakan tujuan kompatibilitas:

  • Pastikan kode vendor terus berfungsi setelah update platform. Dicapai dengan menambahkan atribut ke tipe konkret untuk objek yang sesuai dengan mereka yang diandalkan oleh kode vendor, untuk menjaga akses.
  • Kemampuan untuk menghentikan penggunaan kebijakan. Dicapai dengan jelas menetapkan atribut yang dapat dihapus segera setelah yang sesuai dengannya tidak lagi didukung. Pengembangan dapat melanjutkan platform, mengetahui kebijakan lama masih ada di kebijakan vendor dan akan otomatis dihapus saat/jika upgrade dilakukan.

Kebijakan dapat ditulis

Untuk memenuhi tujuan tidak memerlukan pengetahuan tentang perubahan versi tertentu untuk pengembangan kebijakan, Android 8.0 menyertakan pemetaan antara platform-publik jenis kebijakan dan atributnya. Jenis foo dipetakan untuk mengatribusikan foo_vN, dengan N adalah yang ditargetkan. vN sesuai dengan Variabel build PLATFORM_SEPOLICY_VERSION dan dalam bentuk MM.NN, dengan MM sesuai dengan nomor SDK platform dan NN adalah versi khusus sepolicy platform.

Atribut dalam kebijakan publik tidak memiliki versi, melainkan tersedia sebagai API di kebijakan platform dan vendor mana yang dapat dibuat untuk menjaga antarmuka antara keduanya partisi stabil. Baik penulis kebijakan {i>platform<i} dan vendor dapat terus menulis seperti yang tertulis saat ini.

Kebijakan publik platform yang diekspor sebagai allow source_foo target_bar:class perm; disertakan sebagai bagian dari kebijakan vendor. Selama kompilasi (yang mencakup yang sesuai) diubah menjadi kebijakan yang akan dikirimkan ke bagian vendor perangkat (ditampilkan di Common Intermediate yang telah diubah Bahasa (CIL)): 

 (allow source_foo_vN target_bar_vN (class (perm)))

Karena kebijakan vendor tidak pernah mendahului platform, kebijakan tersebut tidak perlu mengkhawatirkan versi sebelumnya. Namun, kebijakan platform perlu mengetahui seberapa jauh vendor kebijakannya adalah, sertakan atribut pada jenisnya, dan tetapkan kebijakan yang sesuai dengan atribut berversi.

Perbedaan kebijakan

Membuat atribut secara otomatis dengan menambahkan _vN ke bagian akhir setiap jenis tidak melakukan apa pun tanpa memetakan atribut ke jenis di seluruh versi yang berbeda. Android mempertahankan pemetaan antarversi untuk atribut dan pemetaan jenis ke atribut tersebut. Hal ini dilakukan dalam pemetaan yang disebutkan di atas file dengan pernyataan, seperti (CIL): 

(typeattributeset foo_vN (foo))

Upgrade platform

Bagian berikut menjelaskan skenario untuk upgrade platform.

Jenis yang sama

Skenario ini terjadi saat objek tidak mengubah label dalam versi kebijakan. Hal ini sama untuk jenis sumber dan target dan dapat dilihat dengan /dev/binder, yang diberi label binder_device di semua rilis. Hal ini direpresentasikan dalam kebijakan yang ditransformasi sebagai: 

binder_device_v1 … binder_device_vN

Saat mengupgrade dari v1 → v2, kebijakan platform harus berisi: 

type binder_device; -> (type binder_device) (in CIL)

Di file pemetaan v1 (CIL): 

(typeattributeset binder_device_v1 (binder_device))

Di file pemetaan v2 (CIL): 

(typeattributeset binder_device_v2 (binder_device))

Dalam kebijakan vendor v1 (CIL): 

(typeattribute binder_device_v1)
(allow binder_device_v1 …)

Di kebijakan vendor v2 (CIL): 

(typeattribute binder_device_v2)
(allow binder_device_v2 …)
Jenis baru

Skenario ini terjadi ketika platform telah menambahkan tipe baru, yang dapat terjadi saat menambahkan fitur baru atau selama pengerasan kebijakan.

  • Fitur baru. Ketika jenisnya melabeli objek yang sebelumnya tidak ada (seperti proses layanan baru), kode vendor tidak berinteraksi secara langsung dengannya sehingga tidak ada kebijakan yang sesuai. Yang baru yang sesuai dengan jenis tidak memiliki atribut di sehingga tidak memerlukan entri dalam penargetan file pemetaan yang .
  • Hardening kebijakan. Kapan jenisnya mewakili kebijakan hardening, atribut tipe baru harus terhubung kembali ke rantai atribut sesuai dengan contoh sebelumnya (serupa dengan contoh sebelumnya yang mengubah /sys/A dari sysfs hingga sysfs_A). Vendor kode bergantung pada aturan yang mengaktifkan akses ke sysfs, dan memerlukan untuk menyertakan aturan itu sebagai atribut jenis baru.

Saat mengupgrade dari v1 → v2, kebijakan platform harus berisi: 

type sysfs_A; -> (type sysfs_A) (in CIL)
type sysfs; (type sysfs) (in CIL)

Di file pemetaan v1 (CIL): 

(typeattributeset sysfs_v1 (sysfs sysfs_A))

Di file pemetaan v2 (CIL): 

(typeattributeset sysfs_v2 (sysfs))
(typeattributeset sysfs_A_v2 (sysfs_A))

Dalam kebijakan vendor v1 (CIL): 

(typeattribute sysfs_v1)
(allow … sysfs_v1 …)

Di kebijakan vendor v2 (CIL): 

(typeattribute sysfs_A_v2)
(allow … sysfs_A_v2 …)
(typeattribute sysfs_v2)
(allow … sysfs_v2 …)
Jenis yang dihapus

Skenario (jarang) ini terjadi ketika suatu jenis dihapus, yang dapat terjadi ketika objek dasar:

  • Tetap ada, tetapi akan diberi label berbeda.
  • Dihapus oleh platform.

Selama pelonggaran kebijakan, jenis akan dihapus dan objek diberi label dengan jenis tersebut diberi label lain yang sudah ada. Diagram ini mewakili penggabungan pemetaan atribut: Kode vendor harus tetap dapat mengakses atribut dengan atribut yang dulu dimilikinya, tetapi bagian lain dari sistem sekarang harus dapat mengaksesnya dengan atribut barunya.

Jika atribut yang dialihkan masih baru, maka pelabelan ulang adalah sama seperti pada kasus jenis baru, kecuali bahwa ketika label yang ada digunakan, penambahan atribut lama, jenis baru akan menyebabkan objek lain juga dilabeli dengan jenis ini menjadi baru dapat diakses. Pada dasarnya inilah yang dilakukan oleh platform dan dianggap sebagai kompromi yang dapat diterima untuk mempertahankan kompatibilitas mundur. 

(typeattribute sysfs_v1)
(allow … sysfs_v1 …)

Contoh Versi 1: Jenis yang dapat diciutkan (menghapus sysfs_A)

Saat mengupgrade dari v1 → v2, kebijakan platform harus berisi: 

type sysfs; (type sysfs) (in CIL)

Di file pemetaan v1 (CIL): 

(typeattributeset sysfs_v1 (sysfs))
(type sysfs_A) # in case vendors used the sysfs_A label on objects
(typeattributeset sysfs_A_v1 (sysfs sysfs_A))

Di file pemetaan v2 (CIL): 

(typeattributeset sysfs_v2 (sysfs))

Dalam kebijakan vendor v1 (CIL): 

(typeattribute sysfs_A_v1)
(allow … sysfs_A_v1 …)
(typeattribute sysfs_v1)
(allow … sysfs_v1 …)

Di kebijakan vendor v2 (CIL): 

(typeattribute sysfs_v2)
(allow … sysfs_v2 …)

Contoh Versi 2: Menghapus sepenuhnya (foo type)

Saat mengupgrade dari v1 → v2, kebijakan platform harus berisi: 

# nothing - we got rid of the type

Di file pemetaan v1 (CIL): 

(type foo) #needed in case vendors used the foo label on objects
(typeattributeset foo_v1 (foo))

Di file pemetaan v2 (CIL): 

# nothing - get rid of it

Dalam kebijakan vendor v1 (CIL): 

(typeattribute foo_v1)
(allow foo …)
(typeattribute sysfs_v1)
(allow sysfs_v1 …)

Di kebijakan vendor v2 (CIL): 

(typeattribute sysfs_v2)
(allow sysfs_v2 …)
Kelas/izin baru

Skenario ini terjadi saat upgrade platform memperkenalkan komponen kebijakan baru yang tidak ada di versi sebelumnya. Misalnya, saat Android menambahkan Pengelola objek servicemanager yang membuat penambahan, pencarian, dan daftar izin akses, {i>daemon<i} vendor ingin mendaftar dengan servicemanager membutuhkan izin yang tidak yang tersedia. Di Android 8.0, hanya kebijakan platform yang dapat menambahkan kelas dan izin akses.

Untuk mengizinkan semua domain yang dapat dibuat atau diperluas oleh kebijakan vendor untuk menggunakan kelas baru tanpa halangan, kebijakan platform harus menyertakan aturan yang mirip dengan: 

allow {domain -coredomain} *:new_class perm;

Hal ini bahkan mungkin memerlukan kebijakan yang mengizinkan akses untuk semua antarmuka (kebijakan publik) jenis, untuk memastikan bahwa gambar vendor mendapatkan akses. Jika hasilnya tidak dapat diterima kebijakan keamanan (seperti yang mungkin terjadi dengan perubahan {i>servicemanager<i}), vendor upgrade berpotensi dipaksa.

Kelas/izin yang dihapus

Skenario ini terjadi jika pengelola objek dihapus (seperti ZygoteConnection) dan tidak akan menyebabkan masalah. Tujuan di kelas pengelola objek dan izin akses bisa tetap ditentukan dalam kebijakan sampai versi vendor tidak lagi menggunakannya. Cara ini dilakukan dengan menambahkan definisi-definisi, ke file pemetaan yang sesuai.

Penyesuaian vendor untuk jenis baru/yang dilabeli ulang

Jenis vendor baru menjadi inti dari pengembangan kebijakan vendor karena jenis tersebut dibutuhkan untuk menggambarkan proses baru, {i>biner<i}, perangkat, subsistem, dan data yang disimpan. Sebagai oleh karena itu, sangat penting untuk mengizinkan pembuatan jenis yang ditentukan vendor.

Karena kebijakan vendor selalu yang paling lama di perangkat, tidak perlu otomatis mengonversi semua jenis vendor ke atribut dalam kebijakan. Platform tidak bergantung pada apa pun yang diberi label dalam kebijakan vendor karena platform itu tidak memiliki pengetahuan tentangnya; namun, platform akan memberikan atribut dan yang digunakannya untuk berinteraksi dengan objek yang dilabeli dengan tipe ini (seperti domain, sysfs_type, dll.). Agar platform dapat terus berinteraksi secara benar dengan objek, atribut, dan jenis harus diterapkan dengan tepat dan aturan tertentu mungkin perlu ditambahkan ke domain yang dapat disesuaikan (seperti init).

Perubahan atribut untuk Android 9

Perangkat yang mengupgrade ke Android 9 dapat menggunakan atribut berikut, tetapi perangkat peluncuran 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 tidak membagikan file dengan jalur antara vendor dan coredomains. Platform dan proses vendor tidak boleh menggunakan file dalam disk untuk berkomunikasi (ABI yang tidak stabil). Rekomendasi:
    • Kode vendor harus menggunakan /data/vendor.
    • Sistem tidak boleh menggunakan /data/vendor.
  • system_executes_vendor_violators {i>Attribute<i} 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 HIDL HAL.

      ATAU

    • coredomains yang memerlukan akses ke biner vendor harus dipindahkan ke partisi vendor, sehingga tidak lagi menjadi coredomain.

Atribut tidak tepercaya

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

  1. Server HwBinder tidak melakukan otentikasi klien karena HIDL saat ini tidak mengekspos informasi UID pemanggil. Bahkan jika HIDL memang mengekspos data tersebut, banyak Layanan HwBinder beroperasi pada tingkat di bawah aplikasi (seperti HAL) atau tidak boleh mengandalkan identitas aplikasi untuk otorisasi. Jadi, untuk amannya, Asumsinya, setiap layanan HwBinder memperlakukan semua kliennya dengan berwenang untuk melakukan operasi yang ditawarkan oleh layanan.
  2. Server HAL (subset layanan HwBinder) berisi kode dengan tingkat insiden masalah keamanan lebih dari system/core komponen dan memiliki akses ke lapisan tumpukan bawah (sampai ke perangkat keras) sehingga meningkatkan peluang untuk mengabaikan model keamanan Android.

Layanan yang aman

Layanan yang aman meliputi:

  • same_process_hwservice. Layanan ini (menurut definisi) berjalan di proses klien dan dengan demikian memiliki akses yang sama dengan domain klien di yang dijalankan proses.
  • coredomain_hwservice. Layanan ini tidak menimbulkan risiko dikaitkan 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 aplikasi mana saja diizinkan untuk diakses.
  • hal_omx_hwservice. Ini adalah versi HwBinder dari mediacodec Layanan Binder, yang diizinkan untuk diakses oleh aplikasi.
  • hal_codec2_hwservice. Versi 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 diluncurkan dengan Android 9 TIDAK BOLEH menggunakan Atribut untrusted.

Rekomendasi:

  • Aplikasi yang tidak tepercaya seharusnya berkomunikasi dengan layanan sistem yang berkomunikasi dengan vendor HIDL HAL. Misalnya, aplikasi dapat berbicara dengan binderservicedomain, kemudian mediaserver (yang merupakan binderservicedomain) selanjutnya 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 dalam memiliki atribut yang sesuai (seperti, semua file di sysfs memiliki atribut sysfs_type yang diperlukan).

Kebijakan publik platform

Kebijakan platform-publik adalah inti dari kepatuhan dengan Android 8.0 model arsitektur tanpa sekedar mempertahankan gabungan kebijakan platform dari v1 dan v2. Vendor diekspos pada subkumpulan kebijakan platform yang berisi jenis dan atribut yang dapat digunakan serta aturan tentang jenis dan atribut tersebut yang kemudian menjadi bagian dari kebijakan vendor (yaitu vendor_sepolicy.cil).

Jenis dan aturan otomatis diterjemahkan dalam kebijakan yang dibuat vendor ke dalam attribute_vN sehingga semua jenis yang disediakan platform adalah atribut berversi (tetapi atribut tidak berversi). Platform ini bertanggung jawab untuk memetakan jenis-jenis konkret yang diberikannya ke dalam untuk memastikan bahwa kebijakan vendor tetap berfungsi dan aturan yang disediakan untuk versi tertentu. Kombinasi dari kebijakan platform-publik dan kebijakan vendor memenuhi arsitektur Android 8.0 tujuan model yakni memungkinkan pembuatan platform dan vendor independen.

Pemetaan ke rantai atribut

Saat menggunakan atribut untuk dipetakan ke versi kebijakan, jenis dipetakan ke atribut atau beberapa atribut, untuk memastikan objek yang dilabeli dengan tipe bisa diakses melalui yang sesuai dengan jenisnya sebelumnya.

Mempertahankan tujuan untuk menyembunyikan informasi versi dari penulis kebijakan berarti secara otomatis membuat atribut berversi dan menetapkannya ke yang sesuai. Dalam kasus umum jenis statis, hal ini sangat mudah: type_foo dipetakan ke type_foo_v1.

Untuk perubahan label objek seperti sysfs → sysfs_A atau mediaserver → audioserver, membuat pemetaan ini non-trivial (dan dijelaskan dalam contoh di atas). Pengelola kebijakan platform harus menentukan cara membuat pemetaan pada titik transisi untuk objek, membutuhkan pemahaman hubungan antara objek dan fungsi-fungsinya yang ditugaskan label dan menentukan kapan terjadinya masalah ini. Untuk kompatibilitas mundur, kompleksitas perlu dikelola di sisi platform, yang merupakan satu-satunya partisi yang mungkin meningkat.

Peningkatan versi

Untuk mempermudah, platform Android merilis versi sekebijakan saat cabang rilis dipotong. Seperti dijelaskan di atas, nomor versi terdapat dalam PLATFORM_SEPOLICY_VERSION dan dalam bentuk MM.nn, dengan MM sesuai dengan nilai SDK dan nn adalah nilai pribadi dipertahankan di /platform/system/sepolicy. Untuk misalnya, 19.0 untuk Kitkat, 21.0 untuk Lollipop, 22.0 untuk Lollipop-MR1 23.0 untuk Marshmallow, 24.0 untuk Nougat, 25.0 untuk Nougat-MR1, 26.0 untuk Oreo, 27.0 untuk Oreo-MR1, dan 28.0 untuk Android 9. Peningkatan tidak selalu berupa bilangan bulat. Sebagai misalnya, jika suatu MR bump pada suatu versi memerlukan perubahan yang tidak kompatibel dalam system/sepolicy/public, tetapi bukan bump API, maka sepolicy tersebut versi mungkin adalah: vN.1. Versi yang ada dalam pengembangan cabang adalah 10000.0 perangkat yang tidak pernah digunakan dalam pengiriman.

Android dapat menghentikan penggunaan versi terlama saat melakukan update. Untuk masukan tentang kapan menghentikan penggunaan versi, Android dapat mengumpulkan jumlah perangkat dengan vendor kebijakan yang menjalankan versi Android tersebut dan masih menerima platform utama pembaruan. Jika angkanya kurang dari ambang batas tertentu, versi itu tidak digunakan lagi.

Dampak performa beberapa atribut

Seperti yang dijelaskan di https://github.com/SELinuxProject/cil/issues/9, sejumlah besar atribut yang ditetapkan ke suatu jenis menyebabkan masalah performa di saat cache kebijakan tidak ditemukan.

Masalah ini telah terkonfirmasi sebagai masalah di Android, jadi perubahan dibuat ke Android 8.0 untuk menghapus atribut yang ditambahkan ke kebijakan oleh kebijakan compiler, serta untuk menghapus atribut yang tidak digunakan. Perubahan ini telah diselesaikan menyebabkan regresi performa.

Kebijakan publik produk dan publik System_ext

Mulai Android 11, partisi sistem_ext dan produk diizinkan untuk mengekspor tipe publik yang mereka tetapkan ke partisi vendor. Suka platform kebijakan publik, vendor menggunakan jenis dan aturan yang secara otomatis diterjemahkan ke dalam atribut berversi, misalnya dari type ke type_N, dengan N adalah versinya dari platform di mana partisi vendor dibangun.

Jika system_ext dan partisi produk didasarkan pada versi platform yang sama N, sistem build akan menghasilkan file pemetaan dasar untuk system_ext/etc/selinux/mapping/N.cil dan product/etc/selinux/mapping/N.cil, yang berisi identitas pemetaan dari type ke type_N. Vendor dapat akses type dengan atribut berversi type_N.

Jika hanya system_ext dan partisi produk yang diupdate, misalnya N ke N+1 (atau yang lebih baru), sedangkan vendor tetap berada di N, vendor dapat kehilangan akses ke jenis system_ext dan partisi produk. Untuk mencegah kerusakan, system_ext dan partisi produk harus menyediakan file pemetaan dari jenis ke dalam atribut type_N. Setiap partner bertanggung jawab untuk memelihara file pemetaan, jika mereka akan mendukung Vendor N dengan N+1 (atau yang lebih baru) system_ext, dan partisi produk.

Untuk melakukannya, partner diharapkan dapat:

  1. Salin file pemetaan dasar yang dihasilkan dari N system_ext dan partisi produk ke hierarki sumbernya.
  2. Ubah file pemetaan sesuai kebutuhan.
  3. Instal memetakan file ke N+1 (atau yang lebih baru) system_ext dan partisi produk.

Misalnya, anggaplah N system_ext memiliki satu publik jenis bernama foo_type. Setelah itu system_ext/etc/selinux/mapping/N.cil dalam partisi system_ext N akan terlihat seperti ini: 

(typeattributeset foo_type_N (foo_type))
(expandtypeattribute foo_type_N true)
(typeattribute foo_type_N)

Jika bar_type ditambahkan ke N+1 system_ext, dan jika bar_type harus dipetakan ke foo_type untuk Vendor N, N.cil dapat diperbarui dari 

(typeattributeset foo_type_N (foo_type))

to 

(typeattributeset foo_type_N (foo_type bar_type))

lalu diinstal ke partisi N+1 system_ext. Vendor N dapat terus mengakses N+1 foo_type dan bar_type system_ext.

Pelabelan konteks SELinux

Untuk mendukung perbedaan antara sekebijakan platform dan vendor, sistem membangun file konteks SELinux secara berbeda untuk memisahkannya.

Konteks file

Android 8.0 memperkenalkan perubahan berikut untuk file_contexts:

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

Konteks properti

Di Android 8.0, property_contexts dibagi menjadi dua file:

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

Konteks layanan

Pada Android 8.0, service_contexts dibagi menjadi beberapa file:

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

Konteks Seapp

Di Android 8.0, seapp_contexts dibagi menjadi dua file:

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

Izin MAC

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

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