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>

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>

It needs to connect to passt and pasta, whether they're started as
root or not, and the control socket can be anywhere.

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

Frequent DNS queries over UDP from a container or guest can result
in many sockets shown in ss(8), typically one per flow. This is
expected and harmless, but it can make the output of ss(8) look
noisy and potentially concern users.

This patch splits UDP flow timeouts into two, mirroring the Linux
kernel, and sources the values from kernel parameters. The shorter
timeout is applied to unidirectional flows and minimal bidirectional
exchanges (single datagram and reply), while the longer timeout is
used for bidirectional flows with multiple datagrams on either side.

Link: https://bugs.passt.top/show_bug.cgi?id=197
Suggested-by: Stefano Brivio <sbrivio@redhat.com>
Signed-off-by: Yumei Huang <yuhuang@redhat.com>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>

In the 3.0 AppArmor ABI version we currently use, user namespace rules
are not supported, and, as long as we load confined profiles, those
implicitly allow creation of user namespaces.

However, ABI version 4.0 introduces rules for user namespaces, and if
we don't specify any, we can't create user namespaces, see:

  https://gitlab.com/apparmor/apparmor/-/wikis/unprivileged_userns_restriction

This wouldn't affect us in general, given that we're using the 3.0
ABI, but libvirt's policy uses 4.0 instead, and if our abstractions
are used from there, no matter what ABI policy version we declare,
rules for user namespace creation now match ABI policy version 4.0.

As a result, when libvirtd runs as root, and its profile includes
passt's abstraction, cf. commit 66769c2de825 ("apparmor: Workaround
for unconfined libvirtd when triggered by unprivileged user"), passt
can't detach user namespaces and will fail to start, as reported by
Niklas:

  ERROR    internal error: Child process (passt --one-off --socket /run/libvirt/qemu/passt/1-haos-net0.socket --pid /run/libvirt/qemu/passt/1-haos-net0-passt.pid --tcp-ports 8123) unexpected exit status 1: Multiple interfaces with IPv6 routes, picked first
  UNIX domain socket bound at /run/libvirt/qemu/passt/1-haos-net0.socket
  Couldn't create user namespace: Permission denied

This isn't a problem with libvirtd running as regular user, because
in that case, as a workaround, passt currently runs under its own
profile, not as a libvirtd subprofile (see commit referenced above).

Given that ABI 4.0 has been around for a while, being introduced in
July 2023, finally take the step to upgrade to it and explicitly
enable user namespace creation.

No further changes are needed in the existing policies to match new
features introduced in AppArmor 4.0.

Reported-by: Niklas Edmundsson <nikke@accum.se>
Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1124801
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>

Since commits 3dde0e07804e ("tcp: Update data retransmission timeout")
and 1a834879a2f7 ("tcp: Clamp the retry timeout") from 2025-12-02,
passt reads additional TCP-related sysctl parameters from /proc to
configure retransmission timeout behavior:

  - /proc/sys/net/ipv4/tcp_syn_retries
  - /proc/sys/net/ipv4/tcp_syn_linear_timeouts
  - /proc/sys/net/ipv4/tcp_rto_max_ms

These are read by tcp_get_rto_params() during initialization. Adjust the
AppArmor profile accordingly.

Link: https://bugzilla.redhat.com/show_bug.cgi?id=2426863
Link: https://github.com/cockpit-project/bots/pull/8568
Fixes: 3dde0e07804e ("tcp: Update data retransmission timeout")
Fixes: 1a834879a2f7 ("tcp: Clamp the retry timeout")
Signed-off-by: Martin Pitt <mpitt@redhat.com>
[sbrivio: Minor formatting change, changed commit references]
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>

If libvirtd is triggered by an unprivileged user, the virt-aa-helper
mechanism doesn't work, because per-VM profiles can't be instantiated,
and as a result libvirtd runs unconfined.

This means passt can't start, because the passt subprofile from
libvirt's profile is not loaded either.

Example:

  $ virsh start alpine
  error: Failed to start domain 'alpine'
  error: internal error: Child process (passt --one-off --socket /run/user/1000/libvirt/qemu/run/passt/1-alpine-net0.socket --pid /run/user/1000/libvirt/qemu/run/passt/1-alpine-net0-passt.pid --tcp-ports 40922:2) unexpected fatal signal 11

Add an annoying workaround for the moment being. Much better than
encouraging users to start guests as root, or to disable AppArmor
altogether.

Reported-by: Prafulla Giri <prafulla.giri@protonmail.com>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>

A privileged helper to set/clear TCP_REPAIR on sockets on behalf of
passt. Not used yet.

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