On Fri, 14 Feb 2025 03:17:06 -0800 Andrea Bolognani <abologna@xxxxxxxxxx> wrote: > On Thu, Feb 13, 2025 at 01:19:44PM -0500, Laine Stump wrote: > > passt (https://passt.top) provides a method of connecting QEMU virtual > > machines to the external network without requiring special privileges > > or capabilities of any participating processes - even libvirt itself > > can run unprivileged and create an instance of passt (which *always* > > runs unprivileged) that is then connected to the qemu process (and > > thus the virtual machine) with a unix socket. > > > [...] > > > > So far this has been tested both unprivileged and privileged on Fedora > > 40 (with latest passt packet) and selinux enabled (there are a couple > > of selinux policy tweaks that still need to be pushed to > > passt-selinux) as well as unprivileged on debian (I *think* with > > AppArmor enabled) and everything seems to work. > > Unfortunately unprivileged VMs don't actually benefit from AppArmor > isolation. See [1] for a recent discussion about this. I quickly reported to Laine about a test I made with the workaround I proposed there. That's what it means by "working with AppArmor". It's simply passt with: https://archives.passt.top/passt-dev/20250205163101.3793658-1-sbrivio@xxxxxxxxxx/ (merged but not released yet). > > Also, you will need the latest (20250121) passt package. > > I truly appreciate the amount of information you've included in the > cover letter, especially the details about required passt version and > missing SELinux bits. That made it much easier for me to jump in with > some confidence. > > Speaking of SELinux, with the current policy on Fedora 41 I get a > couple of AVC denials related to accessing the shared memory file. > I understand that's expected, based on the above, but it's still > quite surprising to me that the VM would start at all in this case. Just for the record, it's with this: https://archives.passt.top/passt-dev/20250213221642.4085986-1-sbrivio@xxxxxxxxxx/ as you found out meanwhile. Of course, it's temporary (and not even released yet). > Just like the scenario that I've mentioned in my reply to 9/9, the > network interface quietly being broken doesn't make for a great user > experience. I believe this specific failure scenario, unlike the > other one, is pre-existing and not easy to deal with purely through > XML validation, but I really think that we should spend some effort > (as a follow-up) on making sure that, if passt can't set up the > network interface successfully, we report a useful error to the user > instead of just leaving things broken with no clear indication that > they are. I guess that's a valid follow-up improvement regardless of the workaround I'm about to release in passt's policy. > [1] https://lists.libvirt.org/archives/list/devel@xxxxxxxxxxxxxxxxx/thread/R52J7KGT2X5A6WEYKNOSLQUDQKUC5ORA/ -- Stefano
