Menyesuaikan SELinux

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

Produsen tidak boleh menghapus kebijakan SELinux yang sudah ada. Jika tidak, mereka berisiko merusak implementasi Android SELinux dan aplikasi yang mengatur. Termasuk aplikasi pihak ketiga yang mungkin perlu ditingkatkan agar lebih patuh dan operasional. Permohonan tidak boleh mewajibkan agar tetap berfungsi pada perangkat yang mendukung SELinux.

Saat mulai menyesuaikan SELinux, ingatlah untuk:

• Menulis kebijakan SELinux untuk semua daemon baru
• Gunakan domain yang telah ditetapkan jika diperlukan
• Tetapkan domain ke proses apa pun yang dibuat sebagai layanan init
• Membiasakan diri dengan makro sebelum menulis kebijakan
• Mengirimkan perubahan pada 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 dalam Android Dokumen Definisi Kompatibilitas untuk persyaratan tertentu.

SELinux menggunakan pendekatan {i>whitelist<i}, yang berarti semua akses harus secara eksplisit yang diizinkan dalam kebijakan agar dapat diberikan. Karena SELinux default Android kebijakan sudah mendukung Project Open Source Android, Anda tidak harus memodifikasi pengaturan SELinux dengan cara apa pun. Jika Anda menyesuaikan pengaturan SELinux, berhati-hatilah agar tidak merusak aplikasi yang ada. Untuk memulai:

1. Gunakan Android terbaru {i>kernel<i}.
2. Gunakan prinsip dengan hak istimewa terendah.
3. Hanya berikan penambahan Anda sendiri pada Android. Kebijakan {i>default<i} berfungsi dengan Android Open Source Project secara otomatis.
4. Memisahkan komponen software ke dalam modul yang melakukan tugas klasifikasi.
5. Membuat kebijakan SELinux yang mengisolasi tugas-tugas tersebut dari tugas-tugas yang tidak fungsi-fungsi lainnya.
6. Tempatkan kebijakan tersebut di file *.te (ekstensi untuk SELinux file sumber kebijakan) di dalam /device/manufacturer/device-name/sepolicy dan menggunakan variabel BOARD_SEPOLICY untuk menyertakannya dalam build Anda.
7. Buat domain baru permisif di awal. Hal ini dilakukan dengan menggunakan deklarasi dalam file .te domain.
8. Lakukan analisis hasil dan sempurnakan definisi domain Anda.
9. Menghapus deklarasi permisif saat tidak ada penolakan lebih lanjut yang muncul di userdebug build yang berbeda.

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

Saat mulai menyesuaikan SELinux, audit terlebih dahulu penambahan Anda ke Android. Jika Anda telah menambahkan komponen yang menjalankan fungsi baru, 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 membahas secara berlebihan dan kompatibilitas berlebihan daripada terlalu ketat dan tidak kompatibel, yang menyebabkan kerusakan fungsi perangkat. Sebaliknya, jika perubahan Anda akan bermanfaat bagi orang lain, Anda harus mengirimkan modifikasi ke kebijakan SELinux {i>default<i} sebagai patch Anda. Jika patch tersebut diterapkan pada kebijakan keamanan {i>default<i}, Anda tidak perlu membuat perubahan ini dengan setiap rilis Android baru.

Contoh pernyataan kebijakan

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

Dalam contoh berikut, semua domain diberi 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 SELinux *_file_perms {i>macro<i} (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 DHCP yang lengkap, yang kita 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 pelajari contohnya:

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

Pada baris kedua, DHCP diidentifikasi sebagai domain permisif.

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

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

Di baris allow dhcp proc_net:file write;, kebijakan menyatakan DHCP dapat menulis ke file tertentu di /proc. Baris ini menunjukkan Pelabelan file yang mendetail pada SELinux. Kolom 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; menunjukkan bagaimana aplikasi diizinkan untuk berinteraksi satu sama lain. Kebijakan tersebut mengatakan DHCP dan {i>netd<i} dapat berkomunikasi dengan satu sama lain melalui deskriptor file, file FIFO, soket datagram, dan aliran UNIX . DHCP hanya dapat membaca ke dan menulis dari soket datagram dan UNIX soket streaming 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

aturan Neverallow

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

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

Aturan 48: neverallow { domain -debuggerd -vold -dumpstate -system_server } self:capability sys_ptrace;
Lihat halaman manual untuk ptrace. sys_ptrace kapabilitas memberikan kemampuan untuk melakukan ptrace proses apa pun, yang memungkinkan banyak kontrol atas proses lain dan hanya menjadi milik sistem yang ditunjuk komponen, yang diuraikan dalam aturan. Kebutuhan akan kemampuan ini sering kali mengindikasikan adanya sesuatu yang tidak dimaksudkan untuk build yang dilihat 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, perintah ini menegaskan bahwa hanya kode di /system yang dieksekusi, yang memungkinkan jaminan keamanan berkat mekanisme seperti {i>Verified boot<i}. Sering kali, solusi terbaik saat menghadapi masalah dengan Aturan neverallow adalah memindahkan kode yang melanggar ke Partisi /system.

Menyesuaikan SEPolicy di Android 8.0+

Bagian ini menyediakan panduan untuk kebijakan SELinux vendor di Android 8.0 dan lebih tinggi, termasuk detail tentang Proyek Open Source Android (AOSP) SEPolicy dan Ekstensi SEPolicy. Untuk informasi selengkapnya tentang cara menjaga kebijakan SELinux kompatibel di seluruh partisi dan versi Android, lihat Kompatibilitas.

Penempatan kebijakan

Di Android 7.0 dan versi sebelumnya, 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 menempatkan kebijakan hanya di vendor gambar.

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

• system/sepolicy/public. Termasuk kebijakan yang diekspor untuk digunakan dalam kebijakan khusus vendor. Semuanya hadir di Android 8.0 infrastruktur kompatibilitas. Kebijakan publik dimaksudkan untuk tetap ada di seluruh rilis sehingga Anda dapat menyertakan /public apa pun dalam kebijakan yang disesuaikan. Karena ini, jenis kebijakan yang dapat ditempatkan di /public lebih dibatasi. Anggaplah 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 harus tidak memiliki pengetahuan.
• sistem/sepolicy/vendor. Termasuk kebijakan untuk komponen yang masuk di /vendor tetapi ada di hierarki platform inti (bukan direktori khusus perangkat). Ini adalah artefak dari milik sistem build perbedaan antara perangkat dan komponen global; secara konseptual, ini adalah bagian dari kebijakan khusus perangkat yang dijelaskan di bawah.
• device/manufacturer/device-name/sepolicy. Termasuk kebijakan khusus perangkat. Juga mencakup penyesuaian perangkat untuk , yang di Android 8.0 dan lebih tinggi sesuai dengan kebijakan untuk komponen pada gambar vendor.

Di Android 11 dan yang lebih tinggi, partisi system_ext dan produk juga dapat mencakup kebijakan khusus partisi. system_ext dan kebijakan produk juga dibagi menjadi publik dan pribadi, dan vendor dapat menggunakan atribut system_ext dan informasi berbagai kebijakan, 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 fungsi image system_ext, tetapi image vendor mana kebijakan seharusnya tidak dipahami. Diinstal ke partisi system_ext.
• PRODUCT_PUBLIC_SEPOLICY_DIRS. Termasuk kebijakan yang diekspor untuk digunakan dalam kebijakan khusus vendor. Diinstal ke partisi produk.
• PRODUCT_PRIVATE_SEPOLICY_DIRS. Mencakup kebijakan yang diperlukan untuk fungsi gambar produk, tetapi kebijakan gambar vendor mana seharusnya tidak memiliki pengetahuan. 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 teruskan CTS pada gambar referensi ini). Persyaratan ini memastikan pemisahan antara kerangka kerja dan kode vendor. Perangkat tersebut mendukung skenario berikut.

ekstensi khusus gambar vendor

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

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

dukungan vendor-image untuk bekerja dengan AOSP

Contoh: Menambahkan proses baru (didaftarkan ke hwservicemanager dari image vendor) yang menerapkan 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 dikirim sebagai bagian dari kebijakan vendor. Jenis dan atribut dari kebijakan publik dapat digunakan dalam aturan baru yang menentukan interaksi dengan bit khusus vendor, tunduk pada neverallow yang disediakan pembatasan. Seperti pada kasus khusus vendor, kebijakan baru di sini tidak akan diperbarui sebagai bagian dari OTA khusus framework dan akan ada dalam kebijakan gabungan pada dengan referensi image sistem AOSP.

ekstensi khusus image sistem

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

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

gambar vendor ekstensi yang melayani komponen AOSP yang diperluas

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

Kebijakan untuk interaksi antara sistem dan vendor harus disertakan dalam device/manufacturer/device-name/sepolicy yang dikirim pada partisi vendor. Ini mirip dengan skenario di atas mengenai cara menambahkan dukungan gambar vendor agar berfungsi dengan referensi gambar AOSP, kecuali komponen AOSP yang dimodifikasi juga memerlukan kebijakan tambahan agar dapat beroperasi dengan benar dengan seluruh sistem partisi (yang tidak masalah selama mereka masih memiliki jenis AOSP publik label).

Kebijakan untuk interaksi komponen AOSP publik dengan sistem gambar saja ekstensi harus dalam system/sepolicy/private.

image sistem ekstensi yang hanya mengakses antarmuka AOSP

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

Ini serupa dengan sistem-image-only contoh ekstensi, kecuali komponen sistem baru dapat berinteraksi di seluruh Antarmuka system/vendor. Kebijakan untuk komponen sistem baru harus masuk di system/sepolicy/private, yang dapat diterima asalkan melalui antarmuka yang sudah ditetapkan oleh AOSP pada system/sepolicy/public (yaitu jenis dan atribut yang diperlukan untuk fungsionalitasnya). Meskipun kebijakan dapat disertakan dalam setelan Google Cloud, Google tidak akan dapat menggunakan system/sepolicy/private jenis atau perubahan (dengan cara apa pun yang memengaruhi kebijakan) sebagai akibat dari memperbarui. Kebijakan ini dapat diubah di OTA khusus framework, tetapi tidak akan ada saat menggunakan image sistem AOSP (yang tidak memiliki sistem baru juga).

gambar vendor ekstensi yang menyediakan komponen sistem baru

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

Mirip dengan AOSP-extensions contoh, kebijakan untuk interaksi antara sistem dan vendor harus dimasukkan device/manufacturer/device-name/sepolicy direktori yang dikirimkan pada partisi vendor (untuk memastikan bahwa kebijakan sistem tidak diketahui mengenai detail khusus vendor). Anda dapat menambahkan tipe publik baru yang memperluas kebijakan di system/sepolicy/public; hal ini hanya boleh dilakukan selain kebijakan AOSP yang ada, yaitu tidak menghapus kebijakan publik AOSP. Publik baru jenis ini kemudian dapat digunakan untuk kebijakan di system/sepolicy/private dan di device/manufacturer/device-name/sepolicy.

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

Skenario kebijakan yang tidak didukung

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

Tambahan ekstensi ke image sistem yang memerlukan izin ke komponen image vendor baru setelah OTA khusus framework

Contoh: Proses sistem non-AOSP baru, yang memerlukan proses sendiri domain tambahan, ditambahkan di rilis Android berikutnya dan membutuhkan akses ke domain HAL non-AOSP.

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

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

Kebijakan pada image sistem harus ditulis tanpa sepengetahuan penyesuaian vendor. Oleh karena itu, kebijakan terkait antarmuka tertentu di AOSP adalah diekspos melalui atribut di sistem/sepolicy/public sehingga kebijakan vendor dapat 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 belum ditangani oleh atribut yang sudah ada dalam AOSP system/sepolicy/public) harus dalam device/manufacturer/device-name/sepolicy. Ini berarti bahwa jenis sistem tidak dapat berubah akses yang diizinkan ke jenis vendor sebagai bagian dari OTA khusus kerangka kerja.