From f66769c2de82550ac1ee2548960c09a4b052341f Mon Sep 17 00:00:00 2001
From: Stefano Brivio <sbrivio@redhat.com>
Date: Wed, 5 Feb 2025 17:21:59 +0100
Subject: [PATCH] apparmor: Workaround for unconfined libvirtd when triggered
by unprivileged user
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>
---
contrib/apparmor/usr.bin.passt | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/contrib/apparmor/usr.bin.passt b/contrib/apparmor/usr.bin.passt
index 9568189..62a4514 100644
--- a/contrib/apparmor/usr.bin.passt
+++ b/contrib/apparmor/usr.bin.passt
@@ -27,4 +27,25 @@ profile passt /usr/bin/passt{,.avx2} {
owner @{HOME}/** w, # pcap(), pidfile_open(),
# pidfile_write()
+
+ # Workaround: libvirt's profile comes with a passt subprofile which includes,
+ # in turn, <abstractions/passt>, and adds libvirt-specific rules on top, to
+ # allow passt (when started by libvirtd) to write socket and PID files in the
+ # location requested by libvirtd itself, and to execute passt itself.
+ #
+ # However, when libvirt runs as unprivileged user, the mechanism based on
+ # virt-aa-helper, designed to build per-VM profiles as guests are started,
+ # doesn't work. The helper needs to create and load profiles on the fly, which
+ # can't be done by unprivileged users, of course.
+ #
+ # As a result, libvirtd runs unconfined if guests are started by unprivileged
+ # users, starting passt unconfined as well, which means that passt runs under
+ # its own stand-alone profile (this one), which implies in turn that execve()
+ # of /usr/bin/passt is not allowed, and socket and PID files can't be written.
+ #
+ # Duplicate libvirt-specific rules here as long as this is not solved in
+ # libvirt's profile itself.
+ /usr/bin/passt r,
+ owner @{run}/user/[0-9]*/libvirt/qemu/run/passt/* rw,
+ owner @{run}/libvirt/qemu/passt/* rw,
}