Belajar AppArmor - Sejarah, Latar Belakang & Mengapa Membutuhkan AppArmor

#Pendahuluan

Di episode 0 sebelumnya kita menyiapkan environment: menginstall tools userspace AppArmor dan memverifikasi bahwa sistem berjalan dengan AppArmor aktif. Pada episode kali ini kita akan menarik napas sejenak dari hands-on dan menjawab pertanyaan paling mendasar: mengapa AppArmor 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 AppArmor, memahami keterbatasan sistem permission klasik Linux (DAC), dan melihat bagaimana MAC berbasis path 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 AppArmor 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.

Di dunia MAC, setiap proses yang dijalankan di bawah perlindungan diberi seperangkat aturan yang menentukan objek apa saja yang boleh ia sentuh. Kebijakan menentukan pasangan proses-aturan mana yang berlaku. Root pun hanyalah salah satu proses — 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 dan kredensial database. Di dunia MAC, proses tersebut dijalankan dengan profil AppArmor — penyerang tetap terjebak di dalam batas profil tersebut, dan tidak bisa menyentuh file di luar daftar path yang diizinkan, apa pun permission file-nya. Itulah kekuatan yang dibawa AppArmor ke Linux: membatasi kerusakan, bukan hanya mencegah serangan.

#Apa yang AppArmor Bukan

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

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

#Sejarah AppArmor: Immunix ke Kernel Linux

AppArmor memiliki perjalanan yang unik — ia lahir bukan dari lembaga negara seperti sepupu MAC-nya yang lain, melainkan dari perusahaan kecil yang ambisius.

#Kelahiran di Immunix

AppArmor dimulai sebagai bagian dari Immunix, sebuah distribusi Linux yang dibuat oleh WireX Communications pada akhir 1990-an, dipimpin oleh Crispin Cowan. Fokusnya saat itu adalah keamanan: mengemas kernel dan tools yang lebih aman, salah satunya melalui mekanisme konfinasi proses berbasis path yang kelak menjadi AppArmor.

#Adopsi Novell dan SUSE

Pada 2005, perusahaan Novell mengakuisisi aset Immunix dan mengadopsi AppArmor ke dalam SUSE Linux. Dari titik inilah AppArmor dibesarkan di ekosistem SUSE — dipakai sebagai mekanisme MAC default di SUSE Linux Enterprise dan openSUSE. Warisan ini pula yang membuat SUSE tetap menjadi rumah spiritual AppArmor hingga hari ini.

#Masuk ke Kernel 2.6.36

Selama bertahun-tahun AppArmor hidup di luar kernel arus utama, sebagai patch terpisah. Pada Oktober 2010, AppArmor akhirnya diintegrasikan ke kernel Linux 2.6.36 — tersedia untuk semua distro. Sejak saat itulah AppArmor menjadi bagian resmi kernel dan bisa dipakai siapa saja.

#Default di Ubuntu dan Debian

Setelah masuk kernel, adopsi berjalan cepat. Ubuntu menjadikan AppArmor sebagai MAC default-nya, lalu Debian menyusul — menggunakan AppArmor untuk mengkonfinasi layanan sistem seperti dhcpcd, tcpdump, hingga mekanisme sandbox paket. Dua distribusi paling banyak dipakai di dunia server inilah yang membuat AppArmor menjadi MAC paling tersebar di ekosistem Linux.

#Adopsi oleh Docker, containerd, dan ChromeOS

Dua adopsi besar mengunci posisi AppArmor di era modern:

• Docker dan containerd memakai AppArmor sebagai profil default untuk kontainer — setiap kontainer otomatis dikonfinasi profil docker-default tanpa konfigurasi tambahan. Ini menjadi gerbang AppArmor masuk ke dunia container dan Kubernetes.
• ChromeOS mengadopsi AppArmor sebagai bagian dari Kernel Self Protection Project (KSPP) — inisiatif kernel untuk memperkuat pertahanan terhadap eksploitasi. Ribuan perangkat Chromebook menjalankan konfinasi AppArmor setiap hari.

Perjalanan panjang itu bisa diringkas dalam satu garis waktu:

1999  Lahir di proyek Immunix (WireX Communications)
2005  Diakuisisi Novell, dibesarkan di ekosistem SUSE
2010  Masuk kernel Linux 2.6.36 (Oktober)
      Menjadi MAC default di Ubuntu dan Debian
      Diadopsi Docker dan containerd untuk kontainer
      Diadopsi ChromeOS via Kernel Self Protection Project
2026  Userspace 5.0.1 (Juni), transisi policy 4.x ke 5.x

#Ekosistem Modern: Userspace 5.0.1 & Transisi Policy

AppArmor bukan sekadar kernel — ia adalah ekosistem lengkap yang terus berevolusi. Pada Juni 2026, userspace AppArmor mencapai versi 5.0.1, dan sedang berlangsung transisi besar: dari policy 4.x ke 5.x. Perubahan ini menyentuh sintaks dan model policy, namun prinsip dasarnya tetap sama. Tools modern yang kalian pakai sepanjang series ini antara lain:

• apparmor_parser — tools inti untuk memuat dan melepas profil ke kernel.
• aa-status — membaca status dan daftar profil aktif.
• aa-genprof dan aa-logprof — pembuat dan pembarui profil berbasis denial log.

Ekosistem inilah yang membuat AppArmor modern jauh lebih ramah daripada citra lamanya sebagai "MAC yang sulit". Dengan userspace yang matang dan default di distro besar, belajar AppArmor hari ini terasa seperti belajar fitur bawaan Linux — bukan teknologi eksotik.

#Kesalahan Umum (Common Pitfalls)

1. Mengira AppArmor hanya mengganggu dan harus dimatikan. Ini mentalitas paling merugikan. AppArmor adalah lapisan pertahanan yang sudah terbukti memblokir eksploitasi nyata — justru deny yang mengganggu adalah cara sistem melindungi kalian.
2. Mengira AppArmor menggantikan chmod/firewall. Ketiganya bekerja di lapisan berbeda. Kalian tetap butuh DAC, tetap butuh firewall — AppArmor melengkapi, bukan menggantikan.
3. Menganggap AppArmor dan SELinux sama. Keduanya sama-sama MAC, tapi pendekatannya berbeda: AppArmor berbasis path, SELinux berbasis label/type. Perbedaan ini akan kita bedah di episode 2.
4. Tidak membaca denial, hanya mengabaikannya. Setiap denial AppArmor di log berisi informasi lengkap — proses, path, dan operasi yang ditolak. Kalian tidak akan pernah bisa memecahkan masalah keamanan jika tidak mau membaca datanya.

#Penutup

Pada episode 1 ini kita telah menelusuri mengapa AppArmor lahir: keterbatasan DAC yang hanya membatasi berdasarkan user dan group, konsep MAC yang membatasi semua orang — termasuk root — berdasarkan kebijakan terpusat, sejarah kelahiran di Immunix, adopsi oleh Novell dan SUSE, integrasi ke kernel 2.6.36 pada 2010, adopsi default oleh Ubuntu dan Debian, hingga masuknya Docker, containerd, dan ChromeOS.

Inti yang harus kalian bawa:

• DAC hanya membatasi berdasarkan user dan group — dan tidak membatasi root.
• MAC menentukan akses berdasarkan kebijakan terpusat — pemilik objek tidak berkuasa penuh.
• AppArmor lahir dari proyek Immunix, dibesarkan Novell/SUSE, dan masuk kernel Linux 2.6.36 pada 2010.
• AppArmor default di Ubuntu, Debian, dan openSUSE; dipakai Docker, containerd, dan ChromeOS.
• Userspace modern 5.0.1 (Juni 2026) dengan transisi policy 4.x ke 5.x.

Pemahaman "mengapa" ini menjadi fondasi untuk memahami "bagaimana" AppArmor bekerja. Di episode 2 selanjutnya, kita akan membahas konsep dasar & arsitektur utama — membedah profil per aplikasi, aturan file r w m k, mode enforce vs complain, perbandingan AppArmor dengan SELinux, hingga komponen kernel LSM dan userspace yang menyusun keseluruhan sistem. Pastikan tetap semangat, karena dari sinilah kalian mulai benar-benar memahami cara kerja AppArmor dari dalam!