From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7D7DC2C82 for ; Tue, 30 Nov 2021 13:33:27 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id BC762C53FC1; Tue, 30 Nov 2021 13:33:22 +0000 (UTC) Date: Tue, 30 Nov 2021 14:33:18 +0100 From: Christian Brauner To: Stefan Berger Cc: "Serge E. Hallyn" , James Bottomley , linux-integrity@vger.kernel.org, containers@lists.linux.dev, Mimi Zohar , Dmitry Kasatkin , "Eric W . Biederman" , krzysztof.struczynski@huawei.com, Roberto Sassu , Michael Peters , Luke Hinds , Lily Sturmann , Patrick Uiterwijk , Christian Brauner Subject: Re: [RFC 3/3] ima: make the integrity inode cache per namespace Message-ID: <20211130133318.3lpirmouybdn2c2m@wittgenstein> References: <755446b10c8415fd469b814535c4a12964af3264.camel@HansenPartnership.com> <70b81e62-46af-9d39-3dcb-4cfbae645175@linux.ibm.com> <20211129142235.hez3ovtuj3rpscgm@wittgenstein> <20211129153539.GA26325@mail.hallyn.com> <20211129161650.dtcvh2ozgquz6rli@wittgenstein> <20211130050316.GC32444@mail.hallyn.com> <2246a547-3971-8b92-47a4-589a59a33db7@linux.ibm.com> Precedence: bulk X-Mailing-List: containers@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <2246a547-3971-8b92-47a4-589a59a33db7@linux.ibm.com> On Tue, Nov 30, 2021 at 06:55:51AM -0500, Stefan Berger wrote: > > On 11/30/21 00:03, Serge E. Hallyn wrote: > > On Mon, Nov 29, 2021 at 12:04:29PM -0500, Stefan Berger wrote: > > > On 11/29/21 11:16, Christian Brauner wrote: > > > > On Mon, Nov 29, 2021 at 09:35:39AM -0600, Serge Hallyn wrote: > > > > > On Mon, Nov 29, 2021 at 09:46:55AM -0500, James Bottomley wrote: > > > > > > On Mon, 2021-11-29 at 15:22 +0100, Christian Brauner wrote: > > > > > > > On Mon, Nov 29, 2021 at 09:10:29AM -0500, James Bottomley wrote: > > > > > > > > > > > I kept thinking about this question while I was out running and while I > > > > admittedly have reacted poorly to CLONE_NEWIMA patches before it feels > > > > to me that this is the right approach after all. Making it part of > > > > userns at least in this form isn't clean. > > > > > > > > I think attaching a uuid to a userns alone for the sake of IMA is wrong. > > > > Additionally, I think a uuid only for the userns is too limited. This is > > > > similar to the problem of the audit container id. If we have some sort > > > > of uuid for ima it will automatically evolve into something like a > > > > container id (I'm not even arguing that this is necessarily wrong.). > > > > We also have the issue that we then have the container audit id thing - > > > > if this ever lands and the ima userns uuid. All that makes it quite > > > > messy. > > > > > > > > I think CLONE_NEWIMA is ultimately nicer and allows the implementation > > > > to be decoupled from the userns and self-contained as possible. This > > > > also means that ima ns works for privileged containers which sure is a > > > > valid use-case. > > > The thing is that piggy backing on the user namespace at least allows us to > > > 'always see' where IMA's keyring is (across setns()). If we were using an > > > independent IMA namespace how would we guarantee that the user sees the > > > keyring for IMA appraisal? We would at least have to take a reference (as in > > > get_user_ns()) to the user namespace when the IMA namespace is created so > > > that it at least the association of IMA namespace to user namespace remains > > Maybe we pull they keyring info into a new struct which is referred > > to and pinned by both user_ns and ima_ns? (But I actually am ignorant > > of how ima is using the keyrings, so again I need to go do some reading.) > > > > More moving parts isn't my first choice. But if you need namespaced IMA > > for containers that aren't doing CLONE_NEWUSER, then a separate ima_ns is > > your only option. Is that a requirement for you? > > I cannot think of a scenario where a user wouldn't want/refuse to open a > user namespace to get an IMA namespace... The point is that unprivileged containers are still rare. And for quitea few workloads they won't go away. Especially for a lot of Kubernetes workloads - even if it finally has userns support - won't be able to migrate to unprivileged. And I would think that they would want ima support as well. But utlimately that's something the integrity folks have to decide. If you decide that not having this feature for non-CLONE_NEWUSER workloads then so be it.