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>

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 <rjones@redhat.com>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Acked-by: Richard W.M. Jones <rjones@redhat.com>

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 <pholzing@redhat.com>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>

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 <pholzing@redhat.com>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>

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 <sbrivio@redhat.com>

AppArmor resolves executable links before profile attachment rules
are evaluated, so, as long as pasta is installed as a link to passt,
there's no way to differentiate the two cases. Merge the two profiles
and leave a TODO note behind, explaining two possible ways forward.

Update the rules so that passt and pasta are actually usable, once
the profile is installed. Most required changes are related to
isolation and sandboxing features.

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

These should cover any reasonably common use case in distributions.

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