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=IiZdJpaK; 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 84A735A061A for ; Tue, 04 Feb 2025 23:34:48 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1738708487; 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=OHtoLyq7EeWQTdct3nE5aHMsKgQYc5lV3skvxJr1c7c=; b=IiZdJpaKhRZ0fpbtpSFS99M/lq9xOqF6sa/BkBZBKjz8p0Ttqlpj+OcmdnU5wxIFQpuQQN UbZNL9nw0wVQNQ9xOQth06jrznJNCuN34AGaerrQqftoccVFR3tJ/oSH7LOXl9UZXsQz62 D/ox6OdxjYiQ55O6hVQWYBsXwY92zgg= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-694-0UDjNVSBPPam0ldZHm_NUA-1; Tue, 04 Feb 2025 17:34:46 -0500 X-MC-Unique: 0UDjNVSBPPam0ldZHm_NUA-1 X-Mimecast-MFC-AGG-ID: 0UDjNVSBPPam0ldZHm_NUA Received: by mail-wm1-f70.google.com with SMTP id 5b1f17b1804b1-4362552ce62so30972775e9.0 for ; Tue, 04 Feb 2025 14:34:46 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738708484; x=1739313284; 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=OHtoLyq7EeWQTdct3nE5aHMsKgQYc5lV3skvxJr1c7c=; b=Gq+Vb4PjriTjksqu3cs0TRCGzAqnJulnuO+FsphC8sACEKRvz8JuqrlH27nNa+A2ze GtOtICXJKrFFhrck5Wgy5n3RrPD8J/lRWBTTW7nXnvv9Im6l9XKwjJf/BiU/riw5P15T X6PveSwS5o9ZeVp5nXd2yhC0K5R4og3ipzzgHswydLRKHiLzNcz6V7clRoZIIEBS31kp lZDDuwTn67ZHkWMndpFAdHCa8GHEsrxdbgp/nTJLreibwHC3w0lACkFr4g9GYq9e6Bkw pmtroYLyeC/7ttsQH7oqHDSaHt0125VVH62hFPo9qfvEqiDBQt02UqRx4gC/zYgmO2bS uD7w== X-Forwarded-Encrypted: i=1; AJvYcCXyhXGUVZ2WFBcnqULe3g6Jou5fg/+DL0Cd8RmyixSHTVukMtF6TnUJue32YwKFYzUP77hA+bd6Wzw=@passt.top X-Gm-Message-State: AOJu0YyNP/PpGHdkjYyO1HRHhCOjzca/qPVUNMTzBn3bySR0tjffZ7fJ yAZavzyuA7fkZzIdSzAXm/yGLHmVGPLoIZtFYD4ymXisVSDF9VM1YkFe78FQLAlhIO/0qckZOda vYOrxjHC/DfHA5uPHg+1JyaeSGQzM7VThH7kv0tYpdek4WrvPirHtfXKu7D69RVDSwuI536sVJ3 80NRuGfvKaosT5Hg4gHGqAbbHmK3eh91kE X-Gm-Gg: ASbGncsgOYTyEavumXcFd/mOhZAaAlTK0rVWCYYisFKIdcWZI8zyXkwgQSlkTjxbXRw Zbjq4hLo/1m8vrvyrmME/3tJKFCddK86pN8am4rE+Km+OPzuD6iPhVFVH45gIt2v4vpMAmNwDNp Cf0fr8QDCTaApr3y7LXvQ0cuc6Xrjs5/l+i8Eo1puwujItk9lgJGd+b10udQg9tEttS9TOzazDP pz5gtp11ngokLst0fB2OWO1d9w9rT3XRFPB6lYGHfxCwMLfWiX5fj7aeRgG1IpqIvfF0YLR3uhU 7oX8CjnvwEcuRpu5tcrl7tyoMOtof1f1fA== X-Received: by 2002:a05:600c:3c8e:b0:436:f3f6:9582 with SMTP id 5b1f17b1804b1-4390d433bbamr2041095e9.8.1738708484167; Tue, 04 Feb 2025 14:34:44 -0800 (PST) X-Google-Smtp-Source: AGHT+IHXVwDl//xBZwn7+idl8BP437y6OjU+XhUBQhbE1Awn3Ktgj6FSa6w+VmygTzv81p0mc92EYA== X-Received: by 2002:a05:600c:3c8e:b0:436:f3f6:9582 with SMTP id 5b1f17b1804b1-4390d433bbamr2040955e9.8.1738708483667; Tue, 04 Feb 2025 14:34:43 -0800 (PST) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [176.103.220.4]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4390d94d7d4sm1761955e9.10.2025.02.04.14.34.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 04 Feb 2025 14:34:43 -0800 (PST) Date: Tue, 4 Feb 2025 23:34:41 +0100 From: Stefano Brivio To: Andrea Bolognani Subject: Re: Apparmor (and other) Issues Message-ID: <20250204233441.6cda8c64@elisabeth> In-Reply-To: References: <20250203093531.6a71cc81@elisabeth> <0gHPSAbajW7n2zyIE-8k2vez7nkpAHQOnP4p6yfc6i5v948AExss0zBAYKF-92Yqf90DhAg3Xx9u19aw4TtSQLnpNgvCEa--wkPTL0PDdnM=@protonmail.com> <20250204095000.4ca5c43a@elisabeth> <20250204111724.48b73b37@elisabeth> <20250204172242.76889328@elisabeth> <20250204201448.0bf3f7a3@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: 37hR5D9qhzmKHZ_4iBJJhwt8p0xobVAB5Mlyoy9vkzk_1738708485 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: MZZY5YLHVATIK7BFGMDUP2YINWQCHFSS X-Message-ID-Hash: MZZY5YLHVATIK7BFGMDUP2YINWQCHFSS 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 14:19:34 -0800 Andrea Bolognani wrote: > On Tue, Feb 04, 2025 at 08:14:48PM +0100, Stefano Brivio wrote: > > On Tue, 4 Feb 2025 18:46:37 +0000 Andrea Bolognani wrote: > > > > 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. > > > > > > Sounds to me like this would require granting the QEMU process access > > > to roughly the entire filesystem? The disk image could live anywhere > > > after all, and if we can't dynamically add a rule for the exact path > > > the only way out is a free-for-all approach. > > > > Right. That's what we did for libguestfs as well, the image can be > > *almost* anywhere. But it's not free-for-all: you're just granting > > *limited* filesystem access (not to sysfs, not to /etc, and so on). > > > > And I had to build a *very* loose profile for libguestfs because that > > applies to root as well, but for rootless libvirtd, it might even make > > sense to restrict access to just @{HOME}/** and /tmp/** (that's what I > > did for stand-alone passt, for example). > > That could work, I suppose. Needs to be discussed upstream, making > sure to involve those who are more experienced with AppArmor than I > am Sure, that makes sense of course. > especially since it's not just a matter of updating the policy > but fundamentally changing how the driver works when operating in > unprivileged mode. Well, right now it runs unconfined, and (at least with passt) networking doesn't work. Pretty much any change would be good. :) I've been disabling AppArmor when I start guests for quite a while now, thinking that I just broke something on my setup while developing stuff (I reported that to you but I wasn't sure how the whole thing worked...). Oops. > > I'll try to submit a pull request at least for Debian in a couple of > > days. > > Be aware that I will emphatically refuse to introduce changes to the > Debian package unless they have been merged upstream first. AppArmor > support lives in the upstream repository, and all fixes and > improvements have to go through it. Then never mind. I can help filing a Debian issue if needed, let me know. Or let me know how I can help otherwise. I would consider a workaround for passt for the moment, say, the whole block: /usr/bin/passt r, signal (receive) set=("term") peer=/usr/sbin/libvirtd, signal (receive) set=("term") peer=libvirtd, signal (receive) set=("term") peer=virtqemud, owner @{run}/user/[0-9]*/libvirt/qemu/run/passt/* rw, owner @{run}/libvirt/qemu/passt/* rw, as part of the profile for usr.bin.passt. If you don't see issues with it, I'll go ahead with that. I still need to check openSUSE though (I haven't tried for a while there). -- Stefano