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=DaHNbQmJ; 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 3C6765A0275 for ; Tue, 04 Feb 2025 16:50:48 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1738684247; 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=Wx5UhyV4jqWj4ASy4k0Xo9/uS/c9Qo+jcC+kp7O0qIo=; b=DaHNbQmJJ6lKFgeCzMp1XAXMGq4thJC+ADANvdg98mWJds8X5zlyIJrHFLlCdYZXtRDvkC W28zwNO1h2lyeSm9ZeTYOnb9ESWO5aVyA1L5GzDFjrnOoDES95iTGGhstIWNdAC5120jtY D0lKYdfIUYbgx49q72LxQVoBXhY6F3E= Received: from mail-qt1-f197.google.com (mail-qt1-f197.google.com [209.85.160.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-587-Vtqf2KAkNAm4c_RuTAL_wQ-1; Tue, 04 Feb 2025 10:50:46 -0500 X-MC-Unique: Vtqf2KAkNAm4c_RuTAL_wQ-1 X-Mimecast-MFC-AGG-ID: Vtqf2KAkNAm4c_RuTAL_wQ Received: by mail-qt1-f197.google.com with SMTP id d75a77b69052e-46dd46d759eso105810881cf.2 for ; Tue, 04 Feb 2025 07:50:45 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738684245; x=1739289045; h=content-transfer-encoding:cc:to:subject:message-id:date:in-reply-to :mime-version:references:from:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=Wx5UhyV4jqWj4ASy4k0Xo9/uS/c9Qo+jcC+kp7O0qIo=; b=JMiup06U+o5GdOYBg0CheewaiFyC9AD1qDvAMd4XbMfoiD7bwpgu3U87MRLorMaE0W oR1zR269EtM72TEK1Vao+PcwlqEBeoh/Wu7fgHI16/348uoIQLSPHMwHlmu3+cokLqd8 bHQbJcgGmi9q0FQ3EkyUw0zaiO0I+pfg93Bwc9Y0Acd0gSONbmcsjqtygKb/u+/UxEtr 9eDJLnejBhwdeFTTU7AfBowdjf4GPPrY84piWm02yUt8s/c2LjB5zL5DMZNIX7PrS8Wa p3PtGG1ORQPy1er+lNiIKuG6oFVAyeJMo93rz+NZMUiDnHcgfSkbgHq8BMzwgLR7CwZk g6cg== X-Forwarded-Encrypted: i=1; AJvYcCXDmZeMXKcX3ue0gOw+P4UGpCJDboCwmmuvDjveaIJY8wjnRRBXjZ7zkOmVdMev5NFJ83VEpgLfQGs=@passt.top X-Gm-Message-State: AOJu0YyTqzeS8ZJ1bTrGjPz/p/UDkHPIX9SblFfjYRN5hwVBCA0++bOK 25ZlMNqoEzQx+2Rpxgxj5juAE68DzepCe2mYl3z8HQ3wjPbX4kqMVzhIJORWjsGQZzDQPysrNXy 0ig9ADCnK5/fQ6nJrfzW9aUZnMs3YM+blyvG6sv36HKJxrDvEijAhkMnMbQpqRj4yThRzIrrSgO SlDgsTn5C6Ho2azyyIPyJ/5JvU X-Gm-Gg: ASbGncv6OZKJ5b2Q8CqwKQMtvgwYv6qjvr2L6G+wq2iwHJPVUkDYhIBt+NfDTKpyFNM K5if0WUSL7Zq5zqumIHDdctAwwQY0heCeKC2ZLcXnUWJpNMITpyRd+6wRjYe7 X-Received: by 2002:a05:622a:1f95:b0:466:8f68:a606 with SMTP id d75a77b69052e-46fd0b8933fmr408967661cf.40.1738684245282; Tue, 04 Feb 2025 07:50:45 -0800 (PST) X-Google-Smtp-Source: AGHT+IElRe1BUReyjJcUd76cpMQ+E+qpoK5c1bBst1IcO/Rh27yDiw8ImpKe9fEdjR5M+cF4cVqR1boH+Gp4YFYnkiM= X-Received: by 2002:a05:622a:1f95:b0:466:8f68:a606 with SMTP id d75a77b69052e-46fd0b8933fmr408967261cf.40.1738684244895; Tue, 04 Feb 2025 07:50:44 -0800 (PST) Received: from 744723338238 named unknown by gmailapi.google.com with HTTPREST; Tue, 4 Feb 2025 15:50:43 +0000 Received: from 744723338238 named unknown by gmailapi.google.com with HTTPREST; Tue, 4 Feb 2025 15:50:43 +0000 From: Andrea Bolognani References: <20250129194854.6b67fbfe@elisabeth> <3mWvqHbG0sGUhoq9ersir5eXDcFpZkAm8BGfuhs3YOBV36rlbJ82aj27diLMkSjg8YQnrQajsHKkcVh3kXG9gc-o2HZF2rQXo9DnqkqbwNQ=@protonmail.com> <20250131212024.34733b6d@elisabeth> <20250203093531.6a71cc81@elisabeth> <0gHPSAbajW7n2zyIE-8k2vez7nkpAHQOnP4p6yfc6i5v948AExss0zBAYKF-92Yqf90DhAg3Xx9u19aw4TtSQLnpNgvCEa--wkPTL0PDdnM=@protonmail.com> <20250204095000.4ca5c43a@elisabeth> <20250204111724.48b73b37@elisabeth> MIME-Version: 1.0 In-Reply-To: <20250204111724.48b73b37@elisabeth> Date: Tue, 4 Feb 2025 15:50:43 +0000 X-Gm-Features: AWEUYZlaHArMjn16LC3Tk1tQjvp-5iSnDUbm9H9yzwoUrVaFc_KZjtKrviExOPM Message-ID: Subject: Re: Apparmor (and other) Issues To: Stefano Brivio X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: v8usv9J0FdaoaKYt6NfRdTVqZmaXg7hlHskTGJd9qng_1738684245 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Message-ID-Hash: KCEAHPNMX2CHEOUGHN4AQKC3WJN5G7UU X-Message-ID-Hash: KCEAHPNMX2CHEOUGHN4AQKC3WJN5G7UU X-MailFrom: abologna@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: Prafulla Giri , "passt-dev@passt.top" 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 Tue, Feb 04, 2025 at 11:17:24AM +0100, Stefano Brivio wrote: > On Tue, 4 Feb 2025 09:50:40 +0000 Andrea Bolognani = wrote: > > I've skimmed the conversation trying to understand whether there's > > anything that I need do from the libvirt side, but AFAICT no explicit > > action has been called for so far. > > Not yet, because I was hoping to figure out what's going on, but I'm > actually (almost?) stuck now. I don't think this is the same as > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D1094583 by the way, That issue can only manifest itself when upgrading from bookworm, so if you have performed a fresh install of sid you don't need to worry about it. > This is really pretty simple: fresh Debian sid image, all packages > updated to today. Then: > > virt-install -d --name alpine --memory 1024 --noreboot --osinfo alpinel= inux3.20 --network backend.type=3Dpasst,portForward0.proto=3Dtcp,portForwar= d0.range0.start=3D40922,portForward0.range0.to=3D22 --import --disk nocloud= _alpine-3.21.2-x86_64-bios-tiny-r0.qcow2 > > this works. But: > > $ virsh start alpine > error: Failed to start domain 'alpine' > error: internal error: Child process (passt --one-off --socket /run/use= r/1000/libvirt/qemu/run/passt/1-alpine-net0.socket --pid /run/user/1000/lib= virt/qemu/run/passt/1-alpine-net0-passt.pid --tcp-ports 40922:2) unexpected= fatal signal 11 > > execve() of passt is denied by AppArmor. Starting passt on its own > (passt -f) works, instead. I was initially very surprised to read this, but it makes sense after spending some more time looking into it. Normally, virt-install will perform guest creation in two phases. The first one is the installation itself, which needs the install media to be connected; once that's done, the OS installer will usually initiate a reboot, and when the VM comes up again the installl media will no longer be connected. Other changes to the configuration might happen as well, I'm not 100% sure. Anyway, since you've passed --noreboot above, virt-install will only go through the first phase of installing the guest; additionally, since you've passed --import, the VM will only be defined and the installation will be considered done without having to start it once. As a counter-example, see how the behavior changes when performing a "regular" install from CDROM instead: $ virt-install --name alpine --memory 1024 --osinfo alpinelinux3.20 \ --network backend.type=3Dpasst --graphics none --disk none \ --cdrom ./alpine-virt-3.21.2-x86_64.iso Starting install... ERROR internal error: Child process (passt --one-off --socket /run/user/1000/libvirt/qemu/run/passt/3-alpine-net0.socket --pid /run/user/1000/libvirt/qemu/run/passt/3-alpine-net0-passt.pid) unexpected fatal signal 11 So there's no magic to that first VM start that apparently worked even when subsequent ones wouldn't. The VM start simply didn't happen in the first place. > At this point, which libvirtd (?) process should associate with which > libvirtd profile? Once that's clear to me, I can probably debug further. > [...] > > I'm fairly sure it's libvirt, because I didn't change anything > substantial in passt, and it's anyway the AppArmor profile for libvirtd > that seems to be... missing? And yet it's there. We're going back to the question of how AppArmor works for unprivileged VMs... The short answer is that I'm not convinced it does. In order to make a direct comparison, I've create the very same Alpine VM, with no network interface, both on qemu:///system and qemu:///user. When I start the former, the (filtered) output for aa-status goes from 22 profiles are in enforce mode. libvirtd libvirtd//qemu_bridge_helper virt-aa-helper 25 profiles are in complain mode. dnsmasq//libvirt_leaseshelper 2 processes are in enforce mode. /usr/sbin/libvirtd (862) libvirtd to 24 profiles are in enforce mode. libvirt-1cdfdfd3-a020-45d9-8f88-8e0ce31745c4 libvirt-1cdfdfd3-a020-45d9-8f88-8e0ce31745c4//passt libvirtd libvirtd//qemu_bridge_helper virt-aa-helper 25 profiles are in complain mode. dnsmasq//libvirt_leaseshelper 3 processes are in enforce mode. /usr/bin/qemu-system-x86_64 (1310) libvirt-1cdfdfd3-a020-45d9-8f88-8e0ce31745c4 /usr/sbin/libvirtd (862) libvirtd The additional profiles (libvirt-1cdfdfd3-a020-45d9-8f88-8e0ce31745c4 and its passt subprofile) are generated dynamically when the VM is started and the QEMU process gets the correct one assigned to it. So far so good. After launching the qemu:///session VM, however, the situation is a lot different: 22 profiles are in enforce mode. libvirtd libvirtd//qemu_bridge_helper virt-aa-helper 25 profiles are in complain mode. dnsmasq//libvirt_leaseshelper 4 processes are in enforce mode. /usr/sbin/libvirtd (1589) libvirtd /usr/sbin/virtlogd (1632) libvirtd As you can see, the per-VM profile hasn't been created, and so obviously it couldn't be applied to the QEMU process either. This is probably undesirable, but at the same time I'm not really sure how it could be fixed. Creating a new profile requires dropping a file in /etc/apparmor.d/libvirt, and the unprivileged libvirtd intentionally doesn't have the necessary permissions to do that... Do you have any ideas? --=20 Andrea Bolognani / Red Hat / Virtualization