[pkg-apparmor] Bug#1100135: Bug#1100135: Conflict between Podman Profile and Pasta profile breaks rootless network shutdown

[intrigeri]

Hi Sam, Stefano, others,

(almost fully quoting because the Sam's original report Cc'ed
pasta at packages.debian.org, while I believe he meant to write to
passt at packages.debian.org)

Sam Hartman (2025-03-11):
> Recently I started running into the following error shutting down
> containers with podman stop:
>
> 	* rootless netns: kill network process: permission denied
>         This error is produced by
>         golang-github-containers-common/libnetwork/internal/rootlessnetns/netns_linux.go
>         in the cleanup function:
>         	if err := n.cleanupRootlessNetns(); err != nil {
> 		multiErr = multierror.Append(multiErr, wrapError("kill network process", err))
> 	}
>
> And that function effectively just finds and kills the pasta or
> slirp4netns process:
> 	if err == nil {
> 		// kill the slirp/pasta process so we do not leak it
> 		err = unix.Kill(pid, unix.SIGTERM)
> 		if err == unix.ESRCH {
> 			err = nil
> 		}
>
> Looking at my kernel logs, I see that
> [  462.337636] audit: type=1400 audit(1741711021.533:118): apparmor="DENIED" ope
> ration="signal" class="signal" profile="pasta" pid=4552 comm="exe" requested_mas
> k="receive" denied_mask="receive" signal=term peer="podman"
> In other words, apparmor is preventing podman from cleaning up pasta.
>
> Podman is effectively supposed to be unconfined:
> Quoting /etc/apparmor.d/podman:
> # This profile allows everything and only exists to give the
> # application a name instead of having the label "unconfined"
>
> Although it turns out it's not really true that  podman can do anything
> because it turns out that the base abstraction specifically special
> cases the unconfined profile:
> (quoting /etc/apparmor.d/base)
>
>   # Allow unconfined processes to send us signals by default
>   signal (receive) peer=unconfined,
>
>   # Allow us to signal ourselves
>   signal peer=@{profile_name},
>
>   # Checking for PID existence is quite common so add it by default for now
>   signal (receive, send) set=("exists"),
>
>
> So, in other words, podman could send the signal if it were in the
> unconfined profile, but cannot because it has a profile at all.

Thank you Sam for educating me! I did not remember we had these rules
for unconfined processes.

> There's clearly a race condition involved somewhere. Some of my
> containers exhibit this behavior, but some do not.
> However, once it starts happening, it keeps happening, and it is common
> enough that it is breaking a lot of automation.
>
>
>
> On the apparmor side, I'd like to either see the bogus/empty podman
> profile removed   or to see signals from podman permitted by the pasta
> profile.

Thank you Sam for having gone to great lengths to investigate the
problem you were experiencing, up to the point where you could propose
these solutions.

I agree we should do 1 of those.

I would prefer we modify the pasta profile to allow signals
from podman, for 2 reasons:

 - It'll be necessary on Ubuntu, where removing the podman profile is
   not an option. It's not needed *yet* solely because the profile is
   not included in the Ubuntu package, which I'm guessing is a mistake
   that will be fixed at some point
   (https://bugs.launchpad.net/ubuntu/+source/passt/+bug/2077158).
   So we can as well fix this proactively. And the fix should probably
   be upstreamed.

 - It's 1 tiny but still useful step towards being able to some day
   stop accepting signals from unconfined processes.

Stefano, what do you think?

I believe this (untested) rule should do the job:

  signal (receive) peer=podman,

If we don't do that, then I'm fine with removing the podman profile,
which has limited value anyway in the context of Debian.

Cheers,
-- 
intrigeri