Kompatibilitas Kebijakan

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

Desain kebijakan SELinux berbasis treble mempertimbangkan perbedaan biner antara platform dan kebijakan 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 pribadi dan publik. Komponen publik terdiri dari kebijakan dan infrastruktur terkait, yang dijamin tersedia untuk versi platform. Kebijakan ini akan diperlihatkan kepada penulis kebijakan vendor untuk memungkinkan vendor membuat file kebijakan vendor, yang bila digabungkan dengan kebijakan yang disediakan platform, menghasilkan kebijakan yang berfungsi penuh untuk perangkat.

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

Android mengelola pemetaan antara jenis beton yang diekspor dalam kebijakan platform dan atribut berversi yang sesuai untuk setiap versi platform . Ini memastikan bahwa ketika objek diberi label dengan tipe, itu tidak merusak perilaku yang dijamin oleh kebijakan platform-publik di versi sebelumnya. Pemetaan ini dipertahankan dengan menjaga file pemetaan tetap mutakhir 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 platform dan kebijakan vendor tetap terpisah. Misalnya, jika vendor memberi label /dev/foo dan platform kemudian memberi label /dev/foo dalam OTA berikutnya, akan ada perilaku yang tidak ditentukan. Untuk SELinux, ini bermanifestasi sebagai tabrakan pelabelan. Node perangkat hanya dapat memiliki satu label yang menentukan label mana pun yang diterapkan terakhir. Sebagai akibat:

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

Properti sistem juga memiliki potensi untuk penamaan tabrakan yang dapat mengakibatkan perilaku 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-objek ini.

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

Ketik/atribut namespace

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

type foo, domain; → type np_foo, domain;

Properti sistem dan proses pelabelan kepemilikan

Menghindari tabrakan pelabelan paling baik diselesaikan 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 awalan sendiri:

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

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

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

Kepemilikan file

Mencegah tabrakan untuk file merupakan tantangan karena platform dan kebijakan vendor umumnya memberikan label untuk semua sistem file. Tidak seperti penamaan tipe, penspasian nama 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 penegakan teknis. Di masa mendatang, rekomendasi ini akan diberlakukan oleh Vendor Test Suite (VTS).

Sistem (/ sistem)

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

Penjual (/ penjual)

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

/vendor Label yang disediakan platform Proses platform tergantung pada label
/vendor(/. * )? vendor_file Semua klien HAL dalam kerangka kerja, 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.

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 SEPolicy vendor harus memiliki atribut vendor_file_type . Ini diberlakukan melalui neverallows.
  • Untuk menghindari konflik dengan pembaruan platform/kerangka kerja di masa mendatang, hindari pelabelan file selain exec_types di 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 dengan menggunakan label genfscon . Di Android 7.0, baik platform maupun kebijakan vendor menggunakan genfscon untuk melabeli file dalam procfs .

Rekomendasi: Hanya kebijakan platform yang berlabel /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 sebaliknya harus menggunakan tipe proc generik untuk menambahkan aturan untuk domain vendor. Ini memungkinkan pembaruan platform untuk mengakomodasi antarmuka kernel masa depan 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, platform dan label vendor debugfs .

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

Tracef (/sys/kernel/debug/tracing)

Tracefs dapat diberi label di file_contexts dan genfscon . Di Android 7.0, hanya platform yang memberi label 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 mungkin memberi label node sysfs yang tidak spesifik untuk perangkat. Jika tidak, hanya vendor yang dapat melabeli file.

tmpfs (/ dev)

File di /dev mungkin 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 (mis., /dev/vendor/foo , /dev/vendor/socket/bar ).

Rootf (/)

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

Rekomendasi: Hanya sistem yang dapat melabeli file dalam / .

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 jenis sumber dan target untuk kelas dan izin objek tertentu. Setiap objek (proses, file, dll.) yang terpengaruh oleh kebijakan SELinux mungkin hanya memiliki satu jenis, tetapi jenis itu mungkin memiliki beberapa atribut.

Kebijakan ditulis sebagian besar dalam hal jenis yang ada:

allow source_type target_type:target_class permission(s);

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

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, kami dapat memberikan objek yang mendasari jenis 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 hanya diperlukan 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 objek yang diandalkan oleh kode vendor, mempertahankan akses.
  • Kemampuan untuk mencela kebijakan . Dicapai dengan menggambarkan set kebijakan dengan jelas ke dalam atribut yang dapat dihapus segera setelah versi yang terkait tidak lagi didukung. Pengembangan dapat dilanjutkan di platform, mengetahui kebijakan lama masih ada dalam kebijakan vendor dan akan dihapus secara otomatis ketika/jika ditingkatkan.

Kebijakan dapat ditulis

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

Atribut dalam kebijakan publik tidak berversi, melainkan ada sebagai API di mana platform dan kebijakan vendor dapat dibangun untuk menjaga antarmuka antara dua partisi tetap stabil. Baik penulis kebijakan platform maupun vendor dapat terus menulis kebijakan seperti yang ditulis 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) itu diubah menjadi kebijakan yang akan masuk ke bagian vendor perangkat (ditampilkan dalam Bahasa Menengah Umum (CIL) yang diubah):

 (allow source_foo_vN target_bar_vN (class (perm)))

Karena kebijakan vendor tidak pernah berada di depan platform, kebijakan tersebut seharusnya tidak berkaitan dengan versi sebelumnya. Namun, kebijakan platform perlu mengetahui seberapa jauh ke belakang kebijakan vendor, menyertakan atribut ke jenisnya, dan menetapkan kebijakan yang sesuai dengan atribut berversi.

Perbedaan kebijakan

Membuat atribut secara otomatis dengan menambahkan _v N ke akhir setiap tipe tidak melakukan apa pun tanpa memetakan atribut ke tipe di seluruh perbedaan versi. Android memelihara pemetaan antara versi untuk atribut dan pemetaan tipe ke atribut tersebut. Ini dilakukan dalam file pemetaan yang disebutkan di atas dengan pernyataan, seperti (CIL):

(typeattributeset foo_vN (foo))

Peningkatan platform

Bagian berikut merinci skenario untuk peningkatan platform.

Jenis yang sama

Skenario ini terjadi saat objek tidak mengubah label dalam versi kebijakan. Ini sama untuk jenis sumber dan target dan dapat dilihat dengan /dev/binder , yang diberi label binder_device di semua rilis. Ini 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 ketika platform telah menambahkan jenis baru, yang dapat terjadi saat menambahkan fitur baru atau selama pengerasan kebijakan.

  • Fitur baru . Saat tipe memberi label 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 menautkan kembali ke rantai atribut yang sesuai dengan yang sebelumnya (mirip dengan contoh sebelumnya yang mengubah /sys/A dari sysfs ke sysfs_A ). Kode vendor bergantung pada aturan yang memungkinkan akses ke sysfs , dan perlu 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, suatu 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 bahwa ketika label yang ada digunakan, penambahan atribut lama tipe baru akan menyebabkan objek lain juga dilabeli dengan tipe ini. menjadi baru dapat diakses. 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, saat Android menambahkan pengelola objek servicemanager yang membuat izin tambah, temukan, dan daftar, daemon vendor yang ingin mendaftar ke pengelola 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 perlu 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 citra vendor mendapatkan akses. Jika ini menghasilkan kebijakan keamanan yang tidak dapat diterima (seperti yang mungkin terjadi dengan perubahan manajer layanan), pemutakhiran vendor berpotensi dipaksakan.

Kelas/izin yang dihapus

Skenario ini terjadi saat manajer objek dihapus (seperti manajer objek ZygoteConnection ) dan tidak akan menyebabkan masalah. Kelas dan izin pengelola objek 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 dibutuhkan untuk menjelaskan proses baru, binari, perangkat, subsistem, dan data yang disimpan. Karena itu, sangat penting untuk mengizinkan pembuatan tipe yang ditentukan vendor.

Karena kebijakan vendor selalu yang tertua di perangkat, tidak perlu secara otomatis mengonversi semua jenis vendor 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 berlabel tipe ini (seperti domain , sysfs_type , dll.). Agar platform terus berinteraksi dengan benar dengan objek-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

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 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 domain init dan shell domains ) 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 tersebut pada binari vendor harus berada di belakang HIDL HAL.

      ATAU

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

Atribut yang tidak dipercaya

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 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 bergantung pada identitas aplikasi untuk otorisasi. Jadi, untuk amannya, asumsi default adalah bahwa setiap layanan HwBinder memperlakukan semua kliennya sebagai sama-sama berwenang untuk melakukan operasi yang ditawarkan oleh layanan tersebut.
  2. Server HAL (bagian 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 (hingga 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 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 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 Binder mediacodec , 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 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 atribut untrusted .

Rekomendasi:

  • Aplikasi yang tidak dipercaya 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 pembuatan yang memastikan semua file di lokasi tertentu memiliki atribut yang sesuai (seperti, semua file di sysfs memiliki atribut sysfs_type yang diperlukan).

Kebijakan platform-publik

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

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

Pemetaan ke rantai atribut

Saat menggunakan atribut untuk dipetakan ke versi kebijakan, tipe memetakan ke 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 pembuat kebijakan berarti secara otomatis membuat atribut berversi dan menetapkannya ke jenis yang sesuai. Dalam kasus umum tipe statis, ini mudah: type_foo memetakan ke type_foo_v1 .

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

Peningkatan versi

Untuk kesederhanaan, platform Android merilis versi sepolicy ketika cabang rilis baru dipotong. Seperti dijelaskan di atas, nomor versi terdapat dalam PLATFORM_SEPOLICY_VERSION dan berbentuk MM.nn , di mana MM sesuai dengan nilai SDK dan nn adalah nilai pribadi yang dipertahankan di /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 dalam system/sepolicy/public tetapi bukan bump API, maka versi sepolicy tersebut dapat berupa: vN.1 . Versi yang ada di cabang pengembangan adalah perangkat yang tidak pernah digunakan dalam pengiriman 10000.0 .

Android dapat menghentikan versi terlama saat meningkatkan. Untuk masukan tentang kapan harus 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 batas tertentu, versi tersebut tidak digunakan lagi.

Dampak kinerja dari beberapa atribut

Seperti yang dijelaskan dalam https://github.com/SELinuxProject/cil/issues/9 , sejumlah besar atribut yang ditetapkan untuk suatu jenis menghasilkan masalah kinerja jika cache kebijakan tidak ada.

Ini dipastikan menjadi masalah di Android, jadi perubahan dilakukan pada Android 8.0 untuk menghapus atribut yang ditambahkan ke kebijakan oleh penyusun kebijakan, serta untuk 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 ke type_ N , di mana N adalah versi platform yang digunakan untuk membuat partisi vendor.

Ketika partisi system_ext dan produk didasarkan pada platform yang sama versi N , sistem pembangunan 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 partisi system_ext dan produk yang diperbarui, katakanlah 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 ke 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:

  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.

Sebagai contoh, anggaplah N system_ext memiliki satu tipe publik bernama foo_type . Kemudian system_ext/etc/selinux/mapping/ N .cil pada 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 N vendor, 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 platform dan kebijakan vendor, sistem membangun file konteks SELinux secara berbeda untuk memisahkannya.

Konteks file

Android 8.0 memperkenalkan perubahan berikut untuk file_contexts :

  • Untuk menghindari overhead kompilasi tambahan pada perangkat saat boot, file_contexts tidak lagi ada dalam bentuk biner. Sebagai gantinya, mereka dapat dibaca, file teks ekspresi reguler seperti {property, service}_contexts (seperti sebelum 7.0).
  • file_contexts dibagi menjadi dua file:
    • plat_file_contexts
      • file_context platform Android yang tidak memiliki label khusus perangkat, kecuali untuk bagian pelabelan partisi /vendor yang harus diberi label dengan tepat untuk memastikan berfungsinya file sepolicy.
      • Harus berada di partisi system di /system/etc/selinux/plat_file_contexts pada perangkat dan dimuat oleh init di awal bersama dengan file_context vendor.
    • vendor_file_contexts
      • file_context khusus perangkat yang dibuat dengan menggabungkan file_contexts 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 menjadi 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 yang dibuat 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_contexts service_context 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 pada saat boot, untuk perangkat TREBLE yang sepenuhnya sesuai, 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 yang dibuat dengan menggabungkan hwservice_contexts 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
    • vndservicemanager service_context dibuat dengan menggabungkan vndservice_contexts 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 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 di /system/etc/selinux/plat_seapp_contexts.
  • vendor_seapp_contexts
    • Ekstensi khusus perangkat ke platform seapp_context yang dibuat dengan menggabungkan seapp_contexts 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 menjadi dua file:

  • Platform mac_permissions.xml
    • Platform Android mac_permissions.xml 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 yang dibuat dari mac_permissions.xml ditemukan di direktori yang ditunjuk oleh BOARD_SEPOLICY_DIRS di file Boardconfig.mk perangkat.
    • Harus berada di partisi vendor di /vendor/etc/selinux/.