passt/contrib/apparmor/abstractions, 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: 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: 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

apparmor: Expand scope of @{run}/user access, allow writing PID files too

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

With Podman's custom networks, pasta will typically need to open the
target network namespace at /run/user//containers/networks:
grant access to anything under /run/user/ instead of limiting it
to some subpath.

Note that in this case, Podman will need pasta to write out a PID
file, so we need write access, for similar locations, too.

Reported-by: Jörg Sonnenberger 
Link: https://github.com/containers/buildah/issues/5440
Link: https://bugzilla.suse.com/show_bug.cgi?id=1221840
Signed-off-by: Stefano Brivio

apparmor: Add mount rule with explicit, empty source in passt abstraction

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

For the policy to work as expected across either AppArmor commit
9d3f8c6cc05d ("parser: fix parsing of source as mount point for
propagation type flags") and commit 300889c3a4b7 ("parser: fix option
flag processing for single conditional rules"), we need one mount
rule with matching mount options as "source" (that is, without
source), and one without mount options and an explicit, empty source.

Link: https://github.com/containers/buildah/issues/5440
Link: https://bugzilla.suse.com/show_bug.cgi?id=1221840
Signed-off-by: Stefano Brivio

apparmor: Add pasta's own profile

2023-09-06T22:31:35+00:00

If pasta and pasta.avx2 are hard links to passt and passt.avx2,
AppArmor will attach their own profiles on execution, and we can
restrict passt's profile to what it actually needs. Note that pasta
needs to access all the resources that passt needs, so the pasta
abstraction still includes passt's one.

I plan to push the adaptation required for the Debian package in
commit 5bb812e79143 ("debian/rules: Override pasta symbolic links
with hard links"), on Salsa. If other distributions need to support
AppArmor profiles they can follow a similar approach.

The profile itself will be installed, there, via dh_apparmor, in a
separate commit, b52557fedcb1 ("debian/rules: Install new pasta
profile using dh_apparmor").

Signed-off-by: Stefano Brivio

apparmor: Allow pasta to remount /proc, access entries under its own copy

2023-09-06T22:31:35+00:00

Since commit b0e450aa8500 ("pasta: Detach mount namespace, (re)mount
procfs before spawning command"), we need to explicitly permit mount
of /proc, and access to entries under /proc/PID/net (after remount,
that's what AppArmor sees as path).

Fixes: b0e450aa8500 ("pasta: Detach mount namespace, (re)mount procfs before spawning command")
Signed-off-by: Stefano Brivio