Re: Apparmor (and other) Issues

[Stefano Brivio <sbrivio@redhat.com>]

On Sat, 08 Feb 2025 17:19:59 +0000
Prafulla Giri <prafulla.giri@protonmail.com> wrote:

> On Friday, February 7th, 2025 at 3:01 PM, Stefano Brivio <sbrivio@redhat.com> wrote:
> 
> > On Fri, 07 Feb 2025 06:49:45 +0000
> > Prafulla Giri prafulla.giri@protonmail.com wrote:
> >   
> > > On Wednesday, February 5th, 2025 at 4:01 PM, Stefano Brivio
> > > sbrivio@redhat.com wrote:
> > >   
> > > > But 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 association  
> > 
> > 
> > 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:
> 
> I seem to have botched things up really good, or we're getting into more and more trouble here:

Worry not, I can explain:

> 1. I have manually `make install`-ed passt (and friends).
> $ passt version # I don't know what's causing the non-AVX2 thing issue

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:

  /usr/bin/passt.avx2                   ix,     # arch_avx2_exec(), arch.c

and if you want to do experiments with a local version that needs to be:

  /usr/bin/passt.avx2                   ix,     # arch_avx2_exec(), arch.c
  /usr/bin/local/passt.avx2             ix,

> [...]
>
> If, however, I uninstall the manually made version (with the apparmor profile back to pointing to /usr/bin/passt):
> 
> $ 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.
> 
> $ virsh start --domain vm1 
> Domain 'vm1' started
> 
> So I figure it's okay after all.

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.

> I am surprised, the upstream tree does not seem to contain the recent DNS related patch that I shazamed and tested just a couple of days earlier ( b4 shazam https://archives.passt.top/passt-dev/20250203082210.2114348-1-sbrivio@redhat.com/ ). I have just emailed a reply at the patch's own thread, too: https://archives.passt.top/passt-dev/pXatirFM4Zm6ZSKXYsfeyZnHlL8JlQDKRUNtyLqbzrUOFcItX06upuk1cPYaufL1HzqHygkWvySVhawtV8zVi8Ou9qmhz_EvuQxr46UOi3Q=@protonmail.com/

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.

> Please let me know if I'm still missing (or failing to report) something. I'd hate to unknowingly be a bottle-neck by failing to test/report something.

No worries, you're definitely not a bottleneck, my mind sometimes is.
Thanks for the all the tests!

> > > 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 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.
> 
> /var/run deems to be a symbolic link to /run which is a tmpfs mount on my Debian Trixie machine.

Right, yes, hence that @{run} alias that covers whatever you have on
different distributions or different versions.

-- 
Stefano