Context
An application moves its data directory and starts receiving permission errors even after ordinary ownership is correct. AppArmor may be restricting the executable through a path-based security profile. The useful starting point is the exact denied operation and loaded profile, not a system-wide policy change.
Have the application owner identify the expected directory, executable and legitimate action. Collect a reproducible test using harmless data and know the installed Ubuntu and AppArmor versions. Profile syntax and distribution integration can differ. You need read access to status and audit evidence; changing enforcement policy requires the normal configuration-change process.
Connect behavior to a profile
- Run
sudo aa-statusto identify loaded profiles and their modes. Confirm whether the actual worker executable is confined. A profile file on disk does not prove that its current contents are loaded, and an unconfined parent can launch a confined child. Record the program path and profile name rather than assuming the package name identifies both. - Reproduce one expected operation and inspect relevant kernel audit messages around that timestamp, for example through
journalctl -k --since '-10 min'where supported. Look for the profile, operation, requested mask and denied path. Sanitize customer filenames before sharing. Separate the denial from an earlier missing file or conventional permission failure. - Inspect the profile's include structure. Many packaged profiles provide a site-specific file under
/etc/apparmor.d/local/, but the main profile determines which include is actually used. Review the relevant abstraction too. A narrow application path rule may already exist but refer to the old location, or the intended operation may be outside the application's approved purpose.
An illustrative path change
Suppose an illustrative image converter is approved to read originals under /srv/images/input and write results under /srv/images/output. A deployment starts requesting write access to the originals directory. Adding a broad /srv/** rw rule would hide the distinction between legitimate output and destructive source modification. The application owner must first decide whether the new write is necessary or a path-configuration mistake.
| Audit observation | Useful question | Appropriate direction |
|---|---|---|
| Read denied on new input path | Is this the intended source? | Review a precise read rule |
| Write denied on source files | Should originals be modified? | Correct application behavior if unintended |
| Profile file changed, denial unchanged | Was the intended profile loaded? | Inspect load result and include path |
| Multiple helper executables denied | Which subprocess needs access? | Trace each confined execution boundary |
Review and activate a narrow correction
Use aa-logprof only as an interactive review aid. Its suggestions come from observed activity; they do not establish that every request should be authorized. Preserve the current profile and local include, then review the precise path, file pattern and permission letters with the application owner. Avoid patterns that accidentally include private configuration or executable paths.
Validate and reload the affected profile using the distribution's documented procedure. Retest with enforcement active. Check the intended read or write operation, a disallowed neighboring path and a normal application workflow. If the change requires a temporary diagnostic mode, document its scope and restore the approved enforcing state before acceptance.
Maintain policy with deployments
Store site-specific policy in configuration management and check it when executable locations, storage paths or helper programs change. Monitor new denials by profile and operation, without treating every denied request as evidence for an allow rule. Document why the permission exists and who owns that decision. Clouvenix server hardening can help review policy alongside application deployment changes.
Technical reference
Ubuntu AppArmor operations and preserving local package policy changes.