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=TuOqMLAm; 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 905CA5A0275 for ; Fri, 07 Feb 2025 10:16:39 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1738919798; 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=hBdz0/09AvamyUBRtO5lH+Z97BryHudhdRPxpViDivY=; b=TuOqMLAmBQfn79mskp6VYEZ4IZaNuvXJlQsaS+bYQkg4OO6HWODl1l2M94Ik7mCsVY0V+r 4aLXvW6TQ2uAmREfJMg71v1f/HrDSIM4xvZGMskovfmYrhxz5GOD2kBdGG2I6/3IryiUMw FXwng2Y0V5rquOGN0B2KTvo6NBvxiSE= 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-189-vA1re0N-PJCgB88xj5UZvQ-1; Fri, 07 Feb 2025 04:16:37 -0500 X-MC-Unique: vA1re0N-PJCgB88xj5UZvQ-1 X-Mimecast-MFC-AGG-ID: vA1re0N-PJCgB88xj5UZvQ Received: by mail-wm1-f71.google.com with SMTP id 5b1f17b1804b1-438da39bb69so14524625e9.0 for ; Fri, 07 Feb 2025 01:16:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738919795; x=1739524595; 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=hBdz0/09AvamyUBRtO5lH+Z97BryHudhdRPxpViDivY=; b=wazDP6qZvbgMVHm+l1gNF6aIlJYn3fHFncj8bR5XdbcTKwgRhlU+BQTYfq8YZqSUKO WP2cD12kQ73tXZK1C3Oj9TaPIre9A39/XjyNAMx23rzMXUeEFTBexG1UO0VBYEq+sNWk xsKUliXlD6ZXsOnWpWmYRbS5upAPuNT+5GbHD+8lYNIGc3mxbFqYOs0+gThEXAMpmsK1 NT5yqREISTmzm2S7Bv+O3bLISnphiPo2eW4WwBdJruR2AGxgkgWh5FX/XlSFr2FkMgzN DcRxEZ11kg9zJlfRXShCymiSbQqxSLV0OlNeVZ/Hw1H5aee2zb96xlHGi5jTh4Y/OIOA HygQ== X-Forwarded-Encrypted: i=1; AJvYcCVOohjLGOMscSquNy+EVVfrdbuWKKNyFOIZWtZI4i+tGLtlj7i3ASGRqp89Ma4YKXni8HUouView/8=@passt.top X-Gm-Message-State: AOJu0YzoIR5KMefUeNbAzzR2cNqAKGGr5xcirDyDEqqqH5jqPzuGugGY hNof6JfWklJgnRqcYdmbvD9JsCWVVcEfJitCs80cxSiOlW2SCZ317ZACMeEE+xJKbnDymT0bh44 7dyiO20K6FlIu0cJK4hKqAYNssiI+gzlRyarUHkfO7UeQHIQ0+WXyUt5k/Vaa07ZH2Tt42qx9YJ Hc/mwfWAN8mJyEQD1oWnVBKwUka3ujBmcA X-Gm-Gg: ASbGncsrX8s5GKSV3MUTR05zaIqCeZYcKZR3WPThIm5FBeQvQxuGVR+kvbELM8smF+0 eetxrADfXrkqxjt7hQrajQJkvM5i358FeZXjxfRSAKDkYcPTrNEX1gynmUpwSWk/4xyRsHE1uyP 3fq7lWLvGTyOl5nNvNk6eN13IsHWLytZkFDqIlcX6nXGxTysDT37T0b8uDquDGpqSLQiBcrbnty BZc5QWVvvtcwSXbBgOhTDYgh04xZFOEooT1ilyZa22M59d/w+vbLVH5tdl3x+oUUpnsKPOOXR26 x0EuiQ1LEqjI0QBp6bh2DT2cmz6B0TliyQ== X-Received: by 2002:a7b:c001:0:b0:434:f5c0:3288 with SMTP id 5b1f17b1804b1-439250df455mr17133715e9.29.1738919794601; Fri, 07 Feb 2025 01:16:34 -0800 (PST) X-Google-Smtp-Source: AGHT+IEG/06S/OxzOYgGaURkjHYgMHOpN9xx4BE6EfCw+wbfCy70MjPxh6zYWgUbcd9efoU9VcbsUQ== X-Received: by 2002:a7b:c001:0:b0:434:f5c0:3288 with SMTP id 5b1f17b1804b1-439250df455mr17133325e9.29.1738919794060; Fri, 07 Feb 2025 01:16:34 -0800 (PST) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [176.103.220.4]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4391dfc8897sm46849275e9.31.2025.02.07.01.16.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 07 Feb 2025 01:16:33 -0800 (PST) Date: Fri, 7 Feb 2025 10:16:31 +0100 From: Stefano Brivio To: Prafulla Giri Subject: Re: Apparmor (and other) Issues Message-ID: <20250207101631.0875e141@elisabeth> In-Reply-To: References: <20250204172242.76889328@elisabeth> <20250204201448.0bf3f7a3@elisabeth> <20250204233441.6cda8c64@elisabeth> <20250205111651.59551470@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: AoeOt9Y_E0e1TCOSN3D6GApoq_RYwAMencI5FmABQ_w_1738919796 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: 7Q54D7RKMUNGATTS5TRSXFMPTXHD6BOG X-Message-ID-Hash: 7Q54D7RKMUNGATTS5TRSXFMPTXHD6BOG 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 Fri, 07 Feb 2025 06:49:45 +0000 Prafulla Giri wrote: > On Wednesday, February 5th, 2025 at 4:01 PM, Stefano Brivio > 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: apt-get -o Dpkg::Options::="--force-confmiss" install --reinstall passt > whereas SELinux is doing it's thing as it's supposed to. Right, that's because SELinux can do this: https://selinuxproject.org/page/MultiCategorySecurity with AppArmor, it needs to be "emulated", somehow. > > We're just trying to make things as > > strict as possible, and depending on specific paths. > > I see. I'm glad this approach of as-strict-as-possible is being taken. > > > We'll probably need to make them a bit looser for the moment being > > and perhaps just allow passt, no matter who starts it, to write to > > /var/run/**. > > 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. > It also seems that more and more of us use $XDG_RUNTIME_DIR in lieu > of /tmp in our personal shell scripts, because it kinda' feels like a > more private /tmp. Yeah, it is. > Also, the `passt` update fixing DNS issue hasn't yet made it to > Debian Trixie, yet. I didn't release the fix yet. I merged it (upstream), but actually I was expecting you would give it a quick try. If I'm more confident about the change, I can do things faster. > I figure it's going to take some time (?) Perhaps > I should venture to Debian Sid, myself. It's not in Debian Sid either because I didn't make a new release of passt, yet. It probably makes sense to make one next week (we release quite often, especially if there's one or more fixes that might be important for somebody, such as this one). As Debian maintainer I also update Debian packages within a couple of hours. Sid to testing is usually five days of difference, look: https://tracker.debian.org/pkg/passt/news/ -- Stefano