Re: Apparmor (and other) Issues

[Stefano Brivio <sbrivio@redhat.com>]

On Mon, 17 Feb 2025 06:37:18 +0000
Prafulla Giri <prafulla.giri@protonmail.com> wrote:

> Hello there,
> 
> Please forgive me for being MIA.
> 
> On Sunday, February 9th, 2025 at 2:53 PM, Stefano Brivio <sbrivio@redhat.com> wrote:
> 
> > 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:  
> 
> You are a very good teacher, I must say.
> >   
> > > 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,
> 
> I did just that and
> $ pasta --config-net --trace --pcap /tmp/dns.pcap -- nslookup fsf.org # `which pasta` -> /usr/local/bin/pasta
> works as expected, thank you.
> 
> However, for some reason libvirt still can't run pasta.

You mean 'passt', and:

> $ virsh start --domain vm1
> rror: Failed to start domain 'vm1'
> error: internal error: Child process (passt --one-off --socket /run/user/1000/libvirt/qemu/run/passt/2-vm1-net0.socket --pid /run/user/1000/libvirt/qemu/run/passt/2-vm1-net0-passt.pid) unexpected exit status 126: libvirt:  error : 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 enough, the libvirt-qemu abstraction file does import this abstraction file.

https://salsa.debian.org/sbrivio/passt/-/commit/5bb812e79143670a57440cd8aa7f2979583c5a0a

might explain it. You need to create hard links ('make install' doesn't
do that) to associate different AppArmor profiles.

In any case, I'm releasing (and packaging) a new version with the
AppArmor workaround today.

-- 
Stefano