Re: Apparmor (and other) Issues

Re: Apparmor (and other) Issues

[Stefano Brivio]

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.

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.

> - 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.

> Again, I will be making a report to the Debian maintainers, should they wish to chime in regarding Apparmor configs or the DNS resolution issue.

Please file a separate issue, in case. This one would be for
passt.

> Thank you once again for this awesome tool.

And thanks again for trying it out and reporting issues!

-- 
Stefano

Re: Apparmor (and other) Issues

[Prafulla Giri]

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.

> 
> > - 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

Just for the record, I'm also putting in the QEMU commands for Fedora 41 and Debian Trixie, as well:

Fedora 41:
/usr/bin/qemu-system-x86_64 -name guest=debian-trixie,debug-threads=on -S -object {"qom-type":"secret","id":"masterKey0","format":"raw","file":"/home/larryboy/.config/libvirt/qemu/lib/domain-5-debian-trixie/master-key.aes"} -machine pc-q35-9.1,usb=off,vmport=off,dump-guest-core=off,memory-backend=pc.ram,hpet=off,acpi=on -accel kvm -cpu host,migratable=on -m size=8388608k -object {"qom-type":"memory-backend-ram","id":"pc.ram","size":8589934592} -overcommit mem-lock=off -smp 4,sockets=4,cores=1,threads=1 -uuid d00ad47e-3cfe-4a1a-af01-b23417aad670 -no-user-config -nodefaults -chardev socket,id=charmonitor,fd=31,server=on,wait=off -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-shutdown -global ICH9-LPC.disable_s3=1 -global ICH9-LPC.disable_s4=1 -boot strict=on -device {"driver":"pcie-root-port","port":16,"chassis":1,"id":"pci.1","bus":"pcie.0","multifunction":true,"addr":"0x2"} -device {"driver":"pcie-root-port","port":17,"chassis":2,"id":"pci.2","bus":"pcie.0","addr":"0x2.0x1"} -device {"driver":"pcie-root-port","port":18,"chassis":3,"id":"pci.3","bus":"pcie.0","addr":"0x2.0x2"} -device {"driver":"pcie-root-port","port":19,"chassis":4,"id":"pci.4","bus":"pcie.0","addr":"0x2.0x3"} -device {"driver":"pcie-root-port","port":20,"chassis":5,"id":"pci.5","bus":"pcie.0","addr":"0x2.0x4"} -device {"driver":"pcie-root-port","port":21,"chassis":6,"id":"pci.6","bus":"pcie.0","addr":"0x2.0x5"} -device {"driver":"pcie-root-port","port":22,"chassis":7,"id":"pci.7","bus":"pcie.0","addr":"0x2.0x6"} -device {"driver":"pcie-root-port","port":23,"chassis":8,"id":"pci.8","bus":"pcie.0","addr":"0x2.0x7"} -device {"driver":"pcie-root-port","port":24,"chassis":9,"id":"pci.9","bus":"pcie.0","multifunction":true,"addr":"0x3"} -device {"driver":"pcie-root-port","port":25,"chassis":10,"id":"pci.10","bus":"pcie.0","addr":"0x3.0x1"} -device {"driver":"pcie-root-port","port":26,"chassis":11,"id":"pci.11","bus":"pcie.0","addr":"0x3.0x2"} -device {"driver":"pcie-root-port","port":27,"chassis":12,"id":"pci.12","bus":"pcie.0","addr":"0x3.0x3"} -device {"driver":"pcie-root-port","port":28,"chassis":13,"id":"pci.13","bus":"pcie.0","addr":"0x3.0x4"} -device {"driver":"pcie-root-port","port":29,"chassis":14,"id":"pci.14","bus":"pcie.0","addr":"0x3.0x5"} -device {"driver":"qemu-xhci","p2":15,"p3":15,"id":"usb","bus":"pci.2","addr":"0x0"} -device {"driver":"virtio-serial-pci","id":"virtio-serial0","bus":"pci.3","addr":"0x0"} -blockdev {"driver":"file","filename":"/home/larryboy/.local/share/libvirt/images/debian-13-nocloud-amd64-daily.qcow2","node-name":"libvirt-2-storage","auto-read-only":true,"discard":"unmap"} -blockdev {"node-name":"libvirt-2-format","read-only":true,"discard":"unmap","driver":"qcow2","file":"libvirt-2-storage","backing":null} -blockdev {"driver":"file","filename":"/home/larryboy/.local/share/libvirt/images/debian-trixie.qcow2","node-name":"libvirt-1-storage","auto-read-only":true,"discard":"unmap"} -blockdev {"node-name":"libvirt-1-format","read-only":false,"discard":"unmap","driver":"qcow2","file":"libvirt-1-storage","backing":"libvirt-2-format"} -device {"driver":"virtio-blk-pci","bus":"pci.4","addr":"0x0","drive":"libvirt-1-format","id":"virtio-disk0","bootindex":1} -netdev {"type":"stream","addr":{"type":"unix","path":"/run/user/1000/libvirt/qemu/run/passt/5-debian-trixie-net0.socket"},"server":false,"reconnect":5,"id":"hostnet0"} -device {"driver":"virtio-net-pci","netdev":"hostnet0","id":"net0","mac":"52:54:00:8f:e7:c3","bus":"pci.1","addr":"0x0"} -chardev pty,id=charserial0 -device {"driver":"isa-serial","chardev":"charserial0","id":"serial0","index":0} -chardev socket,id=charchannel0,fd=30,server=on,wait=off -device {"driver":"virtserialport","bus":"virtio-serial0.0","nr":1,"chardev":"charchannel0","id":"channel0","name":"org.qemu.guest_agent.0"} -chardev spicevmc,id=charchannel1,name=vdagent -device {"driver":"virtserialport","bus":"virtio-serial0.0","nr":2,"chardev":"charchannel1","id":"channel1","name":"com.redhat.spice.0"} -device {"driver":"usb-tablet","id":"input0","bus":"usb.0","port":"1"} -audiodev {"id":"audio1","driver":"spice"} -spice port=5901,addr=127.0.0.1,disable-ticketing=on,image-compression=off,seamless-migration=on -display egl-headless,rendernode=/dev/dri/renderD128 -device {"driver":"virtio-vga-gl","id":"video0","max_outputs":1,"bus":"pcie.0","addr":"0x1"} -device {"driver":"ich9-intel-hda","id":"sound0","bus":"pcie.0","addr":"0x1b"} -device {"driver":"hda-duplex","id":"sound0-codec0","bus":"sound0.0","cad":0,"audiodev":"audio1"} -global ICH9-LPC.noreboot=off -watchdog-action reset -chardev spicevmc,id=charredir0,name=usbredir -device {"driver":"usb-redir","chardev":"charredir0","id":"redir0","bus":"usb.0","port":"2"} -chardev spicevmc,id=charredir1,name=usbredir -device {"driver":"usb-redir","chardev":"charredir1","id":"redir1","bus":"usb.0","port":"3"} -device {"driver":"virtio-balloon-pci","id":"balloon0","bus":"pci.5","addr":"0x0"} -object {"qom-type":"rng-random","id":"objrng0","filename":"/dev/urandom"} -device {"driver":"virtio-rng-pci","rng":"objrng0","id":"rng0","bus":"pci.6","addr":"0x0"} -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny -msg timestamp=on

Debian Trixie:
/usr/bin/qemu-system-x86_64 -name guest=vm1,debug-threads=on -S -object {"qom-type":"secret","id":"masterKey0","format":"raw","file":"/home/larryboy/.config/libvirt/qemu/lib/domain-1-vm1/master-key.aes"} -machine pc-i440fx-9.2,usb=off,vmport=off,dump-guest-core=off,memory-backend=pc.ram,hpet=off,acpi=on -accel kvm -cpu Denverton,vmx=on,fma=on,pdcm=on,pcid=on,avx=on,f16c=on,hypervisor=on,ss=on,tsc-adjust=on,bmi1=on,avx2=on,bmi2=on,invpcid=on,avx512f=on,avx512dq=on,adx=on,avx512ifma=on,clwb=on,avx512cd=on,avx512bw=on,avx512vl=on,avx512vbmi=on,umip=on,pku=on,avx512vbmi2=on,gfni=on,vaes=on,vpclmulqdq=on,avx512vnni=on,avx512bitalg=on,avx512-vpopcntdq=on,rdpid=on,movdiri=on,movdir64b=on,fsrm=on,avx512-vp2intersect=on,md-clear=on,stibp=on,flush-l1d=on,xsaves=on,abm=on,ibpb=on,ibrs=on,amd-stibp=on,amd-ssbd=on,ibrs-all=on,mds-no=on,pschange-mc-no=on,fbsdp-no=on,gds-no=on,rfds-no=on,vmx-activity-wait-sipi=on,vmx-xsaves=on,vmx-tsc-scaling=on,vmx-invvpid=on,mpx=off -m size=1048576k -object {"qom-type":"memory-backend-ram","id":"pc.ram","size":1073741824} -overcommit mem-lock=off -smp 1,sockets=1,cores=1,threads=1 -uuid aa332a62-1b7f-4a3c-b2c5-908e5e339b72 -no-user-config -nodefaults -chardev socket,id=charmonitor,fd=27,server=on,wait=off -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot menu=on,strict=on -device {"driver":"ich9-usb-ehci1","id":"usb","bus":"pci.0","addr":"0x5.0x7"} -device {"driver":"ich9-usb-uhci1","masterbus":"usb.0","firstport":0,"bus":"pci.0","multifunction":true,"addr":"0x5"} -device {"driver":"ich9-usb-uhci2","masterbus":"usb.0","firstport":2,"bus":"pci.0","addr":"0x5.0x1"} -device {"driver":"ich9-usb-uhci3","masterbus":"usb.0","firstport":4,"bus":"pci.0","addr":"0x5.0x2"} -device {"driver":"virtio-serial-pci","id":"virtio-serial0","bus":"pci.0","addr":"0x6"} -blockdev {"driver":"file","filename":"/home/larryboy/.local/share/libvirt/images/vm1.qcow2","node-name":"libvirt-2-storage","auto-read-only":true,"discard":"unmap"} -blockdev {"node-name":"libvirt-2-format","read-only":false,"driver":"qcow2","file":"libvirt-2-storage","backing":null} -device {"driver":"ide-hd","bus":"ide.0","unit":0,"drive":"libvirt-2-format","id":"ide0-0-0","bootindex":2} -blockdev {"driver":"file","filename":"/home/larryboy/.local/share/libvirt/images/dsl-2024.rc7.iso","node-name":"libvirt-1-storage","read-only":true} -device {"driver":"ide-cd","bus":"ide.0","unit":1,"drive":"libvirt-1-storage","id":"ide0-0-1","bootindex":1} -netdev {"type":"stream","addr":{"type":"unix","path":"/run/user/1000/libvirt/qemu/run/passt/1-vm1-net0.socket"},"server":false,"reconnect-ms":5000,"id":"hostnet0"} -device {"driver":"rtl8139","netdev":"hostnet0","id":"net0","mac":"52:54:00:a0:e1:7c","bus":"pci.0","addr":"0x3"} -chardev pty,id=charserial0 -device {"driver":"isa-serial","chardev":"charserial0","id":"serial0","index":0} -chardev spicevmc,id=charchannel0,name=vdagent -device {"driver":"virtserialport","bus":"virtio-serial0.0","nr":1,"chardev":"charchannel0","id":"channel0","name":"com.redhat.spice.0"} -device {"driver":"usb-tablet","id":"input0","bus":"usb.0","port":"1"} -audiodev {"id":"audio1","driver":"spice"} -spice port=5900,addr=127.0.0.1,disable-ticketing=on,seamless-migration=on -display egl-headless,rendernode=/dev/dri/renderD128 -device {"driver":"virtio-vga-gl","id":"video0","max_outputs":1,"bus":"pci.0","addr":"0x2"} -device {"driver":"AC97","id":"sound0","audiodev":"audio1","bus":"pci.0","addr":"0x4"} -chardev spicevmc,id=charredir0,name=usbredir -device {"driver":"usb-redir","chardev":"charredir0","id":"redir0","bus":"usb.0","port":"2"} -chardev spicevmc,id=charredir1,name=usbredir -device {"driver":"usb-redir","chardev":"charredir1","id":"redir1","bus":"usb.0","port":"3"} -device {"driver":"virtio-balloon-pci","id":"balloon0","bus":"pci.0","addr":"0x7"} -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny -msg timestamp=on

> > Again, I will be making a report to the Debian maintainers, should they wish to chime in regarding Apparmor configs or the DNS resolution issue.
> 
> 
> Please file a separate issue, in case. This one would be for
> passt.
> 

I think I no longer have to, since I have the Debian maintainer right here. (:

> > Thank you once again for this awesome tool.
> 
> 
> And thanks again for trying it out and reporting issues!
> 
I'm happy to be of some assistance (:
> --
> Stefano

Re: Apparmor (and other) Issues

[Stefano Brivio]

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

Re: Apparmor (and other) Issues

[Prafulla Giri]

On Thursday, January 30th, 2025 at 12:33 AM, Stefano Brivio <sbrivio@redhat.com> wrote:

> 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?
> 
I didn't have auditd installed on Debian and installed it, and running everything with the default auditd config (with my Apparmor disabled for passt, as mentioned previously) does not result in anything. Do I have to configure auditd manually? Any pointers on that, please?

On Fedora 41, which seems to have auditd preconfigured, there aren't any significant reports about passt.

> > > > - 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.
Here are the outputs:
$ passt -f -d # on Debian Testing/Trixie
0.0016: No interfaces with usable IPv6 routes
0.0017: Failed to detect external interface for IPv6
0.0028: UNIX domain socket bound at /tmp/passt_1.socket
0.0029: Template interface: enp1s0 (IPv4)
0.0029: MAC:
0.0029:     host: 9a:55:9a:55:9a:55
0.0029:     NAT to host 127.0.0.1: 192.168.100.1
0.0029: DHCP:
0.0029:     assign: 192.168.100.157
0.0029:     mask: 255.255.255.0
0.0029:     router: 192.168.100.1
0.0029: DNS:
0.0029:     192.168.100.1
0.0029: DNS search list:
0.0029:     .
0.0056: 
You can now start qemu (>= 7.2, with commit 13c6be96618c):
0.0056:     kvm ... -device virtio-net-pci,netdev=s -netdev stream,id=s,server=off,addr.type=unix,addr.path=/tmp/passt_1.socket
0.0057: or qrap, for earlier qemu versions:
0.0057:     ./qrap 5 kvm ... -net socket,fd=5 -net nic,model=virtio
0.0067: SO_PEEK_OFF supported
0.0067: TCP_INFO tcpi_snd_wnd field  supported
0.0067: TCP_INFO tcpi_bytes_acked field  supported
0.0067: TCP_INFO tcpi_min_rtt field  supported

$ passt -f -d
0.0022: UNIX domain socket bound at /tmp/passt_1.socket
0.0022: Template interface: wlp0s20f3 (IPv4)
0.0022: MAC:
0.0022:     host: 9a:55:9a:55:9a:55
0.0022:     NAT to host 127.0.0.1: 192.168.100.1
0.0023: DHCP:
0.0023:     assign: 192.168.100.157
0.0023:     mask: 255.255.255.0
0.0023:     router: 192.168.100.1
0.0023: DNS:
0.0023:     192.168.100.1
0.0023: DNS search list:
0.0023:     .
0.0047: 
You can now start qemu (>= 7.2, with commit 13c6be96618c):
0.0047:     kvm ... -device virtio-net-pci,netdev=s -netdev stream,id=s,server=off,addr.type=unix,addr.path=/tmp/passt_1.socket
0.0047: or qrap, for earlier qemu versions:
0.0047:     ./qrap 5 kvm ... -net socket,fd=5 -net nic,model=virtio
0.0055: SO_PEEK_OFF supported
0.0055: TCP_INFO tcpi_snd_wnd field  supported
0.0055: TCP_INFO tcpi_bytes_acked field  supported
0.0055: TCP_INFO tcpi_min_rtt field  supported

> 
> How are resolvers configured on the two hosts? What does
> /etc/resolv.conf say?
$ cat /etc/resolv.conf # On Fedora 41
# This is /run/systemd/resolve/stub-resolv.conf managed by man:systemd-resolved(8).
[...]
nameserver 127.0.0.53
options edns0 trust-ad
search .
$ cat /etc/resolv.conf # On Debian Trixie
# This is /run/systemd/resolve/resolv.conf managed by man:systemd-resolved(8).
[...]
nameserver 192.168.100.1
search .
$ cat /etc/resolv.conf # On a Debian 11 OS
# Generated by NetworkManager
nameserver 192.168.100.1

Also the output of `resolvectl status` for good measure:
# On Fedora 41
Global
         Protocols: LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: stub

Link 2 (wlp0s20f3)
    Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
         Protocols: +DefaultRoute LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 192.168.100.1
       DNS Servers: 192.168.100.1

# On Debian Trixie
Global
         Protocols: +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: uplink

Link 2 (enp1s0)
    Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
         Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
       DNS Servers: 192.168.100.1
     Default Route: yes

> 
> 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.
> 
The log from Debian Trixie host for VM1:
passt 0.0~git20250121.4f2c8e7-1: /usr/bin/passt.avx2 (6428)
0.0017: info:    No interfaces with usable IPv6 routes
0.0029: info:    UNIX domain socket bound at /run/user/1000/libvirt/qemu/run/passt/2-vm1-net0.socket
0.0030: info:    Template interface: enp1s0 (IPv4)
0.0030: info:    MAC:
0.0030: info:        host: 9a:55:9a:55:9a:55
0.0030: info:        NAT to host 127.0.0.1: 192.168.100.1
0.0030: info:    DHCP:
0.0031: info:        assign: 192.168.100.157
0.0031: info:        mask: 255.255.255.0
0.0031: info:        router: 192.168.100.1
0.0031: info:    DNS:
0.0031: info:        192.168.100.1
0.0031: info:    DNS search list:
0.0031: info:        .
0.0066: info:    
You can now start qemu (>= 7.2, with commit 13c6be96618c):
0.0066: info:        kvm ... -device virtio-net-pci,netdev=s -netdev stream,id=s,server=off,addr.type=unix,addr.path=/run/user/1000/libvirt/qemu/run/passt/2-vm1-net0.socket
0.0066: info:    or qrap, for earlier qemu versions:
0.0066: info:        ./qrap 5 kvm ... -net socket,fd=5 -net nic,model=virtio
0.0617: info:    accepted connection from PID 0
38.6257: info:    DHCP: offer to discover
38.6257: info:        from 52:54:00:a0:e1:7c
38.6471: info:    DHCP: ack to request
38.6471: info:        from 52:54:00:a0:e1:7c
451.4989: info:    Client connection closed, exiting

The log from Fedora 41:
passt 0^20250121.g4f2c8e7-2.fc41.x86_64: /usr/bin/passt.avx2 (3138)
0.0017: info:    UNIX domain socket bound at /run/user/1000/libvirt/qemu/run/passt/3-debian-trixie-net0.socket
0.0018: info:    Template interface: wlp0s20f3 (IPv4)
0.0018: info:    MAC:
0.0018: info:        host: 9a:55:9a:55:9a:55
0.0018: info:        NAT to host 127.0.0.1: 192.168.100.1
0.0018: info:    DHCP:
0.0018: info:        assign: 192.168.100.157
0.0018: info:        mask: 255.255.255.0
0.0018: info:        router: 192.168.100.1
0.0018: info:    DNS:
0.0018: info:        192.168.100.1
0.0018: info:    DNS search list:
0.0018: info:        .
0.0043: info:    
You can now start qemu (>= 7.2, with commit 13c6be96618c):
0.0043: info:        kvm ... -device virtio-net-pci,netdev=s -netdev stream,id=s,server=off,addr.type=unix,addr.path=/run/user/1000/libvirt/qemu/run/passt/3-debian-trixie-net0.socket
0.0043: info:    or qrap, for earlier qemu versions:
0.0043: info:        ./qrap 5 kvm ... -net socket,fd=5 -net nic,model=virtio
0.0591: info:    accepted connection from PID 0
10.7894: info:    DHCP: ack to discover (Rapid Commit)
10.7894: info:        from 52:54:00:8f:e7:c3
99.6704: info:    Client connection closed, exiting


> --
> Stefano