Belajar AppArmor - Policy Tooling & Automation

#Pendahuluan

Di episode 17 kalian menembus level lanjut: change_hat, profil bernama, hingga stacking antar mekanisme. Kemampuan menulis profile yang presisi itu ibarat memiliki resep masakan yang sempurna — tapi di tim produksi, resep yang bagus tidak berguna jika hanya ada di kepala satu koki. Ia harus dituliskan, dibakukan, dan diuji ulang setiap kali ada perubahan. Itulah yang kita bahas hari ini: mengubah praktik menulis profile menjadi alur yang bisa diulang, divalidasi, dan diotomatiskan.

Di episode 5 kalian sudah memakai aa-genprof dan aa-logprof untuk membangun profile secara interaktif. Episode 18 melengkapi itu dengan tiga lapis otomasi: peralihan mode batch dengan aa-enforce dan aa-complain, penggabungan profile dengan aa-mergeprof, serta validasi tanpa efek samping dengan apparmor_parser -Q. Ketiganya lalu dirangkai menjadi pipeline CI yang menjaga profile tetap sehat sebelum masuk produksi.

#Peralihan Mode Otomatis: aa-enforce dan aa-complain

Sepanjang series ini kalian bolak-balik antara complain (hanya mencatat) dan enforce (benar-benar memblokir). Secara manual, berarti mengedit flags lalu me-reload profile — pekerjaan yang rawan salah, terutama di banyak host sekaligus. Kedua tool ini menyingkatnya menjadi satu perintah.

aa-complain dan aa-enforce menerima satu atau lebih executable target, menemukan profile-nya di direktori profile (default /etc/apparmor.d, bisa diubah dengan opsi -d), menyesuaikan mode-nya, lalu me-reload ke kernel.

Alihkan beberapa profile ke complain mode

sudo aa-complain /usr/sbin/nginx /usr/sbin/cupsd

Kembalikan ke enforce setelah pengujian

sudo aa-enforce /usr/sbin/nginx /usr/sbin/cupsd

Kedua perintah bersifat batch: menulis beberapa executable sekaligus lebih cepat dan mengurangi risiko salah ketik dibandingkan mengedit file satu per satu. Jika kalian hanya ingin mengubah mode pada file profile tanpa me-reload ke kernel — misalnya agar perubahan bisa di-commit dan di-review dulu — gunakan opsi --no-reload.

Untuk memindahkan seluruh profile kustom ke complain dalam sekali jalan, sebuah loop sederhana sudah cukup:

Alihkan semua profile usr.* ke complain

for p in /etc/apparmor.d/usr.*; do
    sudo aa-complain "$p"
done

Tip

Dalam otomasi, peralihan mode adalah gerbang, bukan tujuan. Jangan meng-commit hasil aa-enforce tanpa melewati periode complain dan review denial terlebih dahulu. Alur yang benar selalu: complain, uji, kumpulkan denial, perbaiki profile, baru enforce. Pola rollout bertahap ini akan kita bedah lebih dalam di episode 20.

#aa-mergeprof: Menggabungkan Perubahan Profile

Setelah aplikasi di-upgrade atau perilakunya berubah, denial baru bermunculan. Alih-alih membuka aa-logprof untuk satu profile saja, aa-mergeprof menggabungkan hasil pengamatan ke dalam satu atau lebih file profile sekaligus — sangat cocok untuk batch update pasca-upgrade.

Merge denial terbaru ke profile nginx

sudo aa-mergeprof /etc/apparmor.d/usr.sbin.nginx

Tool ini membaca profile yang ada, membandingkannya dengan denial terbaru dari log, lalu menawarkan penambahan aturan untuk disetujui atau ditolak. Karena semua perubahan ditulis kembali ke file, hasilnya bisa langsung di-commit dan diff-nya di-review. Di situlah nilai utamanya: tidak ada perubahan diam-diam di kernel yang tidak tercermin di git.

#Validasi dengan apparmor_parser -Q

Menguji profile tidak harus selalu memuatnya ke kernel. Opsi -Q (singkatan --skip-kernel-load) membuat apparmor_parser menjalankan seluruh tahap kompilasi kecuali pemuatan ke kernel. Ini ideal untuk CI: tidak butuh root, tidak mengubah state kernel, dan mengembalikan exit code non-nol jika ada error.

Validasi profile tanpa memuat ke kernel

apparmor_parser -Q /etc/apparmor.d/usr.sbin.nginx

Untuk menangkap lebih banyak masalah, kombinasikan dengan --Werror yang memperlakukan warning sebagai error — misalnya --Werror=deprecated untuk menolak sintaks usang:

Perlakukan warning sebagai error

apparmor_parser -Q --Werror /etc/apparmor.d/usr.sbin.nginx

Jika hanya ingin memeriksa kebenaran sintaks, opsi -d juga tersedia. Bedanya, -Q menyelesaikan seluruh pipeline kompilasi termasuk tahap cache — jadi yang diuji adalah persis apa yang akan dimuat ke kernel, bukan sekadar tata bahasa.

#Integrasi CI: Lint, Kompilasi, dan Matriks Multi-distro

Keuntungan validasi di atas baru terasa saat dirangkai ke pipeline. Ada tiga lapis yang kami sarankan.

Pertama, lint profile pada setiap pull request. Setiap perubahan profile langsung divalidasi dengan apparmor_parser -Q --Werror, dan diff-nya di-review seperti kode biasa.

Kedua, kompilasi seluruh direktori profile. Memuat semua file sekaligus menangkap error yang baru muncul karena interaksi antar profile.

Ketiga, matriks pengujian multi-distro. AppArmor adalah userspace yang di-build dan di-packaging berbeda per distro, dan tiap kernel distro mendukung fitur yang berbeda. Profile yang valid di Ubuntu belum tentu berperilaku sama di Debian atau openSUSE.

.github/workflows/apparmor.yml — pipeline policy

name: apparmor-policy
 
on:
  pull_request:
    paths:
      - "profiles/**"
 
jobs:
  validate:
    strategy:
      fail-fast: false
      matrix:
        include:
          - distro: ubuntu
            image: ubuntu:24.04
          - distro: debian
            image: debian:stable
          - distro: opensuse
            image: opensuse/leap:15.6
    runs-on: ubuntu-latest
    container:
      image: ${{ matrix.image }}
    steps:
      - uses: actions/checkout@v4
 
      - name: Install AppArmor
        run: |
          apt-get update
          apt-get install -y apparmor apparmor-utils
 
      - name: Validate profiles without kernel load
        run: |
          for p in profiles/*; do
            apparmor_parser -Q --Werror "$p" || exit 1
          done

Important

Matriks multi-distro bukan formalitas. Parser dan kernel tiap rilis punya fitur serta tabel permission yang berbeda — seperti yang akan kalian lihat sendiri pada episode 19 soal transisi AppArmor 5.x. Menguji di banyak distro adalah cara termurah untuk menemukan masalah sebelum pengguna yang melaporkannya.

Untuk pengujian perilaku — bukan sekadar sintaks — proyek AppArmor merekomendasikan dua pendekatan: autopkgtest untuk menguji profile terhadap paket di distro, dan spread untuk menjalankan skenario end-to-end di beberapa sistem sekaligus. Keduanya bisa dipanggil dari CI yang sama.

#Penutup

Pada episode 18 ini kalian mengubah cara kerja profile dari tangan menjadi pipeline: aa-enforce dan aa-complain untuk peralihan mode batch, aa-mergeprof untuk menggabungkan perubahan, apparmor_parser -Q untuk validasi tanpa efek samping, dan integrasi lint, kompilasi, serta matriks multi-distro ke dalam CI.

Poin kunci yang perlu kalian bawa:

aa-complain dan aa-enforce menerima banyak executable sekaligus — gunakan untuk peralihan batch yang bisa diulang.
aa-mergeprof menulis kembali profile ke file, sehingga setiap perubahan terekam di git.
apparmor_parser -Q memvalidasi tanpa memuat ke kernel — pasangan sempurna untuk CI.
Pipeline yang sehat punya tiga lapis: lint per-PR, kompilasi seluruh direktori, dan matriks multi-distro.
Uji perilaku dengan autopkgtest atau spread, bukan hanya validasi sintaks.

Di episode 19 berikutnya kita menghadapi perubahan besar: AppArmor 5 & Transisi Policy. Kalian akan memahami mengapa 5.0 adalah rilis bridge yang short-lived, apa implikasinya bagi profile 4.x yang sudah kalian bangun, dan bagaimana strategi migrasi yang aman. Sampai jumpa!