AppArmor

Lists all currently loaded profiles and shows the count of enforce / complain mode entries.

sudo aa-status

aa-enforce switches the profile to enforce mode, actually blocking accesses that violate the rules. The argument is the profile path or binary path.

sudo aa-enforce {profile path or binary path}

aa-complain switches the profile to complain mode (learning mode). Rule-violating accesses are allowed but logged to syslog / audit. Used to test and tune new profiles.

sudo aa-complain {profile path or binary path}

aa-disable completely disables the profile. No AppArmor restrictions are applied.

sudo aa-disable {profile path or binary path}

After editing a profile file, reload it into the kernel with apparmor_parser -r (-r: reload). Use -R to unload the profile (-R: remove). Use --replace --write-cache to reload and also update the cache.

sudo apparmor_parser -r {profile path}
sudo apparmor_parser -R {profile path}
sudo apparmor_parser --replace --write-cache {profile path}

aa-genprof interactively creates a profile while the application is running, collecting activity logs in AppArmor learning mode.

sudo aa-genprof {binary path}

aa-logprof updates profiles based on AppArmor deny / complain log entries in /var/log/syslog or /var/log/audit/audit.log. Used during aa-genprof or to tune profiles after complain mode operation.

sudo aa-logprof

Profiles are stored in /etc/apparmor.d/. The naming convention is to replace / in the path with . (e.g., /usr/sbin/nginx → usr.sbin.nginx). Symbolic links to profiles disabled with aa-disable are placed in /etc/apparmor.d/disable/.

Command	Description
aa-status	Lists all loaded profiles and shows the enforce / complain mode counts. Run this first to get an overview of the current AppArmor state.
aa-enforce {profile}	Switches the specified profile to enforce mode. Accesses that violate the rules are actually blocked.
aa-complain {profile}	Switches the specified profile to complain mode (learning mode). Violations are allowed but logged.
aa-disable {profile}	Completely disables the profile. No AppArmor restrictions are applied.
apparmor_parser -r {profile}	Reloads the profile into the kernel after editing the profile file. -r stands for replace.
apparmor_parser -R {profile}	Unloads the profile from the kernel.
aa-genprof {binary}	Interactively generates a profile while the application is actually running. Use this as the starting point for creating a new profile.
aa-logprof	Interactively updates profiles based on AppArmor entries in the syslog / audit log. Used to tune profiles after operating in complain mode.
/etc/apparmor.d/	Directory where profile files are stored. The convention is to name files by replacing / in the binary path with ..
/etc/apparmor.d/disable/	Directory where symbolic links to profiles disabled with aa-disable are placed.
systemctl reload apparmor	Reloads the AppArmor service and re-applies all profiles to the kernel.
systemctl status apparmor	Checks the running state of the AppArmor service itself.

Checking and enabling a profile

Check whether AppArmor is running and which profiles are in enforce / complain mode.

$ sudo aa-status
apparmor module is loaded.
63 profiles are loaded.
61 profiles are in enforce mode.
   /usr/bin/evince
   /usr/sbin/nginx
   ...
2 profiles are in complain mode.
   /usr/local/bin/akane
   /usr/local/bin/ginoza
3 processes have profiles defined.
3 processes are in enforce mode.
   /usr/sbin/nginx (1842)
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.

Run in complain mode first to verify there are no issues. Rule violations are logged without blocking the process. After operating the application to collect logs, tune the profile with aa-logprof, then switch to enforce mode.

$ sudo aa-complain /usr/local/bin/akane
$ sudo aa-logprof
$ sudo aa-enforce /usr/local/bin/akane
$ sudo aa-status | grep akane
   /usr/local/bin/akane

Creating a custom profile

Running aa-genprof starts AppArmor monitoring in complain mode. Run the application in a separate terminal to exercise all files and network resources it accesses, then in the original terminal press [S]can → specify [A]llow/[D]eny → [F]inish to save the profile.

$ sudo aa-genprof /usr/local/bin/ginoza
$ cat /etc/apparmor.d/usr.local.bin.ginoza
# Last Modified: Wed Mar 25 10:00:00 2026
#include <tunables/global>

/usr/local/bin/ginoza {
  #include <abstractions/base>
  #include <abstractions/nameservice>

  /usr/local/bin/ginoza mr,
  /var/log/psychopass/ r,
  /var/log/psychopass/** rw,
  /etc/psychopass/config.json r,
  network inet stream,
}

Edit the profile, then reload it into the kernel (no service restart needed). Switch to enforce mode to start production operation.

$ sudo nano /etc/apparmor.d/usr.local.bin.ginoza
$ sudo apparmor_parser -r /etc/apparmor.d/usr.local.bin.ginoza
$ sudo aa-enforce /usr/local/bin/ginoza
$ sudo aa-status | grep ginoza
   /usr/local/bin/ginoza

'AppArmor' is a Mandatory Access Control system implemented on top of the Linux kernel's LSM (Linux Security Module) framework. It has been included by default in all Ubuntu-based distributions since Ubuntu 7.10. By associating a "profile" with each process, it restricts the files, directories, network resources, and capabilities that process can access, following the principle of least privilege. It acts as a containment layer that prevents damage from spreading system-wide when a resident process such as a web server or DNS server is compromised.

Compared to SELinux, another MAC framework, AppArmor writes policies based on file paths, making configuration relatively straightforward and lowering the barrier to adoption in Ubuntu-based environments. SELinux, on the other hand, uses a label-based approach (tied to inodes), which means policies continue to follow files even after they are moved or copied. SELinux is the default on RHEL and AlmaLinux-based systems; see the SELinux page for details. AppArmor deny logs are recorded by auditd and in /var/log/syslog. For investigating rule violations, aa-logprof reads the logs automatically and interactively suggests profile corrections, so a workflow of gradually transitioning to enforce mode while using complain mode is a common approach.