Belajar SELinux - Sejarah, Latar Belakang & Mengapa Membutuhkan SELinux

#Pendahuluan

Di episode 0 sebelumnya kita menyiapkan environment: menginstall tools userspace SELinux dan memverifikasi bahwa sistem berjalan dalam mode enforcing. Pada episode kali ini kita akan menarik napas sejenak dari hands-on dan menjawab pertanyaan paling mendasar: mengapa SELinux ada? Tanpa memahami masalah yang ingin dipecahkan, kalian hanya akan menghafal perintah tanpa pernah paham kapan dan kenapa perintah itu diperlukan.

Kita akan menelusuri sejarah kelahiran SELinux, memahami keterbatasan sistem permission klasik Linux (DAC), dan melihat bagaimana Mandatory Access Control (MAC) mengubah aturan main keamanan di level sistem operasi. Seperti kata pepatah, kita perlu memahami masa lalu agar tidak mengulangi kesalahan yang sama di masa depan.

#Keterbatasan DAC: Masalah yang Ingin Dipecahkan

Sebelum SELinux lahir, Linux mengandalkan DAC (Discretionary Access Control) — sistem permission yang sudah kalian pelajari di episode 0: file punya pemilik, dan pemilik berhak menentukan siapa yang boleh mengakses. Ini disebut discretionary karena keputusan akses ada di tangan pemilik objek (user), yang bisa "memberi" akses ke siapa pun sesuka hatinya.

Masalahnya, DAC memiliki tiga kelemahan fundamental:

1. Permission hanya berbasis user dan group. Apakah sebuah proses boleh membaca file ditentukan oleh user yang menjalankannya. Dua proses berbeda yang dijalankan user yang sama memiliki hak yang sama persis — padahal secara fungsi mereka bisa sangat berbeda.
2. Root adalah kekuatan mutlak. User dengan UID 0 (root) bisa mengakses dan melakukan apa pun. Semua aturan chmod tidak berlaku untuknya. Ini seperti memberi satu orang kunci ke seluruh gedung.
3. Program bisa di-exploit tanpa terkendali. Jika aplikasi dengan permission longgar berhasil di-exploit, penyerang langsung mendapat hak sesuai user yang menjalankan aplikasi tersebut — sering kali root.

Analogi paling pas: DAC itu seperti pintu gedung dengan kartu identitas. Selama kalian punya kartu (user yang valid), kalian bisa masuk ke ruangan mana pun yang pintunya tidak dikunci — bahkan ruangan yang isinya sama sekali tidak berhubungan dengan pekerjaan kalian. Kartu di tangan penjahat pun tetap berfungsi sama baiknya.

#MAC: Mandatory Access Control

Dari keterbatasan itulah lahir konsep MAC (Mandatory Access Control). Berbeda dengan DAC yang "discretionary" (terserah pemilik), MAC bersifat "mandatory" (wajib): aturan akses ditentukan oleh kebijakan terpusat, bukan oleh pemilik objek. Pemilik file tidak bisa "memberi" akses lebih dari yang diizinkan kebijakan.

Prinsip kunci yang wajib kalian ingat sepanjang series ini:

Dengan MAC, bahkan root pun dibatasi oleh kebijakan.

Ini lompatan besar. Di dunia MAC, setiap proses dan setiap objek diberi label konteks (security context). Kebijakan (policy) menentukan pasangan proses-label mana yang boleh berinteraksi dengan objek-label mana. Root pun hanyalah salah satu proses berlabel — jika kebijakan tidak mengizinkannya mengakses sesuatu, akses itu akan ditolak, sekalipun UID-nya nol.

Untuk memperjelas perbedaan kedua dunia ini, mari bandingkan DAC dan MAC secara berdampingan:

Pertimbangkan satu skenario untuk merasakan perbedaannya. Bayangkan sebuah web server yang dieksploitasi penyerang: di dunia DAC, proses web server berjalan sebagai user www-data — begitu aplikasi di-exploit, penyerang bisa membaca file apa pun yang bisa dibaca www-data, termasuk file konfigurasi aplikasi, kredensial database, bahkan data pengguna jika permission-nya longgar. Di dunia MAC, proses tersebut berjalan dalam domain berlabel httpd_t — penyerang tetap terjebak di domain itu, dan tidak bisa menyentuh file berlabel passwd_t atau shadow_t, apa pun permission file-nya. Itulah kekuatan yang ingin dibawa SELinux ke Linux: membatasi kerusakan, bukan hanya mencegah serangan.

#Apa yang SELinux Bukan

Sebelum melangkah lebih jauh, mari buang beberapa miskonsepsi yang sering membuat orang takut pada SELinux:

1. SELinux bukan antivirus. Ia tidak memindai file atau mendeteksi malware. Ia membatasi apa yang boleh dilakukan proses — termasuk proses yang sudah terinfeksi.
2. SELinux bukan pengganti firewall. Firewall mengatur lalu lintas jaringan antar host; SELinux mengatur akses di dalam satu host. Keduanya bekerja berdampingan, bukan saling menggantikan.
3. SELinux bukan pengganti permission file. DAC tetap berjalan di lapisan pertama. SELinux adalah lapisan kedua yang memperketat — bukan pengganti chmod dan chown.
4. SELinux bukan "hanya untuk server rahasia". Dari laptop Fedora hingga miliaran perangkat Android, SELinux sudah berjalan di mana-mana tanpa kalian sadari.

#Kelahiran SELinux: NSA, Red Hat, dan Kernel 2.6

SELinux adalah implementasi MAC untuk Linux yang dikembangkan oleh National Security Agency (NSA) bekerja sama dengan Red Hat dan komunitas Linux. Proyek ini dimulai pada awal 2000-an, dengan tujuan membawa keamanan ala lembaga pertahanan (yang sudah lama diterapkan di sistem operasi khusus) ke Linux arus utama.

Perjalanannya ringkas:

Saat ini, SELinux menjadi default enforcing di RHEL, Fedora, dan CentOS. Di Debian, statusnya sebaliknya — minimal dan tidak default (mereka memilih AppArmor). Android sendiri menjalankan SEAndroid, varian SELinux yang dioptimalkan untuk perangkat mobile — jadi perangkat di saku kalian sehari-hari sebenarnya sudah menjalankan teknologi ini.

Sebagai gambaran, berikut potongan log yang akan sangat akrab bagi kalian di episode-episode troubleshooting nanti — contoh denial AVC (Access Vector Cache) saat sebuah proses ditolak:

type=AVC msg=audit(1754256000.123:456): avc: denied { read } for pid=1234 comm="nginx" name="index.html" dev="sda1" ino=5678 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:user_home_t:s0 tclass=file

Perhatikan bagian scontext (konteks subjek/proses) dan tcontext (konteks target/objek): proses berlabel httpd_t menolak membaca file berlabel user_home_t. Inilah inti MAC — bukan siapa user-nya, melainkan label apa yang terlibat. Kita akan membedah setiap bagian log ini di episode 2 dan 3.

#Ekosistem Modern: Userspace 3.11

SELinux bukan sekadar kernel — ia adalah ekosistem lengkap yang terus berevolusi. Pada Juli 2026, userspace SELinux mencapai versi 3.11, dengan seperangkat tools modern yang justru akan kalian pakai setiap hari:

• semodule — mengelola modul policy: menginstall, menghapus, dan menonaktifkan modul.
• semanage — mengelola konfigurasi runtime seperti pemetaan label filesystem, port, dan user.
• audit2allow — membaca log denial dan menghasilkan aturan policy yang mengizinkan — tools yang akan kita dalami di episode-episode berikutnya.

Tools inilah yang membedakan SELinux modern dari citra lamanya yang "sulit dan menyeramkan". Dengan userspace yang matang, mengelola policy SELinux hari ini jauh lebih mudah daripada sepuluh tahun lalu — dan itulah salah satu alasan series ini layak kalian pelajari dari nol.

#Kesalahan Umum (Common Pitfalls)

1. Mengira SELinux hanya mengganggu dan harus dimatikan. Ini mentalitas yang paling merugikan. SELinux adalah lapisan pertahanan yang sudah terbukti memblokir ribuan eksploitasi nyata — justru deny yang mengganggu adalah cara sistem melindungi kalian.
2. Mengira SELinux menggantikan chmod/firewall. Ketiganya bekerja di lapisan berbeda. Kalian tetap butuh DAC, tetap butuh firewall — SELinux melengkapi, bukan menggantikan.
3. Menilai SELinux dari pengalaman usang. Citra "SELinux sulit dan tidak bisa digunakan" lahir dari era awal. Dengan userspace modern seperti 3.11, troubleshooting dan pengelolaan policy jauh lebih ramah.
4. Tidak membaca denial, hanya mengabaikannya. Setiap denial AVC berisi informasi lengkap — proses, label, operasi, dan kelas objek. Kalian tidak akan pernah bisa memecahkan masalah keamanan jika tidak mau membaca datanya.

#Penutup

Pada episode 1 ini kita telah menelusuri mengapa SELinux lahir: keterbatasan DAC yang hanya membatasi berdasarkan user dan group, konsep MAC yang membatasi semua orang — termasuk root — berdasarkan kebijakan terpusat dan label konteks, sejarah pengembangan NSA bersama Red Hat sejak awal 2000-an, integrasi ke kernel 2.6 pada 2003, hingga ekosistem userspace 3.11 modern yang dipakai hari ini.

Inti yang harus kalian bawa:

• DAC hanya membatasi berdasarkan user dan group — dan tidak membatasi root.
• MAC menentukan akses berdasarkan label konteks dan kebijakan terpusat — pemilik objek tidak berkuasa penuh.
• SELinux lahir dari proyek NSA bersama Red Hat dan masuk kernel Linux 2.6 pada 2003.
• SELinux default enforcing di RHEL/Fedora/CentOS; minimal di Debian; SEAndroid di Android.
• Denial AVC adalah informasi berlabel scontext dan tcontext — bukan musuh, melainkan data untuk didiagnosis.

Pemahaman "mengapa" ini menjadi fondasi untuk memahami "bagaimana" SELinux bekerja. Di episode 2 selanjutnya, kita akan membahas konsep dasar & arsitektur utama — membedah Type Enforcement, membongkar format security context user:role:type:sensitivity, memahami peran AVC, hingga struktur kernel LSM dan tools userspace yang menyusun keseluruhan sistem. Pastikan tetap semangat, karena dari sinilah kalian mulai benar-benar memahami cara kerja SELinux dari dalam!