Kompatibilitas Kebijakan

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

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

Di Android 8.0 dan lebih tinggi, kebijakan global SELinux dibagi menjadi komponen privat dan publik. Komponen publik terdiri dari kebijakan dan infrastruktur terkait, yang dijamin tersedia untuk versi platform. Kebijakan ini akan dipaparkan kepada penulis kebijakan vendor untuk memungkinkan vendor membuat file kebijakan vendor, yang bila 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 kemudahan penulisan kebijakan, tipe 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 memelihara pemetaan antara tipe konkret yang diekspor dalam kebijakan platform dan atribut versi yang sesuai untuk setiap versi platform . Hal ini memastikan bahwa ketika objek diberi label dengan suatu tipe, hal ini tidak merusak perilaku yang dijamin oleh kebijakan publik platform di versi sebelumnya. Pemetaan ini dikelola dengan selalu memperbarui file pemetaan untuk setiap versi platform , yang menjaga informasi keanggotaan atribut untuk setiap jenis diekspor dalam kebijakan publik.

Kepemilikan dan pelabelan objek

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

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

Properti sistem juga berpotensi menimbulkan tabrakan penamaan yang dapat mengakibatkan perilaku tidak terdefinisi pada sistem (dan juga 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 tersebut.

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

Spasi nama jenis/atribut

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

type foo, domain; → type np_foo, domain;

Properti sistem dan kepemilikan pelabelan proses

Menghindari tabrakan pelabelan paling baik diselesaikan dengan menggunakan namespace 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:

Jenis properti Awalan yang dapat diterima
properti kontrol ctl.vendor.
ctl.start$vendor.
ctl.stop$vendor.
init.svc.vendor.
dapat dibaca dan ditulis 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 berkas

Mencegah tabrakan pada file merupakan suatu tantangan karena kebijakan platform dan vendor umumnya memberikan label untuk semua sistem file. Berbeda dengan penamaan tipe, penspasian nama file tidak praktis karena banyak file dibuat oleh kernel. Untuk mencegah tabrakan ini, ikuti panduan penamaan sistem file di bagian ini. Untuk Android 8.0, ini adalah rekomendasi tanpa penerapan teknis. Di masa mendatang, rekomendasi ini akan diterapkan oleh Vendor Test Suite (VTS).

Sistem (/ sistem)

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

Penjual (/penjual)

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

/vendor Label yang disediakan platform Proses platform tergantung pada labelnya
/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 (ditegakkan melalui neverallows ) saat memberi label pada file tambahan di partisi vendor :

  • vendor_file harus menjadi label default untuk semua file di partisi vendor . Kebijakan platform 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 . Hal ini ditegakkan melalui neverallows.
  • Untuk menghindari konflik dengan pembaruan platform/kerangka kerja di masa mendatang, hindari memberi label file selain exec_types di partisi vendor .
  • Semua dependensi perpustakaan 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 label genfscon . Di Android 7.0, platform dan kebijakan vendor menggunakan genfscon untuk memberi label 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 memberi label secara eksplisit dan sebaiknya menggunakan tipe proc generik untuk menambahkan aturan untuk domain vendor. Hal ini memungkinkan pembaruan platform untuk mengakomodasi antarmuka kernel masa depan yang diekspos melalui procfs dan memberi label secara eksplisit sesuai kebutuhan.

Debugf (/sys/kernel/debug)

Debugfs dapat diberi label dalam 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 harus menghapus debugfs .

Pelacakan (/sys/kernel/debug/tracing)

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

Rekomendasi: Hanya platform yang boleh memberi label tracefs .

Sysfs (/sys)

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

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

tmpfs (/ dev)

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

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

Rootf (/)

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

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

Data (/data)

Data diberi label melalui kombinasi file_contexts dan seapp_contexts .

Rekomendasi: Larang pelabelan vendor di luar /data/vendor . Hanya platform yang dapat memberi label pada bagian lain /data .

Atribut kompatibilitas

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

Kebijakan sebagian besar ditulis dalam bentuk tipe yang ada:

allow source_type target_type:target_class permission(s);

Ini berhasil karena kebijakan tersebut ditulis dengan pengetahuan tentang semua jenis. Namun, jika kebijakan vendor dan kebijakan platform menggunakan tipe 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. Misalnya:

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 kurangnya kebijakan untuk tipe sysfs_A yang baru.

Dengan mendefinisikan kebijakan dalam bentuk atribut, kita dapat memberikan objek yang mendasarinya sebuah tipe yang memiliki atribut yang sesuai dengan kebijakan untuk platform dan kode vendor. Hal ini dapat dilakukan untuk semua tipe agar secara efektif menciptakan kebijakan atribut dimana tipe konkret tidak pernah digunakan. Dalam praktiknya, hal ini hanya diperlukan untuk bagian kebijakan yang tumpang tindih antara platform dan vendor, yang didefinisikan dan disediakan sebagai kebijakan publik platform yang dibuat 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 kode vendor yang diandalkan, sehingga menjaga akses.
  • Kemampuan untuk mencela kebijakan . Dicapai dengan menggambarkan secara jelas kumpulan kebijakan ke dalam atribut yang dapat dihapus segera setelah versi yang sesuai tidak lagi didukung. Pengembangan dapat dilanjutkan di platform, mengetahui kebijakan lama masih ada dalam kebijakan vendor dan akan dihapus secara otomatis ketika/jika ditingkatkan.

Kemampuan menulis kebijakan

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. Tipe foo dipetakan ke atribut foo_v N , dengan N versi yang ditargetkan. vN sesuai dengan variabel build PLATFORM_SEPOLICY_VERSION dan berbentuk MM.NN , dengan MM sesuai dengan nomor SDK platform dan NN adalah versi khusus sepolicy platform.

Atribut dalam kebijakan publik tidak memiliki versi, melainkan ada sebagai API yang dapat dibangun oleh platform dan kebijakan vendor untuk menjaga antarmuka antara dua partisi tetap stabil. Penulis kebijakan platform dan vendor dapat terus menulis kebijakan seperti yang ditulis saat ini.

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

 (allow source_foo_vN target_bar_vN (class (perm)))

Karena kebijakan vendor tidak pernah mendahului platform, maka kebijakan vendor tidak perlu khawatir dengan versi sebelumnya. Namun, kebijakan platform perlu mengetahui sejauh mana kebijakan vendor, memasukkan atribut ke jenisnya, dan menetapkan kebijakan yang sesuai dengan versi atribut.

Perbedaan kebijakan

Membuat atribut secara otomatis dengan menambahkan _v N di akhir setiap tipe tidak akan menghasilkan apa-apa tanpa memetakan atribut ke tipe di seluruh perbedaan versi. Android mengelola pemetaan antar versi untuk atribut dan pemetaan tipe ke atribut tersebut. Hal ini dilakukan pada file pemetaan yang disebutkan di atas dengan pernyataan, seperti (CIL):

(typeattributeset foo_vN (foo))

Peningkatan platform

Bagian berikut merinci skenario untuk peningkatan platform.

Tipe yang sama

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

binder_device_v1 … binder_device_vN

Saat memutakhirkan dari v1v2 , 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 …)
Tipe baru

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

  • Fitur baru . Ketika tipe tersebut memberi label pada objek yang sebelumnya tidak ada (seperti proses layanan baru), kode vendor sebelumnya tidak berinteraksi langsung dengannya 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 . Jika tipe mewakili pengerasan kebijakan, atribut tipe baru harus terhubung kembali ke rantai atribut yang sesuai dengan yang sebelumnya (mirip dengan contoh sebelumnya yang mengubah /sys/A dari sysfs menjadi sysfs_A ). Kode vendor bergantung pada aturan yang memungkinkan akses ke sysfs , dan perlu menyertakan aturan tersebut sebagai atribut tipe baru.

Saat memutakhirkan dari v1v2 , 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 (yang jarang terjadi) ini terjadi ketika suatu tipe dihapus, yang dapat terjadi ketika objek yang mendasarinya:

  • Tetap tetapi mendapat label 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, namun seluruh sistem sekarang harus dapat mengaksesnya dengan atribut barunya.

Jika atribut yang dialihkan adalah baru, maka pelabelan ulang sama seperti pada kasus tipe baru, hanya saja ketika label yang sudah ada digunakan, penambahan atribut lama tipe baru akan menyebabkan objek lain juga diberi label dengan tipe ini. menjadi baru dapat diakses. Ini pada dasarnya adalah apa yang dilakukan oleh platform dan dianggap sebagai pengorbanan yang dapat diterima untuk menjaga kompatibilitas.

(typeattribute sysfs_v1)
(allow … sysfs_v1 …)

Contoh Versi 1: Menciutkan tipe (menghapus sysfs_A)

Saat memutakhirkan dari v1v2 , 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 v1v2 , 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 ketika pemutakhiran platform memperkenalkan komponen kebijakan baru yang tidak ada di versi sebelumnya. Misalnya, saat Android menambahkan manajer objek servicemanager yang membuat izin tambah, temukan, dan daftar, daemon vendor yang ingin mendaftar ke 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 berdasarkan kebijakan vendor untuk menggunakan kelas baru tanpa hambatan, kebijakan platform perlu menyertakan aturan yang serupa dengan:

allow {domain -coredomain} *:new_class perm;

Hal ini bahkan mungkin memerlukan kebijakan yang mengizinkan akses untuk semua jenis antarmuka (kebijakan publik), untuk memastikan citra vendor mendapatkan akses. Jika hal ini mengakibatkan kebijakan keamanan yang tidak dapat diterima (seperti yang mungkin terjadi pada perubahan manajer layanan), peningkatan vendor mungkin terpaksa dilakukan.

Menghapus kelas/izin

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

Kustomisasi vendor untuk tipe baru/yang diberi label ulang

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

Karena kebijakan vendor selalu yang terlama di perangkat, tidak perlu mengonversi semua jenis vendor secara otomatis menjadi atribut dalam kebijakan. Platform tidak bergantung pada apa pun yang tercantum 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-objek ini, atribut dan tipe harus diterapkan dengan tepat dan aturan spesifik 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, namun perangkat yang diluncurkan dengan Android 9 tidak boleh menggunakan atribut berikut.

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 pada 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 mengeksekusi biner vendor. Eksekusi biner vendor memiliki API yang tidak stabil. Platform tidak boleh mengeksekusi biner vendor secara langsung. Rekomendasi:
    • Ketergantungan platform pada biner 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 tidak tepercaya

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

  1. Server HwBinder tidak melakukan otentikasi klien karena HIDL saat ini tidak memaparkan informasi UID pemanggil. Meskipun HIDL mengekspos data tersebut, banyak layanan HwBinder yang beroperasi pada tingkat di bawah aplikasi (seperti HAL) atau tidak harus bergantung pada identitas aplikasi untuk otorisasi. Jadi, agar aman, asumsi defaultnya adalah bahwa setiap layanan HwBinder memperlakukan semua kliennya memiliki wewenang yang sama 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 dibandingkan 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 yang aman

Layanan yang aman meliputi:

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

Atribut yang bisa digunakan

Semua hwservices yang tidak dianggap aman memiliki atribut untrusted_app_visible_hwservice . Server HAL terkait memiliki atribut untrusted_app_visible_halserver . Perangkat yang 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 berkomunikasi dengan binderservicedomain , lalu mediaserver (yang merupakan binderservicedomain ) pada gilirannya berkomunikasi dengan hal_graphics_allocator .

    ATAU

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

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

Kebijakan platform-publik

Kebijakan platform-publik adalah inti dari penyesuaian model arsitektur Android 8.0 tanpa sekadar mempertahankan gabungan kebijakan platform dari v1 dan v2. Vendor dihadapkan pada subset kebijakan platform yang berisi tipe dan atribut yang dapat digunakan serta aturan pada tipe 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 sehingga semua jenis yang disediakan platform adalah atribut yang diberi versi (namun atribut tidak diberi versi). Platform bertanggung jawab untuk memetakan tipe konkrit 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 tujuan model arsitektur Android 8.0 yang memungkinkan pembuatan platform dan vendor independen.

Memetakan ke rantai atribut

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

Untuk perubahan label objek seperti sysfssysfs_A atau mediaserveraudioserver , membuat pemetaan ini bukanlah hal yang sepele (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 ke belakang, kompleksitas ini perlu dikelola di sisi platform, yang merupakan satu-satunya partisi yang mungkin mengalami peningkatan.

Peningkatan versi

Untuk mempermudah, platform Android merilis versi sepolicy ketika cabang rilis baru dipotong. Seperti dijelaskan di atas, nomor versi terkandung dalam PLATFORM_SEPOLICY_VERSION dan berbentuk MM.nn , dengan 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. Peningkatan tidak selalu bilangan bulat. Misalnya, jika perubahan MR pada suatu versi memerlukan perubahan yang tidak kompatibel pada system/sepolicy/public tetapi bukan perubahan API, maka versi sepolicy tersebut dapat berupa: vN.1 . Versi yang ada di cabang pengembangan adalah 10000.0 yang tidak pernah digunakan dalam perangkat pengiriman.

Android mungkin tidak lagi menggunakan versi terlama saat melakukan perbaikan. Sebagai masukan tentang kapan suatu versi akan dihentikan, 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 ke suatu jenis mengakibatkan masalah kinerja jika cache kebijakan hilang.

Hal ini dipastikan menjadi masalah di Android, sehingga 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.

Kebijakan publik System_ext dan produk publik

Mulai Android 11, partisi system_ext dan product diizinkan 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 menjadi dasar partisi vendor.

Ketika partisi system_ext dan product 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 partisi system_ext dan product yang diperbarui, katakanlah N ke N+1 (atau lebih baru), sementara vendor tetap di N , vendor mungkin kehilangan akses ke jenis partisi system_ext dan product. Untuk mencegah kerusakan, partisi system_ext dan product harus menyediakan file pemetaan dari tipe konkrit 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 melakukan hal tersebut, 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 . Maka 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 ke N+1 system_ext foo_type dan bar_type .

Pelabelan konteks SELinux

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

Konteks berkas

Android 8.0 memperkenalkan perubahan berikut untuk file_contexts :

  • Untuk menghindari overhead kompilasi tambahan pada perangkat saat boot, file_contexts tidak ada lagi dalam bentuk biner. Sebaliknya, mereka adalah file teks ekspresi reguler yang dapat dibaca 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 memberi label pada bagian partisi /vendor 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 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 menjadi beberapa 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 yang 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 pada saat boot, untuk perangkat TREBLE yang sepenuhnya patuh, vendor_service_contexts TIDAK HARUS ada. Hal 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 dibuat 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 Seapp

Di Android 8.0, seapp_contexts dibagi menjadi dua file:

  • plat_seapp_contexts
    • Platform Android seapp_context 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 menjadi dua file:

  • Peron 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/.