From mboxrd@z Thu Jan 1 00:00:00 1970 Received: by passt.top (Postfix, from userid 1000) id 160965A061D; Wed, 05 Feb 2025 17:31:01 +0100 (CET) From: Stefano Brivio To: passt-dev@passt.top Subject: [PATCH] apparmor: Workaround for unconfined libvirtd when triggered by unprivileged user Date: Wed, 5 Feb 2025 17:31:01 +0100 Message-ID: <20250205163101.3793658-1-sbrivio@redhat.com> X-Mailer: git-send-email 2.43.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID-Hash: 2OS7NY4KMVTACPT2KDHMUC2WB4MNNUBO X-Message-ID-Hash: 2OS7NY4KMVTACPT2KDHMUC2WB4MNNUBO X-MailFrom: sbrivio@passt.top X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: Prafulla Giri , Andrea Bolognani , Jim Fehlig , =?UTF-8?q?Maxime=20B=C3=A9lair?= , Dario Faggioli X-Mailman-Version: 3.3.8 Precedence: list List-Id: Development discussion and patches for passt Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: 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, } -- 2.43.0