From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3FD25C433F5 for ; Sat, 15 Jan 2022 19:16:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233441AbiAOTQC (ORCPT ); Sat, 15 Jan 2022 14:16:02 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36406 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230216AbiAOTQC (ORCPT ); Sat, 15 Jan 2022 14:16:02 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DA124C061574; Sat, 15 Jan 2022 11:16:01 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id EE68160F2A; Sat, 15 Jan 2022 19:16:00 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CDD32C36AE7; Sat, 15 Jan 2022 19:15:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1642274160; bh=xIz/CF6YbL8EiqL9FDuCJmC5vvyTkPGEJgVN97GyLGU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=dPtQDljn0od2iWhSz0uZuVwDb6u6SegDHr4Ej+YDI7clnFa3l4e5B/8NUvWxqXUe4 JdXEB/ew2c+IoDDMwGJG8EI1Md3GHuJ7fxT3TDFLoKAIIfjAHVs5ZlnW8TLHavcW4I INNKdDN/ooJCut402ZyHaHlPJZOdRwuBFE3WC+CyiqpRU4/cQYGossEXrCTuyqBwPt 29gEmrQtoYkCFuybVKm2mu3ZHuYWjiHww9qrw/1vWryj7RveUMiV0je8SuHs4RTX5X qfgE22nBhEQh2vHj/1mwMyIWDCmO80gnex1c2ahwUemCtDDgXLSZQ4b2d5aqdcYZXe ZKKl9RsVyteuA== Date: Sat, 15 Jan 2022 21:15:47 +0200 From: Jarkko Sakkinen To: Eric Snowberg Cc: Mimi Zohar , David Howells , "dwmw2@infradead.org" , "ardb@kernel.org" , "jmorris@namei.org" , "serge@hallyn.com" , "nayna@linux.ibm.com" , "keescook@chromium.org" , "torvalds@linux-foundation.org" , "weiyongjun1@huawei.com" , "keyrings@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-efi@vger.kernel.org" , "linux-security-module@vger.kernel.org" , "James.Bottomley@hansenpartnership.com" , "pjones@redhat.com" , Konrad Wilk Subject: Re: [PATCH v9 2/8] integrity: Introduce a Linux keyring called machine Message-ID: References: <20220105235012.2497118-3-eric.snowberg@oracle.com> <883da244c04fcb07add9984859a09d7b1827880a.camel@linux.ibm.com> <100B070F-7EB4-4BF7-B2B9-E5AE78D3066A@oracle.com> <2d681148b6ea57241f6a7c518dd331068a5f47b0.camel@linux.ibm.com> <153F495F-EAF9-4C11-A476-293CC3B78F0A@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: keyrings@vger.kernel.org On Sat, Jan 15, 2022 at 09:14:45PM +0200, Jarkko Sakkinen wrote: > On Sat, Jan 15, 2022 at 07:12:35PM +0000, Eric Snowberg wrote: > > > > > > > On Jan 15, 2022, at 10:11 AM, Jarkko Sakkinen wrote: > > > > > > On Wed, Jan 12, 2022 at 02:41:47PM -0500, Mimi Zohar wrote: > > >> On Tue, 2022-01-11 at 20:14 -0500, Mimi Zohar wrote: > > >>> On Tue, 2022-01-11 at 21:26 +0000, Eric Snowberg wrote: > > >>>> > > >>>>> On Jan 11, 2022, at 11:16 AM, Mimi Zohar wrote: > > >>>>> > > >>>>> On Mon, 2022-01-10 at 23:25 +0000, Eric Snowberg wrote: > > >>>>>>> Jarkko, my concern is that once this version of the patch set is > > >>>>>>> upstreamed, would limiting which keys may be loaded onto the .machine > > >>>>>>> keyring be considered a regression? > > >>>>>> > > >>>>>> > > >>>>>> Currently certificates built into the kernel do not have a CA restriction on them. > > >>>>>> IMA will trust anything in this keyring even if the CA bit is not set. While it would > > >>>>>> be advisable for a kernel to be built with a CA, nothing currently enforces it. > > >>>>>> > > >>>>>> My thinking for the dropped CA restriction patches was to introduce a new Kconfig. > > >>>>>> This Kconfig would do the CA enforcement on the machine keyring. However if the > > >>>>>> Kconfig option was not set for enforcement, it would work as it does in this series, > > >>>>>> plus it would allow IMA to work with non-CA keys. This would be done by removing > > >>>>>> the restriction placed in this patch. Let me know your thoughts on whether this would > > >>>>>> be an appropriate solution. I believe this would get around what you are identifying as > > >>>>>> a possible regression. > > >>>>> > > >>>>> True the problem currently exists with the builtin keys, but there's a > > >>>>> major difference between trusting the builtin keys and those being > > >>>>> loading via MOK. This is an integrity gap that needs to be closed and > > >>>>> shouldn't be expanded to keys on the .machine keyring. > > >>>>> > > >>>>> "plus it would allow IMA to work with non-CA keys" is unacceptable. > > >>>> > > >>>> Ok, I’ll leave that part out. Could you clarify the wording I should include in the future > > >>>> cover letter, which adds IMA support, on why it is unacceptable for the end-user to > > >>>> make this decision? > > >>> > > >>> The Kconfig IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY > > >>> "help" is very clear: > > >> > > >> [Reposting the text due to email formatting issues.] > > >> > > >> help > > >> Keys may be added to the IMA or IMA blacklist keyrings, if the > > >> key is validly signed by a CA cert in the system built-in or > > >> secondary trusted keyrings. > > >> > > >> Intermediate keys between those the kernel has compiled in and the > > >> IMA keys to be added may be added to the system secondary keyring, > > >> provided they are validly signed by a key already resident in the > > >> built-in or secondary trusted keyrings. > > >> > > >> > > >> The first paragraph requires "validly signed by a CA cert in the system > > >> built-in or secondary trusted keyrings" for keys to be loaded onto the > > >> IMA keyring. This Kconfig is limited to just the builtin and secondary > > >> keyrings. Changing this silently to include the ".machine" keyring > > >> introduces integrity risks that previously did not exist. A new IMA > > >> Kconfig needs to be defined to allow all three keyrings - builtin, > > >> machine, and secondary. > > >> > > >> The second paragraph implies that only CA and intermediate CA keys are > > >> on secondary keyring, or as in our case the ".machine" keyring linked > > >> to the secondary keyring. > > >> > > >> Mimi > > >> > > > I have also now test environment for this patch set but if there are > > > any possible changes, I'm waiting for a new version, as it is anyway > > > for 5.18 cycle earliest. > > > > Other than the two sentence changes, I have not seen anything identified > > code wise requiring a change. If you’d like me to respin a v10 with the sentence > > changes let me know. Or if you want to remove the ima reference, that works > > too. Just let me know how you want to handle this. Thanks. > > I'm basically waiting also Mimi to test this as I do not have IMA test > environment. > > From my side: > > Tested-by: Jarkko Sakkinen I can pick the whole thing at the time when I get green light. /Jarkko