Break/Fix 7: AppArmor denial blocks a container from reading /etc/hosts

Reported symptoms

●Container exits immediately with `apparmor=DENIED` in journald.
●`docker logs` shows `Permission denied` for a file that should be readable.
●Restart loop begins.

Evidence

· `sudo journalctl -k --since "5 min ago" | grep DENIED`
· `sudo aa-status` shows the docker-default profile.
· `dmesg | grep -i apparmor`

Diagnosis and resolutionclick to reveal

Root cause

AppArmor is denying an operation the container expects to perform. Common offenders: read access to non-standard host paths, capability use that the profile does not allow, network operations on unusual sockets.

Remediation

Either run the container without the AppArmor profile (`--security-opt apparmor=unconfined`), or add a custom profile that grants the needed access. For development, the former; for production, the latter.

Verification

Container starts and runs as expected. `docker logs` no longer reports permission errors. `journalctl -k` no longer shows DENIED.

Prevention

Test images under the production AppArmor profile before shipping. Bake a custom profile into the image when the default is too restrictive. Document any profile changes in the runbook.

Diagnosis

sudo journalctl -k --since "5 minutes ago" | grep -i 'apparmor.*DENIED'

Look for apparmor="DENIED" followed by operation=... and name=....

Fix

For development / debugging:

docker run --security-opt apparmor=unconfined myorg/app:1.0.0

For production, author a profile:

sudo apt-get install -y apparmor-utils

Create /etc/apparmor.d/docker.myorg-app:

#include <tunables/global>

profile docker.myorg-app flags=(attach_disconnected,mediate_deleted) {
  #include <abstractions/base>
  #include <abstractions/nameservice>
  /usr/local/bin/app mr,
  /etc/myorg/** r,
  deny capability sys_admin,
}

Load:

sudo apparmor_parser -r /etc/apparmor.d/docker.myorg-app

Apply:

docker run --security-opt apparmor=docker.myorg-app myorg/app:1.0.0