On Tue, 4 Feb 2025 14:19:34 -0800 Andrea Bolognani <abologna(a)redhat.com> wrote:On Tue, Feb 04, 2025 at 08:14:48PM +0100, Stefano Brivio wrote:Sure, that makes sense of course.On Tue, 4 Feb 2025 18:46:37 +0000 Andrea Bolognani <abologna(a)redhat.com> wrote:That could work, I suppose. Needs to be discussed upstream, making sure to involve those who are more experienced with AppArmor than I amRight. That's what we did for libguestfs as well, the image can be *almost* anywhere. But it's not free-for-all: you're just granting *limited* filesystem access (not to sysfs, not to /etc, and so on). And I had to build a *very* loose profile for libguestfs because that applies to root as well, but for rootless libvirtd, it might even make sense to restrict access to just @{HOME}/** and /tmp/** (that's what I did for stand-alone passt, for example).2. (most reasonable I think) don't use per-VM profiles for the rootless case. Define a single "libvirt-user" (or "libvirt-session") profile and use that. We could copy it from the existing ones I suppose.Sounds to me like this would require granting the QEMU process access to roughly the entire filesystem? The disk image could live anywhere after all, and if we can't dynamically add a rule for the exact path the only way out is a free-for-all approach.especially since it's not just a matter of updating the policy but fundamentally changing how the driver works when operating in unprivileged mode.Well, right now it runs unconfined, and (at least with passt) networking doesn't work. Pretty much any change would be good. :) I've been disabling AppArmor when I start guests for quite a while now, thinking that I just broke something on my setup while developing stuff (I reported that to you but I wasn't sure how the whole thing worked...). Oops.Then never mind. I can help filing a Debian issue if needed, let me know. Or let me know how I can help otherwise. I would consider a workaround for passt for the moment, say, the whole block: /usr/bin/passt r, signal (receive) set=("term") peer=/usr/sbin/libvirtd, signal (receive) set=("term") peer=libvirtd, signal (receive) set=("term") peer=virtqemud, owner @{run}/user/[0-9]*/libvirt/qemu/run/passt/* rw, owner @{run}/libvirt/qemu/passt/* rw, as part of the profile for usr.bin.passt. If you don't see issues with it, I'll go ahead with that. I still need to check openSUSE though (I haven't tried for a while there). -- StefanoI'll try to submit a pull request at least for Debian in a couple of days.Be aware that I will emphatically refuse to introduce changes to the Debian package unless they have been merged upstream first. AppArmor support lives in the upstream repository, and all fixes and improvements have to go through it.