Menyesuaikan SELinux

Setelah mengintegrasikan tingkat dasar fungsi SELinux dan menganalisis hasilnya secara menyeluruh, Anda dapat menambahkan setelan kebijakan Anda sendiri untuk mencakup penyesuaian Anda ke sistem operasi Android. Kebijakan ini tetap harus memenuhi persyaratan program Kompatibilitas Android dan tidak boleh menghapus setelan SELinux default.

Produsen tidak boleh menghapus kebijakan SELinux yang ada. Jika tidak, akan berisiko merusak implementasi Android SELinux dan aplikasi yang diaturnya. Hal ini mencakup aplikasi pihak ketiga yang kemungkinan perlu ditingkatkan agar mematuhi kebijakan dan beroperasi. Aplikasi tidak boleh memerlukan perubahan agar dapat terus berfungsi di perangkat yang mengaktifkan SELinux.

Saat mulai menyesuaikan SELinux, ingatlah untuk:

• Menulis kebijakan SELinux untuk semua daemon baru
• Gunakan domain standar jika sesuai
• Menetapkan domain ke proses apa pun yang dihasilkan sebagai layanan init
• Memahami makro sebelum menulis kebijakan
• Mengirimkan perubahan pada kebijakan inti ke AOSP

Dan ingatlah untuk tidak:

• Buat kebijakan yang tidak kompatibel
• Mengizinkan penyesuaian kebijakan pengguna akhir
• Mengizinkan penyesuaian kebijakan MDM
• Menakut-nakuti pengguna dengan pelanggaran kebijakan
• Menambahkan backdoor

Lihat bagian Fitur Keamanan Kernel dalam dokumen Definisi Kompatibilitas Android untuk persyaratan tertentu.

SELinux menggunakan pendekatan daftar yang diizinkan, yang berarti semua akses harus diizinkan secara eksplisit dalam kebijakan agar dapat diberikan. Karena kebijakan SELinux default Android sudah mendukung Project Open Source Android, Anda tidak perlu mengubah setelan SELinux dengan cara apa pun. Jika Anda menyesuaikan setelan SELinux, berhati-hatilah agar tidak merusak aplikasi yang ada. Untuk memulai:

1. Gunakan kernel Android terbaru.
2. Terapkan prinsip hak istimewa terendah.
3. Hanya berikan penambahan Anda sendiri pada Android. Kebijakan default berfungsi dengan codebase Proyek Open Source Android secara otomatis.
4. Memisahkan komponen software ke dalam modul yang melakukan tugas tunggal.
5. Buat kebijakan SELinux yang mengisolasi tugas tersebut dari fungsi yang tidak terkait.
6. Masukkan kebijakan tersebut dalam file *.te (ekstensi untuk file sumber kebijakan SELinux) dalam direktori /device/manufacturer/device-name/sepolicy dan gunakan variabel BOARD_SEPOLICY untuk menyertakannya dalam build Anda.
7. Buat domain baru permisif di awal. Hal ini dilakukan dengan menggunakan deklarasi permisif dalam file .te domain.
8. Analisis hasil dan pertajam definisi domain Anda.
9. Hapus deklarasi permisif jika tidak ada penolakan lebih lanjut yang muncul dalam build userdebug.

Setelah mengintegrasikan perubahan kebijakan SELinux, tambahkan langkah ke alur kerja pengembangan untuk memastikan kompatibilitas SELinux ke depannya. Dalam proses pengembangan software yang ideal, kebijakan SELinux hanya berubah saat model software berubah, bukan implementasi yang sebenarnya.

Saat Anda mulai menyesuaikan SELinux, audit penambahan Anda ke Android terlebih dahulu. Jika Anda telah menambahkan komponen yang menjalankan fungsi baru, pastikan komponen tersebut mematuhi kebijakan keamanan Android, serta kebijakan terkait apa pun yang dibuat oleh OEM, sebelum mengaktifkan mode penerapan.

Untuk mencegah masalah yang tidak perlu, sebaiknya Anda membuat kebijakan yang terlalu luas dan terlalu kompatibel daripada terlalu ketat dan tidak kompatibel, yang akan menyebabkan kerusakan fungsi perangkat. Sebaliknya, jika perubahan Anda akan bermanfaat bagi orang lain, Anda harus mengirimkan modifikasi ke kebijakan SELinux default sebagai patch. Jika patch diterapkan ke kebijakan keamanan default, Anda tidak perlu melakukan perubahan ini dengan setiap rilis Android baru.

Contoh pernyataan kebijakan

SELinux didasarkan pada bahasa komputer M4, sehingga mendukung berbagai makro untuk menghemat waktu.

Dalam contoh berikut, semua domain diberi akses untuk membaca dari atau menulis ke /dev/null dan membaca dari /dev/zero.

# Allow read / write access to /dev/null
allow domain null_device:chr_file { getattr open read ioctl lock append write};

# Allow read-only access to /dev/zero
allow domain zero_device:chr_file { getattr open read ioctl lock };

Pernyataan yang sama ini dapat ditulis dengan makro *_file_perms SELinux (singkatan):

# Allow read / write access to /dev/null
allow domain null_device:chr_file rw_file_perms;

# Allow read-only access to /dev/zero
allow domain zero_device:chr_file r_file_perms;

Contoh kebijakan

Berikut adalah contoh kebijakan lengkap untuk DHCP, yang akan kita pelajari di bawah:

type dhcp, domain;
permissive dhcp;
type dhcp_exec, exec_type, file_type;
type dhcp_data_file, file_type, data_file_type;

init_daemon_domain(dhcp)
net_domain(dhcp)

allow dhcp self:capability { setgid setuid net_admin net_raw net_bind_service
};
allow dhcp self:packet_socket create_socket_perms;
allow dhcp self:netlink_route_socket { create_socket_perms nlmsg_write };
allow dhcp shell_exec:file rx_file_perms;
allow dhcp system_file:file rx_file_perms;
# For /proc/sys/net/ipv4/conf/*/promote_secondaries
allow dhcp proc_net:file write;
allow dhcp system_prop:property_service set ;
unix_socket_connect(dhcp, property, init)

type_transition dhcp system_data_file:{ dir file } dhcp_data_file;
allow dhcp dhcp_data_file:dir create_dir_perms;
allow dhcp dhcp_data_file:file create_file_perms;

allow dhcp netd:fd use;
allow dhcp netd:fifo_file rw_file_perms;
allow dhcp netd:{ dgram_socket_class_set unix_stream_socket } { read write };
allow dhcp netd:{ netlink_kobject_uevent_socket netlink_route_socket
netlink_nflog_socket } { read write };

Mari kita bedah contohnya:

Di baris pertama, deklarasi jenis, daemon DHCP diwarisi dari kebijakan keamanan dasar (domain). Dari contoh pernyataan sebelumnya, DHCP dapat membaca dari dan menulis ke /dev/null.

Di baris kedua, DHCP diidentifikasi sebagai domain yang permisif.

Pada baris init_daemon_domain(dhcp), kebijakan menyatakan bahwa DHCP dibuat dari init dan diizinkan untuk berkomunikasi dengannya.

Pada baris net_domain(dhcp), kebijakan memungkinkan DHCP menggunakan fungsi jaringan umum dari domain net seperti membaca dan menulis paket TCP, berkomunikasi melalui soket, dan melakukan permintaan DNS.

Pada baris allow dhcp proc_net:file write;, kebijakan menyatakan DHCP dapat menulis ke file tertentu di /proc. Baris ini menunjukkan pemberian label file terperinci SELinux. Fungsi ini menggunakan label proc_net untuk membatasi akses tulis hanya ke file yang berada di bawah /proc/sys/net.

Blok terakhir dari contoh yang dimulai dengan allow dhcp netd:fd use; menggambarkan cara aplikasi dapat diizinkan untuk berinteraksi satu sama lain. Kebijakan tersebut menyatakan bahwa DHCP dan netd dapat berkomunikasi satu sama lain melalui deskriptor file, file FIFO, soket datagram, dan soket streaming UNIX. DHCP hanya dapat membaca dan menulis dari soket datagram dan soket streaming UNIX, bukan membuat atau membukanya.

Kontrol yang tersedia

ioctl read write create getattr setattr lock relabelfrom relabelto append
unlink link rename execute swapon quotaon mounton

add_name remove_name reparent search rmdir open audit_access execmod

ioctl read write create getattr setattr lock relabelfrom relabelto append bind
connect listen accept getopt setopt shutdown recvfrom sendto recv_msg send_msg
name_bind

mount remount unmount getattr relabelfrom relabelto transition associate
quotamod quotaget

fork transition sigchld sigkill sigstop signull signal ptrace getsched setsched
getsession getpgid setpgid getcap setcap share getattr setexec setfscreate
noatsecure siginh setrlimit rlimitinh dyntransition setcurrent execmem
execstack execheap setkeycreate setsockcreate

compute_av compute_create compute_member check_context load_policy
compute_relabel compute_user setenforce setbool setsecparam setcheckreqprot
read_policy

chown dac_override dac_read_search fowner fsetid kill setgid setuid setpcap
linux_immutable net_bind_service net_broadcast net_admin net_raw ipc_lock
ipc_owner sys_module sys_rawio sys_chroot sys_ptrace sys_pacct sys_admin
sys_boot sys_nice sys_resource sys_time sys_tty_config mknod lease audit_write
audit_control setfcap

aturan neverallow

Aturan neverallow SELinux melarang perilaku yang tidak boleh terjadi. Dengan pengujian kompatibilitas, aturan neverallow SELinux kini diterapkan di seluruh perangkat.

Panduan berikut ditujukan untuk membantu produsen menghindari error terkait aturan neverallow selama penyesuaian. Nomor aturan yang digunakan di sini sesuai dengan Android 5.1 dan dapat berubah menurut rilis.

Aturan 48: neverallow { domain -debuggerd -vold -dumpstate -system_server } self:capability sys_ptrace;
Lihat halaman utama untuk ptrace. Kemampuan sys_ptrace memberikan kemampuan untuk ptrace proses apa pun, yang memungkinkan kontrol yang besar atas proses lain dan hanya boleh dimiliki oleh komponen sistem yang ditetapkan, yang diuraikan dalam aturan. Kebutuhan akan kemampuan ini sering kali menunjukkan adanya sesuatu yang tidak dimaksudkan untuk build yang ditampilkan kepada pengguna atau fungsi yang tidak diperlukan. Hapus komponen yang tidak diperlukan.

Aturan 76: neverallow { domain -appdomain -dumpstate -shell -system_server -zygote } { file_type -system_file -exec_type }:file execute;
Aturan ini dimaksudkan untuk mencegah eksekusi kode arbitrer di sistem. Secara khusus, pernyataan ini menegaskan bahwa hanya kode di /system yang dijalankan, sehingga memungkinkan jaminan keamanan berkat mekanisme seperti booting terverifikasi. Sering kali, solusi terbaik saat mengalami masalah dengan aturan neverallow ini adalah memindahkan kode yang melanggar ke partisi /system.

Menyesuaikan SEPolicy di Android 8.0 dan yang lebih tinggi

Bagian ini memberikan panduan untuk kebijakan SELinux vendor di Android 8.0 dan yang lebih baru, termasuk detail tentang SEPolicy Project Open Source Android (AOSP) dan ekstensi SEPolicy. Untuk mengetahui informasi selengkapnya tentang cara kebijakan SELinux tetap kompatibel di berbagai partisi dan versi Android, lihat Kompatibilitas.

Penempatan kebijakan

Di Android 7.0 dan yang lebih lama, produsen perangkat dapat menambahkan kebijakan ke BOARD_SEPOLICY_DIRS, termasuk kebijakan yang dimaksudkan untuk meningkatkan kebijakan AOSP di berbagai jenis perangkat. Di Android 8.0 dan yang lebih baru, menambahkan kebijakan ke BOARD_SEPOLICY_DIRS hanya akan menempatkan kebijakan dalam image vendor.

Di Android 8.0 dan yang lebih baru, kebijakan ada di lokasi berikut di AOSP:

• system/sepolicy/public. Mencakup kebijakan yang diekspor untuk digunakan dalam kebijakan khusus vendor. Semuanya masuk ke infrastruktur kompatibilitas Android 8.0. Kebijakan publik dimaksudkan untuk tetap ada di seluruh rilis sehingga Anda dapat menyertakan apa pun /public dalam kebijakan yang disesuaikan. Oleh karena itu, jenis kebijakan yang dapat ditempatkan di /public lebih dibatasi. Pertimbangkan ini sebagai API kebijakan yang diekspor platform: Apa pun yang menangani antarmuka antara /system dan /vendor berada di sini.
• system/sepolicy/private. Mencakup kebijakan yang diperlukan untuk fungsi image sistem, tetapi kebijakan image vendor mana yang seharusnya tidak diketahui.
• system/sepolicy/vendor. Mencakup kebijakan untuk komponen yang masuk di /vendor, tetapi ada di hierarki platform inti (bukan direktori khusus perangkat). Ini adalah artefak perbedaan sistem build antara perangkat dan komponen global; secara konseptual, ini adalah bagian dari kebijakan khusus perangkat yang dijelaskan di bawah ini.
• device/manufacturer/device-name/sepolicy. Mencakup kebijakan khusus perangkat. Juga mencakup penyesuaian perangkat ke kebijakan, yang di Android 8.0 dan yang lebih tinggi sesuai dengan kebijakan untuk komponen pada image vendor.

Di Android 11 dan yang lebih tinggi, partisi system_ext dan produk juga dapat menyertakan kebijakan khusus partisi. Kebijakan system_ext dan produk juga dibagi menjadi publik dan pribadi, dan vendor dapat menggunakan kebijakan publik system_ext dan produk, seperti kebijakan sistem.

• SYSTEM_EXT_PUBLIC_SEPOLICY_DIRS. Menyertakan kebijakan yang diekspor untuk digunakan dalam kebijakan khusus vendor. Diinstal ke partisi system_ext.
• SYSTEM_EXT_PRIVATE_SEPOLICY_DIRS. Mencakup kebijakan yang diperlukan agar image system_ext berfungsi, tetapi kebijakan image vendor mana yang seharusnya tidak diketahui. Diinstal ke partisi system_ext.
• PRODUCT_PUBLIC_SEPOLICY_DIRS. Menyertakan kebijakan yang diekspor untuk digunakan dalam kebijakan khusus vendor. Diinstal ke partisi produk.
• PRODUCT_PRIVATE_SEPOLICY_DIRS. Menyertakan kebijakan yang diperlukan untuk fungsi gambar produk, tetapi kebijakan gambar vendor tidak boleh mengetahuinya. Diinstal ke partisi produk.

Skenario kebijakan yang didukung

Pada perangkat yang diluncurkan dengan Android 8.0 dan yang lebih tinggi, image vendor harus berfungsi dengan image sistem OEM dan image sistem AOSP referensi yang disediakan oleh Google (dan lulus CTS pada image referensi ini). Persyaratan ini memastikan pemisahan yang jelas antara framework dan kode vendor. Perangkat tersebut mendukung skenario berikut.

ekstensi khusus gambar vendor

Contoh: Menambahkan layanan baru ke vndservicemanager dari image vendor yang mendukung proses dari image vendor.

Seperti halnya perangkat yang diluncurkan dengan versi Android sebelumnya, tambahkan penyesuaian khusus perangkat di device/manufacturer/device-name/sepolicy. Kebijakan baru yang mengatur cara komponen vendor berinteraksi dengan (hanya) komponen vendor lain harus melibatkan jenis yang hanya ada di device/manufacturer/device-name/sepolicy. Kebijakan yang ditulis di sini memungkinkan kode di vendor berfungsi, tidak akan diperbarui sebagai bagian dari OTA khusus framework, dan ada dalam kebijakan gabungan di perangkat dengan image sistem AOSP referensi.

dukungan image vendor agar dapat berfungsi dengan AOSP

Contoh: Menambahkan proses baru (terdaftar dengan hwservicemanager dari image vendor) yang mengimplementasikan HAL yang ditentukan AOSP.

Seperti perangkat yang diluncurkan dengan versi Android sebelumnya, lakukan penyesuaian khusus perangkat di device/manufacturer/device-name/sepolicy. Kebijakan yang diekspor sebagai bagian dari system/sepolicy/public/ tersedia untuk digunakan, dan dikirim sebagai bagian dari kebijakan vendor. Jenis dan atribut dari kebijakan publik dapat digunakan dalam aturan baru yang menentukan interaksi dengan bit khusus vendor baru, tunduk pada batasan neverallow yang diberikan. Seperti kasus khusus vendor, kebijakan baru di sini tidak akan diperbarui sebagai bagian dari OTA khusus framework dan ada dalam kebijakan gabungan di perangkat dengan image sistem AOSP referensi.

ekstensi khusus image sistem

Contoh: Menambahkan layanan baru (terdaftar dengan servicemanager) yang hanya diakses oleh proses lain dari image sistem.

Tambahkan kebijakan ini ke system/sepolicy/private. Anda dapat menambahkan proses atau objek tambahan untuk mengaktifkan fungsi dalam image sistem partner, asalkan bit baru tersebut tidak perlu berinteraksi dengan komponen baru pada image vendor (khususnya, proses atau objek tersebut harus berfungsi sepenuhnya tanpa kebijakan dari image vendor). Kebijakan yang diekspor oleh system/sepolicy/public tersedia di sini seperti halnya untuk ekstensi khusus gambar vendor. Kebijakan ini merupakan bagian dari image sistem dan dapat diupdate dalam OTA khusus framework, tetapi tidak akan ada saat menggunakan image sistem AOSP referensi.

ekstensi image vendor yang menayangkan komponen AOSP yang diperluas

Contoh: HAL baru non-AOSP untuk digunakan oleh klien yang diperluas yang juga ada dalam image sistem AOSP (seperti system_server yang diperluas).

Kebijakan untuk interaksi antara sistem dan vendor harus disertakan dalam direktori device/manufacturer/device-name/sepolicy yang dikirimkan di partisi vendor. Ini serupa dengan skenario penambahan dukungan image vendor di atas agar berfungsi dengan image AOSP referensi, kecuali bahwa komponen AOSP yang dimodifikasi juga mungkin memerlukan kebijakan tambahan agar dapat beroperasi dengan benar dengan partisi sistem lainnya (yang tidak masalah selama elemen tersebut masih memiliki label jenis AOSP publik).

Kebijakan untuk interaksi komponen AOSP publik dengan ekstensi khusus image sistem harus berada di system/sepolicy/private.

ekstensi image sistem yang hanya mengakses antarmuka AOSP

Contoh: Proses sistem baru non-AOSP harus mengakses HAL yang diandalkan AOSP.

Ini mirip dengan contoh ekstensi khusus gambar sistem, kecuali bahwa komponen sistem baru dapat berinteraksi di seluruh antarmuka system/vendor. Kebijakan untuk komponen sistem baru harus dimasukkan ke system/sepolicy/private, yang dapat diterima asalkan melalui antarmuka yang telah dibuat oleh AOSP di system/sepolicy/public (yaitu, jenis dan atribut yang diperlukan untuk fungsi ada). Meskipun dapat disertakan dalam kebijakan khusus perangkat, kebijakan tidak akan dapat menggunakan jenis atau perubahan system/sepolicy/private lain (dengan cara apa pun yang memengaruhi kebijakan) akibat update khusus framework. Kebijakan ini dapat diubah di OTA khusus framework, tetapi tidak akan ada saat menggunakan image sistem AOSP (yang juga tidak akan memiliki komponen sistem baru).

ekstensi image vendor yang menyediakan komponen sistem baru

Contoh: Menambahkan HAL non-AOSP baru untuk digunakan oleh proses klien tanpa analog AOSP (sehingga memerlukan domainnya sendiri).

Serupa dengan contoh ekstensi AOSP, kebijakan untuk interaksi antara sistem dan vendor harus berada di direktori device/manufacturer/device-name/sepolicy yang dikirim di partisi vendor (untuk memastikan kebijakan sistem tidak memiliki pengetahuan tentang detail khusus vendor). Anda dapat menambahkan jenis publik baru yang memperluas kebijakan di system/sepolicy/public; hal ini hanya boleh dilakukan selain kebijakan AOSP yang ada, yaitu jangan menghapus kebijakan publik AOSP. Jenis publik baru kemudian dapat digunakan untuk kebijakan di system/sepolicy/private dan di device/manufacturer/device-name/sepolicy.

Perlu diingat bahwa setiap penambahan ke system/sepolicy/public akan menambahkan kompleksitas dengan mengekspos jaminan kompatibilitas baru yang harus dilacak dalam file pemetaan dan yang tunduk pada pembatasan lain. Hanya jenis baru dan aturan izinkan yang sesuai yang dapat ditambahkan di system/sepolicy/public; atribut dan pernyataan kebijakan lainnya tidak didukung. Selain itu, jenis publik baru tidak dapat digunakan untuk melabeli objek secara langsung dalam kebijakan /vendor.

Skenario kebijakan yang tidak didukung

Perangkat yang diluncurkan dengan Android 8.0 dan yang lebih tinggi tidak mendukung skenario dan contoh kebijakan berikut.

Ekstensi tambahan ke image sistem yang memerlukan izin ke komponen image vendor baru setelah OTA khusus framework

Contoh: Proses sistem non-AOSP baru, yang memerlukan domainnya sendiri, ditambahkan dalam rilis Android berikutnya dan memerlukan akses ke HAL non-AOSP baru.

Mirip dengan interaksi sistem dan komponen vendor baru (non-AOSP), tetapi jenis sistem baru diperkenalkan di OTA khusus framework. Meskipun jenis baru dapat ditambahkan ke kebijakan di system/sepolicy/public, kebijakan vendor yang ada tidak memiliki pengetahuan tentang jenis baru karena hanya melacak kebijakan publik sistem Android 8.0. AOSP menangani hal ini dengan mengekspos resource yang disediakan vendor melalui atribut (misalnya, atribut hal_foo), tetapi karena ekstensi partner atribut tidak didukung di system/sepolicy/public, metode ini tidak tersedia untuk kebijakan vendor. Akses harus diberikan oleh jenis publik yang sudah ada sebelumnya.

Contoh: Perubahan pada proses sistem (AOSP atau non-AOSP) harus mengubah caranya berinteraksi dengan komponen vendor non-AOSP yang baru.

Kebijakan pada image sistem harus ditulis tanpa mengetahui penyesuaian vendor tertentu. Kebijakan terkait antarmuka tertentu di AOSP diekspos melalui atribut di system/sepolicy/public sehingga kebijakan vendor dapat memilih ikut serta dalam kebijakan sistem mendatang yang menggunakan atribut ini. Namun, ekstensi atribut di system/sepolicy/public tidak didukung, sehingga semua kebijakan yang menentukan cara komponen sistem berinteraksi dengan komponen vendor baru (dan yang tidak ditangani oleh atribut yang sudah ada di AOSP system/sepolicy/public) harus berada di device/manufacturer/device-name/sepolicy. Ini berarti bahwa jenis sistem tidak dapat mengubah akses yang diizinkan ke jenis vendor sebagai bagian dari OTA khusus framework.