On Fri, 07 Feb 2025 06:49:45 +0000 Prafulla Giri <prafulla.giri(a)protonmail.com> wrote:On Wednesday, February 5th, 2025 at 4:01 PM, Stefano Brivio <sbrivio(a)redhat.com> wrote:That, I'm not sure, but at least Andrea asked openSUSE and Ubuntu people for comments. I just prepared (and merged) a workaround for the moment. You are Cc'ed on the patch. If you want to test it, you should add this: # 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, to your /etc/apparmor.d/usr.bin.passt. Note that changes to AppArmor policy files are retained as configuration, so, if you edit it, package upgrades won't override things automatically. You will need to: apt-get -o Dpkg::Options::="--force-confmiss" install --reinstall passtBut the libvirt profile is not associated to the process, oops.Oh, so this is what is being worked upon: that Apparmor is not making the associationwhereas SELinux is doing it's thing as it's supposed to.Right, that's because SELinux can do this: https://selinuxproject.org/page/MultiCategorySecurity with AppArmor, it needs to be "emulated", somehow.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/*. @{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.We're just trying to make things as strict as possible, and depending on specific paths.I see. I'm glad this approach of as-strict-as-possible is being taken.We'll probably need to make them a bit looser for the moment being and perhaps just allow passt, no matter who starts it, to write to /var/run/**.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 process gets access to $XDG_RUNTIME_DIR of it's owner (and not outside of it).It also seems that more and more of us use $XDG_RUNTIME_DIR in lieu of /tmp in our personal shell scripts, because it kinda' feels like a more private /tmp.Yeah, it is.Also, the `passt` update fixing DNS issue hasn't yet made it to Debian Trixie, yet.I didn't release the fix yet. I merged it (upstream), but actually I was expecting you would give it a quick try. If I'm more confident about the change, I can do things faster.I figure it's going to take some time (?) Perhaps I should venture to Debian Sid, myself.It's not in Debian Sid either because I didn't make a new release of passt, yet. It probably makes sense to make one next week (we release quite often, especially if there's one or more fixes that might be important for somebody, such as this one). As Debian maintainer I also update Debian packages within a couple of hours. Sid to testing is usually five days of difference, look: https://tracker.debian.org/pkg/passt/news/ -- Stefano