Belajar AppArmor - Vulnerability Awareness & Fixes

#Pendahuluan

Di episode 13 kalian mengamankan data — file kredensial, direktori SSH, key store — dengan deny rule yang teliti. Sekarang pertanyaan yang lebih dalam: seberapa andal perangkat yang menjalankan semua aturan itu? AppArmor adalah perangkat lunak keamanan, dan seperti perangkat lunak lain, ia bisa mengandung bug. Sebuah bug di AppArmor bukan sekadar error kosmetik — ia bisa membuat konfinasi yang kalian bangun di episode-episode sebelumnya menjadi kepercayaan kosong.

Episode ini membahas dua hal: kesadaran kerentanan — riwayat CVE dan regresi di AppArmor, termasuk kasus parser 4.1.0 di Debian — dan strategi patch yang benar untuk menutupnya.

#Kontrol Keamanan yang Rusak Adalah Rasa Aman Palsu

Bayangkan brankas dengan kunci yang rusak. Selama tidak pernah diperiksa, semua orang percaya isinya aman. Kontrol keamanan yang rusak menghasilkan false assurance — keyakinan aman yang tidak berdasar, dan justru lebih berbahaya daripada tidak punya kontrol sama sekali, karena keputusan dibuat berdasarkan informasi yang salah.

Di dunia AppArmor, pola ini muncul dalam tiga bentuk:

Profile tidak dimuat — apparmor.service gagal start sehingga aplikasi berjalan tanpa konfinasi. Terdengar seperti kegagalan yang keras, tapi tanpa pemantauan ia bisa terjadi diam-diam saat reboot.
Rule salah diterjemahkan — deny yang tidak berfungsi berarti pembatasan yang kalian kira ada sebenarnya tidak ada.
Bug kernel — hook LSM gagal, atau celah di mekanisme load policy yang memungkinkan attacker memanipulasi policy dari dalam.

#Kasus Nyata: Regresi 4.1.0 di Debian

Kasus yang paling sering dikutip adalah rilis AppArmor 4.1.0 yang masuk Debian. Setelah upgrade, apparmor.service gagal start dengan error parser: file /etc/apparmor.d/tunables/home menghasilkan syntax error, unexpected TOK_EQUALS. Akibatnya seluruh profile tidak dimuat — semua aplikasi yang selama ini terkonfinasi tiba-tiba berjalan tanpa pengaman, dan masalahnya baru terasa ketika layanan gagal atau sistem melakukan reboot.

Regresi yang sama juga menimpa profile besar: parser menghabiskan waktu sangat lama atau menolak profile karena terlalu banyak state — kasus yang dikenal dari profile LibreOffice soffice.bin — ditambah pemborosan memori kernel untuk policy yang bisa mencapai beberapa kali lipat dari seharusnya. Perbaikan untuk regresi ukuran policy datang di 4.1.4, dan pelajaran utamanya bukan "jangan update", melainkan: rilis baru bisa membawa regresi, jadi update harus diverifikasi, bukan dianggap remeh.

#Riwayat CVE di Kernel: Kasus CrackArmor

Yang lebih serius datang dari kernel. Pada Maret 2026, Qualys mengungkap CrackArmor: sembilan kerentanan di modul AppArmor kernel Linux yang diberi nomor CVE-2026-23268 hingga CVE-2026-23411, memengaruhi sekitar 12,6 juta sistem dan berakar sejak kernel 4.11 (2017).

Inti masalahnya adalah confused deputy. Interface policy management di /sys/kernel/security/apparmor/ — file .load, .replace, dan .remove — bisa dibuka untuk ditulis oleh proses tanpa privilege, dengan pemeriksaan izin yang baru terjadi saat data benar-benar ditulis. Jika attacker bisa membujuk proses berprivilege (misalnya su) untuk menulis ke file descriptor yang sudah dibuka, ia bisa memuat, mengganti, atau menghapus profile AppArmor secara sewenang-wenang. Dampaknya luas:

Penghapusan konfinasi — melepas profile yang melindungi aplikasi.
Denial of service — memuat profile deny-all yang memblokir seluruh eksekusi.
Kebocoran memori kernel dan bypass KASLR, misalnya CVE-2026-23269.
Local privilege escalation ke root dan container escape, lewat kombinasi dengan celah lain.

Semua kerentanan ini menuntut akses user lokal. Artinya pertahanan terakhir kalian adalah ketepatan waktu patch dan minimasi akses lokal — bukan sekadar rajin menulis policy.

Important

Baca nasihat keamanan resmi distro kalian — misalnya ringkasan CrackArmor di halaman keamanan Ubuntu — untuk versi kernel mana yang terkena dan mana yang sudah diperbaiki. Jangan mengandalkan artikel blog atau berita; gunakan tracker resmi.

#Strategi Patch

#Selalu Update ke Userspace Terbaru

Userspace AppArmor — parser, libapparmor, dan tooling — menentukan bagaimana policy dikompilasi dan dimuat. Bug parser seperti kasus 4.1.0 hanya bisa diperbaiki dengan memperbarui userspace:

Perbarui userspace AppArmor di Debian/Ubuntu

sudo apt update
sudo apt install --only-upgrade apparmor apparmor-utils libapparmor1
sudo systemctl restart apparmor

#Verifikasi Parser, Kernel, dan Profile yang Dimuat

Update saja tidak cukup — verifikasi bahwa versi yang diharapkan benar-benar aktif, dan profile benar-benar termuat setelahnya:

Verifikasi versi dan status

apparmor_parser --version
aa-status --version
uname -r
sudo aa-status

aa-status yang sehat menunjukkan daftar profile yang dimuat beserta mode-nya. Jika setelah upgrade ada profile yang hilang dari daftar, itu sinyal awal regresi — kembali ke workflow di episode 12 untuk menyelidiki.

#Koordinasi dengan Distro Security Updates

AppArmor dikemas berbeda per distro, dan patch yang benar datang dari sumber yang berbeda:

Distribusi	Sumber advisory	Mekanisme update
Ubuntu	USN (Ubuntu Security Notices)	`apt upgrade` plus `pro security-status`
Debian	DSA dan DLA di security-tracker	`apt upgrade` plus `unattended-upgrades`
SUSE	SUSE Security Advisories	`zypper patch` plus SLES Subscription

Aturan praktis: jangan pernah men-download userspace langsung dari upstream ke sistem produksi. Selalu tunggu paket resmi distro — merekalah yang menguji kompatibilitas dengan kernel yang mereka kirim.

#Proses Patch yang Disiplin

Menerapkan patch dengan disiplin bisa disederhanakan menjadi lima langkah:

Inventarisasi — catat versi userspace dan kernel di semua host, jadikan checklist.
Berlangganan advisory — pantau USN, DSA, dan SUSE advisories agar tahu lebih dulu.
Uji di staging — terapkan patch, reload profile, jalankan workload, bandingkan deny log sebelum dan sesudah.
Jadwalkan jendela — terapkan ke produksi pada jam tenang, siapkan rencana rollback.
Verifikasi — setelah apply, jalankan aa-status dan pastikan tidak ada profile yang gagal dimuat.

Warning

Kernel patch dari kasus CrackArmor tidak otomatis terpasang lewat update biasa pada sebagian konfigurasi — periksa apakah host kalian mengaktifkan update kernel otomatis, atau perlu jendela reboot manual. Sistem yang tidak pernah reboot bisa terlihat up-to-date di paket tapi tetap berjalan di kernel yang rentan.

Untuk konteks container, mitigasi tambahan yang dianjurkan adalah menonaktifkan load policy di dalam user namespace melalui sysctl unprivileged_userns_apparmor_policy — ini memotong salah satu jalur eksploitasi yang ditemukan Qualys. Diskusikan dengan tim platform sebelum mengubah nilai global ini, karena dampaknya menyentuh semua workload yang memakai user namespace.

#Penutup

Pada episode ini kalian telah melihat bahwa AppArmor adalah perangkat lunak yang nyata: regresi parser 4.1.0 di Debian menunjukkan rilis baru bisa memutus konfinasi, dan keluarga CVE CrackArmor menunjukkan bug kernel yang serius bisa menembus segalanya. Kalian juga telah menyusun strategi patch: update userspace terbaru, verifikasi parser dan kernel, koordinasi dengan advisory distro, dan proses lima langkah yang disiplin.

Inti yang harus kalian bawa:

Bug di AppArmor menghasilkan rasa aman palsu, bukan sekadar error.
Rilis baru harus diverifikasi, tidak pernah dianggap remeh.
Ketepatan waktu patch adalah pertahanan terakhir melawan kerentanan akses lokal.
Gunakan paket resmi distro dan tracker advisory resmi.
Verifikasi setelah patch: versi benar, profile termuat, deny masih bekerja.

Di episode 15 berikutnya kita membangun mata untuk semua hal di atas: auditing dan monitoring. Mulai dari aa-notify, agregasi log denial, sampai alerting berbasis journald dan auditd, plus dokumentasi coverage profile per service untuk kebutuhan compliance. Sampai jumpa di episode 15!