From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=pass (p=quarantine dis=none) header.from=protonmail.com Authentication-Results: passt.top; dkim=pass (2048-bit key; secure) header.d=protonmail.com header.i=@protonmail.com header.a=rsa-sha256 header.s=protonmail3 header.b=qUzZ6SLy; dkim-atps=neutral Received: from mail-40135.protonmail.ch (mail-40135.protonmail.ch [185.70.40.135]) by passt.top (Postfix) with ESMTPS id 7DC3A5A0272 for ; Mon, 17 Feb 2025 07:37:24 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1739774243; x=1740033443; bh=+oFDZt0v/sCMpjvdRXFccEor+MKrURyP/iVJ1BHSDn4=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=qUzZ6SLyeXU1TfeTjZiYT0f/FEH3AJkZssqOYnvwnQHbgcvSTEuivZfZAFVg6FeR7 GS5g3sCwXn6zF9uzJ129V40m1vY3nWiKlxlDHBLQM9pXLaSFs9dclfKWWZFVSLRGbC 0GNGZdwKXcFpTt+A1cMnrZ/ZrnBYmpuRsnTFO9HJjM3aQVCEU0vZSnMM2fVR9vYKxh 49R3C4YZ7BqkOXF/QkSNYXARLql8WRD4alnB8XFu8Jre0fAbiVEOrPNXA/0vvDQ5TJ PA4/vZ5Q2PhtotfAo/TM/xTPgRqY6f9iQze6+EOnTBKcZMdy/lgnBbrqXB29eWivvD T5LbgRexWWekg== Date: Mon, 17 Feb 2025 06:37:18 +0000 To: Stefano Brivio From: Prafulla Giri Subject: Re: Apparmor (and other) Issues Message-ID: In-Reply-To: <20250209100848.4e5c39de@elisabeth> References: <20250204233441.6cda8c64@elisabeth> <20250205111651.59551470@elisabeth> <20250207101631.0875e141@elisabeth> <20250209100848.4e5c39de@elisabeth> Feedback-ID: 33818994:user:proton X-Pm-Message-ID: 338cef16953ca470dea361778eb808eeb0f9efcc MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID-Hash: 6J76NYKPQAS5QIUIKPHSYF7FE735EI5A X-Message-ID-Hash: 6J76NYKPQAS5QIUIKPHSYF7FE735EI5A X-MailFrom: prafulla.giri@protonmail.com 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: Andrea Bolognani , "passt-dev@passt.top" 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: Hello there, Please forgive me for being MIA. On Sunday, February 9th, 2025 at 2:53 PM, Stefano Brivio wrote: > On Sat, 08 Feb 2025 17:19:59 +0000 > Prafulla Giri prafulla.giri@protonmail.com wrote: >=20 > > On Friday, February 7th, 2025 at 3:01 PM, Stefano Brivio sbrivio@redhat= .com wrote: > >=20 > > > On Fri, 07 Feb 2025 06:49:45 +0000 > > > Prafulla Giri prafulla.giri@protonmail.com wrote: > > >=20 > > > > On Wednesday, February 5th, 2025 at 4:01 PM, Stefano Brivio > > > > sbrivio@redhat.com wrote: > > > >=20 > > > > > But the libvirt profile is not associated to the > > > > > process, oops. > > > >=20 > > > > Oh, so this is what is being worked upon: that Apparmor is not maki= ng > > > > the association > > >=20 > > > That, I'm not sure, but at least Andrea asked openSUSE and Ubuntu > > > people for comments. I just prepared (and merged) a workaround for th= e > > > moment. You are Cc'ed on the patch. If you want to test it, you shoul= d > > > add this: > > >=20 > > > # Workaround: libvirt's profile comes with a passt subprofile which i= ncludes, > > > # in turn, , and adds libvirt-specific rules on t= op, to > > >=20 > > > # allow passt (when started by libvirtd) to write socket and PID file= s in the > > > # location requested by libvirtd itself, and to execute passt itself. > > > # > > > # However, when libvirt runs as unprivileged user, the mechanism base= d on > > > # virt-aa-helper, designed to build per-VM profiles as guests are sta= rted, > > > # doesn't work. The helper needs to create and load profiles on the f= ly, which > > > # can't be done by unprivileged users, of course. > > > # > > > # As a result, libvirtd runs unconfined if guests are started by unpr= ivileged > > > # users, starting passt unconfined as well, which means that passt ru= ns 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, > > >=20 > > > to your /etc/apparmor.d/usr.bin.passt. Note that changes to AppArmor > > > policy files are retained as configuration, so, if you edit it, packa= ge > > > upgrades won't override things automatically. You will need to: > >=20 > > I seem to have botched things up really good, or we're getting into mor= e and more trouble here: >=20 >=20 > Worry not, I can explain: You are a very good teacher, I must say. >=20 > > 1. I have manually `make install`-ed passt (and friends). > > $ passt version # I don't know what's causing the non-AVX2 thing issue >=20 >=20 > If you install it to /usr/local/bin, other than adding a profile for > /usr/local/bin/passt{,.avx2} as you correctly did, you also need to add > the /usr/local/bin path to the "abstraction" that's included by the > profile. In /etc/apparmor.d/abstractions/passt we have: >=20 > /usr/bin/passt.avx2 ix, # arch_avx2_exec(), arch.c >=20 > and if you want to do experiments with a local version that needs to be: >=20 > /usr/bin/passt.avx2 ix, # arch_avx2_exec(), arch.c > /usr/bin/local/passt.avx2 ix, >=20 I did just that and $ pasta --config-net --trace --pcap /tmp/dns.pcap -- nslookup fsf.org # `wh= ich pasta` -> /usr/local/bin/pasta works as expected, thank you. However, for some reason libvirt still can't run pasta. $ virsh start --domain vm1 rror: Failed to start domain 'vm1' error: internal error: Child process (passt --one-off --socket /run/user/10= 00/libvirt/qemu/run/passt/2-vm1-net0.socket --pid /run/user/1000/libvirt/qe= mu/run/passt/2-vm1-net0-passt.pid) unexpected exit status 126: libvirt: er= ror : cannot execute binary passt: Permission denied It seems adding merely '/usr/bin/local/passt.avx2 ix,' in the abstractions = file isn't quite enough. Perhaps there's something missing? Strangely enoug= h, the libvirt-qemu abstraction file does import this abstraction file. > > [...] > >=20 > > If, however, I uninstall the manually made version (with the apparmor p= rofile back to pointing to /usr/bin/passt): > >=20 > > $ passt --version > > passt 0.0~git20250121.4f2c8e7-1 > > Copyright Red Hat > > GNU General Public License, version 2 or later > > https://www.gnu.org/licenses/old-licenses/gpl-2.0.html > > This is free software: you are free to change and redistribute it. > > There is NO WARRANTY, to the extent permitted by law. > >=20 > > $ virsh start --domain vm1 > > Domain 'vm1' started > >=20 > > So I figure it's okay after all. >=20 >=20 > Good, thanks for checking! That patch is already applied by the way. As > I mentioned, I'll make a new release (and Debian packages) in a few > days. >=20 > > I am surprised, the upstream tree does not seem to contain the recent D= NS related patch that I shazamed and tested just a couple of days earlier (= b4 shazam https://archives.passt.top/passt-dev/20250203082210.2114348-1-sb= rivio@redhat.com/ ). I have just emailed a reply at the patch's own thread,= too: https://archives.passt.top/passt-dev/pXatirFM4Zm6ZSKXYsfeyZnHlL8JlQDK= RUNtyLqbzrUOFcItX06upuk1cPYaufL1HzqHygkWvySVhawtV8zVi8Ou9qmhz_EvuQxr46UOi3Q= =3D@protonmail.com/ >=20 >=20 > Right, I thought I applied it, but now I remember: I wasn't entirely > sure it fixed your issue, and I was waiting for reviews as well, then I > forgot about it. It's merged now. >=20 > > Please let me know if I'm still missing (or failing to report) somethin= g. I'd hate to unknowingly be a bottle-neck by failing to test/report somet= hing. >=20 >=20 > No worries, you're definitely not a bottleneck, my mind sometimes is. > Thanks for the all the tests! >=20 > > > > I believe user-mode virtual machines only need access to > > > > /run/user/$USER and not /var/run. Not even /run/*, but only > > > > /run/user/$USER. So if that work-around is to be implemented, that > > > > would be the strictest version of it: each user-started passt proce= ss > > > > gets access to $XDG_RUNTIME_DIR of it's owner (and not outside of i= t). > > >=20 > > > It depends, because if you start passt as root, socket and PID go to > > > @{run}/libvirt/qemu/passt/, and if you don't, the location becomes > > > @{run}/user/[0-9]/libvirt/qemu/run/passt/*. > > >=20 > > > @{run} is an AppArmor handle for /var/run and /run, I think (aren't > > > they generally linked anyway?). Note that Ubuntu and openSUSE might > > > use slightly different paths. > >=20 > > /var/run deems to be a symbolic link to /run which is a tmpfs mount on = my Debian Trixie machine. >=20 >=20 > Right, yes, hence that @{run} alias that covers whatever you have on > different distributions or different versions. >=20 > -- > Stefano