Learn AppArmor - Desktop & System Services

#Introduction

For ten episodes, you've been securing servers and containers — the side of the system we usually focus on as engineers. But AppArmor was born for the whole system, including the machines you use every day: browsers, office suites, applications installed via snap, and the system services that keep a distro running. Episode 11 closes this domain and prepares you to handle a complete system.

#Desktop Applications: Firefox and LibreOffice

Desktop applications are far more demanding than server daemons: they read user configuration in @{HOME}, write caches, open files from any directory, and communicate with the graphical session. Profiles for desktop applications must balance restriction with everyday usability.

An example profile for a browser:

A home-based browser profile

#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,
}

Notice the same pattern as servers: abstractions handle DNS and the graphical session, owner limits access to the user's own files, and wildcards cover entire cache directories. Browsers genuinely need a lot of access — which is why an overly strict profile just breaks browsing. The principle stays the same: start strict, loosen based on the denials that appear (episode 7), not the other way around.

#Snap: Auto-generated Profiles

Applications installed via snap (including Firefox on modern Ubuntu) run in an isolated environment, and snapd is what creates its isolation configuration — including an AppArmor profile generated automatically per application:

/var/lib/snapd/apparmor/profiles/
  snap.firefox.firefox
  snap.firefox.firefox-apparmor
  snap.discord.discord

These profiles are loaded into the kernel at boot, or when a snap is installed/updated. An important consequence: don't edit them. These files are regenerated every time the snap is updated, and the fix isn't manual editing — it's the snap interfaces. See which interfaces a snap is using:

snap connections firefox

If a snap application needs new access — for example to the home directory — connect the appropriate interface:

sudo snap connect firefox:home

The rule of thumb: you manage snap configuration through snap connections, not through its AppArmor profile.

#Flatpak: Sandbox Without AppArmor

Flatpak takes a different route: it uses Bubblewrap — a Linux namespace-based sandbox — and by default doesn't depend on AppArmor for its basic confinement. As an operator, the impact is: when you see AppArmor denials from a flatpak application, the cause is usually a system profile interacting with its helper processes, not the flatpak sandbox itself. Prioritize understanding the flatpak configuration, then handle the remaining AppArmor denials in the usual way.

#Profile Conflicts During Updates

This is the classic trap that frustrates admins: a profile you painstakingly customized suddenly reverts — or even blocks a service — after a package update. Distributions overwrite profile files when updating the related package, and your changes vanish without a trace.

The right pattern to survive updates:

• Distributions provide a local/ directory for overrides. Built-in profiles usually include it: #include <local/usr.sbin.nginx>. Keep your customizations there, not in the main file.
• Store your own custom profiles in a separate directory like /etc/apparmor.d/custom/, and include them in the load mechanism (or symlink them).
• After every system upgrade, check aa-status and diff the profile files that changed before restarting services.

#System Services: Networking, DBus, and systemd

The last screen is the core system services. Built-in profiles cover many daemons: usr.sbin.NetworkManager for networking, usr.sbin.dbus-daemon for inter-process communication, and various other daemons depending on the distro. For DBus in particular, AppArmor has dedicated mediation through the dbus rule inside a profile:

A dbus rule inside a profile

dbus send bus=session path=/org/freedesktop/Notifications peer=(label=firefox),

This rule restricts which messages a process can send to the bus — an extra authorization layer on top of ordinary socket control.

For services run by systemd, a profile can be attached directly from the unit file using the AppArmorProfile directive:

A systemd unit with AppArmorProfile

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

When the unit starts, systemd asks the kernel to attach the myapp-profile to that service's process. This keeps the AppArmor configuration recorded in the same place as the service definition — and managed by the systemd unit rather than by a separate script.

#Conclusion

In episode 11 you've secured the final layer: desktop applications with @{HOME}-based profiles for Firefox and LibreOffice, auto-generated snap profiles managed through interfaces (not manual edits), Bubblewrap-based flatpak sandboxes, the pattern for surviving profile conflicts during updates by using the local/ directory, and system services — the dbus rule, built-in daemon profiles, and the AppArmorProfile directive in systemd units.

Keys to take home:

• Don't edit auto-generated profiles — manage them through interfaces or official config.
• Keep customizations in local/ so they survive updates.
• systemd can attach a profile directly from a unit file.

Now you've confined hosts, containers, and desktops. But building profiles is only half the story — the rest is keeping them lean. In episode 12, we cover Attack Surface Reduction & Policy Refinement: measuring the attack surface, removing unused rules, tightening overly loose profiles, and making refinement an ongoing process rather than a one-off project.