AppArmor rules don't allow podman kill -s HUP container to succeed

[cboylan]

AppArmor 4.0 added new profiles for crun, runc, and podman which required extra AppArmor rules be created. This was originally reported in #1898 and fixed by @NeilW in #2004. This fix was sufficient for common tasks like shutting down containers, but commands like podman kill -s HUP container continue to fail with errors like:

ERRO[0000] unable to signal init: permission denied     
Error: sending signal to container c4b8fdcd6af2f79cfb8fe64223c60f4282a36359add7844f181b45cac24dc46c: `/usr/bin/runc kill c4b8fdcd6af2f79cfb8fe64223c60f4282a36359add7844f181b45cac24dc46c 1` failed: exit status 1

Inspecting AppArmor logs we see DENIED messages like:

kernel: audit: type=1400 audit(1739296150.596:141): apparmor="DENIED" operation="signal" class="signal" profile="containers-default-0.57.4-apparmor1" pid=35666 comm="runc" requested_mask="receive" denied_mask="receive" signal=hup peer="podman"

In the discussion for #2004 it seems like it was acknowledged that podman kill could send any signal; however, my read on that PR was that the rules were set to allow this to succeed. I'm filing this bug since experimentally this seems to not be the case.

Some other notes: I am using Ubuntu Noble's podman package (version 4.9.3+ds1-1ubuntu0.2). The prior issue was raised in https://bugs.launchpad.net/ubuntu/+source/libpod/+bug/2040483 and fixed upstream as part of the distro fixups to correct the original problem which is why I'm reporting the issue here first. Using kill(1) against the pid reported by podman inspect --format '{{ .State.Pid }}' container seems to work. And finally, we've got podman set up as the backend for docker compose using DOCKER_HOST set to the podman socket path. When we issue a docker compose down I also see kernel audit logs recording a DENIED signal=usr1 message (the rest of the message appears equivalent to the HUP message above). The docker compose down does eventually successfully stop and remove the container, but there may be other affected signals.

[cboylan]

Looks like this was already reported on the Ubuntu side in https://bugs.launchpad.net/ubuntu/+source/libpod/+bug/2089664 and a proposed fix in #2228