Commit 7bf1595c9242 ("isolation: Don't create our userns as nobody")
changed the procedure user namespaces are detached, also for passt,
and adds unconditional setting of UID and GID maps.

This needs AppArmor adjustments:

- rules to access gid_map, uid_map, and setgroups entries in procfs
  now need to be enabled for passt as well, not just for pasta: move
  them to the passt abstraction (which is included from the pasta
  abstraction)

- we now need to open a user namespace originally detached by a
  separate holder process, which requires us to open procfs entries
  that are disconnected (from an AppArmor perspective) from the
  original namespace: add the attach_disconnected flag to the profile
  for passt as well (this was already the case for pasta).

  This isn't ideal but there doesn't seem any way around it: opening
  the namespace from the holder process itself doesn't help either.

  We'll need to add this flag also in passt subprofiles for
  guestfs-tools (maintained in Debian) and libvirtd (which only
  applies when guests are started as root for the moment, maintained
  by libvirt upstream).

Reported-by: Michal Humpula <bts@hudrydum.cz>
Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1149683
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>

Starting from commit 7bf1595c9242 ("isolation: Don't create our userns
as nobody"), we unconditionally set uidmap and gidmap in the detached
user namespace.

Allow that in SELinux rules. We also need to allow explicit access to
the related files.

While at it, add the matching class requirements in pasta.te, which I
forgot (harmless as they were indirectly required, but not really
correct).

Link: https://bodhi.fedoraproject.org/updates/FEDORA-2026-3a8fb909da#comment-4790590
Fixes: 71b74e924426 ("isolation: Don't create our userns as nobody")
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>

The change to the user-tmp abstraction broke pasta as it can no longer
open the netns path given by podman when it is under /tmp.

The abstraction uses "owner" while the kernel always seems to report
ouid=0 for the bind mounted netns reference. I originally fixed that
in commit 6cdc9fd51bf6 ("apparmor: allow netns paths on /tmp").

In order to fix the regression add /tmp explicitly again here while
keeping the abstraction to still allow /var/tmp for the other regular
files.

Link: https://github.com/podman-container-tools/podman/pull/29867#pullrequestreview-5378330040
Fixes: f2683d14802d ("apparmor: Use user-tmp abstraction, allow /var/tmp instead of /tmp only")
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
[sbrivio: Replaced spaces with tabs, slightly reworded comment]
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>

Podman overrides TMPDIR to /var/tmp, and an upcoming change in the
requires pasta to write its PID file to TMPDIR.

To support this in the AppArmor policy, we need to loosen the existing
rule restricting file writes to /tmp/ and subpaths in order to include
common alternative paths for TMPDIR: the user-tmp abstraction does
exactly this.

Reported-by: Giuseppe Scrivano <gscrivan@redhat.com>
Link: https://github.com/podman-container-tools/container-libs/pull/1207
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>

Since Linux 5.12, writing a mapping from UID 0 to /proc/self/uid_map
requires CAP_SETFCAP. isolation.c already retains this capability for
the case where pasta spawns a child from a non-init user namespace,
but the AppArmor profile doesn't grant it, so the write is denied
whenever the profile is enforced.

Add setfcap to the AppArmor abstraction to match what isolation.c
expects.

Link: https://bugs.passt.top/show_bug.cgi?id=172
Signed-off-by: Sevinj Aghayeva <sevinj.aghayeva@gmail.com>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>

No sunsetting or rightsizing for you, qrap: dig, bury, and cover.

Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>

A few additional rules are needed when pasta is started by Podman in
particular cases:

- with podman-build or Buildah, pasta needs to access the target
  namespace reference using a procfs namespace link entry, instead of
  the usual directory under /run or /var/run. For that, we have a
  rule enabling access to container_t:lnk_file.

  On some systems, though, the class is 'dir' instead of 'lnk_file'.
  I don't have a concrete way to reproduce this or a full explanation,
  but in any case, an additional rule for that is obviously harmless:
  allow pasta_t to open, read, and search a container_t:dir

- with custom networks, pasta needs to write PID files to a location
  indicated by Podman. If the PID file already exists, the existing
  permissions aren't sufficient: we also need a 'read' rule. Add that,
  for 'dir' and 'file' objects labeled as either container_var_run_t
  or ifconfig_var_run_t (this depends on the installed Podman and
  container-selinux versions)

Signed-off-by: Stefano Brivio <sbrivio@redhat.com>

If Podman starts us, we need to be able to create and use a UNIX
domain socket file under ifconfig_var_run_t or container_var_run_t:
add the related permissions.

The failure reported by Jan would have been fixed by a simple:

  allow pasta_t ifconfig_var_run_t:sock_file create;

but we'll need more than that for actual operation with pesto(1),
and to cover all possible cases.

Reported-by: Jan Rodák <jrodak@redhat.com>
Link: https://github.com/containers/podman/pull/28478
Fixes: 533577008942 ("selinux: Add file context and type enforcement for pesto")
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>

It's time to ship it in packages.

Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Reviewed-by: Laurent Vivier <lvivier@redhat.com>

Loosely inspired by passt-repair's policy: pesto needs to be able to
run, check networking entries under /proc (for ip_local_port_range),
talk to passt and pasta, wherever the control socket is.

Signed-off-by: Stefano Brivio <sbrivio@redhat.com>