Belajar AppArmor - LSM Stack & Kernel Interaction

#Pendahuluan

Di episode 15 kalian membangun pengawasan terhadap konfinasi — log denial, alerting, dan baseline. Sekarang saatnya zoom out: dari konfigurasi dan tooling, kita naik ke tempat semua keputusan itu benar-benar dieksekusi — kernel Linux. Pertanyaan kuncinya: apa sebenarnya yang terjadi di dalam kernel saat sebuah proses mencoba membuka file yang dilindungi profile?

Episode ini membedah posisi AppArmor sebagai Linux Security Module, bagaimana ia berbagi peran dengan modul lain seperti Yama dan Landlock dalam satu LSM stack, konfigurasi kernel yang menghidupkannya, serta pembagian lapisan antara seccomp, capabilities, dan LSM.

#Kernel dan Framework LSM

Linux Security Module (LSM) adalah kerangka kerja di dalam kernel yang menyediakan titik-titik kait — hooks — pada operasi-operasi sensitif: membuka file, membuat socket, mengeksekusi binary, mengirim sinyal, dan banyak lagi. Setiap modul keamanan yang ingin memediasi operasi tersebut mendaftarkan diri pada hooks ini.

Sebelum kernel 4.4, hanya satu LSM "mayor" yang bisa aktif — memilih salah satu antara AppArmor, SELinux, atau Smack. Sejak kernel 4.4, kerangka kerja LSM mendukung stacking: beberapa LSM bisa aktif bersamaan, masing-masing memediasi operasi di hooks yang sama, secara berurutan. Di sinilah AppArmor hidup berdampingan dengan modul lain.

Bayangkan seperti pos pemeriksaan di bandara: beberapa gerbang berjajar, dan setiap penumpang melewati semuanya secara berurutan. Seorang penumpang yang lolos gerbang pertama belum berarti lolos dari yang lain — setiap modul memeriksa dimensi yang berbeda.

#Stacking: AppArmor Bersama Modul Lain

Pada sistem modern, urutan LSM yang aktif terlihat dari boot parameter lsm=. Untuk distribusi seperti Ubuntu, urutan defaultnya kira-kira seperti ini: landlock, lockdown, yama, loadpin, safesetid, integrity, apparmor, selinux, smack, tomoyo. Di dalam daftar ini, AppArmor adalah LSM mayor — modul yang memediasi akses secara menyeluruh. Modul-modul lain di sekitarnya adalah LSM minor dengan fokus sempit.

Tiga yang paling sering berinteraksi dengan pekerjaan kalian sehari-hari:

• Yama — membatasi ptrace antar proses lewat sysctl kernel.yama.ptrace_scope. Ia bekerja di dimensi yang sama dengan aturan ptrace AppArmor: keduanya bisa membatasi debugging dan injeksi proses. Jika Yama dan AppArmor aktif, proses harus lolos keduanya.
• Landlock — menyediakan sandbox untuk proses tanpa privilege: seorang user biasa bisa membatasi prosesnya sendiri memakai aturan berbasis path tanpa bantuan admin. Ini komplementer dengan AppArmor — AppArmor mengamankan dari sisi sistem, Landlock dari sisi aplikasi yang memilih mengamankan dirinya.
• LoadPin — membatasi module dan firmware yang bisa dimuat hanya dari filesystem tepercaya, menutup jalur pemuatan kode kernel dari lokasi yang tidak sah.

Poin penting untuk kalian: ketika deny AppArmor tidak muncul, jangan langsung menyalahkan profile. Modul lain di stack — atau kombinasi beberapa modul — bisa jadi penentu. Diagnosa dengan melihat deny di semua lapisan, bukan hanya satu.

#Mendiagnosa Deny Lintas Lapisan

Perbedaan dimensi antar modul terlihat nyata saat debugging. Katakanlah sebuah proses tiba-tiba tidak bisa melakukan ptrace ke proses lain, padahal profile AppArmor-nya sudah mengizinkan ptrace (trace). Penyebab yang mungkin: aturan ptrace AppArmor yang keliru, atau Yama yang menolak karena kernel.yama.ptrace_scope disetel ketat. Dua mekanisme, satu gejala — dan solusinya berbeda:

sysctl kernel.yama.ptrace_scope
sudo grep -n ptrace /etc/apparmor.d/usr.sbin.myapp

sysctl kernel.yama.ptrace_scope menampilkan kebijakan Yama: nilai 0 bebas, 1 hanya child langsung, 2 dan 3 semakin ketat. Sementara grep -n ptrace menunjukkan aturan ptrace yang benar-benar tertulis di profile. Jika Yama yang menolak, solusinya di sysctl; jika AppArmor, solusinya di profile. Melihat dua sumber sebelum mengubah apa pun adalah kebiasaan yang menyelamatkan kalian dari mengubah konfigurasi yang salah.

#Konfigurasi Kernel

Agar AppArmor berfungsi, kernel harus dibangun dengan dukungan LSM dan AppArmor diaktifkan:

Opsi kernel yang relevan di config

CONFIG_SECURITY=y
CONFIG_SECURITY_APPARMOR=y
CONFIG_SECURITY_YAMA=y
CONFIG_SECURITY_LANDLOCK=y
CONFIG_SECURITYFS=y
CONFIG_LSM="landlock,lockdown,yama,loadpin,safesetid,integrity,apparmor,selinux,smack,tomoyo"

Baris CONFIG_LSM menentukan urutan modul yang dicoba diaktifkan saat boot, dan konfigurasi ini berbeda antar distro — Debian, Ubuntu, dan SUSE memilih kombinasi yang berbeda. Untuk memeriksa kernel yang sedang berjalan:

zcat /proc/config.gz | grep -E 'CONFIG_SECURITY|CONFIG_DEFAULT_SECURITY'

Jika /proc/config.gz tidak tersedia (biasanya karena modul configs tidak dimuat), periksa file config di /boot/. Kernel vanilla dari kernel.org biasanya tidak mengaktifkan AppArmor; kernel yang dikemas distro — Ubuntu, Debian, openSUSE — hampir selalu membangunnya dengan CONFIG_SECURITY_APPARMOR=y.

#Validasi Runtime

Konfigurasi kernel hanyalah syarat; yang menentukan adalah apa yang benar-benar aktif saat boot. Ada beberapa cara memvalidasinya, dan cara tercepatnya adalah membaca file yang dibangun kernel itu sendiri:

cat /sys/kernel/security/lsm
cat /sys/module/apparmor/parameters/enabled
aa-status

• /sys/kernel/security/lsm mendaftar LSM yang benar-benar aktif, dalam urutan eksekusinya. AppArmor harus ada di daftar ini.
• /sys/module/apparmor/parameters/enabled menunjukkan apakah modul AppArmor diaktifkan lewat boot parameter apparmor=0 atau apparmor=1.
• aa-status memberikan konfirmasi fungsional: profile yang dimuat dan proses yang terkonfinasi.

Boot parameter lain yang perlu kalian kenal: apparmor_restrict_unprivileged_userns=1 membatasi pembuatan user namespace tanpa privilege — restriksi yang sudah dibahas di episode 14 sebagai mitigasi. Perubahan urutan LSM juga bisa dilakukan lewat boot parameter lsm=..., tetapi ubahlah dengan sangat hati-hati: urutan menentukan hasil akhir dari stacking.

#Pembagian Peran: seccomp, Capabilities, dan LSM

Satu pertanyaan yang sering membingungkan: apa bedanya AppArmor dengan seccomp dan capabilities, dan bukankah semuanya "membatasi proses"? Jawabannya adalah lapisan. Ketiga mekanisme bekerja di titik yang berbeda dalam perjalanan sebuah syscall:

Urutan pemeriksaan biasanya: seccomp menyaring di titik masuk syscall, lalu LSM memeriksa operasi secara kontekstual (path apa yang disentuh, socket apa yang dibuka, terhadap siapa), sementara capabilities dan DAC mengecek privilege dan izin saat operasi spesifik dieksekusi. Sebuah syscall harus melewati semuanya.

Perbedaan inilah yang membuat ketiganya saling melengkapi, bukan saling menggantikan. Seccomp sangat tajam pada level syscall — ia bisa memblokir mount untuk semua proses — tapi ia tidak tahu path: dua proses yang memanggil open akan diperlakukan sama. AppArmor justru berbasis konteks: profil yang sama bisa mengizinkan open pada satu path dan menolaknya pada path lain. Inilah kekuatan yang kalian manfaatkan di seluruh series ini.

#Penutup

Pada episode ini kalian telah memahami AppArmor dalam konteks yang lebih luas: ia adalah LSM di dalam kerangka kerja keamanan kernel, hidup berdampingan dengan Yama, Landlock, LoadPin, dan lainnya dalam satu stack; dihidupkan oleh CONFIG_SECURITY_APPARMOR dan urutan CONFIG_LSM; dan tervalidasi lewat /sys/kernel/security/lsm serta aa-status. Kalian juga telah melihat pembagian lapisan dengan seccomp, capabilities, dan DAC — semua memeriksa dimensi yang berbeda dalam perjalanan sebuah syscall.

Inti yang harus kalian bawa:

• AppArmor adalah LSM mayor yang memediasi operasi melalui kernel hooks.
• Stacking memungkinkan beberapa LSM bekerja berurutan — Yama, Landlock, dan lainnya ikut menentukan.
• Kernel harus dibangun dengan CONFIG_SECURITY_APPARMOR=y; kernel distro umumnya sudah.
• Validasi runtime: baca /sys/kernel/security/lsm dan jalankan aa-status.
• seccomp, capabilities, dan LSM bekerja di lapisan berbeda — saling melengkapi.

Di episode 17 berikutnya kita masuk ke fitur-fitur lanjutan yang membuka dimensi baru profile: mount rules, ptrace dan signal, pivot_root, network filtering yang lebih halus, transisi antar profile dengan child profile dan attach, serta cara policy versioning bekerja antara format 4.x dan 5.x. Sampai jumpa di episode 17!