From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: passt.top; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=hiFAO6QB; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by passt.top (Postfix) with ESMTPS id 1052C5A062A for ; Fri, 31 Jan 2025 21:20:33 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1738354833; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=gJtawEQDMzrWm++WqBztvasHNDoW7qATZAgS44vJnEM=; b=hiFAO6QBWgFdy0BOn/WHBKMUBBr1Dn7STZLZt7TEjZIo6h3mwePolZLISxJG6Ej/Oerdtr pZeGmS5c9dqibo4pHrYhNOdiWoGEdU7rwGJk/TTC0HB8RstCSPCSd18cSar6ZLWdL/+CEN e2cmjpS3e+XvXKoAkXfpuwt3JZXKIj4= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-453-c2xw5-2RNN-trtWEhfpRww-1; Fri, 31 Jan 2025 15:20:31 -0500 X-MC-Unique: c2xw5-2RNN-trtWEhfpRww-1 X-Mimecast-MFC-AGG-ID: c2xw5-2RNN-trtWEhfpRww Received: by mail-wm1-f72.google.com with SMTP id 5b1f17b1804b1-43626224274so12047175e9.0 for ; Fri, 31 Jan 2025 12:20:31 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738354828; x=1738959628; h=content-transfer-encoding:mime-version:organization:references :in-reply-to:message-id:subject:cc:to:from:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=gJtawEQDMzrWm++WqBztvasHNDoW7qATZAgS44vJnEM=; b=gZVi44NCThPKOiw4d7HixvVZRiiGibXUcD4r9Mvq9dObqWfp0cDHIo7eZUBmQ0oH9Y oJW++eH/uOI+l+j5iuMWloW7L8CklGhQuiReo1iblE8Ez1QOg/Pw2Tt181yauplaubXS +XD3LRUyEWTcfgULYiUSLDSbJnOvLikkyFmEBjRLj1t1/0Ot4h2U0rjI2b3NMjTXecCa ipgSSY6hj5fQvHCWFo0x5iJKKeexr5L+RQ8Q8qI4l2nH5gi1/CyGvbR/R0jDMO5aZYyh EVBOW+/J58/ltsBqPZUxOgMah2eS3RKvDrx7fadDkTs6TXC+712ht92tOinJTXpUEmhP XRow== X-Gm-Message-State: AOJu0YwZ5xsv1WQ5OYLglQTXybDi8lQCXAg3S2sImpH4BSxZpzdCMD3U T4smGCNHIO8HGqm4zxtRgP22Np4D9rCOADAIlrWbBGvlXnobVqShehVcPvbxX2ds8T3/0Hm20Ud ZPCV71cegCzgu9YqH+KiE5j+nuqcQC+XfjOm2I0ONOlngWCnM89UVTbbJQsq5JKe2teb8So5kLd aFM2Gobd6nZurMVE9Uqq947qROGscNXhju X-Gm-Gg: ASbGncsPWutHD2l3p7vFJRXxSC9BuXXqVOnH5T72rfboOBwKLsnLM9o21OZrqhztjde Pz4rNCQSBbG1qg/JiBBykx8DIkEdY2gRYMUTZD3eiyT54StfXi/DC6RaaKkrhf1/fminmtEPe95 Ed0QE0EZ94NytVd9edAIo+Z0KDchYcXtfmGaIgzZCtozvoucIjaO5JDLJmZT+9ciEFHG3CzCCD2 MTSZsLtZukeN8kvEl09k7JTXYO+tA764v2Izufx8W3vBA7z4PnDhN58av2y4KLdmaO/NgPRpgP+ jxDIFi8azokH3aiB X-Received: by 2002:a05:600c:1c89:b0:434:f82b:c5e6 with SMTP id 5b1f17b1804b1-438dc3af78cmr95599165e9.1.1738354827900; Fri, 31 Jan 2025 12:20:27 -0800 (PST) X-Google-Smtp-Source: AGHT+IGQkQOmHjEBpEujczWftp5MHmc+GHM3hovxqqmhJ+9m5l28AyPjoJG1gl87wjAZzR0biNtVpg== X-Received: by 2002:a05:600c:1c89:b0:434:f82b:c5e6 with SMTP id 5b1f17b1804b1-438dc3af78cmr95599045e9.1.1738354827450; Fri, 31 Jan 2025 12:20:27 -0800 (PST) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [2a10:fc81:a806:d6a9::1]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-438e23d4456sm66782385e9.7.2025.01.31.12.20.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 31 Jan 2025 12:20:26 -0800 (PST) Date: Fri, 31 Jan 2025 21:20:24 +0100 From: Stefano Brivio To: Prafulla Giri Subject: Re: Apparmor (and other) Issues Message-ID: <20250131212024.34733b6d@elisabeth> In-Reply-To: <3mWvqHbG0sGUhoq9ersir5eXDcFpZkAm8BGfuhs3YOBV36rlbJ82aj27diLMkSjg8YQnrQajsHKkcVh3kXG9gc-o2HZF2rQXo9DnqkqbwNQ=@protonmail.com> References: <20250129104112.0756df5c@elisabeth> <20250129194854.6b67fbfe@elisabeth> <3mWvqHbG0sGUhoq9ersir5eXDcFpZkAm8BGfuhs3YOBV36rlbJ82aj27diLMkSjg8YQnrQajsHKkcVh3kXG9gc-o2HZF2rQXo9DnqkqbwNQ=@protonmail.com> Organization: Red Hat X-Mailer: Claws Mail 4.2.0 (GTK 3.24.41; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: sAvdkz1Jb2OecFDEE1zIdfFfDOzGA3VrUjGVxBMta1s_1738354830 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: PULPDW57ZXE4OA6JTRX4PNDUNTNPR75Z X-Message-ID-Hash: PULPDW57ZXE4OA6JTRX4PNDUNTNPR75Z X-MailFrom: sbrivio@redhat.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: "passt-dev@passt.top" , Andrea Bolognani X-Mailman-Version: 3.3.8 Precedence: list List-Id: Development discussion and patches for passt Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Thu, 30 Jan 2025 10:05:14 +0000 Prafulla Giri 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