SELinux diatur ke default-deny, yang berarti bahwa setiap akses yang memiliki kaitan di kernel harus secara eksplisit diizinkan oleh kebijakan. Ini berarti file kebijakan terdiri dari sejumlah besar informasi mengenai aturan, jenis, kelas, izin, dan banyak lagi. Pertimbangan menyeluruh tentang SELinux berada di luar cakupan dokumen ini, namun pemahaman tentang cara menulis aturan kebijakan kini menjadi penting saat memperkenalkan perangkat Android baru. Ada banyak informasi yang tersedia mengenai SELinux. Lihat Dokumentasi pendukung untuk sumber daya yang disarankan.
File kunci
Untuk mengaktifkan SELinux, integrasikan kernel Android terbaru dan kemudian gabungkan file yang ditemukan di direktori sistem/sepolicy . Saat dikompilasi, file-file tersebut berisi kebijakan keamanan kernel SELinux 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 di direktori /device/ manufacturer / device-name /sepolicy
. Di Android 8.0 dan lebih tinggi, perubahan yang Anda buat pada file ini hanya akan memengaruhi kebijakan di direktori vendor Anda. Untuk detail lebih lanjut tentang pemisahan sepolicy publik di Android 8.0 dan lebih tinggi, lihat Menyesuaikan SEPOlicy di Android 8.0+ . 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
, namun Anda harus mencoba memperbarui file yang ada jika memungkinkan.
File konteks
File konteks adalah tempat Anda menentukan label untuk objek Anda.
-
file_contexts
memberikan label pada file dan digunakan oleh berbagai komponen ruang pengguna. Saat Anda membuat kebijakan baru, buat atau perbarui file ini untuk menetapkan label baru pada file. Untuk menerapkanfile_contexts
baru, bangun kembali citra sistem file atau jalankanrestorecon
pada file yang akan diberi label ulang. Pada peningkatan, perubahan padafile_contexts
secara otomatis diterapkan pada sistem dan partisi data pengguna sebagai bagian dari peningkatan. Perubahan juga dapat diterapkan secara otomatis saat pemutakhiran ke partisi lain dengan menambahkan panggilanrestorecon_recursive
ke init. board file .rc setelah partisi dipasang baca-tulis. -
genfs_contexts
memberikan label pada sistem file, sepertiproc
atauvfat
yang tidak mendukung atribut yang diperluas. Konfigurasi ini dimuat sebagai bagian dari kebijakan kernel tetapi perubahan mungkin tidak berlaku untuk inode dalam inti, sehingga memerlukan reboot atau unmounting dan pemasangan ulang sistem file untuk menerapkan perubahan sepenuhnya. Label tertentu juga dapat ditetapkan ke mount tertentu, sepertivfat
menggunakan opsicontext=mount
. -
property_contexts
memberikan label pada properti sistem Android untuk mengontrol proses apa yang dapat menyetelnya. Konfigurasi ini dibaca oleh prosesinit
saat startup. -
service_contexts
memberikan label pada layanan pengikat Android untuk mengontrol proses apa yang dapat menambahkan (mendaftarkan) dan menemukan (mencari) referensi pengikat untuk layanan tersebut. Konfigurasi ini dibaca oleh prosesservicemanager
saat startup. -
seapp_contexts
memberikan label ke proses aplikasi dan direktori/data/data
. Konfigurasi ini dibaca oleh proseszygote
pada setiap peluncuran aplikasi dan olehinstalld
saat startup. -
mac_permissions.xml
memberikan tagseinfo
ke aplikasi berdasarkan tanda tangannya dan opsional nama paketnya. Tagseinfo
kemudian dapat digunakan sebagai kunci dalam fileseapp_contexts
untuk menetapkan label tertentu ke semua aplikasi dengan tagseinfo
tersebut. Konfigurasi ini dibaca olehsystem_server
saat startup. -
keystore2_key_contexts
memberikan label pada namespace Keystore 2.0. Namespace ini diberlakukan oleh daemon keystore2. Keystore selalu menyediakan namespace berbasis UID/AID. Keystore 2.0 juga menerapkan namespace yang ditentukan sepolicy. Penjelasan rinci tentang format dan konvensi file ini dapat ditemukan di sini .
File make-up BoardConfig.mk
Setelah mengedit atau menambahkan file kebijakan dan konteks, perbarui file make /device/ manufacturer / device-name /BoardConfig.mk
Anda untuk mereferensikan subdirektori sepolicy
dan setiap file kebijakan baru. Untuk informasi lebih lanjut 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 dibangun kembali, perangkat Anda diaktifkan dengan SELinux. Anda sekarang dapat menyesuaikan kebijakan SELinux untuk mengakomodasi penambahan Anda sendiri pada sistem operasi Android seperti yang dijelaskan dalam Penyesuaian atau memverifikasi pengaturan yang ada seperti yang tercakup dalam Validasi .
Ketika file kebijakan baru dan pembaruan BoardConfig.mk sudah ada, pengaturan kebijakan baru secara otomatis dimasukkan ke dalam file kebijakan kernel final. Untuk informasi lebih lanjut tentang bagaimana sepolicy dibuat pada perangkat, lihat Membangun sepolicy .
Penerapan
Untuk memulai SELinux:
- Aktifkan SELinux di kernel:
CONFIG_SECURITY_SELINUX=y
- Ubah parameter kernel_cmdline atau bootconfig sehingga:
BOARD_KERNEL_CMDLINE := androidboot.selinux=permissive
atauBOARD_BOOTCONFIG := androidboot.selinux=permissive
Ini hanya untuk pengembangan awal kebijakan perangkat. Setelah Anda memiliki kebijakan bootstrap awal, hapus parameter ini agar perangkat Anda dapat diterapkan atau CTS akan gagal. - Boot sistem secara permisif dan lihat penolakan apa yang ditemui saat boot:
Di Ubuntu 14.04 atau 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 keluaran peringatan yang menyerupai
init: Warning! Service name needs a SELinux domain defined; please fix!
Lihat Validasi untuk instruksi dan alat. - Identifikasi perangkat, dan file baru lainnya yang perlu diberi label.
- Gunakan label yang sudah ada atau baru untuk objek Anda. Lihat file
*_contexts
untuk melihat bagaimana sesuatu diberi label sebelumnya dan gunakan pengetahuan tentang arti label untuk menetapkan yang baru. Idealnya, label ini adalah label yang sudah ada dan sesuai dengan kebijakan, namun terkadang diperlukan label baru, dan diperlukan aturan untuk mengakses label tersebut. Tambahkan label Anda ke file konteks yang sesuai. - Identifikasi domain/proses yang harus memiliki domain keamanannya sendiri. Anda mungkin perlu menulis kebijakan yang benar-benar baru untuk masing-masing kebijakan. Semua layanan yang dihasilkan dari
init
, misalnya, harus memiliki layanannya sendiri. Perintah berikut membantu mengungkap layanan yang masih berjalan (tetapi SEMUA layanan memerlukan perlakuan seperti itu):adb shell su -c ps -Z | grep init
adb shell su -c dmesg | grep 'avc: '
- Tinjau
init. device .rc
untuk mengidentifikasi domain apa pun yang tidak memiliki tipe domain. Beri mereka domain di awal proses pengembangan Anda untuk menghindari penambahan aturan keinit
atau membingungkan aksesinit
dengan aturan yang ada dalam kebijakan mereka sendiri. - Siapkan
BOARD_CONFIG.mk
untuk menggunakan variabelBOARD_SEPOLICY_*
. Lihat README disystem/sepolicy
untuk rincian tentang pengaturan ini. - Periksa initnya. device .rc dan fstab. file device dan pastikan setiap penggunaan
mount
sesuai dengan sistem file yang diberi label dengan benar atau opsicontext= mount
ditentukan. - Periksa setiap penolakan dan buat kebijakan SELinux untuk menangani setiap penolakan dengan benar. Lihat contoh di Kustomisasi .
Anda harus memulai dengan kebijakan di AOSP dan kemudian mengembangkan kebijakan tersebut untuk penyesuaian Anda sendiri. Untuk informasi selengkapnya tentang strategi kebijakan dan melihat lebih dekat beberapa langkah ini, lihat Menulis Kebijakan SELinux .
Kasus penggunaan
Berikut adalah contoh spesifik eksploitasi yang perlu dipertimbangkan saat membuat perangkat lunak Anda sendiri dan kebijakan SELinux terkait:
Symlinks - Karena symlink muncul sebagai file, maka sering kali dibaca sebagai file, sehingga dapat menyebabkan eksploitasi. Misalnya, beberapa komponen yang memiliki hak istimewa, seperti init
, mengubah izin file tertentu, terkadang menjadi terlalu terbuka.
Penyerang kemudian dapat mengganti file tersebut dengan symlink ke kode yang mereka kendalikan, sehingga memungkinkan penyerang untuk menimpa file apa pun. Namun jika Anda tahu aplikasi Anda tidak akan pernah melintasi symlink, Anda dapat melarangnya melakukan hal tersebut dengan SELinux.
File sistem - Pertimbangkan kelas file sistem yang harus dimodifikasi hanya oleh server sistem. Namun, karena netd
, init
, dan vold
dijalankan sebagai root, mereka dapat mengakses file sistem tersebut. Jadi, jika netd
disusupi, hal ini dapat membahayakan file-file tersebut dan kemungkinan juga 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. Bahkan jika netd
disusupi, netd tidak dapat mengalihkan domain ke domain server sistem dan mengakses file sistem tersebut meskipun dijalankan sebagai root.
Data aplikasi - Contoh lainnya adalah kelas fungsi yang harus dijalankan sebagai root tetapi tidak boleh mengakses data aplikasi. Hal ini sangat berguna karena pernyataan yang luas dapat dibuat, seperti domain tertentu yang tidak terkait dengan data aplikasi dilarang mengakses internet.
setattr - Untuk perintah seperti chmod
dan chown
, Anda dapat mengidentifikasi kumpulan file tempat domain terkait dapat menjalankan setattr
. Apa pun di luar itu dapat dilarang dari perubahan ini, bahkan secara root. Jadi suatu aplikasi mungkin berjalan chmod
dan chown
terhadap yang berlabel app_data_files
tetapi tidak shell_data_files
atau system_data_files
.