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 partisivendor
. Kebijakan platform mengharuskan ini untuk mengakses implementasi HAL passthrough. - Semua
exec_types
baru yang ditambahkan di partisivendor
melalui vendor SEPolicy harus memiliki atributvendor_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 partisivendor
. - 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 v1
→ v2
, kebijakan platform harus memuat:
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
darisysfs
menjadisysfs_A
). Kode vendor bergantung pada aturan yang memungkinkan akses kesysfs
, dan perlu menyertakan aturan tersebut 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 (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 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 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 antaravendor
dancoredomains
. 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
.
- Kode vendor harus menggunakan
-
system_executes_vendor_violators
. Atribut untuk semua domain sistem (kecualishell 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 menjadicoredomain
.
- Ketergantungan platform pada biner vendor harus berada di belakang HIDL HAL.
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:
- 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.
- 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 layanansurfaceflinger
Binder, yang diizinkan untuk diakses oleh aplikasi. -
hal_omx_hwservice
. Ini adalah versi HwBinder dari layananmediacodec
Binder, yang boleh diakses oleh aplikasi. -
hal_codec2_hwservice
. Ini adalah versi terbaru darihal_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
, lalumediaserver
(yang merupakanbinderservicedomain
) pada gilirannya berkomunikasi denganhal_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 sysfs
→ sysfs_A
atau mediaserver
→ audioserver
, 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:
- Salin file pemetaan dasar yang dihasilkan dari
N
system_ext dan partisi produk ke pohon sumbernya. - Ubah file pemetaan sesuai kebutuhan.
- 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 olehinit
di awal bersama dengan vendorfile_context
.
-
-
vendor_file_contexts
-
file_context
khusus perangkat dibuat dengan menggabungkanfile_contexts
yang ditemukan di direktori yang ditunjuk olehBOARD_SEPOLICY_DIRS
di fileBoardconfig.mk
perangkat. - Harus diinstal di
/vendor/etc/selinux/vendor_file_contexts
di partisivendor
dan dimuat olehinit
di awal bersama dengan platformfile_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 olehinit
di awal bersama dengan vendorproperty_contexts
.
-
-
vendor_property_contexts
-
property_context
khusus perangkat yang dibuat dengan menggabungkanproperty_contexts
yang ditemukan di direktori yang ditunjuk olehBOARD_SEPOLICY_DIRS
dalam fileBoardconfig.mk
perangkat. - Harus berada di partisi
vendor
di/vendor/etc/selinux/vendor_property_contexts
dan dimuat olehinit
di awal bersama dengan platformproperty_context
-
Konteks layanan
Di Android 8.0, service_contexts
dibagi menjadi beberapa file berikut:
-
plat_service_contexts
-
service_context
khusus platform Android untukservicemanager
.service_context
tidak memiliki label khusus perangkat. - Harus berada di partisi
system
di/system/etc/selinux/plat_service_contexts
dan dimuat olehservicemanager
di awal bersama dengan vendorservice_contexts
.
-
-
vendor_service_contexts
-
service_context
khusus perangkat yang dibuat dengan menggabungkanservice_contexts
yang ditemukan di direktori yang ditunjuk olehBOARD_SEPOLICY_DIRS
di fileBoardconfig.mk
perangkat. - Harus berada di partisi
vendor
di/vendor/etc/selinux/vendor_service_contexts
dan dimuat olehservicemanager
di awal bersama dengan platformservice_contexts
. - Meskipun
servicemanager
mencari file ini pada saat boot, untuk perangkatTREBLE
yang sepenuhnya patuh,vendor_service_contexts
TIDAK HARUS ada. Hal ini karena semua interaksi antaravendor
dan prosessystem
HARUS melaluihwservicemanager
/hwbinder
.
-
-
plat_hwservice_contexts
- Platform Android
hwservice_context
untukhwservicemanager
yang tidak memiliki label khusus perangkat. - Harus berada di partisi
system
di/system/etc/selinux/plat_hwservice_contexts
dan dimuat olehhwservicemanager
di awal bersama denganvendor_hwservice_contexts
.
- Platform Android
-
vendor_hwservice_contexts
-
hwservice_context
khusus perangkat dibuat dengan menggabungkanhwservice_contexts
yang ditemukan di direktori yang ditunjuk olehBOARD_SEPOLICY_DIRS
di fileBoardconfig.mk
perangkat. - Harus berada di partisi
vendor
di/vendor/etc/selinux/vendor_hwservice_contexts
dan dimuat olehhwservicemanager
di awal bersama denganplat_service_contexts
.
-
-
vndservice_contexts
-
service_context
khusus perangkat untukvndservicemanager
yang dibuat dengan menggabungkanvndservice_contexts
yang ditemukan di direktori yang ditunjuk olehBOARD_SEPOLICY_DIRS
diBoardconfig.mk
perangkat. - File ini harus berada di partisi
vendor
di/vendor/etc/selinux/vndservice_contexts
dan dimuat olehvndservicemanager
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.
- Platform Android
-
vendor_seapp_contexts
- Ekstensi khusus perangkat ke platform
seapp_context
dibuat dengan menggabungkanseapp_contexts
yang ditemukan di direktori yang ditunjuk olehBOARD_SEPOLICY_DIRS
di fileBoardconfig.mk
perangkat. - Harus berada di partisi
vendor
di/vendor/etc/selinux/vendor_seapp_contexts
.
- Ekstensi khusus perangkat ke platform
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/.
- Platform Android
-
mac_permissions.xml
non-Platform- Ekstensi khusus perangkat ke platform
mac_permissions.xml
yang dibuat darimac_permissions.xml
ditemukan di direktori yang ditunjuk olehBOARD_SEPOLICY_DIRS
di fileBoardconfig.mk
perangkat. - Harus berada di partisi
vendor
di/vendor/etc/selinux/.
- Ekstensi khusus perangkat ke platform