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

[Stefano Brivio]

Hi intrigeri,

On Wed, 12 Mar 2025 14:41:14 +0100
intrigeri <intrigeri at debian.org> wrote:

> 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)

Thanks for fixing the address, yes, I didn't get the original report.
Let me Cc: podman at packages.debian.org as well.

> 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.

By the way, note that Podman explicitly terminates pasta only in some
selected cases, such as a network namespace with several containers,
and perhaps others, but not in the most common (I guess?) case with a
single container and its own network.

In general, pasta terminates by itself once it sees (via inotify)
that the network namespace goes away. In the case with multiple
containers the mechanism is not reliable so there's this extra step in
Podman.

> > 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.

I'm not sure what fix you mean here, but Launchpad #2077158 is already
fixed on Debian, and there's no further fix needed upstream.

>  - 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,

I'm fine with it, even though, strictly speaking, I think we should go
the same way we adopted for libvirt and passt(1) (same binary, command
invocation for virtual machines).

That is, Podman's profile should include pasta's abstraction and add
whatever Podman needs specifically on top.

For libvirt, letting this issue aside:

  https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/R52J7KGT2X5A6WEYKNOSLQUDQKUC5ORA/#R52J7KGT2X5A6WEYKNOSLQUDQKUC5ORA

we have a passt subprofile which includes abstractions/passt and adds:

    signal (receive) set=("term") peer=libvirtd,
    signal (receive) set=("term") peer=virtqemud,

on top (this is from /etc/apparmor.d/abstractions/libvirt-qemu).

The advantage is that, if Podman runs pasta, we don't unnecessarily
grant access to resources that are presumed necessary for pasta's stand
alone case, that is, /tmp/** rw, owner @{HOME}/** w.

> 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.

Well, eventually, it would make sense to have an actual profile, I
guess.

Anyway, let me know. If somebody is willing to add to change Podman's
profile in the way I mentioned (I can also submit a merge request
eventually, but that will be in a while), I'd prefer that, but I can
also just add a rule in pasta's profile for the moment.

-- 
Stefano