Manage SELinux/AppArmor policies

I need the SELinux and AppArmor rules tightened for our web servers in production because last week a permitted but unnecessary write to /var/www allowed a partner script to overwrite files. Update policies so the nginx process can only read and write its own content directories and may not execute new binaries from /var/www. Test on web-prod-03 first, then apply to web-prod-01 and web-prod-02 if nothing breaks. Confirm with an ls -Z and aa-status output before and after, and schedule a one-hour maintenance window on Thursday at 02:00.

Before I roll these policy changes to the team, make them easy to approve and audit: show the exact AVC denials we’re preventing, surface the one-line risk reduction summary up top, list the files and paths that will lose write access, and flag any change that will require pkexec or reboot. Produce the minimal policy snippets for selinux and apparmor and include a short rollback plan that restores the previous module or profile within five minutes.

I added a SELinux module to block unexpected writes to /var/www and pushed it to web-prod-03; the service started, but requests for /static/images return 403. I don’t know whether the denial is because of file context, an exec transition, or AppArmor overlapping rules; the site must be up for a marketing campaign at 09:00. What is the most likely cause and the fastest safe fix to restore image delivery while keeping the write-protection in place?

Over the last six months we repeatedly push tightened SELinux/AppArmor rules, then revert them after we break something in production and spend hours chasing AVC logs. I want to stop this pattern. Which change to our process or habit will reduce these emergency rollbacks most effectively: stricter policy development workflow, mandatory targeted canaries, expanded local QA on identical image, or a cross-team precommit review? Recommend one primary habit to adopt and one quick metric to prove it’s working.