Bayangkan Anda sudah memasang firewall, mengunci akses SSH dengan key-based authentication, rutin update paket, lalu merasa server sudah “aman”. Tapi ada satu lapisan pertahanan yang sangat sering diabaikan, bahkan oleh sysadmin berpengalaman: Mandatory Access Control (MAC), yang di Linux diwujudkan lewat dua nama besar — SELinux dan AppArmor.

Banyak orang mengenal keduanya hanya sebagai “sumber error yang bikin aplikasi gagal jalan”, sehingga solusi paling populer adalah mematikannya dengan setenforce 0 atau systemctl disable apparmor. Padahal langkah itu sama saja dengan melepas rompi anti-peluru karena terasa berat dipakai.

Artikel ini akan membahas tuntas konsep MAC, perbedaan mendasar SELinux dan AppArmor, kenapa setenforce 0 berbahaya, serta cara mendiagnosis masalah SELinux secara benar menggunakan audit2allow — tanpa harus mengorbankan keamanan sistem.

Apa Itu Mandatory Access Control (MAC)?

Secara default, Linux menggunakan Discretionary Access Control (DAC) — sistem permission klasik berbasis rwx, user, dan group yang kita kenal lewat chmod dan chown. Masalahnya, DAC punya kelemahan fundamental: siapa pun yang berjalan sebagai root, atau siapa pun yang memiliki file, bisa mengubah aksesnya sendiri. Jika sebuah proses (misalnya web server) berhasil dieksploitasi, penyerang otomatis mewarisi seluruh hak akses user tersebut.

MAC hadir sebagai lapisan kedua yang tidak bisa diubah oleh pemilik proses itu sendiri. Kebijakan MAC ditentukan oleh administrator sistem lewat policy terpusat, dan berlaku terlepas dari permission DAC. Analoginya sederhana: DAC seperti kunci pintu rumah yang bisa dibuka pemiliknya kapan saja, sedangkan MAC seperti satpam kompleks yang tetap memeriksa identitas Anda meskipun Anda sudah punya kunci rumah sendiri. Bahkan jika pintu rumah (DAC) berhasil dibobol, satpam (MAC) tetap membatasi ruang gerak penyusup.

Di Linux, MAC diimplementasikan lewat kerangka kerja Linux Security Modules (LSM) di level kernel, dan dua implementasi paling populer adalah SELinux dan AppArmor.

SELinux: Kontrol Berbasis Label

SELinux (Security-Enhanced Linux) awalnya dikembangkan oleh NSA bersama Red Hat, dan menjadi default di distro keluarga RHEL seperti CentOS, Fedora, Rocky Linux, dan AlmaLinux.

Prinsip kerja SELinux adalah labeling. Setiap file, proses, port, dan socket diberi security context dengan format user:role:type:level. Mekanisme intinya disebut Type Enforcement (TE) — misalnya proses Apache berjalan dengan label httpd_t, sedangkan file konten web memiliki label berbeda seperti httpd_sys_content_t. Aturan policy menentukan domain proses mana yang boleh berinteraksi dengan tipe objek apa.

Karakteristik penting SELinux:

• Default deny. Kecuali ada aturan eksplisit yang mengizinkan, akses akan ditolak.
• Mendukung Multi-Level Security (MLS) dan Multi-Category Security (MCS), cocok untuk lingkungan yang butuh klasifikasi data ketat seperti pemerintahan atau finansial.
• Policy sangat granular, tapi kurva belajarnya curam dan proses debugging bisa terasa rumit bagi pemula.

AppArmor: Kontrol Berbasis Path

AppArmor mengambil pendekatan berbeda: path-based alih-alih label-based. AppArmor default aktif di Ubuntu sejak versi 7.10 dan banyak dipakai di distro turunan Debian.

Alih-alih menandai setiap file dengan label, AppArmor mendefinisikan profile per aplikasi yang berisi path file atau direktori mana saja yang boleh diakses, beserta jenis izinnya (baca, tulis, eksekusi). Profile ini berupa file teks biasa di /etc/apparmor.d/, jauh lebih mudah dibaca manusia dibanding policy SELinux.

Karakteristik penting AppArmor:

• Konfigurasi lebih sederhana, kurva belajar lebih landai.
• Tidak mendukung MLS/MCS, sehingga kurang cocok untuk lingkungan dengan kebutuhan klasifikasi data sangat ketat.
• Overhead performa umumnya lebih rendah dibanding SELinux karena jumlah hook LSM yang dilalui lebih sedikit.
• Karena berbasis path, ada celah teoretis: jika sebuah file di-hardlink atau diakses lewat path lain yang tidak tercakup profile, proteksi bisa terlewati — berbeda dengan SELinux yang labelnya melekat pada inode, bukan path.

Perbandingan Singkat

Aspek	SELinux	AppArmor
Model kontrol	Label-based (Type Enforcement)	Path-based
Distro default	RHEL, CentOS, Fedora, Rocky Linux	Ubuntu, Debian turunan
Kurva belajar	Curam	Landai
Granularitas	Sangat detail, system-wide	Fokus per-aplikasi
MLS/MCS	Didukung	Tidak didukung
Overhead	Relatif lebih tinggi	Relatif lebih rendah
Tools debug	audit2allow, sealert, ausearch	aa-genprof, aa-logprof

Tidak ada yang secara mutlak “lebih baik” — keduanya sama-sama mengimplementasikan MAC, hanya filosofi dan target penggunanya berbeda. Rekomendasi umum: gunakan LSM default distro Anda, karena itu yang paling teruji dan didukung penuh oleh komunitas serta vendor.

Kenapa Orang Sering setenforce 0?

Skenario ini sangat familiar bagi sysadmin: aplikasi tiba-tiba gagal menulis file, service tidak bisa bind ke port tertentu, atau container tidak bisa mount volume — padahal permission DAC (rwx) sudah benar. Setelah frustrasi mencari penyebab, seseorang menyarankan setenforce 0, masalah langsung hilang, dan solusi itu dianggap “berhasil”.

Penyebab umum orang menjalankan setenforce 0 secara permanen:

• Kurang paham cara membaca AVC denial di log audit, sehingga SELinux dianggap “biang masalah” alih-alih dianggap sedang bekerja sesuai fungsinya.
• Tekanan waktu — ingin aplikasi cepat jalan tanpa mau menganalisis akar masalah.
• Copy-paste dari forum yang menyarankan “matikan saja SELinux” sebagai solusi instan.
• Tidak tahu ada mode di antaranya, yaitu permissive mode, yang sebenarnya adalah alat diagnosis, bukan solusi permanen.

Kenapa Mematikan SELinux/AppArmor Itu Berbahaya

Ini bagian paling krusial yang wajib dipahami: permissive mode dan disabled adalah dua hal yang sangat berbeda.

• Enforcing — kebijakan MAC aktif penuh, pelanggaran diblokir dan dicatat.
• Permissive — pelanggaran hanya dicatat ke log, tidak diblokir. Berguna untuk debugging, tapi sistem sama sekali tidak terlindungi selama mode ini aktif.
• Disabled — modul keamanan mati total. Tidak ada labeling, tidak ada logging, dan pada SELinux bahkan bisa memicu proses relabeling penuh saat sistem kembali diaktifkan karena semua label dianggap basi.

Ketika Anda menjalankan setenforce 0 secara permanen atau mengubah /etc/selinux/config menjadi disabled, dampaknya:

1. Hilangnya defense-in-depth. Jika penyerang berhasil mengeksploitasi celah di aplikasi (misalnya RCE di web app), tanpa MAC mereka bebas bergerak lateral ke seluruh sistem selama masih dalam batas permission DAC user tersebut — yang seringkali sudah cukup untuk membaca file sensitif atau memasang backdoor.
2. Compliance gagal. Standar seperti PCI DSS, HIPAA, dan DISA-STIG sering mensyaratkan MAC aktif; server dengan SELinux disabled otomatis gagal audit.
3. Container escape lebih mudah. Di lingkungan Kubernetes/OpenShift, SELinux/AppArmor adalah salah satu lapisan yang membatasi proses di dalam container agar tidak leluasa menyentuh host.
4. Kehilangan jejak forensik. Tanpa AVC log, saat terjadi insiden, tim forensik kehilangan salah satu sumber log paling detail tentang perilaku proses yang mencurigakan.

Intinya: error SELinux/AppArmor bukan bug, melainkan bukti bahwa sistem sedang berfungsi sebagaimana mestinya. Tugas sysadmin adalah menerjemahkan penolakan itu menjadi policy yang tepat, bukan mematikan seluruh mekanismenya.

Studi Kasus Sederhana

Sebuah tim deploy aplikasi Node.js custom di server RHEL yang perlu menulis log ke /var/www/app/logs. Setelah deploy, aplikasi gagal menulis file dengan pesan Permission denied, padahal ls -l menunjukkan permission rwx sudah benar untuk user aplikasi.

Alih-alih menjalankan setenforce 0, tim melakukan langkah berikut:

1. Cek status: getenforce → hasilnya Enforcing.
2. Cari AVC denial terbaru: sudo ausearch -m avc -ts recent.
3. Ditemukan bahwa proses berjalan dengan domain httpd_t, tapi direktori log memiliki label default_t (bukan label yang biasa dipakai konten web).
4. Solusi yang benar bukan mengubah policy, melainkan memperbaiki label direktori: sudo semanage fcontext -a -t httpd_log_t "/var/www/app/logs(/.*)?" lalu sudo restorecon -Rv /var/www/app/logs.
5. Masalah selesai, aplikasi berjalan normal, dan SELinux tetap enforcing.

Kasus ini menunjukkan bahwa sebagian besar “masalah SELinux” sebenarnya adalah masalah labeling yang salah, bukan kebutuhan untuk menonaktifkan seluruh sistem.

Tutorial Step-by-Step: Debugging SELinux dengan audit2allow

Berikut alur kerja standar dan aman untuk mendiagnosis penolakan SELinux tanpa mengorbankan keamanan sistem.

Langkah 1 — Pastikan Anda Berada di Mode yang Tepat

Cek mode aktif saat ini:

getenforce

Jika hasilnya Enforcing dan aplikasi gagal, jangan langsung mematikan SELinux secara global. Sebagai gantinya, gunakan permissive domain yang hanya membuat satu domain tertentu jadi permissive tanpa membuka seluruh sistem:

sudo semanage permissive -a nama_domain_t

Cara ini jauh lebih aman dibanding setenforce 0 karena hanya proses spesifik itu yang sementara tidak diblokir, sementara domain lain tetap terlindungi penuh.

Langkah 2 — Kumpulkan AVC Denial

Jalankan ulang aksi yang gagal, lalu ambil log penolakan terbaru:

sudo ausearch -m avc -ts recent

Jika setroubleshoot-server terpasang, gunakan versi yang lebih mudah dibaca manusia:

sudo sealert -a /var/log/audit/audit.log

Langkah 3 — Generate Policy dengan audit2allow

Ubah log penolakan menjadi modul policy siap pakai:

sudo ausearch -m avc -ts recent | audit2allow -M nama_modul

Perintah ini menghasilkan dua file: nama_modul.te (source policy dalam format teks) dan nama_modul.pp (modul terkompilasi).

Langkah 4 — Review Manual Sebelum Install

Ini langkah yang paling sering dilewati padahal paling penting:

cat nama_modul.te

audit2allow hanya membaca apa yang diminta oleh proses saat penolakan terjadi — bukan apa yang seharusnya boleh dilakukan. Jika prosesnya sendiri sedang dieksploitasi atau salah konfigurasi, audit2allow bisa saja menyarankan izin yang sangat berbahaya, misalnya akses tulis ke kmem_device atau kemampuan memanggil setenforce dari dalam proses non-root. Jangan pernah mengeksekusi output audit2allow secara membabi buta.

Langkah 5 — Install Modul Setelah Diverifikasi

Jika setelah ditinjau aturan tersebut memang wajar dan diperlukan:

sudo semodule -i nama_modul.pp

Langkah 6 — Kembali ke Enforcing dan Verifikasi

Jika sebelumnya memakai permissive domain, kembalikan ke mode enforcing:

sudo semanage permissive -d nama_domain_t

Uji ulang aplikasi, dan pastikan tidak ada AVC denial baru:

sudo ausearch -m avc -ts recent

Kesalahan yang Sering Terjadi

1. Menjalankan setenforce 0 permanen sebagai “solusi cepat”

• Penyebab: frustrasi debugging, tekanan waktu deploy.
• Dampak: sistem kehilangan seluruh lapisan MAC, rentan lateral movement.
• Solusi: gunakan permissive domain per-service, bukan global.

2. Copy-paste output audit2allow tanpa direview

• Penyebab: dianggap tools ini “pasti benar” karena buatan sistem sendiri.
• Dampak: policy terlalu longgar, bisa membuka celah privilege escalation.
• Solusi: selalu baca file .te sebelum compile dan install.

3. Tidak memperbaiki label file setelah memindahkan data

• Penyebab: perintah mv mempertahankan label sumber, bukan label direktori tujuan.
• Dampak: file “terlihat” benar permission DAC-nya, tapi tetap ditolak SELinux.
• Solusi: gunakan restorecon -Rv setelah memindahkan file penting, atau gunakan cp alih-alih mv bila label perlu mengikuti direktori tujuan.

4. Menyamakan AppArmor dengan firewall aplikasi

• Penyebab: miskonsepsi bahwa profile AppArmor otomatis memblokir traffic jaringan berbahaya.
• Dampak: asumsi keamanan yang keliru, celah tetap terbuka di layer lain.
• Solusi: pahami bahwa AppArmor membatasi akses file/kapabilitas sistem, bukan pengganti firewall atau WAF.

5. Lupa mode tidak persist setelah reboot

• Penyebab: setenforce 0 hanya efektif untuk sesi berjalan.
• Dampak: tim mengira sistem sudah aman kembali (enforcing) padahal file /etc/selinux/config masih menyimpan permissive, atau sebaliknya.
• Solusi: selalu selaraskan perubahan runtime dengan file konfigurasi permanen jika memang perubahan itu disengaja.

Tips dan Rekomendasi

• Gunakan LSM default distro Anda kecuali ada alasan kuat untuk beralih.
• Jadikan permissive mode sebagai alat diagnosis sementara, bukan status akhir produksi.
• Biasakan tim untuk membaca AVC log sebelum mengambil kesimpulan “SELinux yang salah”.
• Dokumentasikan setiap modul policy custom yang dibuat lewat audit2allow, agar audit keamanan di masa depan lebih mudah ditelusuri.
• Untuk lingkungan container, kombinasikan SELinux/AppArmor dengan seccomp profile untuk pertahanan berlapis yang lebih kuat.
• Lakukan review policy secara berkala, terutama setelah upgrade aplikasi besar yang mengubah pola akses file.

Kesimpulan

SELinux dan AppArmor sama-sama mengimplementasikan Mandatory Access Control, lapisan pertahanan yang bekerja independen dari permission rwx biasa. SELinux unggul dalam granularitas dan cocok untuk lingkungan yang butuh kepatuhan ketat, sementara AppArmor menawarkan kesederhanaan dan kurva belajar yang lebih ramah pemula.

Kebiasaan mematikan MAC lewat setenforce 0 secara permanen adalah jalan pintas yang mengorbankan salah satu lapisan pertahanan paling penting di server Linux. Solusi yang tepat adalah memahami AVC denial, memanfaatkan audit2allow sebagai alat bantu — bukan sumber kebenaran mutlak — dan selalu meninjau setiap policy sebelum diaktifkan secara permanen.

Poin penting yang perlu diingat: penolakan MAC adalah sinyal, bukan gangguan. Menjadikannya sebagai peta untuk menulis policy yang presisi jauh lebih baik daripada mematikannya demi kenyamanan sesaat.

Frequently Asked Questions (FAQ)

Pertanyaan: Apa perbedaan utama antara SELinux dan AppArmor? Jawaban: SELinux menggunakan pendekatan berbasis label pada setiap file dan proses (Type Enforcement), sedangkan AppArmor menggunakan pendekatan berbasis path lewat profile per aplikasi. SELinux lebih granular tapi lebih kompleks, AppArmor lebih sederhana tapi kurang mendalam.

Pertanyaan: Apakah aman menjalankan setenforce 0 untuk sementara saat debugging? Jawaban: Untuk debugging singkat di lingkungan non-produksi, permissive mode bisa dipakai. Namun untuk server produksi, lebih aman menggunakan permissive domain per-service lewat semanage permissive, bukan mematikan SELinux secara global.

Pertanyaan: Apakah audit2allow selalu menghasilkan policy yang aman? Jawaban: Tidak. audit2allow hanya menerjemahkan log penolakan menjadi aturan izin, tanpa menilai apakah izin tersebut memang seharusnya diberikan. Selalu review file .te sebelum menginstal modul yang dihasilkan.

Pertanyaan: Distro apa yang menggunakan SELinux dan AppArmor secara default? Jawaban: SELinux menjadi default di RHEL, CentOS, Fedora, dan Rocky Linux. AppArmor menjadi default di Ubuntu dan sejumlah distro turunan Debian.

Pertanyaan: Apakah boleh menggunakan SELinux dan AppArmor secara bersamaan? Jawaban: Tidak disarankan menjalankan dua LSM berbeda secara bersamaan pada satu sistem karena berpotensi menimbulkan konflik. Gunakan salah satu sesuai default distro Anda.

---

Sudah pernah mengalami drama Permission denied gara-gara SELinux atau AppArmor? Ceritakan pengalaman Anda di kolom komentar —

apakah akhirnya menyelesaikannya dengan cara yang benar, atau pernah “terpaksa” menjalankan setenforce 0? Jangan lupa bagikan artikel ini ke rekan tim sysadmin dan DevOps Anda, dan jelajahi artikel terkait lainnya seputar hardening server Linux di blog ini agar infrastruktur Anda semakin tangguh.