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=PyANBcM1; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by passt.top (Postfix) with ESMTPS id B99015A0275 for ; Tue, 04 Feb 2025 17:22:49 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1738686168; 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=Sfq+XDrJa0Yi63nHcvFmWYUGVRBMSldsJ4aIq5bLMew=; b=PyANBcM1Hsm2K57qJKS3MhrM4WA+9yNXHTRvxDpkiIrrcqaly9whmU+aXVJ6sTbiWp5GSW m2vLV6Wsn18CC1SCB/uGR9Zm5XoifjvqVsAnzBF2AZsD3N7oz3rubxYzYu7/YQOpIK0H7V 2M19n9fMf5Jwl/NBC+G6AVksrx13cok= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-302-nLIGMnYdNAivHP5lzYoq2w-1; Tue, 04 Feb 2025 11:22:47 -0500 X-MC-Unique: nLIGMnYdNAivHP5lzYoq2w-1 X-Mimecast-MFC-AGG-ID: nLIGMnYdNAivHP5lzYoq2w Received: by mail-wm1-f71.google.com with SMTP id 5b1f17b1804b1-43582d49dacso41572455e9.2 for ; Tue, 04 Feb 2025 08:22:47 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738686165; x=1739290965; 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=Sfq+XDrJa0Yi63nHcvFmWYUGVRBMSldsJ4aIq5bLMew=; b=TjsVmP4MtDk4A6AACuhx+XCq+wKastx5Jt3ZdYQN+QWEJsZp49bav3BRUzk5evyZ/j PNu991Aj+t49w91Xk7IvGcS8vGtB5jr8jA0Auadp5dL9pGn1uzEa8YH3WLhp1pmVuM3Q ciEaG0kfQ571LinVz/ykTLZafYyFKUa86rRhUCdj+oYAzCp5JNZsxg87ggTmqej22nzE KnOjN1oVS8muQOOazBSXrkBD4d3uNE4tSfDcBFXak6swYVHOP8cHBe3olyE0+aN81HoE U/LZRa6jEKuww6DgljnJ/STeoZtG9/nubehc+8gWAYSyaa/OKE+Joka2WXR+/Gco8Was eVWA== X-Forwarded-Encrypted: i=1; AJvYcCXi6Jwj1ELxlgFv0LPnDLAAyRYoQ6mlPG5O7xy96wY9UqDg67Gv7q2Nnd4w6A7sNacJ2d/pjudVHoM=@passt.top X-Gm-Message-State: AOJu0Yyf3TKKieE17sqKTALpNDtr9aMXIBIW/8WtM9TXPv6b2Mg3eG8I JAA2Jf7T8WZjTs6m55lruDnpBwtOwpFtGhknSAtf4u98PIJnWrDlllcrWJyAWSPaKpTSPpBlAXn e9olVfJ0HojQdMb2a8217lxwzxCey3LpAqPGdcoy1SeAHXArfRG9/lvxmGpaIE9LJQjyiFGVEWh hHJPCZz/gT/f8vDgqznyQN8+CA42WO45O5 X-Gm-Gg: ASbGncu/0e1Rque/yE+Pxj753ofNJ9GUJ4NH2RBP8QsyLa4gI1ddQa/NFrkDreuH0sY pBX6pYY1JmWm6IbB6jFLa5GrTSIKpBNfiJTvoGzkhZfAcKRcrHdv1EKkT0aKomeC2KQxZ4ZzcZA 2RBMUjnFIFHQ69Iy5v+gTN9Eg8W0FzG3YHIdXH/xjvPbxjkGVliGXVmy/EA325iOS4RUHSNzXUg Z0enuhxSouOCitodhaDDjKsMs+7D2kMyK4HaMQBNRbBft8vySvahgB6D8u4435ylD5DXokqgO1z 11XHhK6X+zS/PW27a26SnPT9icX9DaUTww== X-Received: by 2002:a05:600c:3501:b0:434:a7e3:db5c with SMTP id 5b1f17b1804b1-438e2446708mr238558865e9.11.1738686165250; Tue, 04 Feb 2025 08:22:45 -0800 (PST) X-Google-Smtp-Source: AGHT+IGc0WVzVTfBAhQiNdctNzQsX/VkYdFNly5bAIw+EOAqcByULA7VqU7TejKR47WQCEdAitN86A== X-Received: by 2002:a05:600c:3501:b0:434:a7e3:db5c with SMTP id 5b1f17b1804b1-438e2446708mr238558515e9.11.1738686164708; Tue, 04 Feb 2025 08:22:44 -0800 (PST) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [176.103.220.4]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-38c5c1b547csm16436229f8f.62.2025.02.04.08.22.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 04 Feb 2025 08:22:44 -0800 (PST) Date: Tue, 4 Feb 2025 17:22:42 +0100 From: Stefano Brivio To: Andrea Bolognani Subject: Re: Apparmor (and other) Issues Message-ID: <20250204172242.76889328@elisabeth> In-Reply-To: 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> 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: fb61jhTtZ7OJ0YumSgaTrE17GBxATHycTWNdny7-KqQ_1738686166 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: 26M6BLXPOU6U6VS6DX2GDPMQECG6EW3S X-Message-ID-Hash: 26M6BLXPOU6U6VS6DX2GDPMQECG6EW3S 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: 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, 4 Feb 2025 15:50:43 +0000 Andrea Bolognani wrote: > 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=1094583 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 alpinelinux3.20 --network backend.type=passt,portForward0.proto=tcp,portForward0.range0.start=40922,portForward0.range0.to=22 --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/user/1000/libvirt/qemu/run/passt/1-alpine-net0.socket --pid /run/user/1000/libvirt/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. Ah, sure, sorry! I didn't mean to waste your time with that, it was clear to me that passt doesn't start there... I just wanted to show the setup. > [...] > > 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. Why do we need additional profiles, I wonder? Are we trying to replicate the MCS (Multi-Category Security) stuff from SELinux? > 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. Oh, now I understand the whole "template" thing finally! And now that you mention virt-aa-helper (I wasn't aware of that) I also found: https://gitlab.com/apparmor/apparmor/-/wikis/Libvirt Yes, of course, that won't work unless you're root. > This is probably undesirable, but at the same time I'm not really > sure how it could be fixed. If I understood the purpose correctly: implementing equivalent MCS functionality in AppArmor would probably be the only "complete" fix. But for the moment (or more realistically): > 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... Profiles could reside in other places too, but they won't be associated "just like that". A privileged helper could... help. But if users can edit their own profiles in their homes, that defies a bit the point of AppArmor profiles altogether. > Do you have any ideas? Probably you should ask somebody more familiar (openSUSE/Ubuntu maintainers of libvirt, or the authors of the virt-aa-helper thing?), but a couple of quick ideas: 1. user-specific subprofiles could be added at adduser time (is there a hook?) and libvirtd could use aa_change_hat(2) to select the appropriate one based on UID 2. (most reasonable I think) don't use per-VM profiles for the rootless case. Define a single "libvirt-user" (or "libvirt-session") profile and use that. We could copy it from the existing ones I suppose. I think that MCS-equivalent functionality is anyway much less critical if guests are started as unprivileged users because you have a strong separation given by the fact that guests are started as different users. If all the guests are started as root, and multiple users have access to that facility, user separation is much more seriously endangered, hence a stronger need for per-VM profiles. And, stating the obvious, it's counterproductive to force users to run guests as root because we can't have that kind of functionality. By the way, I recently happened to introduce an AppArmor profile for guestfs-tools: https://salsa.debian.org/libvirt-team/guestfs-tools/-/merge_requests/1 there are no separate profiles, there. I can try to work on this but I'm really a bit too busy right now. If you can, great, otherwise, let me know. On the other hand this feels pretty urgent. :( -- Stefano