Belajar AppArmor - Konsep Dasar & Arsitektur Utama

#Pendahuluan

Di episode 1 kita menelusuri sejarah AppArmor: mengapa dunia butuh MAC, kelahirannya di Immunix, dan adopsi besar-besaran oleh Ubuntu, Debian, Docker, hingga ChromeOS. Kini saatnya memahami bagaimana AppArmor sebenarnya bekerja di dalam. Episode ini adalah fondasi teknis: semua episode setelah ini akan berdiri di atas konsep yang kita bangun di sini.

Tiga hal yang akan kita kuasai: konsep profil sebagai unit kebijakan AppArmor, mode kerja yang menentukan apakah aturan dijalankan atau hanya dicatat, dan arsitektur yang menghubungkan kernel dengan tools userspace. Setelah episode ini, kalian akan bisa menjelaskan kepada orang lain apa itu AppArmor tanpa membuka dokumentasi.

#Konsep Profil: Kebijakan per Aplikasi

Unit dasar AppArmor adalah profil — seperangkat aturan yang melekat pada satu aplikasi (executable) dan menentukan apa yang boleh dilakukan proses turunannya. Nama profil biasanya mengikuti path executable, misalnya /usr/sbin/nginx. Analoginya: profil adalah kontrak kerja seorang karyawan — sebelum masuk gedung, karyawan itu disodori kontrak yang menyebutkan ruangan mana yang boleh ia masuki, dokumen apa yang boleh ia baca, dan peralatan apa yang boleh ia pakai.

Profil AppArmor mengatur beberapa dimensi akses:

Prinsip paling penting yang wajib kalian internalisasi: proses tanpa profil adalah proses yang kebal. Kalau sebuah aplikasi tidak punya profil sama sekali, AppArmor tidak membatasi apa pun — ia berjalan persis seperti tanpa MAC. Nilai keamanan muncul justru ketika kita memberi profil. Ini berbeda dengan beberapa MAC lain yang mencoba melabeli semua objek.

#Aturan File: r, w, m, k

Di dimensi file, AppArmor mengenal empat akses dasar yang akan kalian temui terus-menerus:

m sering menjadi sumber denial yang membingungkan pemula: sebuah program boleh mengeksekusi biner, tapi gagal menjalankan library karena library itu tidak diizinkan di-mmap. Kita akan membedah ini lebih dalam di episode 4 saat menulis profil.

#Mode Enforce vs Complain

Setiap profil dijalankan dalam salah satu dari dua mode:

• Enforce mode — aturan dijalankan sungguhan. Akses yang tidak diizinkan ditolak dan dicatat di log. Ini mode default untuk profil yang sudah kalian percaya.
• Complain mode — aturan dibaca, tapi tidak dijalankan. Akses yang tidak diizinkan tetap diperbolehkan, namun dicatat sebagai pelanggaran di log. Cocok untuk learning mode saat menyusun profil baru.

Analogi yang pas: enforce adalah teman yang menahanmu saat kalian mau masuk ruangan terlarang, sedangkan complain adalah teman yang hanya mencatat setiap pintu yang kalian coba buka tanpa menahan — lalu memberimu laporan di akhir hari. Log itulah bahan untuk menyempurnakan profil.

Mode complain adalah salah satu keunggulan terbesar AppArmor untuk produksi: kalian bisa meluncurkan aplikasi dengan profil baru dalam mode complain, mengumpulkan perilaku aslinya selama beberapa hari, lalu menaikkannya ke enforce dengan percaya diri.

#AppArmor vs SELinux: Path-based vs Type-based

Ini pertanyaan yang paling sering muncul di komunitas: kenapa AppArmor bukan SELinux? Jawabannya ada pada basis keputusan:

• AppArmor berbasis path. Aturan ditulis dalam bentuk path file, misalnya owner /etc/nginx/nginx.conf r. Saat sebuah proses mengakses file, kernel membandingkan path file itu dengan aturan profil. Mudah dipahami dan ditulis karena langsung mencerminkan struktur filesystem.
• SELinux berbasis label/type. Setiap objek (file, proses, port, socket) diberi security context berlabel, dan aturan ditulis dalam bentuk pasangan label proses-label objek. Lebih ekspresif untuk objek non-file, tapi lebih kompleks: kalian harus memastikan label file benar selain menulis aturannya.

Perbandingan ini bukan soal mana yang "lebih baik" — keduanya sama-sama MAC yang sudah terbukti. Pertanyaannya adalah konteks: di ekosistem yang berbasis path (Debian/Ubuntu), AppArmor adalah pilihan natural. Dan ingat, keduanya bisa hidup berdampingan di satu sistem melalui LSM stacking modern.

#Arsitektur: Kernel LSM + Userspace

AppArmor terdiri dari dua dunia yang bekerja bersama:

#Kernel: AppArmor LSM

Di sisi kernel, AppArmor diimplementasikan sebagai Linux Security Module (LSM). LSM adalah kerangka hook keamanan di kernel yang dipanggil setiap kali ada operasi sensitif: membuka file, membuat socket, memanggil mount, dan seterusnya. Hook AppArmor memeriksa profil proses yang aktif — jika ada, keputusan diambil berdasarkan aturan; jika tidak ada, operasi dibiarkan lolos.

Kernel mengekspos dua area penting:

• /sys/kernel/security/apparmor — securityfs tempat kernel mempublikasikan status dan profil yang dimuat, dan tempat userspace menulis policy.
• Penyimpanan compiled profile di cache — profil yang sudah dikompilasi disimpan agar proses load berikutnya lebih cepat.

#Userspace: apparmor_parser, aa-status, libapparmor

Di sisi userspace, tiga komponen utama:

Sumber kebenaran berada di /etc/apparmor.d/ — direktori tempat semua file profil teks disimpan. Saat sistem boot (atau saat kalian menjalankan apparmor_parser), profil di direktori ini dikompilasi dan dimuat ke kernel. Alur lengkapnya:

/etc/apparmor.d/nginx
      │  ditulis sebagai teks
      ▼
apparmor_parser (kompilasi + load)
      │
      ▼
Kernel LSM (memuat aturan ke memori)
      │
      ▼
Hook LSM menilai akses proses terhadap path

Alur inilah yang akan kalian pegang di episode 3 dan 4: menulis profil di /etc/apparmor.d/, memuatnya dengan apparmor_parser, lalu memverifikasi dengan aa-status.

#Kesalahan Umum (Common Pitfalls)

1. Mengira proses tanpa profil sudah aman. Salah besar — proses tanpa profil tidak dibatasi apa pun. Nilai AppArmor ada di profil yang diberikan.
2. Mengira m sama dengan r. m mengizinkan memory-mapping file — kritis untuk library. Tanpa m, program bisa gagal dijalankan meski r sudah diizinkan.
3. Langsung enforce tanpa complain. Menulis profil baru lalu langsung enforce tanpa menonton perilaku aslinya adalah resep aplikasi yang error misterius. Gunakan complain dulu.
4. Menganggap AppArmor dan SELinux identik. Keduanya MAC, tapi basisnya berbeda: path vs label. Memahami perbedaannya menyelamatkan kalian dari kebingungan saat pindah distro.

#Penutup

Pada episode 2 ini kita telah membangun fondasi teknis AppArmor: konsep profil sebagai unit kebijakan per aplikasi, aturan file r w m k serta dimensi lain seperti network, capabilities, mount, ptrace, dan signals; dua mode kerja enforce dan complain; perbandingan path-based vs type-based dengan SELinux; hingga arsitektur kernel LSM dan komponen userspace apparmor_parser, aa-status, dan libapparmor.

Inti yang harus kalian bawa:

• Profil = kontrak kerja aplikasi — menentukan file, network, capabilities, dan sinyal yang boleh diakses.
• Tanpa profil = tidak dibatasi. Nilai keamanan lahir dari pemberian profil.
• Enforce menolak, complain hanya mencatat — mode complain adalah gerbang menuju profil yang matang.
• AppArmor path-based, SELinux type-based — basis keputusan yang membedakan keduanya.
• Profil bersumber di /etc/apparmor.d/, diproses apparmor_parser, diverifikasi dengan aa-status.

Di episode 3 selanjutnya, kita akan masuk ke praktik pertama: status, mode, dan load/unload profil — membaca status lengkap dengan aa-status, memeriksa apakah AppArmor aktif dengan aa-enabled, mengubah mode enforce/complain, serta memuat dan melepas profil dengan apparmor_parser. Pastikan tetap semangat, karena mulai episode inilah kalian menyentuh AppArmor secara langsung!