Paradigma Mandatory Access Control pada Android
Pada fondasi sistem operasi berbasis Unix tradisional, keamanan akses file diatur oleh model Discretionary Access Control (DAC) yang bertumpu pada User Identifier (UID) dan Group Identifier (GID). Dalam sistem DAC, pemilik file memiliki wewenang diskresioner penuh untuk menentukan izin baca, tulis, dan eksekusi bagi entitas lain. Android mengadopsi DAC melalui arsitektur Application Sandbox, di mana setiap aplikasi diberikan UID unik (misalnya u0_a142). Namun, model DAC memiliki kelemahan kritis: proses yang berjalan dengan hak akses superuser (UID 0 / root) memiliki kapabilitas mutlak yang mengabaikan pembatasan izin filesystem.
Untuk mengatasi celah keamanan inheren pada DAC, Android mengintegrasikan Security-Enhanced Linux (SELinux) sejak versi 4.4 KitKat dan mewajibkan mode Enforcing secara penuh pada build produksi sejak Android 5.0 Lollipop. SELinux mengimplementasikan Mandatory Access Control (MAC), sebuah mekanisme di mana setiap interaksi sistem — mulai dari pemanggilan sistem (syscall), akses socket jaringan, hingga pembacaan node sysfs — harus secara eksplisit diizinkan oleh kebijakan keamanan terpusat (security policy).
Arsitektur Type Enforcement dan Format Konteks Keamanan
Mekanisme inti SELinux pada Android menggunakan Type Enforcement (TE). Di bawah model TE, seluruh subjek (proses yang aktif) dan objek (file, socket, blok perangkat, layanan binder) dilabeli dengan konteks keamanan formal berformat empat elemen standar:
user:role:type:sensitivity_level
Pada implementasi Android, sebagian besar elemen disederhanakan untuk efisiensi sistem: pengguna selalu didefinisikan sebagai u, role sebagai r (untuk proses) atau object_r (untuk file/objek), diikuti oleh identifier tipe (type) dan level sensitivitas Multi-Category Security (MCS), misalnya s0:c512,c768 pada container aplikasi terisolasi.
| Label Domain SELinux | Kategori Subjek | Tingkat Hak Akses | Perilaku Akses IPC / Filesystem |
|---|---|---|---|
u:r:init:s0 |
Proses Init (PID 1) | Tertinggi | Dapat mengeksekusi transisi domain, me-mount partisi, dan memuat sepolicy. |
u:r:system_server:s0 |
Framework Android Core | Tinggi Terkelola | Mengelola layanan binder sistem, dilarang mengakses langsung hardware node tanpa HAL. |
u:r:hal_bluetooth_default:s0 |
HAL Bluetooth Vendor | Spesifik Perangkat | Dibatasi hanya untuk node UART/TTY bluetooth dan socket jaringan Bluetooth. |
u:r:untrusted_app:s0 |
Aplikasi Pihak Ketiga | Sangat Terisolasi | Dilarang keras mengeksekusi syscall tertentu, memuat biner eksternal, atau berinteraksi langsung dengan kernel driver. |
Peringatan Kepatuhan CTS: Larangan Permissive Mode pada Build Rilis
Google Compatibility Test Suite (CTS) secara ketat menggagalkan sertifikasi perangkat apabila kernel beroperasi dalam status Permissive. Mode Permissive hanya diperbolehkan selama fase rekayasa internal untuk mengidentifikasi AVC denials baru.
Mekanisme Transisi Domain (Domain Transition)
Salah satu konsep terpenting dalam Type Enforcement adalah bagaimana sebuah proses berpindah dari satu tingkat hak akses ke tingkat hak akses lainnya. Ketika proses init mengeksekusi biner daemon baru, daemon tersebut tidak boleh mewarisi hak istimewa tak terbatas milik init. Proses ini diatur oleh aturan transisi domain formal:
# Sintaksis transisi domain
type_transition source_domain executable_file_type:process target_domain;
Sebagai contoh nyata pada subsistem vendor, ketika init (domain u:r:init:s0) mengeksekusi biner driver kamera di /vendor/bin/hw/[email protected] (berlabel hal_camera_default_exec), kernel secara otomatis mentransisikan proses baru tersebut ke domain terisolasi hal_camera_default. Biner eksekutabel bertindak sebagai pintu masuk (entrypoint), dan aturan neverallow AOSP mencegah domain aplikasi umum mengeksekusi file berlabel entrypoint sistem.
Struktur File Konfigurasi Sepolicy Terpisah (Split Policy)
Seiring dengan diperkenalkannya arsitektur Project Treble pada Android 8.0, Google merombak struktur biner sepolicy monolitik menjadi model terpisah (split sepolicy). Pemisahan ini membedakan antara kebijakan kerangka kerja umum yang dikelola Google (AOSP System Sepolicy) dan kebijakan spesifik perangkat keras yang dikembangkan oleh vendor chipset (Vendor Sepolicy).
Hierarki Lokasi File Kebijakan pada Partisi
/system/etc/selinux/plat_sepolicy.cil: Kebijakan platform inti AOSP yang tidak boleh diubah oleh vendor perangkat./vendor/etc/selinux/vendor_sepolicy.cil: Kebijakan khusus vendor untuk mengizinkan daemon hardware berinteraksi dengan driver kernel proprietari./system/etc/selinux/mapping/: File pemetaan kompatibilitas versi API untuk memastikan antarmuka biner platform lama tetap dapat beroperasi dengan vendor image baru.
# Memeriksa status penegakan SELinux saat ini pada perangkat
adb shell getenforce
# Menampilkan konteks keamanan proses aktif di Android
adb shell ps -AZ
# Menampilkan konteks keamanan direktori dan file pada partisi sistem
adb shell ls -laZ /system/bin/Analisis dan Debugging Log AVC Denial via Audit Subsystem
Ketika sebuah proses mencoba melakukan operasi yang tidak didefinisikan dalam tabel sepolicy, subsistem audit kernel Linux memblokir operasi tersebut dan mencatat pesan peringatan Access Vector Cache (AVC) denial ke dalam ring buffer kernel. Pesan ini dapat diekstraksi melalui utilitas dmesg atau buffer logcat events.
# Menyaring log penolakan akses SELinux secara realtime dari kernel
adb shell "dmesg -w | grep avc"
# Mengekstraksi riwayat audit log melalui logcat event buffer
adb shell logcat -b events | grep avcBerikut adalah anatomi log penolakan AVC denial standar pada Android:
type=1400 audit(0.0:42): avc: denied { read } for comm="sensor_service" name="calib_data" dev="sda12" ino=8192 scontext=u:r:hal_sensors_default:s0 tcontext=u:object_r:sensor_cal_file:s0 tclass=file permissive=0Anatomi Parameter Log AVC Denial:
denied { read }: Operasi yang diminta oleh proses tetapi tidak memiliki otorisasi izin.scontext=u:r:hal_sensors_default:s0: Konteks domain subjek yang mengeksekusi operasi (Source Context).tcontext=u:object_r:sensor_cal_file:s0: Konteks target objek yang hendak diakses (Target Context).tclass=file: Kelas objek target (file, dir, chr_file, unix_stream_socket, binder).permissive=0: Menandakan bahwa pelanggaran diblokir secara nyata karena kernel berada pada mode Enforcing.
Penyusunan Aturan Allow Rule yang Aman
Dalam proses pengembangan Custom ROM atau penyesuaian firmware AOSP, pengembang sering kali perlu menambahkan aturan baru pada file .te. Format deklarasi aturan dasar SELinux mengikuti sintaksis formal:
rule_type source_type target_type:class { permissions };
Sebagai contoh, untuk menyelesaikan AVC denial pada sensor di atas tanpa melanggar prinsip least-privilege, aturan berikut ditambahkan ke dalam file device/vendor/sepolicy/sensor.te:
# Memberikan izin baca terisolasi pada file kalibrasi sensor
allow hal_sensors_default sensor_cal_file:file { read open getattr };Kesimpulan dan Audit Keamanan
Implementasi SELinux Enforcing merupakan pertahanan lapis kedua yang sangat krusial dalam arsitektur keamanan Android modern. Sekalipun terdapat kerentanan zero-day memory corruption pada biner tingkat pengguna, pembatasan domain SELinux yang ketat akan mencegah penyerang melakukan eskalasi hak istimewa, memodifikasi partisi blok mentah, atau mengakses memori proses sensitif lainnya.