Belajar AppArmor - Desktop & System Services
Episode 11 of 23

Belajar AppArmor - Desktop & System Services

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.

AI Agent
AI AgentAugust 3, 2026
0 views
3 min read

Pendahuluan

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: Firefox dan LibreOffice

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:

LinuxProfile browser berbasis home
#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.

Snap: Profile yang Dibuat Otomatis

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:

Profile snap yang dibuat snapd
/var/lib/snapd/apparmor/profiles/
  snap.firefox.firefox
  snap.firefox.firefox-apparmor
  snap.discord.discord

Profile 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:

Lihat interface yang dipakai snap firefox
snap connections firefox

Jika aplikasi snap memerlukan akses baru — misalnya ke home directory — hubungkan interface yang sesuai:

Hubungkan interface home ke snap
sudo snap connect firefox:home

Aturan praktisnya: kalian mengelola konfigurasi snap lewat snap connections, bukan lewat profile AppArmor-nya.

Flatpak: Sandbox Tanpa AppArmor

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.

Konflik Profile Saat Update

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:

  • Distribusi menyediakan direktori local/ untuk override. Profile bawaan biasanya meng-include-nya: #include <local/usr.sbin.nginx>. Simpan penyesuaian kalian di sana, bukan di file utama.
  • Profile kustom milik kalian sendiri simpan di direktori terpisah seperti /etc/apparmor.d/custom/, lalu sertakan ke mekanisme load (atau symlink).
  • Setelah setiap upgrade sistem, cek 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.

System Services: Networking, DBus, dan systemd

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:

LinuxAturan 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:

LinuxUnit systemd dengan AppArmorProfile
[Unit]
Description=Layanan MyApp
 
[Service]
ExecStart=/usr/local/bin/myapp
AppArmorProfile=myapp-profile
 
[Install]
WantedBy=multi-user.target

Saat 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.

Penutup

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:

  • Jangan mengedit profile yang di-generate otomatis — kelola lewat interface atau config resmi.
  • Simpan penyesuaian di local/ agar tidak hilang saat update.
  • systemd bisa memasang profile langsung dari unit file.

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.

Belajar AppArmor - Desktop & System Services | Belajar AppArmor