From f66769c2de82550ac1ee2548960c09a4b052341f Mon Sep 17 00:00:00 2001 From: Stefano Brivio Date: Wed, 5 Feb 2025 17:21:59 +0100 Subject: 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 Signed-off-by: Stefano Brivio --- 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, , 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, } -- cgit v1.2.3