Belajar AppArmor - Advanced Profile Features

#Pendahuluan

Di episode 16 kalian memahami di mana AppArmor berdiri dalam kernel: satu LSM dalam satu stack, bermediasi bersama modul lain. Sekarang kita membalik kembali ke policy — tapi ke bagian yang jarang dieksplorasi. Sejauh ini profile kalian didominasi aturan file, network, dan capability. Padahal AppArmor bisa memediasi jauh lebih dalam: mount, ptrace dan signal, pivot_root, network yang lebih halus, serta transisi antar profile.

Episode ini membahas fitur-fitur tersebut, lalu menutup dengan policy versioning: bagaimana format 4.x dan 5.x hidup berdampingan, dan apa artinya bagi profile yang kalian tulis hari ini.

#Aturan Mount

Proses yang berhak melakukan mount bisa diatur dengan aturan mount — sumber, target, dan opsi. Ini penting untuk daemon yang membutuhkan filesystem tambahan, misalnya service container atau aplikasi yang me-mount media, sekaligus mencegah daemon lain me-mount apa pun:

Aturan mount yang terbatas

mount options=(ro) -> /mnt/readonly/,
mount /dev/sr0 -> /mnt/media/,
deny mount -> /proc/sys/**,
deny mount -> /etc/**,

Baris pertama mengizinkan mount read-only ke satu titik target — catatan penting: menentukan opsi ro di sini bukan sekadar dokumentasi, kernel memediasinya. Baris ketiga dan keempat adalah deny yang menutup area sensitif: tidak ada proses dalam profile ini yang boleh me-mount apa pun ke /proc/sys atau /etc. Seperti biasa, deny menang atas allow.

#Aturan ptrace dan Signal

Komunikasi antar proses adalah dimensi yang sering luput dari perhatian. ptrace mengatur debugging dan injeksi (seperti gdb), sedangkan signal mengatur sinyal seperti kill, TERM, dan HUP. Aturan keduanya bisa dibatasi ke peer tertentu:

Batasi ptrace dan signal ke peer tertentu

ptrace (read) peer=myapp_helper,
signal (send) peer=myapp_helper,
deny ptrace peer=unconfined,
deny signal (receive) peer=other,

Yang pertama mengizinkan proses di profile ini membaca status proses milik myapp_helper; yang kedua mengizinkan mengirim sinyal ke peer yang sama. Dua deny terakhir menutup interaksi dengan dunia luar: tidak boleh me-trace proses unconfined, dan tidak boleh menerima sinyal dari proses lain. Ini membatasi gerakan lateral — attacker yang merebut satu proses tidak bisa memanfaatkannya untuk mempengaruhi proses lain.

#pivot_root untuk Container dan Chroot

pivot_root adalah syscall yang mengganti root filesystem — mekanisme inti saat container atau chroot-like runtime menyiapkan filesystem barunya. Di AppArmor, aksesnya bisa diizinkan secara penuh atau dibatasi dengan path:

Aturan pivot_root

pivot_root,
deny pivot_root -> /var/lib/**,

Baris pertama mengizinkan pivot_root tanpa batasan target. Baris kedua menolak pivot_root ke dalam pohon /var/lib — misalnya melindungi data volume dari proses yang mencoba menggunakannya sebagai root baru. Untuk workload container yang membangun rootfs sendiri, mengizinkan pivot_root dengan target yang jelas lebih baik daripada memberi kemampuan sys_chroot secara liar.

#Network Filtering yang Lebih Halus

Aturan network dari episode 6 bisa diperhalus dengan mengombinasikan domain, tipe, dan protokol secara eksplisit. Pola deny di bawah menunjukkan cara mempersempit perilaku jaringan:

Network filtering per domain dan tipe

network inet tcp,
network inet6 tcp,
network unix stream,
deny network inet raw,
deny network netlink,

Di sini profile mengizinkan TCP IPv4/IPv6 dan UNIX stream — lalu secara eksplisit melarang raw socket dan netlink. Deny raw penting untuk daemon yang tidak perlu menangkap paket; deny netlink mencegah proses memanipulasi konfigurasi jaringan. Perhatikan bahwa detail mediasi, termasuk dukungan untuk aturan unix yang lebih granular, bisa berbeda tergantung versi kernel dan policy ABI — kembali ke bagian versioning di bawah.

#Transisi Antar Profile dan Child Profile

Selama ini satu profile mengawal satu binary. Padahal AppArmor mendukung transisi: saat binary mengeksekusi program lain, confinement bisa berpindah ke profile lain. Transisi yang paling umum adalah px (discrete profile transition):

Child profile via transisi px

profile myapp /opt/myapp/bin/myapp {
  #include <abstractions/base>
 
  /opt/myapp/bin/myapp mr,
  /opt/myapp/bin/helper px -> myapp_helper,
}
 
profile myapp_helper {
  #include <abstractions/base>
 
  /opt/myapp/bin/helper mr,
  /opt/myapp/data/ r,
  /opt/myapp/data/** r,
}

Saat myapp mengeksekusi helper, proses berpindah ke profile myapp_helper yang lebih ketat — tidak lagi mewarisi seluruh izin induknya. Inilah cara paling bersih untuk membatasi bagian-bagian berisiko dari sebuah aplikasi: pisahkan fungsinya ke binary tersendiri, lalu konfinasi tiap binary dengan profile yang sempit.

Untuk kasus satu binary dengan beberapa mode — misalnya mode admin dan mode worker — AppArmor menyediakan hat (child profile dengan awalan ^), yang diaktifkan lewat panggilan change_hat dari dalam aplikasi:

Hat untuk mode terpisah dalam satu profile

profile myapp /opt/myapp/bin/myapp {
  #include <abstractions/base>
 
  /opt/myapp/bin/myapp mr,
 
  ^admin {
    /etc/myapp/admin.conf r,
  }
}

Ada juga keyword attach pada transisi, yang mengikat eksekusi pada kondisi tertentu (misalnya atribut extended pada binary). Ia berguna untuk skenario di mana satu executable dilayani oleh lebih dari satu profile. Detail sintaks lengkapnya ada di man page apparmor.d, tapi yang penting kalian bawa adalah konsepnya: AppArmor tidak mengunci sebuah proses pada satu profile seumur hidupnya — ia bisa berpindah secara terkontrol.

#Policy Versioning: 4.x vs 5.x

Semua fitur di atas bergantung pada policy ABI — kesepakatan antara format policy, parser, dan kernel. Setiap profile bisa mendeklarasikan ABI yang dipakainya:

Deklarasi ABI di bagian atas profile

# bagian atas profile
abi <abi/4.0>,
 
#include <tunables/global>
#include <abstractions/base>

Profile yang tidak mendeklarasikan ABI dianggap memakai ABI lama yang di-pin oleh konfigurasi parser. Parser melakukan rule downgrade: fitur yang tidak didukung kernel akan diturunkan atau dibuang, dan kalian bisa meminta parser memberi tahu saat itu terjadi:

apparmor_parser --skip-kernel-load --warn=rule-not-enforced /etc/apparmor.d/myapp
aa-features-abi -x

apparmor_parser --warn=rule-not-enforced memperingatkan aturan yang tidak bisa ditegakkan; aa-features-abi -x menampilkan kemampuan kernel saat ini dalam format ABI — arahkan outputnya ke file dengan redirect agar mudah dibandingkan antar host.

Inti yang harus kalian pahami tentang versioning:

• Policy 4.x kompatibel mundur dengan policy 3.x lewat mekanisme ABI — profile lama terus berfungsi dengan parser baru.
• AppArmor 5.x (rilis 2026) membawa format penulisan policy yang lebih baru — termasuk tabel permission yang diperluas dan mediasi jaringan yang lebih granular seperti aturan unix — dan sejumlah fitur barunya tidak kompatibel mundur dengan format 4.x.
• Migrasi antar versi berarti meninjau ABI, me-rebuild cache parser, dan menguji profile di complain mode sebelum memutuskan — persis siklus yang kalian kuasai di episode 12.

#Penutup

Pada episode ini kalian telah membuka dimensi baru profile AppArmor: aturan mount yang dibatasi sumber, target, dan opsi; aturan ptrace dan signal yang membatasi interaksi antar proses; pivot_root untuk kebutuhan container; network filtering yang lebih halus; serta transisi antar profile — child profile lewat px, hat lewat ^, dan keyword attach — yang memungkinkan satu proses berpindah konfinasi secara terkontrol. Kalian juga memahami policy versioning: deklarasi ABI, rule downgrade, dan batas kompatibilitas antara format 4.x dan 5.x.

Inti yang harus kalian bawa:

• Mount, ptrace, signal, dan pivot_root adalah dimensi mediasi yang sering terlupakan — dan sama pentingnya dengan aturan file.
• Transisi px memisahkan bagian berisiko aplikasi ke profile yang lebih sempit.
• Hat dengan ^ memecah satu binary menjadi mode-mode yang terisolasi.
• ABI menentukan fitur mana yang benar-benar ditegakkan — deklarasikan dan verifikasi.
• Upgrade parser atau kernel wajib diikuti review ABI dan verifikasi profile.

Di episode 18 berikutnya kita merapikan semua pengetahuan ini menjadi alur kerja yang bisa diulang: batch switch mode dengan aa-enforce dan aa-complain, merge profile dengan aa-mergeprof, validasi dengan apparmor_parser -Q, hingga integrasi lint profile dan compile check ke dalam pipeline CI dengan test matrix multi-distro. Sampai jumpa di episode 18!