Hak akses di Linux menjawab pertanyaan «siapa yang boleh membaca berkas ini». AppArmor menjawab pertanyaan lain: «program ini sebenarnya boleh melakukan apa». Perbedaannya terlihat saat pembobolan. Sebuah web shell berjalan sebagai pengguna server web dan mewarisi seluruh haknya — yakni akses baca ke lebih dari separuh sistem. Profil AppArmor membatasi proses pada daftar hal yang ia perlukan untuk bekerja, dan upaya membaca /etc/shadow atau menjalankan /bin/bash berakhir dengan penolakan terlepas dari hak si pengguna.

Apa yang sudah aktif

sudo aa-status

Keluarannya menjawab tiga pertanyaan: berapa profil yang dimuat, berapa di antaranya dalam mode enforce dan complain, dan proses mana yang berjalan tanpa profil sama sekali. Pada Ubuntu biasa akan ada beberapa lusin profil, tetapi hampir semuanya milik program pendukung seperti man dan tcpdump. Layanan utama — nginx, Apache, PHP-FPM — biasanya tidak ada dalam daftar yang dibatasi.

Tiga mode yang perlu dibedakan:

  • enforce — aturannya diterapkan, semua yang berlebih ditolak;
  • complain — pelanggaran hanya dicatat di jurnal, tidak ada yang diblokir. Mode untuk penyetelan;
  • unconfined — tidak ada profil, programnya berjalan tanpa pembatasan.

Bagian paling berguna dari keluaran aa-status adalah yang terakhir: proses yang mendengarkan di jaringan dan tidak dibatasi apa pun. Itulah daftar yang harus jadi titik mulai.

Perkakasnya

sudo apt install apparmor-utils

Tanpa paket itu perintah aa-complain, aa-enforce dan aa-logprof tidak ada di sistem, meskipun AppArmor sendiri berjalan.

Cara menyalakan profil tanpa menghentikan layanan

Urutannya bersifat mendasar. Sebuah profil yang langsung dipindahkan ke enforce dengan kemungkinan besar akan menolak sesuatu yang diperlukan layanan, dan layanannya berhenti bekerja — biasanya tidak seketika, melainkan pada suatu operasi langka seperti mengunggah berkas atau mengirim surat.

Urutan yang benar:

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

Sepekan bekerja dalam mode itu, mencakup setiap skenario yang tidak biasa: membuat cadangan, pembaruan, mengunggah berkas besar. Lalu telusuri apa yang terkumpul:

sudo aa-logprof

Perintah ini menelusuri pelanggaran yang tercatat dan menanyai satu per satu apakah akan diizinkan. Di sini perlu perhatian: izinkan apa yang memang bagian dari pekerjaan layanan, bukan semua yang terlihat — kalau tidak Anda akan mendapat profil yang mengizinkan segalanya, dan maknanya hilang.

Dan baru kemudian:

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

Di mana melihat penolakannya

Semua pelanggaran masuk ke jurnal kernel:

sudo journalctl -k | grep -i apparmor
sudo grep 'apparmor="DENIED"' /var/log/audit/audit.log

Berkas kedua ada kalau auditd terpasang — dan dengannya catatannya jauh lebih rinci. Sebuah catatan penolakan menunjukkan nama profil, operasi yang diminta dan jalur yang diakses; itu sudah cukup untuk tahu apakah profilnya perlu diperbaiki atau justru patut disyukuri karena ia menyala.

Ada satu gejala yang layak diingat: layanan berperilaku aneh — tidak bisa membaca konfigurasi, tidak bisa menulis ke direktori, tidak bisa membuka socket — sementara log miliknya sendiri menunjukkan galat «permission denied» padahal hak aksesnya jelas benar. Itu hampir selalu AppArmor, dan hal pertama yang harus dilakukan adalah melihat di jurnal kernel.

Tindakan praktis, bukan teoretis

Sebuah profil untuk PHP-FPM atau nginx terbayar dengan cara yang sangat konkret. Ketika prosesnya dibatasi, sebuah web shell yang mencapai situs tidak bisa membaca berkas sistem, tidak bisa menjalankan shell, dan tidak bisa menulis apa pun di luar direktori yang diizinkan. Situs yang diretas tetap sekadar situs yang diretas alih-alih berubah menjadi akses ke seluruh mesin — dan justru peralihan itulah yang menyumbang sebagian besar kerugian.

Urutan penerapan yang masuk akal: pertama profil untuk apa pun yang menghadap internet (server web, PHP-FPM), lalu untuk basis data, lalu sesuai kebutuhan. Tidak perlu menyalakan semuanya sekaligus, dan tidak ada himpunan siap pakai yang universal: profil bergantung pada di mana berkas Anda berada.

Apa yang perlu diperiksa secara berkala

Profil kembali ke unconfined lebih sering daripada yang dikira: pembaruan paket bisa mengganti berkas profil, penelusuran galat manual meninggalkan layanan di complain, dan layanan baru datang tanpa profil sama sekali. Dua angka berguna: berapa profil yang ada di enforce, dan berapa proses yang menghadap jaringan yang masih unconfined. Perubahan pada salah satunya layak diketahui. Bagaimana tampilannya ketika dikumpulkan pada satu halaman — lihat di demo bawah.