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>