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=Qbwv3hco; 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 184735A0274 for ; Sun, 09 Feb 2025 10:08:59 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1739092137; 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=7jGCKM3b9MjzAuMB0n5ydLhVV/prQkFAkOk3/fZlIJY=; b=Qbwv3hcotRzL5xw4y7pUffgtvyAhRFZhmgSekeXTHLoSUY2SGGTlVAg0+MKew1+XTABchT qJXH/rLfmtjE31WJkudVzz6q/Fd9zaXB3ketTYCV/Hke21PV6OpZZbzJ9nDUPJT+Kd8i6f Xdpa/MeqoxFLeRavxVhs0y8YalofoU8= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-284-bgtJuqnBPBO8jjxVTX9I-Q-1; Sun, 09 Feb 2025 04:08:56 -0500 X-MC-Unique: bgtJuqnBPBO8jjxVTX9I-Q-1 X-Mimecast-MFC-AGG-ID: bgtJuqnBPBO8jjxVTX9I-Q Received: by mail-wm1-f69.google.com with SMTP id 5b1f17b1804b1-4393b6763a3so2813735e9.2 for ; Sun, 09 Feb 2025 01:08:56 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739092134; x=1739696934; 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=7jGCKM3b9MjzAuMB0n5ydLhVV/prQkFAkOk3/fZlIJY=; b=ibZg1FMW9dvN6dCNKuWzB5i4kPAkKBJIcedlVdlRG7MJgS/PhJ53BW15aC+hu2+sh/ O0ha7AzyiEtO6Sl4ptlHcixQGuqBlxi46ipGbPxpDMmAheshU74aym6XsVXcWrvm45EG 1KhQsKChMpzGJT8f12cxU5CzNGH+jjty5YgFcMJGwafzFBf0txo60eWvpU1QqAk6ehGT ET7i/Vm8kuBTqmXLJvyIcxDiBLhWiI1xDrsII63ZuzyyzLGOH8nWrcf4SX3RlZHNtutA 9ZrBW6lvBDOMTLhEjaR18A2DMFof1E3G2rnz1pShCHrqk52nJHwfbs1xDlz3vCAIGA9z QYhQ== X-Forwarded-Encrypted: i=1; AJvYcCXY+3WbEvBKnIvr135kDoUmKWCgaMGHzMXoAeX0+0qpMnVhOphMLu82VpH8Y2CNH218PPoZOkm03hs=@passt.top X-Gm-Message-State: AOJu0Yxosz+T6LgYRGhbqZLW3W9BMiJO1nWEaobxApcdMec4Vx67dgXb atR6hw2QBo4LCxDM9MNUxxxY8/ZJLzgT6bWjU0OrqwuzBK66obswRL29rljfTwG5VXmZH/YL/1C vidRP+2cYXMunbiXVv3Cd8csY9aoxvFhQcZzhhmL2NYIjNaPx9O5eyrRdAIxtuwM9o6zCtoL3KL lkyQb3exN4UlcZR8M3Kr0AY3BOZeeHjk5L X-Gm-Gg: ASbGncuiSltt6xyP/azgTR5LoBQmB9nL5VSbONVrncxjjPEKf+7GlBA8oX9OdbAsr52 NCTJ44mZ6ieRpWrWZuQYVfaqHyOKEOY9jv/HaV0KEw7Os7Ok/+hwRKntTsPFr0hVanxJZFn5Kf5 xlsHMJYhZmcYVrQJEq4ObkOE7N6JsXq6c6mOlmu9TkKGMSpdEtNZSsbl6l76WgG8ozlan+6CX/F ohXePFVFYOh0ZuPaBKKLFl9SrLZ4s5Hp8PHOMPCs/GdiXNjlN5ftf3vQ/xUXsc7bb5QJxy2uG5w 5iA/2EfAP9xmk00j X-Received: by 2002:a05:600c:524c:b0:431:5044:e388 with SMTP id 5b1f17b1804b1-439249b2ec4mr62741415e9.22.1739092133616; Sun, 09 Feb 2025 01:08:53 -0800 (PST) X-Google-Smtp-Source: AGHT+IGHYkYf4ChGmgeNJm52ECVMf58DX7CYJWFTzBuvdJAqNGYX6zQv1cdLCMipL3HLQXa1i5JIjg== X-Received: by 2002:a05:600c:524c:b0:431:5044:e388 with SMTP id 5b1f17b1804b1-439249b2ec4mr62741115e9.22.1739092133073; Sun, 09 Feb 2025 01:08:53 -0800 (PST) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [2a10:fc81:a806:d6a9::1]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4390698a164sm91899005e9.2.2025.02.09.01.08.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 09 Feb 2025 01:08:51 -0800 (PST) Date: Sun, 9 Feb 2025 10:08:48 +0100 From: Stefano Brivio To: Prafulla Giri Subject: Re: Apparmor (and other) Issues Message-ID: <20250209100848.4e5c39de@elisabeth> In-Reply-To: References: <20250204201448.0bf3f7a3@elisabeth> <20250204233441.6cda8c64@elisabeth> <20250205111651.59551470@elisabeth> <20250207101631.0875e141@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: 6CnQIpxNiEXfAeiCVNuSKbzoKzkcyA7OME4zOQGrots_1739092135 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: XWDUOQIIYSEQHC6SCBBDSW7ZHFHKB2HG X-Message-ID-Hash: XWDUOQIIYSEQHC6SCBBDSW7ZHFHKB2HG 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: Andrea Bolognani , "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 Sat, 08 Feb 2025 17:19:59 +0000 Prafulla Giri wrote: > On Friday, February 7th, 2025 at 3:01 PM, Stefano Brivio wrote: > > > On Fri, 07 Feb 2025 06:49:45 +0000 > > Prafulla Giri prafulla.giri@protonmail.com wrote: > > > > > On Wednesday, February 5th, 2025 at 4:01 PM, Stefano Brivio > > > sbrivio@redhat.com wrote: > > > > > > > But the libvirt profile is not associated to the > > > > process, oops. > > > > > > Oh, so this is what is being worked upon: that Apparmor is not making > > > the association > > > > > > That, I'm not sure, but at least Andrea asked openSUSE and Ubuntu > > people for comments. I just prepared (and merged) a workaround for the > > moment. You are Cc'ed on the patch. If you want to test it, you should > > add this: > > > > # Workaround: libvirt's profile comes with a passt subprofile which includes, > > # in turn, , and adds libvirt-specific rules on top, to > > > > # allow passt (when started by libvirtd) to write socket and PID files in the > > # location requested by libvirtd itself, and to execute passt itself. > > # > > # However, when libvirt runs as unprivileged user, the mechanism based on > > # virt-aa-helper, designed to build per-VM profiles as guests are started, > > # doesn't work. The helper needs to create and load profiles on the fly, which > > # can't be done by unprivileged users, of course. > > # > > # As a result, libvirtd runs unconfined if guests are started by unprivileged > > # users, starting passt unconfined as well, which means that passt runs under > > # its own stand-alone profile (this one), which implies in turn that execve() > > # of /usr/bin/passt is not allowed, and socket and PID files can't be written. > > # > > # Duplicate libvirt-specific rules here as long as this is not solved in > > # libvirt's profile itself. > > /usr/bin/passt r, > > owner @{run}/user/[0-9]/libvirt/qemu/run/passt/ rw, > > owner @{run}/libvirt/qemu/passt/* rw, > > > > to your /etc/apparmor.d/usr.bin.passt. Note that changes to AppArmor > > policy files are retained as configuration, so, if you edit it, package > > upgrades won't override things automatically. You will need to: > > I seem to have botched things up really good, or we're getting into more and more trouble here: Worry not, I can explain: > 1. I have manually `make install`-ed passt (and friends). > $ passt version # I don't know what's causing the non-AVX2 thing issue If you install it to /usr/local/bin, other than adding a profile for /usr/local/bin/passt{,.avx2} as you correctly did, you also need to add the /usr/local/bin path to the "abstraction" that's included by the profile. In /etc/apparmor.d/abstractions/passt we have: /usr/bin/passt.avx2 ix, # arch_avx2_exec(), arch.c and if you want to do experiments with a local version that needs to be: /usr/bin/passt.avx2 ix, # arch_avx2_exec(), arch.c /usr/bin/local/passt.avx2 ix, > [...] > > If, however, I uninstall the manually made version (with the apparmor profile back to pointing to /usr/bin/passt): > > $ passt --version > passt 0.0~git20250121.4f2c8e7-1 > Copyright Red Hat > GNU General Public License, version 2 or later > > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. > > $ virsh start --domain vm1 > Domain 'vm1' started > > So I figure it's okay after all. Good, thanks for checking! That patch is already applied by the way. As I mentioned, I'll make a new release (and Debian packages) in a few days. > I am surprised, the upstream tree does not seem to contain the recent DNS related patch that I shazamed and tested just a couple of days earlier ( b4 shazam https://archives.passt.top/passt-dev/20250203082210.2114348-1-sbrivio@redhat.com/ ). I have just emailed a reply at the patch's own thread, too: https://archives.passt.top/passt-dev/pXatirFM4Zm6ZSKXYsfeyZnHlL8JlQDKRUNtyLqbzrUOFcItX06upuk1cPYaufL1HzqHygkWvySVhawtV8zVi8Ou9qmhz_EvuQxr46UOi3Q=@protonmail.com/ Right, I thought I applied it, but now I remember: I wasn't entirely sure it fixed your issue, and I was waiting for reviews as well, then I forgot about it. It's merged now. > Please let me know if I'm still missing (or failing to report) something. I'd hate to unknowingly be a bottle-neck by failing to test/report something. No worries, you're definitely not a bottleneck, my mind sometimes is. Thanks for the all the tests! > > > I believe user-mode virtual machines only need access to > > > /run/user/$USER and not /var/run. Not even /run/*, but only > > > /run/user/$USER. So if that work-around is to be implemented, that > > > would be the strictest version of it: each user-started passt process > > > gets access to $XDG_RUNTIME_DIR of it's owner (and not outside of it). > > > > It depends, because if you start passt as root, socket and PID go to > > @{run}/libvirt/qemu/passt/, and if you don't, the location becomes > > @{run}/user/[0-9]/libvirt/qemu/run/passt/*. > > > > @{run} is an AppArmor handle for /var/run and /run, I think (aren't > > they generally linked anyway?). Note that Ubuntu and openSUSE might > > use slightly different paths. > > /var/run deems to be a symbolic link to /run which is a tmpfs mount on my Debian Trixie machine. Right, yes, hence that @{run} alias that covers whatever you have on different distributions or different versions. -- Stefano