passt/contrib/apparmor, branch 2026_01_17.81c97f6

apparmor: Upgrade ABI version to 4.0, explicitly enable user namespace creation

2026-01-14T00:07:51+00:00

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 
Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1124801
Signed-off-by: Stefano Brivio

apparmor: Allow reading TCP RTO sysctl parameters

2026-01-08T14:02:51+00:00

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 
[sbrivio: Minor formatting change, changed commit references]
Signed-off-by: Stefano Brivio

apparmor: Workaround for unconfined libvirtd when triggered by unprivileged user

2025-02-06T08:43:09+00:00

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 
Signed-off-by: Stefano Brivio

Introduce passt-repair

2025-02-04T00:28:04+00:00

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

Signed-off-by: Stefano Brivio

apparmor: Allow read access to /proc/sys/net/ipv4/ip_local_port_range

2024-09-06T13:34:06+00:00

...for both passt and pasta: use passt's abstraction for this.

Fixes: eedc81b6ef55 ("fwd, conf: Probe host's ephemeral ports")
Signed-off-by: Stefano Brivio

apparmor: Fix comments after PID file and AF_UNIX socket creation refactoring

2024-05-23T14:44:21+00:00

Now:
- we don't open the PID file in main() anymore
- PID file and AF_UNIX socket are opened by pidfile_open() and
  tap_sock_unix_open()
- write_pidfile() becomes pidfile_write()

Reported-by: Richard W.M. Jones 
Signed-off-by: Stefano Brivio 
Acked-by: Richard W.M. Jones

apparmor: Fix passt abstraction

2024-05-22T21:16:27+00:00

Commit b686afa2 introduced the invalid apparmor rule
`mount options=(rw, runbindable) /,` since runbindable mount rules
cannot have a source.

Therefore running aa-logprof/aa-genprof will trigger errors (see
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2065685)

    $ sudo aa-logprof
    ERROR: Operation {'runbindable'} cannot have a source. Source = AARE('/')

This patch fixes it to the intended behavior.

Link: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2065685
Fixes: b686afa23e85 ("apparmor: Explicitly pass options we use while remounting root filesystem")
Signed-off-by: Maxime Bélair 
Signed-off-by: Stefano Brivio

apparmor: allow netns paths on /tmp

2024-05-13T21:02:18+00:00

For some unknown reason "owner" makes it impossible to open bind mounted
netns references as apparmor denies it. In the kernel denied log entry
we see ouid=0 but it is not clear why that is as the actual file is
owned by the real (rootless) user id.

In abstractions/pasta there is already `@{run}/user/@{uid}/**` without
owner set for the same reason as this path contains the netns path by
default when running under Podman.

Fixes: 72884484b00d ("apparmor: allow read access on /tmp for pasta")
Signed-off-by: Paul Holzinger 
Signed-off-by: Stefano Brivio

apparmor: allow read access on /tmp for pasta

2024-05-10T14:53:35+00:00

The podman CI on debian runs tests based on /tmp but pasta is failing
there because it is unable to open the netns path as the open for read
access is denied.

Link: https://github.com/containers/podman/issues/22625
Signed-off-by: Paul Holzinger 
Signed-off-by: Stefano Brivio

apparmor: Fix access to procfs namespace entries in pasta's abstraction

2024-04-05T10:12:26+00:00

From an original patch by Danish Prakash.

With commit ff22a78d7b52 ("pasta: Don't try to watch namespaces in
procfs with inotify, use timer instead"), if a filesystem-bound
target namespace is passed on the command line, we'll grab a handle
on its parent directory. That commit, however, didn't introduce a
matching AppArmor rule. Add it here.

To access a network namespace procfs entry, we also need a 'ptrace'
rule. See commit 594dce66d3bb ("isolation: keep CAP_SYS_PTRACE when
required") for details as to when we need this -- essentially, it's
about operation with Buildah.

Reported-by: Jörg Sonnenberger 
Link: https://github.com/containers/buildah/issues/5440
Link: https://bugzilla.suse.com/show_bug.cgi?id=1221840
Fixes: ff22a78d7b52 ("pasta: Don't try to watch namespaces in procfs with inotify, use timer instead")
Signed-off-by: Stefano Brivio