Re: Apparmor (and other) Issues

[Stefano Brivio <sbrivio@redhat.com>]

On Thu, 30 Jan 2025 10:05:14 +0000
Prafulla Giri <prafulla.giri@protonmail.com> wrote:

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

No, the default configuration is just fine. But you should re-enable
AppArmor for passt so that we can see meaningful messages in the logs.

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

So, judging from this configuration, it looks like we advertise to
the guest (via DHCP) 192.168.100.1 as resolver (copied from the host),
and when we receive packets from the guest for 192.168.100.1, we'll
re-map them to the host.

Nothing strange so far, systemd-resolved is running on the host, it
should get our queries and reply to them.

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

Everything as expected here, I don't see any obvious reason why
systemd-resolved should discard our queries.

> 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

Unfortunately libvirt doesn't let us enable more verbose logging. I
hoped to see DNS queries there, but without --debug given to passt,
that won't work.

Another idea: pasta(1) does the same job as passt(1) (it's the same
code and same binary) and it's intended for containers, but it has a
stand-alone mode that can probably help us to debug this, because it's
a network namespace that will look like your guest, and it can also
take packet captures.

What happens if you run:

  pasta --config-net --trace --pcap /tmp/dns.pcap -- nslookup fsf.org

?

If the query fails (that's what I would expect), can you please attach
the output and the resulting packet capture?

Note that the packet capture might have sensitive data, please have a
look at it with e.g. Wireshark/tshark before sharing it.

By the way, if you run this without specifying any command, for example:

  pasta --config-net --pcap /tmp/dns.pcap

you will get a shell where you can play around in a separate network
namespace and with a network stack that looks pretty much the same as
passt for your guest.

-- 
Stefano