Membawa AppArmor ke mesin desktop dan layanan sistem: profile browser dan office, integrasi snap dan flatpak, konflik profile saat update, serta layanan sistem seperti networking, DBus, dan unit systemd.

Selama sepuluh episode, kalian mengamankan server dan container — sisi sistem yang biasanya menjadi fokus kita sebagai engineer. Tapi AppArmor lahir untuk seluruh sistem, termasuk mesin yang kalian pakai sehari-hari: browser, office suite, aplikasi yang diinstall lewat snap, hingga layanan sistem yang membuat distro berjalan. Episode 11 ini menutup ranah tersebut dan mempersiapkan kalian menghadapi sistem lengkap.
Aplikasi desktop jauh lebih menuntut daripada daemon server: mereka membaca konfigurasi pengguna di @{HOME}, menulis cache, membuka file dari direktori mana pun, dan berkomunikasi dengan sesi grafis. Profile untuk aplikasi desktop harus menyeimbangkan pembatasan dengan kegunaan sehari-hari.
Contoh profile untuk browser:
#include <tunables/global>
profile firefox flags=(attach_disconnected) {
#include <abstractions/base>
#include <abstractions/nameservice>
#include <abstractions/X11>
network inet tcp,
network inet6 tcp,
/usr/bin/firefox mr,
/usr/lib/firefox/** mr,
owner @{HOME}/.mozilla/** rw,
owner @{HOME}/Downloads/** rw,
/tmp/** rw,
}Perhatikan pola yang sama dengan server: abstractions menangani DNS dan sesi grafis, owner membatasi akses ke file milik pengguna sendiri, dan wildcard menutup seluruh direktori cache. Browser memang membutuhkan banyak akses — itulah kenapa profile yang terlalu ketat justru membuat browsing rusak. Prinsipnya tetap sama: mulai ketat, longgarkan berdasarkan denial yang muncul (episode 7), bukan sebaliknya.
Note
Di banyak distribusi, Firefox dan LibreOffice tidak dibundel dengan profile AppArmor aktif — konfinasinya diserahkan ke mekanisme lain (lihat bagian snap dan flatpak). Jika kalian memakai paket .deb/.rpm biasa, memasang profile kustom seperti di atas adalah keputusan yang masuk akal, tapi siap-siap menyempurnakannya selama beberapa minggu pemakaian.
Aplikasi yang diinstall lewat snap (termasuk Firefox di Ubuntu modern) dijalankan dalam lingkungan terisolasi, dan snapd-lah yang membuat konfigurasi isolasinya — salah satunya berupa profile AppArmor yang di-generate otomatis per aplikasi:
/var/lib/snapd/apparmor/profiles/
snap.firefox.firefox
snap.firefox.firefox-apparmor
snap.discord.discordProfile ini dimuat ke kernel saat sistem boot atau saat snap diinstall/diupdate. Konsekuensi penting: jangan mengeditnya. File ini dibuat ulang setiap kali snap diupdate, dan perbaikannya bukan lewat edit manual, melainkan lewat interface snap. Lihat interface yang sedang dipakai sebuah snap:
snap connections firefoxJika aplikasi snap memerlukan akses baru — misalnya ke home directory — hubungkan interface yang sesuai:
sudo snap connect firefox:homeAturan praktisnya: kalian mengelola konfigurasi snap lewat snap connections, bukan lewat profile AppArmor-nya.
Flatpak mengambil jalur berbeda: ia memakai Bubblewrap — sandbox berbasis namespace Linux — dan secara default tidak bergantung pada AppArmor untuk konfinasi dasarnya. Sebagai operator, dampaknya adalah: bila kalian melihat denial AppArmor dari aplikasi flatpak, penyebabnya biasanya profile system yang berinteraksi dengan proses bantuannya, bukan sandbox flatpak itu sendiri. Prioritaskan memahami konfigurasi flatpak-nya, lalu tangani denial AppArmor yang tersisa dengan cara biasa.
Ini jebakan klasik yang membuat admin frustrasi: sebuah profile yang sudah disesuaikan dengan susah payah tiba-tiba kembali seperti semula — atau malah memblokir layanan — setelah pembaruan paket. Distribusi menimpa file profile saat meng-update paket terkait, dan perubahan kalian hilang tanpa jejak.
Pola yang benar untuk bertahan dari update:
local/ untuk override. Profile bawaan biasanya meng-include-nya: #include <local/usr.sbin.nginx>. Simpan penyesuaian kalian di sana, bukan di file utama./etc/apparmor.d/custom/, lalu sertakan ke mekanisme load (atau symlink).aa-status dan selisihkan file profile yang berubah sebelum merestart layanan.Warning
Upgrade sistem adalah momen paling rawan: profile baru bisa saja mengubah perilaku layanan yang sedang produksi. Kebiasaan yang menyelamatkan: lakukan upgrade di staging dulu, perhatikan profile apa yang berubah, lalu bandingkan dengan versi lama sebelum menerapkan di produksi.
Layar terakhir adalah layanan inti sistem. Profile bawaan menutupi banyak daemon: usr.sbin.NetworkManager untuk jaringan, usr.sbin.dbus-daemon untuk komunikasi antar proses, dan berbagai daemon lain sesuai distro. Khusus DBus, AppArmor punya mediasi khusus lewat aturan dbus di dalam profile:
dbus send bus=session path=/org/freedesktop/Notifications peer=(label=firefox),Aturan ini membatasi message yang bisa dikirim sebuah proses ke bus — lapisan otorisasi tambahan di atas kontrol socket biasa.
Untuk layanan yang dijalankan systemd, profile bisa dipasang langsung dari unit file menggunakan direktif AppArmorProfile:
[Unit]
Description=Layanan MyApp
[Service]
ExecStart=/usr/local/bin/myapp
AppArmorProfile=myapp-profile
[Install]
WantedBy=multi-user.targetSaat unit start, systemd meminta kernel memasang profile myapp-profile ke proses layanan tersebut. Ini membuat konfigurasi AppArmor tercatat di tempat yang sama dengan definisi layanan — dan ikut ter-manage oleh systemd unit, bukan oleh script terpisah.
Pada episode 11 ini kalian sudah mengamankan lapisan terakhir: aplikasi desktop dengan profile berbasis @{HOME} untuk Firefox dan LibreOffice, profile snap yang di-generate otomatis dan dikelola lewat interface (bukan edit manual), sandbox flatpak berbasis Bubblewrap, pola menghadapi konflik profile saat update dengan memakai direktori local/, serta layanan sistem — aturan dbus, profile daemon bawaan, dan direktif AppArmorProfile di unit systemd.
Kunci yang harus dibawa pulang:
local/ agar tidak hilang saat update.Sekarang kalian telah mengonfinasi host, container, dan desktop. Namun membangun profile hanyalah separuh cerita — sisanya adalah menjaganya tetap ramping. Di episode 12, kita membahas Attack Surface Reduction & Policy Refinement: mengukur permukaan serang, menghapus aturan yang tidak terpakai, mengetatkan profile yang terlalu longgar, dan menjadikan refinement sebagai proses berkelanjutan, bukan proyek sekali jalan.