AA-LOGPROF(8)

✨ NAME ✨

aa-logprof β€” bestie, this is THE utility for updating your AppArmor security profiles πŸ’…


🌸 SYNOPSIS 🌸

aa-logprof [-d  /path/to/profiles] [-f /path/to/logfile] [-m <mark in logfile>]

πŸŽ€ OPTIONS πŸŽ€

  • -d --dir /path/to/profiles β€” tells aa-logprof where to go look for the AppArmor security profile set. no flag? it defaults to /etc/apparmor.d, easy peasy 🫢
  • -f --file /path/to/logfile β€” points at the logfile holding your AppArmor security events. the default locations get read from /etc/apparmor/logprof.conf. the typical defaults are literally:
    • /var/log/audit/audit.log
    • /var/log/syslog
    • /var/log/messages
  • -m --logmark "mark" β€” aa-logprof will straight up ignore every event in the system log until it sees the mark you specified. heads up tho: if the mark has spaces in it, you must wrap it in quotes or it won't work correctly 🫠

πŸ’– DESCRIPTION πŸ’–

aa-logprof is an interactive tool, and its whole job is reviewing AppArmor generated messages and updating AppArmor security profiles. it's giving assistant energy honestly.

so when you run aa-logprof it scans the log file, and if there are new AppArmor events that your existing profile set isn't covering, you get prompted with suggested modifications to augment the profile. it's like "hey girl, you missed these, want me to add them?" ✨

when aa-logprof exits, profile changes get saved to disk. and if AppArmor is running, the updated profiles get reloaded, and if any processes that generated AppArmor events are still running in the null-complain-profile, those processes get set to run under their proper profiles. iconique behavior honestly πŸ‘‘


🌈 Responding to AppArmor Events 🌈

aa-logprof generates a list of suggested profile changes that you can choose from β€” or you can create your own β€” to modify the permission set of the profile so that the generated access violation will not re-occur. periodt.

then you get presented with info about the access, including the profile, the path, the old mode if there was a previous entry in the profile for this path, the new mode, the suggestion list, and given these options:

(A)llow, (D)eny, (I)gnore, (N)ew, (G)lob last piece, (Q)uit

if the AppArmor profile was in complain mode when the event was generated, the default for this option is (A)llow. otherwise, it's (D)eny. 🫑

  • the (D)eny option adds a "deny" rule to the AppArmor profile, which silences logging. quiet, calm, no more yapping πŸ’€
  • the (I)gnore option lets you ignore the event entirely, without making any changes to the AppArmor profile. not today, not ever πŸ™ˆ

the suggestion list comes at you as a numbered list, with includes at the top, the literal path in the middle, and the suggested globs at the bottom. if any globs are being suggested, the shortest glob is the selected option β€” otherwise, the literal path is selected. and picking includes from the list has to be done manually, so no shortcuts sorry bestie.

hitting a numbered key will change the selected option to the corresponding numbered entry in the list. numbers are your friends πŸ”’

if you select (N)ew, you'll be prompted to enter your own globbed entry to match the path. and if the glob you typed doesn't match the path for this event, you'll be informed and given the option to fix it. it's not judging you, it's just honest 🫢

if you select (G)lob last piece, then, taking the currently selected option, aa-logprof will remove the last path element and replace it with /*.

if the last path element already was /*, aa-logprof will go up a directory level and replace it with /**.

this new globbed entry then gets added to the suggestion list and marked as the selected option.

so like, /usr/share/themes/foo/bar/baz.gif can be turned into /usr/share/themes/** by hitting "g" three times. three taps, one glow-up ✨

if you select (A)llow, aa-logprof will take the current selection and add it to the profile, deleting other entries in the profile that are matched by the new entry.

for example, adding r access to /usr/share/themes/** would delete an entry for r access to /usr/share/themes/foo/*.gif if it exists in the profile. out with the old, in with the broad 🌸

if (Q)uit is selected at this point, aa-logprof will ignore all new pending accesses.

after all of the accesses have been handled, aa-logprof will write all updated profiles to the disk and reload them if AppArmor is running. that's the finale, bestie πŸŽ€


🌟 New Process (Execution) Events 🌟

if there are unhandled x accesses generated by the execve(2) of a new process, aa-logprof will display the parent profile and the target program that's being executed, then prompt you to select an execute modifier. these modifiers give you a choice for the target to:

  • have it's own profile (px)
  • inherit the parent's profile (ix)
  • run unconfined (ux)
  • deny access for the target

see apparmor.d(5) for details.

if there's a corresponding entry for the target in the [qualifiers] section of /etc/apparmor/logprof.conf, the presented list will contain only the allowed modes. no extra options, we keep it tight πŸ’…

the default option for this question gets selected using this logic:

# if px mode is allowed and profile exists for the target
#   px is default.
# else if ix mode is allowed
#   ix is default
# else
#   deny is default

and aa-logprof will never suggest "ux" as the default. not once, not ever, no cap 🚫


πŸ¦‹ ChangeHat Events πŸ¦‹

if unknown aa_change_hat(2) events are found, you get prompted to either:

  • add a new hat,
  • put the events into the default hat for this profile, based on the corresponding entry in the [defaulthat] section of logprof.conf,
  • or deny the following events that run under that hat altogether.

pick your fighter βš”οΈ


πŸ“ Capability Events πŸ“

if there are capability accesses, you get shown each capability access one by one and asked if the capability should be allowed, denied, or if you want to quit. see capability(7) for details. one at a time, very attentive, very thorough.


πŸ’€ BUGS πŸ’€

if you find any bugs (tragic, but it happens), please report them at <https://gitlab.com/apparmor/apparmor/-/issues>. the maintainers will love you for it 🫢


πŸ‘‘ SEE ALSO πŸ‘‘

klogd(8), auditd(8), apparmor(7), apparmor.d(5), aa_change_hat(2), logprof.conf(5), aa-genprof(1), aa-enforce(1), aa-complain(1), aa-disable(1), and <https://wiki.apparmor.net>. go read 'em, they're all part of the lore πŸ“šβœ¨


okay that's the whole page bestie!! this one's from AppArmor 6.0.0~alpha1, dated 2026-10-05, and it's the AA-LOGPROF(8) manual. mwah, go update those profiles πŸ’–πŸŽ€

πŸ“¦ where this page comes from