Belajar AppArmor - AppArmor 5 & Transisi Policy

#Pendahuluan

Di episode 18 kalian mengotomasi pengelolaan profile — lint di CI, matriks multi-distro, peralihan mode batch. Semua itu dibangun di atas satu asumsi: format policy relatif stabil. Tapi pada 2026, papan catur berubah. AppArmor 5.0 dirilis sebagai jembatan menuju generasi policy baru, dan para admin yang tidak memahami transisinya akan kebingungan saat upgrade distro berikutnya.

Di episode 19 ini kita membedah rilis besar pertama dalam bertahun-tahun ini: peta rilis 2026, apa artinya istilah bridge release, fitur baru yang dibawa 5.0, perbaikan di 5.0.1, implikasi migrasi bagi profile 4.x kalian, dan ke mana arah peta jalan 5.x. Kalian tidak perlu panik — yang kalian butuhkan adalah peta yang jelas.

#Peta Rilis AppArmor 2026

Supaya konteksnya utuh, mari letakkan semua rilis di satu garis waktu:

Perhatikan pola di kolom terakhir: 4.1.x tetap dipelihara sebagai cabang stabil sementara 5.0 diperkenalkan sebagai awal dari seri baru. Ini bukan versi yang saling menggantikan secara instan — ini adalah transisi yang dijalankan berdampingan.

#Apa Itu Bridge Release

Terminologi ini penting. Tim AppArmor menyebut 5.0 sebagai bridge release: ia tetap kompatibel mundur dengan policy AppArmor 4.0 — semua profile kalian yang sudah ditulis tetap bisa dimuat — sambil memperkenalkan fitur baru yang tidak kompatibel mundur ke arah sebaliknya. Profile yang memakai fitur baru tidak bisa dibaca parser 4.x.

Analogi yang tepat adalah jembatan sementara saat pembangunan gedung baru: jembatan itu berfungsi penuh, tapi tidak dirancang untuk bertahan lama. Konsekuensinya jelas — 5.0 adalah rilis short-lived dan tidak akan menerima long term support. Fitur-fitur barunya akan distabilkan pada 5.1, yang direncanakan sebagai rilis reguler.

#Fitur Baru di 5.0

Fitur-fitur di bawah ini yang membedakan policy 5.x dari 4.x:

Fitur baru AppArmor 5.0

- network interface mediation
- network port ranges
- overriding & conditional assignment operators
- conditionals pada variable pre-amble
- variabel otomatis: @{attach_path} dan @{exec_path}
- diff-encoded policy
- policy compression
- extended permissions & permission mapping
- network packet mediation

Dari sisi parser dan runtime, tiga di antaranya paling berpengaruh di dunia nyata. Policy compression memangkas ukuran policy terkompilasi 40-60 persen dan mempercepat pemuatan — dengan ongkos waktu kompilasi kecil. Diff-encoding menurunkan ukuran policy runtime rata-rata sekitar 15 persen. Extended permissions & permission mapping memungkinkan granularity aturan yang lebih halus, sekaligus menambah langkah kompilasi khusus untuk kernel lama yang belum mendukung tabel permission diperluas.

Yang perlu diingat: fitur-fitur ini opsional. Profile 4.0 yang tidak memakainya tetap berjalan normal di parser dan kernel 5.x.

#Rilis 5.0.1: Menstabilkan Jembatan

Karena 5.0.0 adalah rilis pertama yang mendukung pengembangan policy baru, ia membawa beberapa masalah yang diperbaiki di 5.0.1 (10 Juni 2026). Di antaranya: perubahan cara parser menyortir dan mendeduplikasi aturan (umumnya memangkas waktu kompilasi sekitar dua persen), perbaikan regresi parsing mount yang dipicu assignment overriding, perbaikan penghitungan link rules terhadap batas transition, perbaikan header cache terkompresi, dan perbaikan penulisan user header ke file output.

#Implikasi Migrasi: 4.x ke 5.x

Ada tiga hal yang wajib kalian pahami sebelum upgrade.

Pertama, profile tidak perlu ditulis ulang. Karena kompatibilitas mundur, profile ber-ABI 4.0 tetap dimuat oleh parser 5.x. Migrasi ke fitur baru dilakukan bertahap per profile, dengan mengarahkan ABI-nya:

Mengarahkan ABI profile ke 5.0

abi <abi/5.0,>
 
profile nginx /usr/sbin/nginx {
    # aturan tetap bisa dibaca parser 5.x
}

Kedua, cache policy ikut berganti. Parser 5.x menghasilkan cache terkompresi dengan format dan header yang berbeda. Kunci cache mencakup versi parser dan fitur kernel, sehingga cache lama tidak akan dipakai ulang dan di-rebuild otomatis. Jika ingin memastikan kebersihan cache secara eksplisit:

sudo apparmor_parser --purge-cache
sudo systemctl restart apparmor

Ketiga, pengujian distro tidak bisa dilewati. Userspace 5.x mendukung kernel mulai dari 2.6.15 ke atas, tetapi fitur baru seperti extended permissions, network packet mediation, dan compressed policy membutuhkan kernel yang lebih baru. Cek dulu versi parser yang terpasang dengan apparmor_parser -V. Policy yang dikompilasi terhadap fitur kernel baru gagal dimuat di kernel lama. Karena itu, matriks multi-distro dari episode 18 menjadi lebih penting — uji profile kalian terhadap parser 5.x di staging dulu, di semua distro yang kalian jalankan, sebelum rollout.

#Strategi Versi untuk Distro

Keputusan versi tidak terjadi di ruang hampa — distro kalian ikut menentukan. Ubuntu, Debian, dan openSUSE mengemas AppArmor sebagai bagian dari rilis mereka, dan tiap distro memilih cabang yang dianggap matang pada saat rilis. Sebagai admin, kalian biasanya tidak perlu mengompilasi AppArmor sendiri; kalian cukup mengikuti cabang yang disediakan distro.

Tiga aturan yang kami pegang:

1. Jangan campur userspace antar cabang di satu host. Mengambil parser 5.0 dari backport sementara library dari paket 4.1 adalah resep kegagalan yang sulit dilacak.
2. Verifikasi versi parser di CI. Panggil apparmor_parser -V sebagai langkah pertama pipeline — pastikan CI menguji versi yang sama dengan produksi.
3. Catat versi di profil perubahan. Saat menaikkan userspace, catat versi parser dan tanggalnya di commit — audit ini menyelamatkan kalian saat ada denial aneh yang muncul pasca-upgrade.

#Peta Jalan 5.x: Menuju 5.1

Karena 5.0 short-lived, keputusan strategisnya sederhana: jadikan 5.1 sebagai target adopsi produksi, bukan 5.0. Distribusi yang mengejar LTS kemungkinan akan melewati 5.0 dan langsung membawa 5.1 sebagai rilis 5.x pertama yang stabil. Sementara itu, cabang 4.1.x tetap aman untuk dipakai — versi 4.1.7 adalah titik paling matang dari era policy 4.x.

Peta jalannya jelas: 5.0 dan 5.0.1 membangun fondasi format policy baru, dan 5.1 menyempurnakan serta menstabilkan fitur-fiturnya menjadi rilis reguler yang didukung jangka panjang.

#Penutup

Pada episode 19 ini kalian memahami bahwa AppArmor 5 adalah transisi yang dijalankan berdampingan, bukan pergantian mendadak: 5.0 (23 April 2026) adalah bridge release yang tetap memuat policy 4.0, 5.0.1 (10 Juni 2026) menstabilkannya, dan keduanya short-lived tanpa LTS — target produksi ada di 5.1.

Poin kunci:

• Policy 4.0 tetap valid di parser 5.x; tidak ada kewajiban menulis ulang profile.
• Fitur baru 5.0 tidak kompatibel mundur — gunakan bertahap per profile lewat ABI baru.
• Cache policy berubah format; rebuild otomatis, atau bersihkan manual dengan apparmor_parser --purge-cache.
• Jangan pakai 5.0.0 di produksi: gunakan 4.1.7 atau 5.0.1.
• Uji di matriks multi-distro sebelum upgrade — fitur baru butuh kernel yang mendukungnya.

Di episode 20 berikutnya kita naik satu level dari rilis ke operasional: Scale & Multi-host Management — mendistribusikan profile ke banyak host dengan config management, menangani perbedaan kernel, dan rollout bertahap dari complain ke enforce tanpa mengorbankan kestabilan. Sampai jumpa!