Membongkar fondasi arsitektur SELinux: Type Enforcement yang membatasi domain terhadap type, format security context user:role:type:sensitivity, peran Access Vector Cache (AVC), hingga lapisan kernel LSM dan tools userspace yang bekerja sama menjalankan policy.

Di episode 1 kita memahami mengapa SELinux ada: DAC tidak cukup membatasi, dan MAC lahir untuk membatasi semua orang — termasuk root — berdasarkan kebijakan terpusat dan label konteks. Sekarang saatnya membongkar bagaimana SELinux bekerja. Episode ini akan membangun bahasa dasar yang akan kalian pakai di semua episode berikutnya: Type Enforcement, security context, AVC, dan arsitektur lengkap dari kernel hingga userspace.
Anggap episode ini sebagai pembelajaran tata bahasa: tanpa menguasai istilah dan struktur ini, kalian tidak akan bisa membaca log denial, apalagi menulis policy sendiri.
Jantung SELinux adalah Type Enforcement (TE) — mekanisme yang menentukan apakah sebuah proses boleh melakukan akses tertentu terhadap sebuah objek. TE bekerja dengan dua konsep inti:
httpd_t untuk web server.httpd_sys_content_t untuk file yang boleh dibaca web server, atau etc_t untuk file konfigurasi di /etc.Policy SELinux adalah kumpulan aturan yang menentukan pasangan domain → type mana yang boleh berinteraksi, beserta operasi apa saja (baca, tulis, eksekusi, buka port, dan seterusnya). Tanpa aturan eksplisit yang mengizinkan, akses ditolak — ini prinsip default deny yang menjadi kekuatan utama SELinux.
Analogi terbaik: domain adalah kartu akses pegawai, type adalah label pintu ruangan. Web server (httpd_t) boleh masuk ruangan httpd_sys_content_t, tapi tidak boleh masuk ruangan shadow_t yang berisi file password. Meski kartunya dipegang root sekalipun — karena aturan dipegang kebijakan, bukan pemegang kartu.
Setiap proses dan objek di sistem SELinux membawa label bernama security context dengan format:
user:role:type:sensitivity[:category]Contoh nyata yang sudah sempat kita lihat di episode 1:
unconfined_u:object_r:etc_t:s0Mari bedah satu per satu komponennya:
unconfined_u — SELinux user. Bukan user Linux, melainkan user dalam domain policy yang menentukan tingkat kepercayaan. unconfined_u berarti user biasa tanpa batasan khusus.object_r — role. Pada objek, peran hampir selalu object_r; pada proses, role menentukan domain mana yang boleh digunakan.etc_t — type. Ini bagian yang paling sering kalian perhatikan: label objek yang dicocokkan dengan aturan TE.s0 — sensitivity, level keamanan. Untuk policy targeted tanpa MLS, hampir selalu s0. Bagian :category (MCS) ditambahkan jika kalian perlu memisahkan data lebih lanjut, misalnya s0:c0,c1.Untuk melihat context di sistem nyata, coba ps -eZ untuk proses dan ls -Z untuk file:
ps -eZ | head -5
ls -Z /etcLABEL PID TTY TIME CMD
system_u:system_r:init_t:s0 1 ? 00:00:02 systemd
system_u:system_r:sshd_t:s0 980 ? 00:00:00 sshd
/etc:
system_u:object_r:etc_t:s0 aliases
system_u:object_r:etc_t:s0 chronyPerhatikan pola s0 di semua baris dan perbedaan antara role system_r (proses) dan object_r (file). Keterbiasaan membaca format ini akan sangat membantu di episode 3 saat kalian membaca log denial.
Menghitung izin berdasarkan ribuan aturan policy setiap kali sebuah proses menyentuh file akan sangat lambat. Di sinilah Access Vector Cache (AVC) berperan: SELinux menyimpan hasil keputusan di dalam cache agar permintaan akses berikutnya bisa dijawab langsung tanpa mengevaluasi policy lagi.
Setiap kali keputusan menghasilkan denied, AVC mencatatnya ke log audit — dan log inilah yang disebut denial AVC, seperti yang sudah kalian lihat di episode 1. Istilah "AVC denied" yang sering kalian jumpai di forum adalah hasil catatan cache ini. Dengan memahami bahwa AVC adalah lapisan performa sekaligus sumber log, kalian akan lebih mudah menavigasi file /var/log/audit/audit.log nanti.
SELinux dibangun dari dua dunia yang berjalan bersama.
Di dalam kernel, SELinux terpasang sebagai Linux Security Module (LSM) — kerangka kerja yang menyediakan hook ke titik-titik pengambilan keputusan akses. Setiap kali ada syscall yang menyentuh objek, hook LSM dipanggil, label dicek terhadap policy, dan hasilnya di-cache di AVC. Antarmuka untuk berkomunikasi dengan kernel tersedia lewat filesystem virtual selinuxfs yang di-mount di /sys/fs/selinux.
Di luar kernel, lapisan userspace menyediakan tools dan library yang akan kalian gunakan setiap hari:
| Komponen | Peran |
|---|---|
policycoreutils | Tools inti: restorecon, setsebool, chcon |
libselinux | Library C untuk interaksi aplikasi dengan SELinux |
libsepol | Compiler dan parser policy binary |
setools | Tools analisis: sesearch, seinfo untuk membaca policy |
semanage | Manajemen konfigurasi runtime: fcontext, port, user, boolean |
Alur kerjanya: admin mengubah konfigurasi lewat tools userspace → policy dikompilasi ke format binary oleh libsepol → dimuat ke kernel → hook LSM menegakkannya berdasarkan label dan AVC. Satu sistem besar yang semua lapisannya bisa kita observasi.
Policy SELinux hadir dalam beberapa varian, dan dua yang paling sering dibahas adalah:
targeted — policy default di RHEL/Fedora/Rocky. Hanya melindungi proses yang ditargetkan (daemon seperti httpd_t, sshd_t, named_t); sisanya berjalan dalam domain unconfined_t yang nyaris tanpa batasan. Pilihan yang paling seimbang antara keamanan dan kenyamanan.strict — seluruh proses dibatasi ketat, tanpa domain unconfined_t. Jauh lebih aman secara teori, tapi sangat berat untuk dioperasikan sehari-hari — karena itu jarang dipakai di produksi.Varian lain yang perlu kalian kenal namanya saja: minimum (turunan targeted yang lebih kecil) dan mls (menambahkan Multi-Level Security dengan sensitivity bertingkat). Kapan pun kalian melihat SELINUXTYPE=targeted di /etc/selinux/config, itulah policy yang sedang berjalan.
Note
Untuk series ini, semua contoh dan praktik berasumsi policy targeted — default di hampir semua instalasi keluarga Red Hat. Konsep Type Enforcement, context, dan denial yang kalian pelajari berlaku sama di semua varian policy; yang berbeda hanya seberapa banyak proses yang dilindungi.
Pada episode 2 ini kita telah membangun bahasa dasar SELinux: Type Enforcement yang membatasi domain (subjek) terhadap type (objek), format security context user:role:type:sensitivity[:category], peran AVC sebagai cache keputusan sekaligus sumber log denial, arsitektur kernel LSM + userspace yang bekerja bersama, hingga perbedaan policy targeted dan strict.
Inti yang harus kalian bawa:
user:role:type:sensitivity[:category] — contoh unconfined_u:object_r:etc_t:s0.libselinux, libsepol, setools, semanage) sebagai pengendali.Dengan tata bahasa ini di tangan, kalian siap berlatih. Di episode 3 selanjutnya, kita akan membahas mode, status & troubleshooting dasar — perbedaan enforcing, permissive, dan disabled, cara berpindah antar mode dengan aman, membaca getenforce dan sestatus, hingga mendiagnosis denial pertama kalian dari /var/log/audit/audit.log menggunakan ausearch. Pastikan tetap semangat, karena mulai episode ini kalian akan sering berdiri di terminal!