Menyesuaikan SELinux

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

Produsen tidak boleh menghapus kebijakan SELinux yang ada. Jika tidak, mereka berisiko merusak implementasi Android SELinux dan aplikasi yang diaturnya. Hal ini mencakup aplikasi pihak ketiga yang mungkin perlu ditingkatkan agar patuh dan dapat beroperasi. Aplikasi tidak boleh memerlukan modifikasi untuk terus berfungsi pada perangkat yang mendukung SELinux.

Saat mulai menyesuaikan SELinux, ingatlah untuk:

• Tulis kebijakan SELinux untuk semua daemon baru
• Gunakan domain yang telah ditentukan sebelumnya bila diperlukan
• Tetapkan domain untuk setiap proses yang dihasilkan sebagai layanan init
• Biasakan diri Anda dengan makro sebelum menulis kebijakan
• Kirimkan perubahan kebijakan inti ke AOSP

Dan ingatlah untuk tidak:

• Buat kebijakan yang tidak kompatibel
• Izinkan penyesuaian kebijakan pengguna akhir
• Izinkan penyesuaian kebijakan MDM
• Menakut-nakuti pengguna dengan pelanggaran kebijakan
• Tambahkan pintu belakang

Lihat bagian Fitur Keamanan Kernel pada dokumen Definisi Kompatibilitas Android untuk mengetahui persyaratan spesifik.

SELinux menggunakan pendekatan daftar putih, artinya semua akses harus diizinkan secara eksplisit dalam kebijakan agar dapat diberikan. Karena kebijakan SELinux default Android sudah mendukung Proyek Sumber Terbuka Android, Anda tidak perlu mengubah pengaturan SELinux dengan cara apa pun. Jika Anda menyesuaikan pengaturan SELinux, berhati-hatilah agar tidak merusak aplikasi yang ada. Untuk memulai:

1. Gunakan kernel Android terbaru .
2. Mengadopsi prinsip hak istimewa paling rendah .
3. Hanya atasi tambahan Anda sendiri pada Android. Kebijakan default berfungsi dengan basis kode Proyek Sumber Terbuka Android secara otomatis.
4. Pisahkan komponen perangkat lunak ke dalam modul yang melakukan tugas tunggal.
5. Buat kebijakan SELinux yang mengisolasi tugas-tugas tersebut dari fungsi yang tidak terkait.
6. Letakkan kebijakan tersebut di file *.te (ekstensi untuk file sumber kebijakan SELinux) di dalam direktori /device/ manufacturer / device-name /sepolicy dan gunakan variabel BOARD_SEPOLICY untuk memasukkannya ke dalam build.
7. Jadikan domain baru bersifat permisif pada awalnya. Hal ini dilakukan dengan menggunakan deklarasi permisif dalam file .te domain.
8. Analisis hasil dan sempurnakan definisi domain Anda.
9. Hapus deklarasi permisif ketika tidak ada penolakan lebih lanjut yang muncul di build userdebug.

Setelah Anda mengintegrasikan perubahan kebijakan SELinux, tambahkan satu langkah ke alur kerja pengembangan Anda untuk memastikan kompatibilitas SELinux di masa mendatang. Dalam proses pengembangan perangkat lunak yang ideal, kebijakan SELinux hanya berubah ketika model perangkat lunak berubah dan bukan implementasi sebenarnya.

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

Untuk mencegah masalah yang tidak perlu, lebih baik bersikap berlebihan dan kompatibel daripada terlalu membatasi dan tidak kompatibel, yang mengakibatkan fungsi perangkat rusak. Sebaliknya, jika perubahan Anda akan bermanfaat bagi orang lain, Anda harus mengirimkan modifikasi tersebut ke kebijakan default SELinux sebagai patch . Jika patch diterapkan pada kebijakan keamanan default, Anda tidak perlu melakukan perubahan ini pada setiap rilis Android baru.

Contoh pernyataan kebijakan

SELinux didasarkan pada bahasa komputer M4 dan karenanya mendukung berbagai makro untuk menghemat waktu.

Dalam contoh berikut, semua domain diberikan akses untuk membaca 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 SELinux *_file_perms (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 lengkap kebijakan untuk DHCP, yang kami periksa di bawah ini:

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 membedah contohnya:

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

Pada baris kedua, DHCP diidentifikasi sebagai domain permisif.

Di baris init_daemon_domain(dhcp) , kebijakan menyatakan DHCP dihasilkan dari init dan diizinkan untuk berkomunikasi dengannya.

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

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

Blok terakhir dari contoh dimulai dengan allow dhcp netd:fd use; menggambarkan bagaimana aplikasi diperbolehkan berinteraksi satu sama lain. Kebijakan tersebut menyatakan DHCP dan netd dapat berkomunikasi satu sama lain melalui deskriptor file, file FIFO, soket datagram, dan soket aliran UNIX. DHCP hanya dapat membaca dan menulis dari soket datagram dan soket aliran UNIX dan tidak 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

jangan pernah mengizinkan aturan

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

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

Aturan 48: neverallow { domain -debuggerd -vold -dumpstate -system_server } self:capability sys_ptrace;
Lihat halaman manual untuk ptrace . Kemampuan sys_ptrace memberikan kemampuan untuk ptrace proses apa pun, yang memungkinkan kontrol yang besar terhadap proses lain dan hanya boleh dimiliki oleh komponen sistem yang ditunjuk, yang diuraikan dalam aturan. Kebutuhan akan kemampuan ini sering kali menunjukkan adanya sesuatu yang tidak dimaksudkan untuk build yang digunakan pengguna atau fungsionalitas 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 pada sistem. Secara khusus, ini menegaskan bahwa hanya kode di /system yang dieksekusi, yang memungkinkan jaminan keamanan berkat mekanisme seperti boot terverifikasi. Seringkali, solusi terbaik ketika menghadapi masalah dengan aturan neverallow ini adalah dengan memindahkan kode yang melanggar ke partisi /system .

Menyesuaikan SEPolicy di Android 8.0+

Bagian ini memberikan panduan untuk kebijakan SELinux vendor di Android 8.0 dan lebih tinggi, termasuk detail tentang SEPOlicy Proyek Sumber Terbuka Android (AOSP) dan ekstensi SEPolicy. Untuk informasi lebih lanjut tentang bagaimana kebijakan SELinux tetap kompatibel di seluruh partisi dan versi Android, lihat Kompatibilitas .

Penempatan kebijakan

Di Android 7.0 dan versi 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 tinggi, menambahkan kebijakan ke BOARD_SEPOLICY_DIRS akan menempatkan kebijakan hanya pada gambar vendor.

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

• sistem/sepolicy/publik . Termasuk 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 memasukkan apa pun /public ke dalam kebijakan khusus Anda. Oleh karena itu, jenis kebijakan yang dapat ditempatkan di /public lebih dibatasi. Anggap ini API kebijakan yang diekspor platform: Apa pun yang berhubungan dengan antarmuka antara /system dan /vendor ada di sini.
• sistem/kebijakan/pribadi . Termasuk kebijakan yang diperlukan untuk memfungsikan citra sistem, namun kebijakan citra vendor tidak boleh mengetahuinya.
• sistem/sepolicy/vendor . Menyertakan kebijakan untuk komponen yang masuk ke /vendor tetapi ada di pohon platform inti (bukan direktori khusus perangkat). Ini adalah artefak pembedaan sistem build antara perangkat dan komponen global; secara konseptual, ini adalah bagian dari kebijakan khusus perangkat yang dijelaskan di bawah.
• perangkat/ manufacturer / device-name /sepolicy . Termasuk kebijakan khusus perangkat. Juga mencakup penyesuaian perangkat terhadap kebijakan, yang di Android 8.0 dan lebih tinggi sesuai dengan kebijakan untuk komponen pada image vendor.

Di Android 11 dan yang lebih tinggi, partisi system_ext dan product 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 . Termasuk kebijakan yang diekspor untuk digunakan dalam kebijakan khusus vendor. Diinstal ke partisi system_ext.
• SYSTEM_EXT_PRIVATE_SEPOLICY_DIRS . Termasuk kebijakan yang diperlukan untuk memfungsikan image system_ext, namun kebijakan image vendor tidak boleh mengetahuinya. Diinstal ke partisi system_ext.
• PRODUCT_PUBLIC_SEPOLICY_DIRS . Termasuk kebijakan yang diekspor untuk digunakan dalam kebijakan khusus vendor. Dipasang ke partisi produk.
• PRODUCT_PRIVATE_SEPOLICY_DIRS . Termasuk kebijakan yang diperlukan untuk memfungsikan citra produk, namun kebijakan citra vendor tidak boleh mengetahuinya. Dipasang ke partisi produk.

Skenario kebijakan yang didukung

Pada perangkat yang diluncurkan dengan Android 8.0 dan 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 bersih antara kerangka kerja 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 bagaimana komponen vendor berinteraksi dengan (hanya) komponen vendor lain harus melibatkan tipe yang hanya ada di device/ manufacturer / device-name /sepolicy . Kebijakan yang ditulis di sini memungkinkan kode pada vendor untuk berfungsi, tidak akan diperbarui sebagai bagian dari kerangka kerja OTA saja, dan akan ada dalam kebijakan gabungan pada perangkat dengan gambar sistem AOSP referensi.

dukungan vendor-image untuk bekerja dengan AOSP

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

Seperti halnya 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 dikirimkan sebagai bagian dari kebijakan vendor. Jenis dan atribut dari kebijakan publik dapat digunakan dalam aturan baru yang menentukan interaksi dengan bit khusus vendor baru, dengan tunduk pada batasan neverallow yang diberikan. Seperti halnya kasus vendor saja, kebijakan baru di sini tidak akan diperbarui sebagai bagian dari kerangka kerja OTA saja dan akan ada dalam kebijakan gabungan pada perangkat dengan gambar sistem AOSP referensi.

ekstensi khusus gambar sistem

Contoh : Menambahkan layanan baru (terdaftar di 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 fungsionalitas pada citra sistem mitra, asalkan bit baru tersebut tidak perlu berinteraksi dengan komponen baru pada citra vendor (khususnya, proses atau objek tersebut harus berfungsi sepenuhnya tanpa kebijakan dari citra vendor) . Kebijakan yang diekspor oleh system/sepolicy/public tersedia di sini sama seperti untuk ekstensi vendor-image-only. Kebijakan ini adalah bagian dari citra sistem dan dapat diperbarui dalam kerangka kerja OTA saja, namun tidak akan ada saat menggunakan citra sistem referensi AOSP.

ekstensi vendor-image yang melayani komponen AOSP yang diperluas

Contoh: HAL non-AOSP baru untuk digunakan oleh klien perluasan yang juga ada di citra sistem AOSP (seperti server_sistem yang diperluas).

Kebijakan interaksi antara sistem dan vendor harus disertakan dalam direktori device/ manufacturer / device-name /sepolicy yang dikirimkan pada partisi vendor. Hal ini mirip dengan skenario di atas yang menambahkan dukungan vendor-image untuk bekerja dengan image AOSP referensi, kecuali komponen AOSP yang dimodifikasi mungkin juga memerlukan kebijakan tambahan agar dapat beroperasi dengan baik dengan seluruh partisi sistem (yang tidak masalah selama masih ada). memiliki label tipe AOSP publik).

Kebijakan untuk interaksi komponen AOSP publik dengan ekstensi system-image-only harus ada di system/sepolicy/private .

ekstensi gambar sistem yang hanya mengakses antarmuka AOSP

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

Hal ini mirip dengan contoh ekstensi system-image-only , kecuali komponen sistem baru dapat berinteraksi di seluruh antarmuka system/vendor . Kebijakan untuk komponen sistem baru harus masuk system/sepolicy/private , yang dapat diterima asalkan melalui antarmuka yang sudah dibuat oleh AOSP di system/sepolicy/public (yaitu jenis dan atribut yang diperlukan untuk fungsionalitas ada di sana). Meskipun kebijakan dapat disertakan dalam kebijakan khusus perangkat, kebijakan tersebut tidak dapat menggunakan jenis atau perubahan system/sepolicy/private lain (dengan cara apa pun yang memengaruhi kebijakan) sebagai hasil dari pembaruan hanya kerangka kerja. Kebijakan ini dapat diubah dalam OTA kerangka saja, namun tidak akan ada saat menggunakan image sistem AOSP (yang juga tidak memiliki komponen sistem baru).

ekstensi vendor-image yang melayani komponen sistem baru

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

Mirip dengan contoh ekstensi AOSP , kebijakan untuk interaksi antara sistem dan vendor harus masuk ke direktori device/ manufacturer / device-name /sepolicy yang dikirimkan pada partisi vendor (untuk memastikan kebijakan sistem tidak memiliki pengetahuan tentang detail spesifik vendor). Anda dapat menambahkan tipe publik baru yang memperluas kebijakan di system/sepolicy/public ; hal ini sebaiknya dilakukan hanya sebagai tambahan terhadap kebijakan AOSP yang sudah ada, yaitu tidak menghapus kebijakan publik AOSP. Tipe publik yang baru kemudian dapat digunakan untuk kebijakan di system/sepolicy/private dan di device/ manufacturer / device-name /sepolicy .

Ingatlah bahwa setiap penambahan pada system/sepolicy/public menambah kompleksitas dengan memberikan jaminan kompatibilitas baru yang harus dilacak dalam file pemetaan dan tunduk pada batasan lainnya. Hanya tipe baru dan aturan izin terkait yang dapat ditambahkan di system/sepolicy/public ; atribut dan pernyataan kebijakan lainnya tidak didukung. Selain itu, tipe publik baru tidak dapat digunakan untuk memberi label langsung pada objek dalam kebijakan /vendor .

Skenario kebijakan yang tidak didukung

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

Ekstensi tambahan untuk citra sistem yang memerlukan izin untuk komponen citra vendor baru setelah OTA khusus kerangka kerja

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

Mirip dengan interaksi sistem baru (non-AOSP) dan komponen vendor , kecuali jenis sistem baru yang diperkenalkan dalam kerangka kerja OTA saja. Meskipun tipe baru dapat ditambahkan ke kebijakan di system/sepolicy/public , kebijakan vendor yang ada tidak mengetahui tipe baru karena hanya melacak kebijakan publik sistem Android 8.0. AOSP menangani hal ini dengan mengekspos sumber daya yang disediakan vendor melalui atribut (misalnya atribut hal_foo ) tetapi karena ekstensi mitra atribut tidak didukung di system/sepolicy/public , metode ini tidak tersedia untuk kebijakan vendor. Akses harus disediakan oleh tipe publik yang sudah ada sebelumnya.

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

Kebijakan pada citra sistem harus ditulis tanpa pengetahuan tentang penyesuaian vendor tertentu. Kebijakan mengenai antarmuka spesifik di AOSP diekspos melalui atribut di system/sepolicy/public sehingga kebijakan vendor dapat ikut serta dalam kebijakan sistem masa depan yang menggunakan atribut ini. Namun, ekstensi atribut di system/sepolicy/public tidak didukung , jadi semua kebijakan yang menentukan bagaimana komponen sistem berinteraksi dengan komponen vendor baru (dan yang tidak ditangani oleh atribut yang sudah ada di AOSP system/sepolicy/public ) harus ada di device/ manufacturer / device-name /sepolicy . Ini berarti bahwa tipe sistem tidak dapat mengubah akses yang diizinkan ke tipe vendor sebagai bagian dari OTA yang hanya kerangka kerja.