Re: Apparmor (and other) Issues

[Stefano Brivio <sbrivio@redhat.com>]

On Wed, 29 Jan 2025 18:10:36 +0000
Prafulla Giri <prafulla.giri@protonmail.com> wrote:

> Hello,
> 
> On Wednesday, January 29th, 2025 at 3:26 PM, Stefano Brivio <sbrivio@redhat.com> wrote:
> 
> > Hi,
> > 
> > On Wed, 29 Jan 2025 09:14:12 +0000
> > Prafulla Giri prafulla.giri@protonmail.com wrote:
> >   
> > > Esteemed maintainer,
> > > 
> > > First and foremost, thank you very much for your hard work: passt is awesome and allows one to run more useful user-space VM-s.
> > > 
> > > I have encountered 2 particular issues with the usage of passt with Debian, and wanted to bring them to your attention as I think you are probably the best person to deal with this. I do plan on sending a report to the Debian team afterwards.
> > > 
> > > For reference, I tested these on Debian Testing Daily Image dated 28 January 2025, with updates, and the version of passt available with it is passt 0.0~git20250121.4f2c8e7-1
> > > 
> > > - Passt's default Apparmor config needs to allow writes to $XDG_RUNTIME_DIR (which is at /run/user/$UID). Currently it doesn't. Virt-manager, at least, tries to create the necessary sockets in the directory but apparmor prevents that from happening (and the error message Virt-Manager gives isn't helpful either: the first time around I falsely believed it was a segfault or similar issue). I managed to get passt working past this flaw (pun intended) by manually disabling apparmor for the binary. Passt works just fine in Fedora 41 as it doesn't use Apparmor but uses SELinux, and thus the configs don't affect it.  
> > 
> > 
> > Thanks for reporting this! I'm the maintainer of the Debian package, by
> > the way. Cc'ing Andrea, who is a maintainer of the libvirt package for
> > Debian and surely more knowledgeable about this.
> 
> I'm glad to have bumped into you. Because of the email domain, I thought you weren't the Debian maintainer. Silly me.

:)

> > Note that virt-manager uses passt through libvirt (I think that's only
> > possibility) and this should actually be allowed in libvirt's AppArmor
> > policy, in the sub-profile for passt:
> > 
> > https://gitlab.com/libvirt/libvirt/-/blob/0264a7704ada52f686cafe8f6402d5b60f9f0fc4/src/security/apparmor/libvirt-qemu.in#L204
> > 
> > the rationale is that passt itself doesn't know which directory libvirt
> > will pick for its socket and PID files, so libvirt's policy has to
> > specify that.
> > 
> > So I think you should file an issue for the libvirt package in this
> > case, unless Andrea has some pointers.  
> 
> I will wait for the maintainers input on this one.

One thing that might help meanwhile is if you have a look at
/var/log/audit/audit.log after the failure occurs. Look for 'passt'
there. There should be a message logging a denied access to some
file: what does it say?

> > > - This second issue is perhaps a bit more Debian-specific, but I am going to mention it so that you might drop some hints for the Debian maintainers to debug this: Once Apparmor is disabled and a VM is configured to work with passt, DNS resolution doesn't work in the VM (IP Addresses work just fine) i.e. ping fsf.org doesn't work but `ping 209.51.188.174` does. The hypervisor details follow:
> > > $ virsh version # on Debian Testing a.k.a. 'Trixie'
> > > Compiled against library: libvirt 11.0.0
> > > Using library: libvirt 11.0.0
> > > Using API: QEMU 11.0.0Running hypervisor: QEMU 9.2.0
> > > This, again, isn't an issue with Fedora 41, where everything just works. The hypervisor details for Fedora 41 are:
> > > $ virsh version # on Fedora 41
> > > Compiled against library: libvirt 10.6.0
> > > Using library: libvirt 10.6.0
> > > Using API: QEMU 10.6.0
> > > Running hypervisor: QEMU 9.1.2  
> > 
> > 
> > Oops. Can you share the command line of passt as run by libvirt
> > (say, 'ps aux|grep passt') for this case? passt has some basic
> > DNS forwarding capabilities, which are configured depending on
> > the host's resolver configuration.
> >   
> 
> Certainly! I'm sorry I didn't do this earlier. I'd checked on this: there is no difference between the command that runs passt on Fedora 41 or Debian Trixie.
> 
> This is the command on Fedora 41:
> passt --one-off --socket /run/user/1000/libvirt/qemu/run/passt/4-dragora-net0.socket --pid /run/user/1000/libvirt/qemu/run/passt/4-dragora-net0-passt.pid
> 
> and this is the command on Debian Trixie:
> passt --one-off --socket /run/user/1000/libvirt/qemu/run/passt/1-vm1-net0.socket --pid /run/user/1000/libvirt/qemu/run/passt/1-vm1-net0-passt.pid

Okay, nothing unexpected so far. Could you also please compare the
output of 'passt -f -d' between the two cases? Just terminate it with
^C once you have the output.

How are resolvers configured on the two hosts? What does
/etc/resolv.conf say?

If nothing is visible from there, next check: 'virsh edit vm1' on
Debian and add a log file in the XML, that is, replace this line:

  <backend type='passt'/>

with:

  <backend type='passt' logFile='/tmp/passt.log'/>

and then share the log.

-- 
Stefano