What to know
- This is a 2027 readiness plan based on current documented controls.
- Review one existing service profile in a staging environment.
- Enforce only after functional tests and keep a targeted rollback.
A readiness plan, reviewed in October 2026
This is planning guidance for 2027 using AppArmor capabilities already documented at publication. It does not announce a future operating-system release or a new vulnerability. The scope is an Ubuntu host with a service-specific profile available for review. Check the distribution’s installed manuals and package support before applying examples to another system.
Understand the current protection boundary
Ubuntu’s AppArmor guide describes program-specific mandatory access controls that supplement ordinary Unix permissions. Inspect the loaded state and recent kernel records:
sudo aa-status
sudo journalctl -k --since "1 hour ago" --no-pagerRecord which profile covers the service, whether it is enforcing and what the application actually needs to read or write. Protect captured logs because they may include user or file details. Do not assume that an installed AppArmor package means every application is confined.
Observe a selected profile in staging
Use a dedicated test copy and save the current profile. The aa-complain manual documents a mode that logs most policy violations instead of enforcing them; explicit deny rules still apply. For a service with an existing profile, replace the example executable path before use:
sudo aa-complain /usr/sbin/YOUR_PROFILED_SERVICEDo not run this against every profile or use it as a permanent production workaround. Exercise the real workload: startup, file access, uploads, scheduled work, log rotation and recovery. Review each denial against an actual requirement rather than automatically granting everything the log suggests.
Enforce and repeat the tests
After a narrow profile review, the aa-enforce manual describes returning that selected profile to enforcement:
sudo aa-enforce /usr/sbin/YOUR_PROFILED_SERVICE
sudo aa-statusRepeat the staging workload and investigate new denials. Schedule production rollout with a saved profile and a service-specific recovery plan. If a test fails, restore the reviewed profile or use the agreed temporary mode for that service while investigating; disabling AppArmor system-wide is not a targeted fix.
Turn the exercise into a 2027 maintenance task
Our suggested handover records profile owner, package version, tested paths, denial review and the date of the next check. Revisit after application upgrades that change file locations or behavior. Pair confinement with security updates, useful logs and a tested recovery route. These observable checks are a stronger readiness milestone than labeling a server “2027 secure.”
Sources & further reading
Primary sources supporting this article. The practical recommendations are Kiava’s general guidance and should be adapted to your project.