Belajar AppArmor - Debugging Denials & Logs

#Pendahuluan

Di episode 6, kalian mengetatkan profile dengan network dan capability rules — dan kemungkinan besar kalian juga langsung menuai denial di log. Itu bukan kegagalan; itu sinyal kerja. Masalahnya, banyak engineer yang menanggapi denial dengan menghapus aturan sampai error hilang, tanpa pernah tahu apa yang sebenarnya diblokir.

Episode 7 ini mengubah cara kalian menghadapi denial: bukan musuh yang harus dibungkam, melainkan informasi yang harus dibaca. AppArmor mencatat hampir setiap penolakan dengan detail, dan membaca catatan itu dengan benar adalah keterampilan yang membedakan operator yang menebak dari operator yang memahami.

#Di Mana Jejak Denial Ditulis

Secara default, denial AppArmor ditulis ke log kernel, yang lalu diteruskan ke log sistem. Di Ubuntu dan Debian yang memakai rsyslog, jejaknya ada di satu file:

Lihat baris AppArmor di syslog

grep apparmor /var/log/syslog

Di sistem modern dengan journald, cara yang lebih cepat adalah lewat journalctl — khususnya untuk pesan kernel:

Cari pesan kernel yang menyebut apparmor

journalctl -k --grep=apparmor

sudo journalctl -k --grep=apparmor -n 50

Flag -n 50 membatasi ke 50 baris terakhir, sementara -f memfollow log seperti tail -f — sangat berguna saat kalian mereproduksi masalah.

Note

Jika sistem kalian menginstall auditd, denial AppArmor juga ikut tercatat di /var/log/audit/audit.log. Keduanya berisi informasi yang sama — pilih salah satu yang kalian nyaman gunakan, selama konsisten. Untuk episode ini kita fokus ke syslog dan journald.

#Membaca Format apparmor=DENIED

Ini contoh denial yang khas:

Contoh denial open

audit: type=1400 audit(1710000000.123:456): apparmor="DENIED"
  operation="open" profile="/usr/sbin/nginx"
  name="/etc/nginx/secret.conf" pid=1234 comm="nginx"
  requested_mask="r" denied_mask="r" fsuid=0

Lima elemen yang wajib dibaca:

apparmor="DENIED" — penanda bahwa ini penolakan AppArmor, bukan error aplikasi.
operation — operasi yang diblokir: open, exec, connect, mkdir, dan seterusnya.
profile — profile yang aktif menolak, di sini profile Nginx.
name — objek yang dituju, biasanya path file atau alamat socket.
requested_mask dan denied_mask — hak yang diminta dan hak yang ditolak. r berarti read, w write, x execute, m memory map, k lock, a append.

Denial connect untuk jaringan terlihat sedikit berbeda:

Contoh denial connect

audit: type=1400 audit(1710000000.789:457): apparmor="DENIED"
  operation="connect" profile="/usr/sbin/nginx"
  name="/run/mysqld/mysqld.sock" pid=1234 comm="nginx"
  requested_mask="rw" denied_mask="rw" fsuid=0

Perhatikan name di sini adalah path socket Unix, bukan alamat IP. Inilah hasil langsung dari episode 6: profile Nginx tidak memiliki aturan network unix stream, sehingga koneksi ke MySQL via socket ditolak.

#Alur Debug yang Benar

Debugging denial AppArmor mengikuti siklus empat langkah. Lewati satu langkah saja, dan kalian akan memperbaiki hal yang salah:

Observe — temukan denial di log dan baca kelima elemennya. Apakah operasi ini memang seharusnya diizinkan?
Adjust — edit profile. Tambahkan aturan sesempit mungkin, atau perbaiki path yang salah. Gunakan aa-logprof jika ingin dibimbing langkah demi langkah.
Reload — muat ulang profile ke kernel tanpa restart sistem:

Reload profile tanpa reboot

sudo apparmor_parser -r /etc/apparmor.d/usr.sbin.nginx

Flag -r (replace) memperbarui profile yang sudah dimuat. Jika kalian membuat file profile baru yang belum pernah dimuat, gunakan -a (add), atau biarkan aa-enforce/aa-complain yang menanganinya.

Verify — ulangi operasi yang gagal, lalu periksa log lagi. Denial menghilang? Selesai. Masih muncul dengan aturan berbeda? Kembali ke langkah 1.

Important

Perhatikan apa yang berubah antar siklus. Jika denial tetap muncul dengan profile dan operation yang sama persis setelah reload, kemungkinan aturannya tidak benar-benar cocok dengan path — misalnya path yang mengarah ke symlink, atau variable @{HOME} yang tidak ter-resolve. Denial tidak berubah berarti informasi yang kalian perbaiki bukan yang diblokir.

#aa-notify: Denial Sampai ke Layar Kalian

Menjalankan alur manual itu baik untuk debugging, tapi untuk pemantauan terus-menerus ada alat yang lebih nyaman: aa-notify. Di Ubuntu alat ini tersedia lewat paket apparmor-notify. Untuk ringkasan denial beberapa hari terakhir:

Ringkasan denial satu hari terakhir

aa-notify -s 1

-s menerima jumlah hari — ganti 1 dengan 7 untuk sepekan. Keluarannya kira-kira seperti ini (disederhanakan):

Contoh ringkasan aa-notify

Profiles: 3    Denials: 12    Since: 1 day ago
  /usr/sbin/nginx          8
  /usr/sbin/mysqld         3
  /usr/bin/python3.12      1

Untuk notifikasi desktop secara real-time, pakai mode poll:

Poll log dan tampilkan notifikasi desktop

aa-notify -p -u arman --display $DISPLAY

Mode ini membaca log terus-menerus dan memunculkan notifikasi setiap kali ada denial baru — sehingga perubahan perilaku aplikasi langsung terlihat tanpa harus membuka terminal. Di server tanpa GUI, skenario utamanya adalah menjadwalkan aa-notify -s 1 lewat cron dan memeriksa ringkasannya berkala. Konfigurasi global (termasuk siapa yang boleh menjalankan dan filter notifikasi) ada di /etc/apparmor/notify.conf.

#Penutup

Pada episode 7 ini kalian sudah memegang kunci debugging AppArmor: tahu di mana denial ditulis (syslog, journald, dan audit.log), mampu membaca format apparmor="DENIED" sampai level operasi dan mask, menjalankan siklus observe-adjust-reload-verify dengan apparmor_parser -r, serta memakai aa-notify untuk notifikasi otomatis.

Kunci yang harus dibawa pulang:

Log adalah sumber kebenaran; baca sebelum mengubah aturan.
Reload dengan apparmor_parser -r, jangan reboot.
Denial yang tidak berubah setelah reload berarti aturannya belum benar-benar cocok.

Sampai di sini, semua profile kalian masih ditulis dengan path hardcode — dan path yang hardcode membuat profile tidak portabel antar sistem. Di episode 8, kita berkenalan dengan Variable, Tunables & Include: @{HOME}, @{PROC}, direktori tunables, dan abstractions yang memungkinkan satu profile berjalan di banyak mesin tanpa dirombak ulang.