Belajar AppArmor - Securing Sensitive Data & Paths

#Pendahuluan

Di episode 12 kalian mengecilkan permukaan serang dengan deny eksekusi dan binary setuid. Tapi ada dimensi kedua dari konfinasi yang sama pentingnya: data. Sebuah daemon boleh saja tidak bisa mengeksekusi shell, tapi jika ia bisa membaca /etc/shadow atau key pribadi, ia tetap menjadi lubang kebocoran yang fatal ketika berhasil dieksploitasi.

AppArmor memberi kalian kendali halus atas akses baca-tulis file. Episode ini tentang melindungi data: deny akses ke path sensitif, menyusun profile untuk daemon yang secara sah menyentuh data sensitif, dan memastikan setiap data hanya bisa ditulis ke lokasi yang benar.

#Mengapa Path Sensitif Butuh Perlindungan Eksplisit

Bayangkan server sebagai kantor dengan brankas. /etc/shadow adalah kunci master, ~/.ssh adalah lemari kunci, dan key store adalah brankas dokumen penting. DAC (permission biasa) sudah membatasi siapa yang boleh membuka brankas, tapi AppArmor menambah lapisan yang berbeda: ia membatasi proses, bukan sekadar user. Sebuah daemon yang berjalan sebagai root secara teknis bisa membaca semua file — kecuali profile AppArmor-nya secara eksplisit melarangnya.

Inilah kekuatan deny rule untuk data: proses yang seharusnya tidak pernah menyentuh data tertentu, tidak akan pernah menyentuhnya, seberapa tinggi pun privilege-nya. Dan karena deny menang atas allow, larangan ini tetap berlaku meskipun abstractions atau aturan lain memberi izin.

#Deny Akses ke File Kredensial Sistem

File yang menyimpan kredensial sistem — shadow, passwd, gshadow beserta file backup-nya — hanya boleh dibaca oleh program yang benar-benar membutuhkannya, biasanya hanya proses autentikasi. Semua daemon lain sebaiknya mendapat aturan deny eksplisit. Mulailah dengan mengecek profil mana yang sudah dimuat lewat aa-status, lalu tambahkan deny untuk daemon yang seharusnya tidak pernah menyentuh file-file ini:

Deny file kredensial sistem

deny /etc/shadow rw,
deny /etc/shadow- rw,
deny /etc/gshadow rw,
deny /etc/gshadow- rw,
deny /etc/security/opasswd rw,

Perhatikan file berekstensi - seperti /etc/shadow-: itu backup yang dibuat tool seperti vipw. Memori jangka pendek mudah menebak memblokir /etc/shadow, tapi lupa backup-nya — padahal attacker yang teliti justru mencari file backup yang izinnya lebih longgar. Blokir keduanya.

#Melindungi Direktori SSH dan Key Store

~/.ssh dan direktori tempat key pribadi disimpan adalah target paling berharga kedua. Private key di /root/.ssh, @{HOME}/.ssh, /etc/ssl/private, atau /etc/kubernetes/pki membuka pintu ke sistem lain. Untuk daemon yang tidak pernah melakukan koneksi SSH atau memegang key, deny seluruh direktori:

Deny direktori SSH dan key store

deny @{HOMEDIRS}/*/.ssh/** r,
deny /root/.ssh/** r,
deny /etc/ssl/private/** r,
deny /etc/kubernetes/pki/** r,
deny /var/lib/mysql/** rw,
deny /root/.gnupg/** r,

Aturan deny /var/lib/mysql/** rw di atas patut dicermati: sebuah daemon web tidak pernah butuh membaca basis data MySQL secara langsung — itu tugas aplikasi itu sendiri. Deny ini melindungi data MySQL dari proses lain yang di-exploit. Pola yang sama berlaku untuk key store lain: /etc/openvpn/, /etc/letsencrypt/live/, dan direktori secret yang di-mount ke container (kembali ke episode 10).

#Profile untuk Daemon yang Menyentuh Data Sensitif

Tidak semua daemon harus ditolak dari data sensitif. Daemon yang secara sah menanganinya — misalnya agen backup, agen rotasi secret, atau service yang membaca sertifikat — perlu profile yang disusun dengan prinsip berbeda: beri akses minimal yang pas, dan hanya untuk apa yang menjadi tugasnya.

Profile daemon dengan data terbatas

profile myapp /usr/sbin/myapp {
  #include <abstractions/base>
 
  /usr/sbin/myapp mr,
  /etc/myapp/ r,
  /etc/myapp/** r,
 
  /var/lib/myapp-data/ r,
  /var/lib/myapp-data/** r,
 
  /var/run/myapp/ rw,
  /var/log/myapp.log w,
 
  deny /etc/shadow rw,
  deny /etc/shadow- rw,
  deny @{HOMEDIRS}/*/.ssh/** r,
  deny /root/.ssh/** r,
  deny /etc/ssl/private/** r,
  deny /var/lib/mysql/** rw,
  deny /tmp/** w,
}

Perhatikan pola di atas:

• Konfigurasi dan data dibaca read-only (r), bukan rw. Jika daemon hanya membaca data, beri hanya r — modifikasi tidak perlu, jadi tidak diizinkan.
• Area yang boleh ditulis dipersempit ke dua tempat: direktori runtime (/var/run/myapp/) dan log. Tidak ada izin menulis di tempat lain.
• deny /tmp/** w mencegah daemon menulis file sementara di lokasi yang bisa dibaca semua user — mencegah skenario symlink race dan tempat persembunyian payload.
• Aturan deny eksplisit menjadikan niat keamanan terlihat jelas, sekaligus menjadi pengaman jika abstractions di masa depan mengizinkan akses ke path sensitif.

#Memaksa Read-Only untuk Data

Di atas kalian sudah melihat satu idiom penting: akses baca tanpa tulis. AppArmor membedakan r (read) dan w (write) secara terpisah, sehingga "read-only" bukan sekadar niat — ia ditegakkan kernel. Manfaatkan untuk seluruh data yang hanya boleh dibaca:

• File sertifikat dan konfigurasi: r, jangan pernah rw.
• Basis data yang diakses hanya oleh satu daemon: r plus k untuk lock jika diperlukan.
• Backup yang diambil dari file produksi: akses r dari sisi pembaca backup, rw hanya untuk proses yang menulis.

Jika kalian menemukan denial write yang tidak diharapkan, jangan langsung menambahkan w — tanyakan dulu mengapa daemon menulis ke sana. Sering kali jawabannya adalah path yang salah atau bug aplikasi, dan deny write justru menyelamatkan data dari korupsi. Untuk menyelidiki penyebabnya, gunakan aa-logprof sebagai panduan saat meninjau setiap entri deny.

#Verifikasi Setelah Enforce

Setelah profile dipasang dalam mode enforce, jangan berasumsi — verifikasi. Cara paling cepat adalah memicu denial dengan benar-benar memanggil akses yang dilarang dari konteks aplikasi, lalu memeriksa log. Untuk memastikan profile benar-benar dimuat dalam enforce, mulai dari aa-status:

sudo aa-enforce /usr/sbin/myapp
sudo systemctl restart myapp
sudo journalctl -k --grep=apparmor | tail -20

Setiap akses yang dilarang akan muncul sebagai event apparmor="DENIED" dengan nama profile, operasi, dan path yang diblokir. Dari sini kalian bisa memastikan dua hal: deny bekerja, dan tidak ada deny lain yang memblokir fungsi sah aplikasi. Jika ada deny sah yang muncul, kembalilah ke siklus complain menuju enforce dari episode 12 untuk memperbaikinya dengan disiplin.

#Penutup

Pada episode ini kalian telah melindungi data dari dua arah: deny eksplisit untuk path sensitif seperti /etc/shadow, ~/.ssh, dan key store — sehingga proses yang tidak berhak tidak akan pernah menyentuhnya — serta profile untuk daemon yang sah menangani data sensitif, dengan prinsip read-only untuk data, area write yang disempitkan, dan verifikasi denial setelah enforce.

Inti yang harus kalian bawa:

• Aturan deny untuk data melindungi proses dari dirinya sendiri, seberapa tinggi pun privilege-nya.
• Blokir juga file backup dan direktori turunan, bukan hanya file utamanya.
• Daemon yang menyentuh data sensitif dapat profile minimal: r untuk baca, area kecil untuk write.
• Read-only adalah keputusan yang ditegakkan kernel, bukan sekadar konvensi.
• Verifikasi deny dengan memicu akses dan membaca log.

Di episode 14 berikutnya kita membalik pandangan dari konfigurasi menuju perangkat lunaknya: sejauh apa AppArmor sendiri pernah rapuh — riwayat CVE dan regresi seperti kasus parser 4.1.0 di Debian — dan bagaimana strategi patch yang benar menjaga konfinasi tetap nyata, bukan sekadar kepercayaan. Sampai jumpa di episode 14!