SELinux disiapkan untuk menolak secara default, yang berarti setiap akses yang memiliki hook di kernel harus diizinkan secara eksplisit oleh kebijakan. Artinya, file kebijakan terdiri dari sejumlah besar informasi terkait aturan, jenis, class, izin, dan lainnya. Pertimbangan lengkap SELinux tidak termasuk dalam cakupan dokumen ini, tetapi pemahaman tentang cara menulis aturan kebijakan kini sangat penting saat menampilkan perangkat Android baru. Ada banyak informasi yang tersedia terkait SELinux. Lihat Dokumentasi dukungan untuk referensi yang disarankan.
File kunci
Untuk mengaktifkan SELinux, integrasikan kernel Android terbaru, lalu gabungkan file yang ditemukan di direktori system/sepolicy. Saat dikompilasi, file tersebut terdiri dari 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 sendiri di direktori /device/manufacturer/device-name/sepolicy
. Di Android 8.0 dan yang lebih tinggi, perubahan yang Anda buat pada file ini hanya
akan memengaruhi kebijakan di direktori vendor Anda. Untuk mengetahui detail selengkapnya tentang pemisahan
sepolicy publik di Android 8.0 dan yang lebih tinggi, lihat
Menyesuaikan SEPolicy di Android
8.0+. Terlepas dari versi Android, Anda masih mengubah file ini:
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 mengupdate 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 ruang pengguna. Saat Anda membuat kebijakan baru, buat atau perbarui file ini untuk menetapkan label baru ke file. Untuk menerapkanfile_contexts
baru, build ulang image sistem file atau jalankanrestorecon
pada file yang akan diberi label ulang. Saat upgrade, perubahan padafile_contexts
secara otomatis diterapkan ke partisi sistem dan userdata sebagai bagian dari upgrade. Perubahan juga dapat diterapkan secara otomatis saat mengupgrade ke partisi lain dengan menambahkan panggilanrestorecon_recursive
ke file init.board.rc setelah partisi di-mount sebagai baca-tulis.genfs_contexts
menetapkan label ke 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 core, yang memerlukan mulai ulang atau pembongkaran dan pemasangan ulang sistem file untuk menerapkan perubahan sepenuhnya. Label tertentu juga dapat ditetapkan ke pemasangan tertentu, sepertivfat
menggunakan opsicontext=mount
.property_contexts
menetapkan label ke properti sistem Android untuk mengontrol proses yang dapat menetapkannya. Konfigurasi ini dibaca oleh prosesinit
selama startup.service_contexts
menetapkan label ke layanan binder Android untuk mengontrol proses yang dapat menambahkan (mendaftarkan) dan menemukan (mencari) referensi binder untuk layanan. Konfigurasi ini dibaca oleh prosesservicemanager
selama startup.seapp_contexts
menetapkan label ke proses aplikasi dan direktori/data/data
. Konfigurasi ini dibaca oleh proseszygote
pada setiap peluncuran aplikasi dan olehinstalld
selama startup.mac_permissions.xml
menetapkan tagseinfo
ke aplikasi berdasarkan tanda tangan dan nama paketnya secara opsional. Tagseinfo
kemudian dapat digunakan sebagai kunci dalam fileseapp_contexts
untuk menetapkan label tertentu ke semua aplikasi dengan tagseinfo
tersebut. Konfigurasi ini dibaca olehsystem_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 namespace yang ditentukan sepolicy. Deskripsi mendetail tentang format dan konvensi file ini dapat ditemukan di sini.
File make BoardConfig.mk
Setelah mengedit atau menambahkan file kebijakan dan konteks, perbarui
makefile
/device/manufacturer/device-name/BoardConfig.mk
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 mem-build ulang, perangkat Anda akan diaktifkan dengan SELinux. Sekarang Anda dapat menyesuaikan kebijakan SELinux untuk mengakomodasi penambahan Anda sendiri ke sistem operasi Android seperti yang dijelaskan dalam Penyesuaian atau memverifikasi penyiapan yang ada seperti yang dibahas dalam Validasi.
Saat file kebijakan baru dan update BoardConfig.mk diterapkan, setelan kebijakan baru akan otomatis di-build ke dalam file kebijakan kernel akhir. Untuk informasi selengkapnya tentang cara sepolicy dibuat di perangkat, lihat Mem-build sepolicy.
Implementasi
Untuk memulai SELinux:
- Mengaktifkan SELinux di kernel:
CONFIG_SECURITY_SELINUX=y
- Ubah parameter kernel_cmdline atau bootconfig sehingga:
atauBOARD_KERNEL_CMDLINE := androidboot.selinux=permissive
Ini hanya untuk pengembangan awal kebijakan untuk perangkat. Setelah Anda memiliki kebijakan bootstrap awal, hapus parameter ini agar perangkat Anda menerapkan atau gagal CTS.BOARD_BOOTCONFIG := androidboot.selinux=permissive
- Mulai booting sistem dalam mode permisif dan lihat penolakan yang terjadi saat booting:
Di Ubuntu 14.04 atau yang lebih baru: Di Ubuntu 12.04:adb shell su -c dmesg | grep denied | audit2allow -p out/target/product/BOARD/root/sepolicy
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 memerlukan pemberian label.
- Gunakan label yang ada atau baru untuk objek Anda. Lihat file
*_contexts
untuk melihat cara pemberian label sebelumnya dan gunakan pengetahuan tentang makna label untuk menetapkan label baru. Idealnya, ini adalah label yang ada dan sesuai dengan kebijakan, tetapi terkadang label baru diperlukan, dan aturan untuk akses ke label tersebut diperlukan. 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 setiap kebijakan. Misalnya, semua
layanan yang dihasilkan dari
init
harus memiliki layanannya sendiri. Perintah berikut membantu mengungkapkan layanan 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. Berikan domain kepada mereka lebih awal dalam proses pengembangan Anda untuk menghindari penambahan aturan keinit
atau membingungkan aksesinit
dengan akses yang ada dalam kebijakan mereka sendiri. - Siapkan
BOARD_CONFIG.mk
untuk menggunakan variabelBOARD_SEPOLICY_*
. Lihat README disystem/sepolicy
untuk mengetahui detail tentang cara menyiapkannya. - Periksa file init.device.rc dan fstab.device dan
pastikan setiap penggunaan
mount
sesuai dengan sistem file yang diberi label dengan benar atau bahwa opsicontext= mount
ditentukan. - Periksa setiap penolakan dan buat kebijakan SELinux untuk menangani setiap penolakan dengan benar. Lihat contoh di Penyesuaian.
Anda harus memulai dengan kebijakan di AOSP, lalu mem-build-nya untuk penyesuaian Anda sendiri. Untuk informasi selengkapnya tentang strategi kebijakan dan penjelasan lebih lanjut tentang beberapa langkah ini, lihat Menulis Kebijakan SELinux.
Kasus penggunaan
Berikut adalah contoh khusus eksploit yang perlu dipertimbangkan saat membuat software Anda sendiri dan kebijakan SELinux terkait:
Symlink: Karena symlink muncul sebagai file, symlink sering kali
dibaca sebagai file, yang dapat menyebabkan eksploitasi. Misalnya, beberapa komponen
berhak istimewa, seperti init
, mengubah izin file tertentu,
terkadang terlalu terbuka.
Penyerang kemudian dapat mengganti file tersebut dengan symlink ke kode yang mereka kontrol, sehingga penyerang dapat menimpa file arbitrer. Namun, jika Anda mengetahui bahwa aplikasi tidak pernah melintasi symlink, Anda dapat melarangnya melakukannya dengan SELinux.
File sistem: Pertimbangkan class file sistem yang
hanya boleh diubah oleh server sistem. Namun, karena netd
,
init
, dan vold
berjalan sebagai root, ketiganya dapat mengakses
file sistem tersebut. Jadi, jika netd
disusupi, file tersebut dapat
disusupi dan berpotensi 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 ke domain tersebut adalah server sistem.
Meskipun disusupi, netd
tidak dapat mengalihkan domain ke
domain server sistem dan mengakses file sistem tersebut meskipun berjalan sebagai root.
Data aplikasi: Contoh lainnya adalah class fungsi yang harus berjalan 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 yang dilarang mengakses internet.
setattr: Untuk perintah seperti chmod
dan
chown
, Anda dapat mengidentifikasi kumpulan file tempat domain
terkait dapat melakukan setattr
. Apa pun di luar itu dapat
dilarang dari perubahan ini, bahkan oleh root. Jadi, aplikasi mungkin menjalankan
chmod
dan chown
terhadap aplikasi yang berlabel
app_data_files
, tetapi bukan shell_data_files
atau system_data_files
.