SELinux dan AppArmor sama-sama sistem kontrol akses wajib pada Linux. Keduanya bekerja di lapisan yang berbeda dari izin pengguna biasa: alih-alih bertanya “siapa yang menjalankan proses ini”, keduanya bertanya “apakah proses ini, apa pun identitasnya, boleh menyentuh sumber daya itu”. Jawabannya ditentukan oleh kebijakan yang dibuat lebih dulu, bukan oleh keputusan pengguna saat itu juga. Karena itu keduanya disebut kontrol akses wajib — mandatory access control — dan sifatnya mengekang, bukan memberi izin tambahan.
Perbedaan paling kasat mata terletak pada distribusi yang memakainya secara bawaan. SELinux umum pada turunan Red Hat, sedangkan AppArmor umum pada Debian dan Ubuntu. Artinya, pengguna Fedora, RHEL, atau Rocky Linux lebih sering berhadapan dengan SELinux, sementara pengguna Ubuntu dan Debian lebih sering menemukan AppArmor aktif sejak instalasi. Keduanya jarang muncul di permukaan sampai ada proses yang tiba-tiba ditolak.
Justru penolakan itulah yang membuat banyak orang mematikannya. Mematikan keduanya mempermudah konfigurasi tetapi menghapus satu lapis pertahanan. Artikel ini membahas cara kerja masing-masing, alasan orang melumpuhkannya, dan kapan lapisan ini sebaiknya dibiarkan hidup. Semua latihan yang disebut di sini ditujukan untuk sistem milik sendiri atau sistem yang memang diizinkan untuk diuji.
Apa yang Dimaksud Kontrol Akses Wajib
Linux secara bawaan memakai model izin berbasis pemilik. File punya pemilik, grup, dan bit izin baca-tulis-eksekusi. Pemilik file boleh mengubah izinnya, dan proses yang berjalan sebagai pemilik itu mendapat keleluasaan penuh. Model ini praktis, tetapi punya kelemahan mendasar: begitu sebuah proses diambil alih penyerang, proses itu mewarisi seluruh keleluasaan pemiliknya.
Kontrol akses wajib menutup celah itu dengan menambahkan aturan yang tidak bisa dilangkahi pengguna biasa. Sebuah layanan web yang berjalan sebagai pengguna dengan hak luas tetap tidak bisa membaca berkas di luar daftar yang diizinkan kebijakan, meski secara izin file ia mampu. Inilah nilai utamanya: ketika ada kesalahan konfigurasi atau eksploitasi pada satu layanan, dampaknya terkurung pada sumber daya yang sudah ditentukan.
Baik SELinux maupun AppArmor menerapkan gagasan yang sama. Yang berbeda adalah cara mereka menyatakan aturan dan seberapa besar usaha yang dibutuhkan untuk menyesuaikannya.
SELinux: Kebijakan Berbasis Label
SELinux menempelkan label pada setiap proses dan setiap objek — file, direktori, soket, port. Aturan disusun dari label-label ini, bukan dari lokasi berkas semata. Sebuah berkas yang dipindahkan ke direktori baru bisa saja kehilangan kecocokan label, dan layanan yang membacanya langsung ditolak. Perilaku ini sering membingungkan pengguna baru karena izin file terlihat benar, tetapi proses tetap gagal.
Untuk memeriksa keadaan SELinux, dua perintah yang lazim dipakai adalah getenforce untuk melihat mode aktif dan sestatus untuk ringkasan lengkap. SELinux punya mode enforcing, permissive, dan disabled. Mode permissive mencatat pelanggaran tanpa memblokirnya — berguna ketika menelusuri masalah karena layanan tetap berjalan sementara jejaknya tersimpan di log. Mode disabled benar-benar mematikannya.
Karena kebijakan SELinux sudah disusun untuk banyak layanan populer, sebagian besar penolakan bisa diselesaikan dengan menyesuaikan label atau mengaktifkan boolean kebijakan yang relevan, bukan dengan mematikan seluruh sistem. Pendekatan ini memang menuntut waktu belajar lebih panjang dibanding AppArmor, dan itu salah satu alasan SELinux punya reputasi menakutkan di kalangan pemula.
AppArmor: Profil Berbasis Path
AppArmor mengambil jalan yang lebih langsung: aturannya menunjuk ke jalur berkas, bukan ke label. Sebuah profil biasanya menempel pada satu program dan menyebutkan berkas, direktori, dan kemampuan apa yang boleh diakses program tersebut. Karena berbasis jalur, aturannya lebih mudah dibaca dan lebih mudah diprediksi oleh orang yang baru mengenalnya.
Perintah aa-status menampilkan profil yang sedang dimuat beserta modenya. AppArmor mengenal mode enforce dan complain. Mode complain berperan seperti permissive pada SELinux — pelanggaran dicatat, tetapi tidak diblokir, sehingga cocok untuk menyusun profil baru sebelum diberlakukan penuh. Sebagian distribusi juga menyediakan cara untuk mengubah mode profil tertentu tanpa menyentuh profil lain.
Konsekuensi dari pendekatan berbasis jalur adalah aturan jadi lebih rapuh terhadap perubahan lokasi berkas. Memindahkan biner atau direktori data bisa membuat profil tidak lagi cocok. Namun untuk banyak kasus sehari-hari, kemudahan membaca dan menyesuaikan profil membuat AppArmor lebih ramah bagi pengguna yang baru mulai menggeluti kontrol akses wajib.
Kenapa Banyak Orang Mematikannya
Alasan paling umum adalah waktu. Ketika sebuah layanan gagal dan pesan galatnya hanya menyebut penolakan akses tanpa penjelasan jelas, mematikan kontrol akses langsung menyelesaikan masalah dalam hitungan detik. Perbaikan yang benar — menyesuaikan label, mengaktifkan boolean, atau menulis pengecualian profil — bisa memakan waktu jauh lebih lama, terutama bagi yang belum terbiasa membaca log audit.
Alasan kedua adalah warisan tutorial. Banyak panduan lama, termasuk panduan pemasangan aplikasi, memuat langkah mematikan SELinux atau AppArmor sebagai prasyarat. Langkah itu memang membuat panduan berjalan mulus, tetapi jarang menjelaskan konsekuensinya. Pengguna yang mengikuti panduan tersebut tanpa berpikir panjang akan membawa kebiasaan itu ke sistem produksi.
Alasan ketiga adalah lingkungan terisolasi. Di dalam kontainer, mesin virtual, atau sistem uji, kontrol akses wajib sering dianggap penghalang yang tidak perlu karena isolasi sudah ditangani lapisan lain. Untuk keperluan belajar, pertimbangan ini masuk akal. Masalahnya, kebiasaan yang dibentuk di lingkungan uji kerap terbawa ke server yang menghadap internet.
Yang perlu disadari: mematikan keduanya mempermudah konfigurasi tetapi menghapus satu lapis pertahanan. Ketika lapisan itu hilang, satu layanan yang berhasil dieksploitasi bisa bergerak lebih bebas di dalam sistem — membaca berkas yang seharusnya tidak terjangkau, menulis ke lokasi yang seharusnya terlindungi, atau menghubungi port yang seharusnya tertutup bagi proses tersebut.
Kapan Lapisan Ini Layak Dipertahankan
Kontrol akses wajib paling layak dipakai pada sistem yang melayani banyak pihak atau menghadap jaringan luar. Server web, basis data, layanan berkas, dan aplikasi dengan banyak pengguna adalah kandidat utama. Di sana, pembatasan ruang gerak proses memberi manfaat nyata karena satu kesalahan tidak langsung berubah menjadi kompromi menyeluruh.
Pada mesin kerja pribadi, manfaatnya lebih kecil tetapi tetap ada, terutama bila mesin itu dipakai untuk menyimpan kredensial atau kunci akses. Menyalakannya dalam mode enforcing sejak awal membuat Anda terbiasa berhadapan dengan penolakan dan menelusuri penyebabnya, bukan menghindarinya.
Pendekatan yang lebih aman daripada mematikan adalah menurunkannya ke mode permissive atau complain sementara waktu. Dengan begitu layanan tetap berjalan, Anda bisa membaca log, lalu menyusun pengecualian yang tepat sebelum mengembalikannya ke mode enforcing. Cara ini menuntut kesabaran, tetapi mempertahankan lapisan pertahanan yang sudah tersedia gratis di sistem.
Untuk latihan, gunakan mesin virtual atau sistem milik sendiri. Menguji kebijakan pada sistem orang lain tanpa izin melanggar hukum dan etika, dan tidak ada hubungannya dengan pembelajaran yang sah.
Menyiapkan Kebiasaan Belajar yang Etis
Mulailah dengan mengenali sistem yang Anda pakai. Cek apakah SELinux atau AppArmor yang aktif, dalam mode apa, dan profil atau kebijakan apa yang sedang dimuat. Dari situ, buat satu layanan sederhana di mesin virtual, sengaja picu penolakan, lalu baca log auditnya sampai Anda paham sumber masalahnya. Latihan kecil seperti ini jauh lebih berharga daripada menghafal perintah.
Bila ingin memperdalam sisi keamanan Linux secara lebih luas, sumber berbahasa Indonesia seperti kalilinux.net dan kalilinux.info bisa dijadikan referensi lanjutan, terutama untuk memahami konteks pengujian yang legal dan terbatas pada lingkungan laboratorium sendiri.
SELinux dan AppArmor bukan penghalang yang harus dimusuhi, melainkan alat yang bekerja diam-diam sampai ada proses yang mencoba keluar batas. Keduanya memang menuntut waktu belajar, dan itu wajar untuk lapisan keamanan yang menyentuh hampir seluruh sistem. Kebiasaan yang sehat adalah menyesuaikan kebijakan alih-alih mematikannya, memakai mode permissive atau complain sebagai jembatan saat menelusuri masalah, dan menyimpan keputusan mematikan sebagai pilihan terakhir yang disadari konsekuensinya. Dengan begitu, konfigurasi tetap bisa diselesaikan tanpa mengorbankan satu lapis pertahanan yang sudah tersedia.