** Description changed: [ Impact ] apparmor denies signals from runc, making stopping containers (a basic/core feature of most container runtimes) infeasible. [ Test Plan ] A basic case would include running a container and trying to stop it as described in the podman SRU testplan in LP: #2040483. Here, let's use a container from docker hub which is known to run in the foreground and capture SIGINTs (CTRL + c) to terminate its process docker.io/library/redis:alpine. For docker, run # docker run docker.io/library/redis:alpine wait for the process to start in the foreground, you will see the following message: 1:M 25 Oct 2024 00:54:48.415 * Ready to accept connections tcp Then try to terminate the process by sending a single SIGINT by pressing CTRL+c. You will verify that, in affected systems, the process will not be terminated. You will also see the following message in dmesg's output: [Fri Oct 25 00:56:53 2024] audit: type=1400 audit(1729817813.238:144): apparmor="DENIED" operation="signal" class="signal" profile="docker- default" pid=1757 comm="runc" requested_mask="receive" denied_mask="receive" signal=int peer="runc". For containerd, run # ctr images pull docker.io/library/redis:alpine # ctr run --apparmor-default-profile="ctr-test" docker.io/library/redis:alpine redis wait for the process to start in the foreground, you will see the following message: 1:M 25 Oct 2024 00:54:48.415 * Ready to accept connections tcp Then try to terminate the process by sending a single SIGINT by pressing CTRL+c. You will verify that, in affected systems, the process will not be terminated. Moreover, you should see the following error message on the screen: ERRO[0091] forward signal interrupt error="unknown error after kill: runc did not terminate successfully: exit status 1: unable to signal init: permission denied\n: unknown". You will also see the following message in dmesg's output: [ 157.340083] audit: type=1400 audit(1729822489.388:130): apparmor="DENIED" operation="signal" class="signal" profile="ctr-test" pid=1245 comm="runc" requested_mask="receive" denied_mask="receive" signal=int peer="runc" Also note that the containerd API allows custom apparmor profile names. Hence, a fix containing a name change to the apparmor profile (as the one seen in the podman fix for this same issue) is not feasible. In fixed systems (for both docker and containerd), the "ctrl+c" command in the scenarios above will terminate the process and the error messages described above will not be present. Note that after a package upgrade, the system need to be restarted so the fixed apparmor profiles are loaded. + Moreover, before restarting the system, do verify if a system reboot + hint was added by running: + + # cat /run/reboot-required.pkgs + + and verifying that "containerd" is present in the output. + [ Where problems could occur ] The fixes here are bundled in new upstream releases as per the exceptions in place. There are risks of regression which should be dealt with in a case-by-case fashion. [ Other Info ] This is part of the regular container stack MREs as described in https://bugs.launchpad.net/ubuntu/+source/haproxy/+bug/2028418 This is the docker/containerd counterpart of the fix released for podman in LP: #2040483
-- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2065423 Title: Update AppArmor template to allow confined runc to kill containers To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/containerd-app/+bug/2065423/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
