Google berkomitmen untuk mendorong terwujudnya keadilan ras bagi komunitas Kulit Hitam. Lihat caranya.

Halaman ini diterjemahkan oleh Cloud Translation API.

Mengimplementasikan SELinux

SELinux diatur ke {i>default-deny<i}, yang berarti bahwa setiap akses untuk yang memiliki {i>hook<i} di {i>kernel<i} harus diizinkan secara eksplisit oleh kebijakan. Ini berarti file kebijakan terdiri dari sejumlah besar informasi yang aturan, jenis, class, izin, dan lainnya. Pertimbangan penuh SELinux berada di luar cakupan dokumen ini, tetapi pemahaman tentang cara menulis sekarang menjadi penting saat memunculkan perangkat Android baru. Terdapat banyak informasi yang tersedia mengenai SELinux. Lihat Mendukung dokumentasi untuk referensi yang disarankan.

File kunci

Untuk mengaktifkan SELinux, integrasikan terbaru Kernel Android lalu gabungkan file-file yang ditemukan dalam sistem/sepolicy saat ini. Ketika dikompilasi, file-file itu membentuk keamanan kernel SELinux kebijakan dan mencakup sistem operasi Android upstream.

Secara umum, Anda tidak boleh mengubah file system/sepolicy secara langsung. Sebagai gantinya, tambahkan atau edit file kebijakan khusus perangkat Anda sendiri di /device/manufacturer/device-name/sepolicy saat ini. Di Android 8.0 dan yang lebih tinggi, perubahan yang Anda buat pada file ini seharusnya hanya memengaruhi kebijakan di direktori vendor Anda. Untuk detail selengkapnya tentang pemisahan sepolicy publik di Android 8.0 dan yang lebih tinggi, lihat Menyesuaikan SEPolicy di Android 8.0 dan yang lebih baru. Terlepas dari versi Android, Anda masih memodifikasi file berikut:

File kebijakan

File yang diakhiri dengan *.te adalah file sumber kebijakan SELinux, yang menentukan domain dan labelnya. Anda mungkin perlu membuat file kebijakan baru di /device/manufacturer/device-name/sepolicy, tetapi Anda harus mencoba memperbarui file yang ada jika memungkinkan.

File konteks

File konteks adalah tempat Anda menentukan label untuk objek.

file_contexts menetapkan label ke file dan digunakan oleh berbagai komponen userspace. Saat Anda membuat kebijakan baru, buat atau perbarui file ini untuk menetapkan label baru ke file. Untuk menerapkan file_contexts baru, membangun ulang image sistem file atau menjalankan restorecon pada file untuk diberi label ulang. Pada upgrade, perubahan pada file_contexts akan otomatis diterapkan ke sistem dan partisi data pengguna sebagai bagian dari {i>upgrade.<i} Perubahan juga dapat diterapkan secara otomatis saat meningkatkan versi ke partisi dengan menambahkan panggilan restorecon_recursive ke file init.board.rc setelah partisi terpasang baca-tulis.
genfs_contexts menetapkan label ke sistem file, seperti proc atau vfat yang tidak mendukung perpanjangan . Konfigurasi ini dimuat sebagai bagian dari kebijakan {i>kernel<i} tetapi perubahan mungkin tidak berlaku untuk inode dalam inti, memerlukan {i>reboot<i} atau melepas dan memasang kembali sistem file untuk menerapkan perubahan sepenuhnya. Label khusus juga dapat ditetapkan ke dudukan tertentu, seperti vfat menggunakan opsi context=mount.
property_contexts menetapkan label ke properti sistem Android untuk mengontrol proses apa yang dapat mengaturnya. Konfigurasi ini dibaca oleh Proses init selama startup.
service_contexts menetapkan label ke layanan binder Android untuk mengontrol proses apa yang dapat menambahkan (mendaftarkan) dan menemukan (mencari) binder layanan terkait. Konfigurasi ini dibaca oleh Proses servicemanager selama startup.
seapp_contexts menetapkan label untuk proses aplikasi dan /data/data direktori. Konfigurasi ini dibaca oleh zygote proses pada setiap peluncuran aplikasi dan pada installd selama startup.
mac_permissions.xml menetapkan tag seinfo ke aplikasi berdasarkan tanda tangan mereka dan secara opsional nama paket mereka. Tujuan Tag seinfo kemudian dapat digunakan sebagai kunci di seapp_contexts untuk menetapkan label khusus ke semua aplikasi dengan tag seinfo tersebut. Konfigurasi ini dibaca oleh system_server selama startup.
keystore2_key_contexts menetapkan label ke namespace Keystore 2.0. Namespace ini diterapkan oleh daemon keystore2. Keystore selalu menyediakan namespace berbasis UID/AID. Keystore 2.0 juga menerapkan sepolicy namespace yang ditentukan. Deskripsi rinci tentang format dan konvensi ini file dapat ditemukan di sini.

Makefile BoardConfig.mk

Setelah mengedit atau menambahkan file kebijakan dan konteks, perbarui /device/manufacturer/device-name/BoardConfig.mk makefile untuk mereferensikan subdirektori sepolicy dan setiap file kebijakan baru. Untuk informasi selengkapnya tentang variabel BOARD_SEPOLICY, lihat File system/sepolicy/README.

BOARD_SEPOLICY_DIRS += \
        <root>/device/manufacturer/device-name/sepolicy

BOARD_SEPOLICY_UNION += \
        genfs_contexts \
        file_contexts \
        sepolicy.te

Setelah membangun ulang, perangkat Anda akan diaktifkan dengan SELinux. Sekarang Anda bisa menyesuaikan kebijakan SELinux Anda untuk mengakomodasi penambahan Anda sendiri ke Android seperti yang dijelaskan di Penyesuaian atau verifikasi konfigurasi yang ada seperti yang dibahas dalam Validasi.

Saat file kebijakan baru dan pembaruan BoardConfig.mk diterapkan, pengaturan kebijakan secara otomatis dibangun ke dalam file kebijakan {i>kernel<i} akhir. Untuk informasi selengkapnya tentang bagaimana sepolicy di-build pada perangkat, lihat Membangun sepolicy.

Implementasi

Untuk mulai menggunakan SELinux:

Aktifkan SELinux di kernel: CONFIG_SECURITY_SELINUX=y
Ubah parameter kernel_cmdline atau bootconfig sehingga:
```
BOARD_KERNEL_CMDLINE := androidboot.selinux=permissive
```
atau
```
BOARD_BOOTCONFIG := androidboot.selinux=permissive
```
Ini hanya untuk pengembangan awal kebijakan untuk perangkat. Setelah Anda memiliki kebijakan bootstrap awal, hapus parameter ini sehingga diterapkan atau CTS akan gagal.

Booting sistem secara permisif dan lihat penolakan yang ditemui saat booting:
Pada Ubuntu 14.04 atau yang lebih baru:

adb shell su -c dmesg | grep denied | audit2allow -p out/target/product/BOARD/root/sepolicy

Di Ubuntu 12.04:

adb pull /sys/fs/selinux/policy
adb logcat -b all | audit2allow -p policy

Evaluasi output untuk peringatan yang menyerupai init: Warning! Service name needs a SELinux domain defined; please fix! Lihat Validasi untuk petunjuk dan alat.
Identifikasi perangkat dan file baru lainnya yang perlu diberi label.
Gunakan label yang sudah ada atau label baru untuk objek Anda. Lihat *_contexts file untuk melihat cara pelabelan sebelumnya dan menggunakan pengetahuan tentang arti label untuk menetapkan yang baru. Idealnya, ini adalah label yang sudah ada dan sesuai dengan kebijakan, namun terkadang label baru akan diperlukan, dan aturan untuk akses ke label tersebut akan diperlukan. Tambahkan label ke file konteks yang sesuai.
Identifikasi domain/proses yang harus memiliki domain keamanan sendiri. Anda mungkin perlu menulis kebijakan yang benar-benar baru untuk setiap opsi. Semua layanan yang berasal dari init, misalnya, harus memiliki sendiri. Perintah berikut membantu menunjukkan program yang tetap berjalan (tetapi SEMUA layanan memerlukan perlakuan tersebut):
```
adb shell su -c ps -Z | grep init
```
```
adb shell su -c dmesg | grep 'avc: '
```
Tinjau init.device.rc untuk mengidentifikasi domain yang tidak memiliki jenis domain. Beri mereka domain lebih awal dalam proses pengembangan aplikasi untuk menghindari penambahan aturan ke init atau sebaliknya membingungkan akses init dengan akses yang ada di kebijakan Anda sendiri.
Siapkan BOARD_CONFIG.mk untuk menggunakan BOARD_SEPOLICY_* variabel. Lihat README di system/sepolicy untuk mengetahui detail tentang penyiapannya.
Periksa file init.device.rc dan fstab.device, lalu memastikan setiap penggunaan mount sesuai dengan sistem file berlabel atau opsi context= mount yang ditentukan.
Periksa setiap penolakan dan buat kebijakan SELinux untuk menangani setiap penolakan dengan benar. Lihat contoh di Penyesuaian.

Anda harus mulai dengan kebijakan di AOSP dan kemudian membangunnya untuk penyesuaian Anda sendiri. Untuk informasi selengkapnya tentang strategi kebijakan dan melihat lebih dekat beberapa langkah ini, lihat Menulis Kebijakan SELinux.

Kasus penggunaan

Berikut ini contoh spesifik eksploit yang perlu dipertimbangkan saat membuat eksploit software dan kebijakan SELinux terkait:

Symlink - Karena symlink muncul sebagai file, symlink sering dibaca sebagai file, yang dapat menyebabkan eksploitasi. Misalnya, beberapa hak istimewa komponen, seperti init, mengubah izin file tertentu, terkadang menjadi terlalu terbuka.

Penyerang kemudian mengganti file-file itu dengan {i>symlink<i} ke kode yang mereka kontrol, yang memungkinkan penyerang menimpa file arbitrer. Namun, jika Anda mengetahui aplikasi tidak akan pernah melintasi symlink, Anda dapat melarangnya dengan SELinux.

File sistem - Pertimbangkan kelas file sistem yang hanya boleh dimodifikasi oleh server sistem. Namun, sejak netd, init dan vold berjalan sebagai root, mereka dapat mengakses file-file sistem tersebut. Jadi, jika netd disusupi, akun tersebut akan menyusupi file-file itu dan mungkin server sistem itu sendiri.

Dengan SELinux, Anda dapat mengidentifikasi file tersebut sebagai file data server sistem. Oleh karena itu, satu-satunya domain yang memiliki akses baca/tulis adalah server sistem. Meskipun netd disusupi, domain tersebut tidak dapat dialihkan ke domain server sistem dan mengakses file sistem meskipun dijalankan sebagai {i>root<i}.

Data aplikasi - Contoh lain adalah class fungsi yang harus berjalan sebagai root namun tidak boleh untuk mengakses data aplikasi. Hal ini sangat berguna karena pernyataan yang sangat luas dapat dibuat, seperti domain tertentu yang tidak terkait ke data aplikasi dilarang mengakses internet.

setattr - Untuk perintah seperti chmod dan chown, Anda dapat mengidentifikasi kumpulan file dengan dapat melakukan setattr. Hal apa pun di luar itu bisa menjadi dilarang dari perubahan ini, bahkan oleh akar. Jadi aplikasi mungkin berjalan chmod dan chown dibandingkan dengan label yang diberi label app_data_files tetapi bukan shell_data_files atau system_data_files.