Kompatibilitas Kebijakan

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

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 lebih tinggi, kebijakan global SELinux dibagi menjadi komponen pribadi dan publik. Komponen publik terdiri dari kebijakan dan infrastruktur terkait, yang dijamin akan tersedia untuk versi platform. Kebijakan ini akan dipaparkan kepada penulis kebijakan vendor untuk memungkinkan vendor membuat file kebijakan vendor, yang jika digabungkan dengan kebijakan yang disediakan platform, akan menghasilkan kebijakan yang berfungsi penuh untuk perangkat.

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

Android mengelola pemetaan antara jenis konkret yang diekspor dalam kebijakan platform dan atribut berversi yang sesuai untuk setiap versi platform . Ini memastikan bahwa saat objek diberi label dengan sebuah tipe, itu tidak merusak perilaku yang dijamin oleh kebijakan platform-publik di versi sebelumnya. Pemetaan ini dipertahankan dengan memperbarui file pemetaan untuk setiap versi platform , yang menyimpan informasi keanggotaan atribut untuk setiap jenis yang diekspor dalam kebijakan publik.

Kepemilikan dan pelabelan objek

Saat menyesuaikan kebijakan di Android 8.0 dan yang lebih tinggi, kepemilikan harus ditentukan 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 terdefinisi. Untuk SELinux, ini bermanifestasi sebagai tabrakan pelabelan. Node perangkat hanya dapat memiliki satu label yang menyelesaikan label mana pun yang diterapkan terakhir. Sebagai akibat:

• Proses yang memerlukan akses ke label yang gagal diterapkan akan kehilangan akses ke sumber daya.
• Proses yang mendapatkan akses ke file dapat rusak karena node perangkat yang salah telah dibuat.

Properti sistem juga memiliki potensi tabrakan 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 SELinux, termasuk properti, layanan, proses, file, dan soket. Untuk menghindari masalah ini, tentukan dengan jelas kepemilikan objek ini.

Selain tabrakan label, nama tipe/atribut SELinux juga dapat bertabrakan. Tabrakan nama jenis/atribut akan selalu menghasilkan kesalahan penyusun kebijakan.

Ketik/atribut namespace

SELinux tidak mengizinkan beberapa deklarasi dari tipe/atribut yang sama. Kebijakan dengan deklarasi duplikat akan gagal dikompilasi. Untuk menghindari tabrakan nama tipe dan atribut, semua deklarasi vendor harus diberi spasi nama dimulai dengan np_ .

type foo, domain; → type np_foo, domain;

Properti sistem dan kepemilikan pelabelan proses

Menghindari tabrakan pelabelan paling baik diselesaikan dengan menggunakan ruang nama properti. Untuk mengidentifikasi properti platform dengan mudah dan menghindari konflik nama saat mengganti nama atau menambahkan properti platform yang diekspor, pastikan semua properti vendor memiliki awalannya sendiri:

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

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

Kepemilikan file

Mencegah tabrakan untuk file itu menantang karena kebijakan platform dan vendor biasanya menyediakan label untuk semua sistem file. Tidak seperti penamaan tipe, penamaan file tidak praktis karena banyak di antaranya dibuat oleh kernel. Untuk mencegah benturan ini, ikuti panduan penamaan untuk sistem file di bagian ini. Untuk Android 8.0, ini adalah rekomendasi tanpa penerapan teknis. Di masa mendatang, rekomendasi ini akan diberlakukan oleh Vendor Test Suite (VTS).

Sistem (/sistem)

Hanya citra sistem yang harus menyediakan label untuk /system melalui file_contexts , service_contexts , dll. Jika label untuk /system ditambahkan dalam kebijakan /vendor , pembaruan OTA khusus kerangka kerja mungkin tidak dapat dilakukan.

Vendor (/vendor)

Kebijakan SELinux AOSP sudah melabeli bagian partisi vendor yang berinteraksi dengan platform, yang memungkinkan penulisan aturan SELinux untuk proses platform agar dapat berbicara dan/atau mengakses bagian partisi vendor . Contoh:

Akibatnya, aturan khusus harus diikuti (diberlakukan melalui neverallows ) saat memberi label file tambahan di partisi vendor :

• 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 yang ditambahkan di partisi vendor melalui vendor SEPolicy harus memiliki atribut vendor_file_type . Ini ditegakkan melalui tidak pernah diizinkan.
• Untuk menghindari konflik dengan pembaruan platform/kerangka kerja di masa mendatang, hindari memberi label file selain exec_types di partisi vendor .
• Semua dependensi pustaka untuk HAL proses yang sama yang teridentifikasi AOSP harus diberi label sebagai same_process_hal_file.

Proses (/proc)

File di /proc dapat diberi label hanya menggunakan label genfscon . Di Android 7.0, platform dan kebijakan vendor menggunakan genfscon untuk melabeli 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 secara eksplisit melabelinya dan harus menggunakan jenis proc generik untuk menambahkan aturan untuk domain vendor. Ini memungkinkan pembaruan platform untuk mengakomodasi antarmuka kernel di masa mendatang yang diekspos melalui procfs dan memberi 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, baik platform maupun vendor memberi label debugfs .

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

Jejak (/sys/kernel/debug/tracing)

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

Rekomendasi: Hanya platform yang boleh melabeli tracefs .

Sysfs (/sys)

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

Rekomendasi: Platform dapat melabeli node sysfs yang tidak spesifik untuk perangkat. Jika tidak, hanya vendor yang dapat melabeli 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 boleh melabeli file di /dev/vendor (misalnya, /dev/vendor/foo , /dev/vendor/socket/bar ).

Rootf (/)

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 melabeli 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 boleh melabeli bagian lain dari /data .

Atribut kompatibilitas

Kebijakan SELinux adalah interaksi antara tipe sumber dan target untuk kelas dan izin objek tertentu. Setiap objek (proses, file, dll.) yang dipengaruhi oleh kebijakan SELinux mungkin hanya memiliki satu jenis, tetapi jenis tersebut mungkin memiliki banyak atribut.

Kebijakan sebagian besar ditulis berdasarkan jenis yang ada:

allow source_type target_type:target_class permission(s);

Ini berfungsi karena kebijakan ditulis dengan pengetahuan tentang semua jenis. Namun, jika kebijakan vendor dan kebijakan platform menggunakan jenis tertentu, dan label objek tertentu hanya berubah di salah satu kebijakan tersebut, yang lain mungkin berisi kebijakan yang memperoleh atau kehilangan akses yang sebelumnya diandalkan. Misalnya:

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

Bisa diubah menjadi:

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

Meskipun kebijakan vendor akan tetap sama, v_domain akan kehilangan akses karena kurangnya kebijakan untuk tipe sysfs_A yang baru.

Dengan mendefinisikan kebijakan dalam hal atribut, kita dapat memberikan objek yang mendasari sebuah tipe yang memiliki atribut yang sesuai dengan kebijakan untuk platform dan kode vendor. Ini dapat dilakukan untuk semua tipe untuk secara efektif membuat kebijakan atribut di mana tipe konkret tidak pernah digunakan. Dalam praktiknya, ini diperlukan hanya untuk bagian kebijakan yang tumpang tindih antara platform dan vendor, yang didefinisikan dan disediakan sebagai kebijakan publik platform yang dibangun sebagai bagian dari kebijakan vendor.

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

• Pastikan kode vendor terus berfungsi setelah pembaruan platform . Dicapai dengan menambahkan atribut ke tipe konkret untuk objek yang sesuai dengan yang diandalkan oleh kode vendor, menjaga akses.
• Kemampuan untuk mencela kebijakan . Dicapai dengan jelas menggambarkan set kebijakan menjadi atribut yang dapat dihapus segera setelah versi yang sesuai tidak lagi didukung. Pengembangan dapat dilanjutkan di platform, mengetahui kebijakan lama masih ada di kebijakan vendor dan akan dihapus secara otomatis saat/jika ditingkatkan.

Ketertulisan kebijakan

Untuk memenuhi tujuan agar tidak memerlukan pengetahuan tentang perubahan versi tertentu untuk pengembangan kebijakan, Android 8.0 menyertakan pemetaan antara jenis kebijakan platform-publik dan atributnya. Ketik foo dipetakan ke atribut foo_v N , di mana N adalah versi yang ditargetkan. vN sesuai dengan variabel build PLATFORM_SEPOLICY_VERSION dan dalam bentuk MM.NN , di mana MM sesuai dengan nomor SDK platform dan NN adalah versi spesifik sepolicy platform.

Atribut dalam kebijakan publik tidak diberi versi, melainkan ada sebagai API tempat platform dan kebijakan vendor dapat membangun untuk menjaga antarmuka antara dua partisi tetap stabil. Penulis kebijakan platform dan vendor dapat terus menulis kebijakan seperti yang tertulis hari ini.

Kebijakan platform-publik diekspor sebagai allow source_foo target_bar: class perm ; disertakan sebagai bagian dari kebijakan vendor. Selama kompilasi (yang menyertakan versi yang sesuai), kebijakan diubah menjadi kebijakan yang akan masuk ke bagian vendor perangkat (ditampilkan dalam Common Intermediate Language (CIL) yang diubah):

 (allow source_foo_vN target_bar_vN (class (perm)))

Karena kebijakan vendor tidak pernah berada di depan platform, kebijakan tersebut tidak boleh dikaitkan dengan versi sebelumnya. Namun, kebijakan platform perlu mengetahui sejauh mana kebijakan vendor, menyertakan atribut ke jenisnya, dan menyetel kebijakan yang sesuai dengan atribut berversi.

Perbedaan kebijakan

Secara otomatis membuat atribut dengan menambahkan _v N ke akhir setiap tipe tidak melakukan apa-apa tanpa memetakan atribut ke tipe di seluruh versi berbeda. Android mengelola pemetaan antar versi untuk atribut dan pemetaan tipe ke atribut tersebut. Hal ini dilakukan dalam file pemetaan tersebut dengan pernyataan, seperti (CIL):

(typeattributeset foo_vN (foo))

Peningkatan platform

Bagian berikut merinci skenario untuk pemutakhiran platform.

Jenis yang sama

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

binder_device_v1 … binder_device_vN

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

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

Dalam file pemetaan v1 (CIL):

(typeattributeset binder_device_v1 (binder_device))

Dalam file pemetaan v2 (CIL):

(typeattributeset binder_device_v2 (binder_device))

Dalam kebijakan vendor v1 (CIL):

(typeattribute binder_device_v1)
(allow binder_device_v1 …)

Dalam kebijakan vendor v2 (CIL):

(typeattribute binder_device_v2)
(allow binder_device_v2 …)

Jenis baru

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

• Fitur baru . Saat tipe melabeli objek yang sebelumnya tidak ada (seperti proses layanan baru), kode vendor sebelumnya tidak berinteraksi dengannya secara langsung sehingga tidak ada kebijakan terkait. Atribut baru yang sesuai dengan tipe tidak memiliki atribut di versi sebelumnya, sehingga tidak memerlukan entri dalam file pemetaan yang menargetkan versi tersebut.
• Pengerasan kebijakan . Ketika tipe mewakili pengerasan kebijakan, atribut tipe baru harus ditautkan kembali ke rantai atribut yang sesuai dengan yang sebelumnya (mirip dengan contoh sebelumnya mengubah /sys/A dari sysfs menjadi sysfs_A ). Kode vendor bergantung pada aturan yang memungkinkan akses ke sysfs , dan harus menyertakan aturan itu sebagai atribut tipe baru.

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

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

Dalam file pemetaan v1 (CIL):

(typeattributeset sysfs_v1 (sysfs sysfs_A))

Dalam 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 …)

Dalam 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 tipe dihapus, yang dapat terjadi ketika objek yang mendasarinya:

• Tetap tetapi mendapat label yang berbeda.
• Dihapus oleh platform.

Selama pelonggaran kebijakan, sebuah tipe dihapus dan objek yang diberi label dengan tipe tersebut diberi label berbeda yang sudah ada. Ini mewakili penggabungan pemetaan atribut: Kode vendor masih harus dapat mengakses objek yang mendasarinya dengan atribut yang dulu dimilikinya, tetapi sistem lainnya sekarang harus dapat mengaksesnya dengan atribut barunya.

Jika atribut yang telah dialihkan adalah baru, maka pelabelan ulang sama seperti pada kasus tipe baru, kecuali jika label yang ada digunakan, penambahan tipe baru atribut lama akan menyebabkan objek lain juga dilabeli dengan tipe ini. untuk dapat diakses baru. Ini pada dasarnya adalah apa yang dilakukan oleh platform dan dianggap sebagai pertukaran yang dapat diterima untuk menjaga kompatibilitas.

(typeattribute sysfs_v1)
(allow … sysfs_v1 …)

Contoh Versi 1: Jenis runtuh (menghapus sysfs_A)

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

type sysfs; (type sysfs) (in CIL)

Dalam 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))

Dalam 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 …)

Dalam kebijakan vendor v2 (CIL):

(typeattribute sysfs_v2)
(allow … sysfs_v2 …)

Contoh Versi 2: Menghapus sepenuhnya (tipe foo)

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

# nothing - we got rid of the type

Dalam file pemetaan v1 (CIL):

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

Dalam 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 …)

Dalam kebijakan vendor v2 (CIL):

(typeattribute sysfs_v2)
(allow sysfs_v2 …)

Kelas/izin baru

Skenario ini terjadi saat pemutakhiran platform memperkenalkan komponen kebijakan baru yang tidak ada di versi sebelumnya. Misalnya, ketika Android menambahkan manajer objek servicemanager yang membuat izin tambah, temukan, dan daftar, daemon vendor yang ingin mendaftar dengan servicemanager memerlukan izin yang tidak tersedia. Di Android 8.0, hanya kebijakan platform yang dapat menambahkan kelas dan izin baru.

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;

Ini bahkan mungkin memerlukan kebijakan yang mengizinkan akses untuk semua jenis antarmuka (kebijakan publik), untuk memastikan akses gambar vendor. Jika ini menghasilkan kebijakan keamanan yang tidak dapat diterima (seperti yang mungkin terjadi pada perubahan manajer layanan), pemutakhiran vendor berpotensi dipaksakan.

Kelas/izin dihapus

Skenario ini terjadi ketika manajer objek dihapus (seperti manajer objek ZygoteConnection ) dan seharusnya tidak menyebabkan masalah. Kelas pengelola objek dan izin dapat tetap ditentukan dalam kebijakan hingga versi vendor tidak lagi menggunakannya. Ini dilakukan dengan menambahkan definisi ke file pemetaan yang sesuai.

Kustomisasi vendor untuk tipe baru/berlabel ulang

Jenis vendor baru merupakan inti dari pengembangan kebijakan vendor karena diperlukan untuk menjelaskan proses baru, binari, perangkat, subsistem, dan data yang disimpan. Dengan demikian, sangat penting untuk mengizinkan pembuatan tipe yang ditentukan vendor.

Karena kebijakan vendor selalu merupakan yang tertua di perangkat, tidak perlu mengonversi semua jenis vendor secara otomatis ke atribut dalam kebijakan. Platform tidak bergantung pada apa pun yang diberi label dalam kebijakan vendor karena platform tidak mengetahuinya; namun, platform akan menyediakan atribut dan tipe publik yang digunakannya untuk berinteraksi dengan objek yang diberi label dengan tipe ini (seperti domain , sysfs_type , dll.). Agar platform dapat terus berinteraksi dengan benar dengan objek ini, atribut dan tipe harus diterapkan dengan tepat dan aturan khusus mungkin perlu ditambahkan ke domain yang dapat disesuaikan (seperti init ).

Perubahan atribut untuk Android 9

Upgrade perangkat 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 berbagi file melalui 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 .
• system_executes_vendor_violators . Atribut untuk semua domain sistem (kecuali shell domains init dan shell ) yang melanggar persyaratan untuk tidak menjalankan binari vendor. Eksekusi binari vendor memiliki API yang tidak stabil. Platform tidak boleh mengeksekusi binari vendor secara langsung. Rekomendasi:
  • Ketergantungan platform semacam itu pada binari vendor harus berada di belakang HIDL HAL.

    ATAU

  • coredomains yang membutuhkan akses ke binari 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 akses dari aplikasi tersebut (lihat layanan aman di bawah). Dua alasan utama untuk ini adalah:

1. Server HwBinder tidak melakukan autentikasi klien karena HIDL saat ini tidak memaparkan informasi UID penelepon. Bahkan jika HIDL benar-benar mengekspos data tersebut, banyak layanan HwBinder beroperasi pada tingkat di bawah aplikasi (seperti, HAL) atau tidak boleh bergantung pada identitas aplikasi untuk otorisasi. Oleh karena itu, untuk amannya, asumsi standarnya adalah bahwa setiap layanan HwBinder memperlakukan semua kliennya dengan kewenangan yang sama untuk melakukan operasi yang ditawarkan oleh layanan tersebut.
2. Server HAL (subset dari layanan HwBinder) berisi kode dengan tingkat insiden masalah keamanan yang lebih tinggi daripada komponen system/core dan memiliki akses ke lapisan tumpukan yang lebih rendah (sampai ke perangkat keras) sehingga meningkatkan peluang untuk melewati model keamanan Android .

Layanan aman

Layanan yang aman meliputi:

• same_process_hwservice . Layanan ini (menurut definisi) berjalan dalam proses klien dan karenanya 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 apa pun.
• hal_graphics_allocator_hwservice . Operasi ini juga ditawarkan oleh layanan Binder surfaceflinger , yang diizinkan untuk diakses oleh aplikasi.
• hal_omx_hwservice . Ini adalah versi HwBinder dari layanan mediacodec Binder, yang diizinkan untuk diakses oleh aplikasi.
• hal_codec2_hwservice . Ini adalah versi yang lebih baru dari hal_omx_hwservice .

Atribut yang bisa 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 HARUS menggunakan salah satu atribut untrusted .

Rekomendasi:

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

  ATAU

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

Tes 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).

Platform-kebijakan publik

Kebijakan platform-publik adalah inti dari penyesuaian dengan model arsitektur Android 8.0 tanpa hanya menjaga penyatuan kebijakan platform dari v1 dan v2. Vendor dihadapkan pada subset kebijakan platform yang berisi tipe dan atribut yang dapat digunakan dan aturan pada tipe dan atribut tersebut yang kemudian menjadi bagian dari kebijakan vendor (yaitu vendor_sepolicy.cil ).

Tipe dan aturan secara otomatis diterjemahkan dalam kebijakan yang dihasilkan vendor ke dalam attribute_v N sehingga semua tipe yang disediakan platform adalah atribut berversi (namun atribut tidak berversi). Platform bertanggung jawab untuk memetakan tipe konkret yang disediakannya ke dalam atribut yang sesuai untuk memastikan bahwa kebijakan vendor terus berfungsi dan aturan yang disediakan untuk versi tertentu disertakan. Kombinasi kebijakan platform-publik dan kebijakan vendor memenuhi sasaran model arsitektur Android 8.0 untuk memungkinkan pembuatan platform dan vendor independen.

Pemetaan ke rantai atribut

Saat menggunakan atribut untuk dipetakan ke versi kebijakan, sebuah tipe dipetakan ke sebuah atribut atau beberapa atribut, memastikan objek yang diberi label dengan tipe tersebut dapat diakses melalui atribut yang sesuai dengan tipe sebelumnya.

Mempertahankan tujuan untuk menyembunyikan informasi versi dari penulis kebijakan berarti membuat atribut berversi secara otomatis dan menugaskannya ke jenis yang sesuai. Dalam kasus umum tipe statis, ini langsung: type_foo memetakan ke type_foo_v1 .

Untuk perubahan label objek seperti sysfs → sysfs_A atau mediaserver → audioserver , membuat pemetaan ini tidak sepele (dan dijelaskan dalam contoh di atas). Pemelihara kebijakan platform harus menentukan cara membuat pemetaan pada titik transisi untuk objek, yang membutuhkan pemahaman hubungan antara objek dan label yang ditetapkan dan menentukan kapan hal ini terjadi. Untuk kompatibilitas mundur, kerumitan ini perlu dikelola di sisi platform, yang merupakan satu-satunya partisi yang dapat ditingkatkan.

Versi uprev

Untuk kesederhanaan, platform Android merilis versi sepolicy saat cabang rilis baru 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 yang dipertahankan dalam /platform/system/sepolicy. 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. Uprev tidak selalu bilangan bulat. Misalnya, jika MR bump ke versi memerlukan perubahan yang tidak kompatibel di system/sepolicy/public tetapi bukan bump API, maka versi sepolicy itu bisa jadi: vN.1 . Versi yang ada di cabang pengembangan adalah perangkat 10000.0 yang tidak pernah digunakan dalam pengiriman.

Android mungkin menghentikan versi terlama saat upreving. Untuk masukan tentang kapan menghentikan versi, Android dapat mengumpulkan jumlah perangkat dengan kebijakan vendor yang menjalankan versi Android tersebut dan masih menerima pembaruan platform utama. Jika jumlahnya kurang dari ambang tertentu, versi tersebut tidak digunakan lagi.

Dampak kinerja dari beberapa atribut

Seperti yang dijelaskan di https://github.com/SELinuxProject/cil/issues/9 , sejumlah besar atribut yang ditetapkan ke suatu jenis mengakibatkan masalah kinerja jika cache kebijakan hilang.

Hal ini dipastikan menjadi masalah di Android, jadi perubahan dilakukan pada Android 8.0 untuk menghapus atribut yang ditambahkan ke kebijakan oleh compiler kebijakan, serta menghapus atribut yang tidak digunakan. Perubahan ini menyelesaikan regresi kinerja.

System_ext publik dan kebijakan publik produk

Mulai dari Android 11, partisi system_ext dan produk diizinkan untuk mengekspor tipe publik yang ditentukan ke partisi vendor. Seperti kebijakan publik platform, vendor menggunakan tipe dan aturan yang secara otomatis diterjemahkan ke dalam atribut berversi, misalnya dari type menjadi type_ N , di mana N adalah versi platform tempat partisi vendor dibuat.

Ketika system_ext dan partisi produk didasarkan pada versi platform yang sama N , sistem build menghasilkan file pemetaan dasar ke 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 mengakses type dengan atribut berversi type_ N .

Jika hanya system_ext dan partisi produk yang diperbarui, misalnya N ke N+1 (atau lebih baru), sementara vendor tetap di N , vendor mungkin kehilangan akses ke tipe system_ext dan partisi produk. Untuk mencegah kerusakan, partisi system_ext dan produk harus menyediakan file pemetaan dari tipe konkret menjadi atribut type_ N . Setiap mitra bertanggung jawab untuk memelihara file pemetaan, jika mereka akan mendukung N vendor dengan N+1 (atau lebih baru) system_ext dan partisi produk.

Untuk itu, mitra diharapkan untuk:

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

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

(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))

ke

(typeattributeset foo_type_N (foo_type bar_type))

dan kemudian diinstal ke partisi N+1 system_ext. N vendor dapat terus mengakses foo_type dan bar_type N+1 system_ext.

pelabelan konteks SELinux

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

konteks file

Android 8.0 memperkenalkan perubahan berikut untuk file_contexts :

• Untuk menghindari overhead kompilasi tambahan pada perangkat selama boot, file_contexts tidak lagi ada dalam bentuk biner. Alih-alih, mereka dapat dibaca, file teks ekspresi reguler seperti {property, service}_contexts (seperti sebelum 7.0).
• file_contexts dibagi antara dua file:
  • plat_file_contexts
    • file_context platform Android yang tidak memiliki label khusus perangkat, kecuali untuk melabeli bagian /vendor partisi yang harus diberi label secara tepat untuk memastikan file sepolicy berfungsi dengan baik.
    • Harus berada di partisi system di /system/etc/selinux/plat_file_contexts pada perangkat dan dimuat oleh init di awal bersama dengan vendor file_context .
  • vendor_file_contexts
    • file_context khusus perangkat dibuat dengan menggabungkan file_contexts yang ditemukan di direktori yang ditunjuk oleh BOARD_SEPOLICY_DIRS di file Boardconfig.mk perangkat.
    • Harus diinstal di /vendor/etc/selinux/vendor_file_contexts di partisi vendor dan dimuat oleh init di awal bersama dengan platform file_context .

Konteks properti

Di Android 8.0, property_contexts dibagi antara dua file:

• plat_property_contexts
  • property_context platform Android 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 vendor property_contexts .
• vendor_property_contexts
  • property_context khusus perangkat dibangun dengan menggabungkan property_contexts yang ditemukan di direktori yang ditunjuk oleh BOARD_SEPOLICY_DIRS di file Boardconfig.mk perangkat.
  • Harus berada di partisi vendor di /vendor/etc/selinux/vendor_property_contexts dan dimuat oleh init di awal bersama dengan platform property_context

konteks layanan

Di Android 8.0, service_contexts dibagi antara file-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 vendor service_contexts .
• vendor_service_contexts
  • service_context khusus perangkat dibuat dengan menggabungkan service_contexts yang ditemukan di direktori yang ditunjuk oleh BOARD_SEPOLICY_DIRS di file Boardconfig.mk perangkat.
  • Harus berada di partisi vendor di /vendor/etc/selinux/vendor_service_contexts dan dimuat oleh servicemanager di awal bersama dengan platform service_contexts .
  • Meskipun servicemanager mencari file ini saat boot, untuk perangkat TREBLE yang sepenuhnya kompatibel, vendor_service_contexts TIDAK HARUS ada. Ini karena semua interaksi antara vendor dan proses system 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 khusus perangkat dibuat dengan menggabungkan hwservice_contexts yang ditemukan di direktori yang ditunjuk oleh BOARD_SEPOLICY_DIRS di 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 dibangun dengan menggabungkan vndservice_contexts yang ditemukan di direktori yang ditunjuk 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 di awal.

konteks aplikasi

Di Android 8.0, seapp_contexts dibagi antara dua file:

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

izin MAC

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

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