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 352191F03D7; Tue, 4 Mar 2025 22:25:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1741127103; cv=none; b=rc4zDm9ryxccmXJvsIrLT5cS/X4le5aCFlqGQKaD/L8ZlgZsxVSPhQPSu2hy8ACWv7EQGjQktIzmlVYExQmC/qGBe6yaP/V/DkHnWfzKNDcgJwzc+0XFBEvQNztWC4qM+nbwHaKzdadNn3nmuaOo9FwHzzrN7KaKpa2lJbo501U= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1741127103; c=relaxed/simple; bh=0+/9utZ9Ftp9xnO55BpJlM6f0mOe8fIs9GJvBVmZITk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=AegxbHOszA5k06k723MxcsNidFbLSkTcyPKLdhvxbvqQDk2GctRl0nyrtp+WX0MJt84GHJEWMlyrJWqBOVKqJ0Sh96PNz+2L+LdU2C0Aka69zAWvc/isqI7LVl/Ia1rGJUksHKDxLT9zjsKOKxRsdnl7NMwtbV8kjJcnJnyWeoU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Y0WFhpkn; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Y0WFhpkn" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0A2EFC4CEE5; Tue, 4 Mar 2025 22:25:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1741127102; bh=0+/9utZ9Ftp9xnO55BpJlM6f0mOe8fIs9GJvBVmZITk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Y0WFhpknFwe00UPXpOJYc/hs7CmG0pQXTXXpLKYxAe3NhDpNbWU9mKpO6aKD/vmIr KbBPUSgUayaNkK5jIEfWx22v4wwNfz1yhPY422ZfN+WfJHGyc5Z/uy0DCwOyLTzQIj +pfeK8SVY0SDSYCNXDxyga2WqrNyWsmCI0Q2PVGOO+9C424j1HSRoSw1qeTPCgxpne xI85EmF39tWrVpqTepxyQGCzlar3aS2yiqC/tqu6Abuq923ZoOsuz+SKiHznVDd5ej BW/aRZ4wO6sFWsTr+5vOkuoquA6rlzYX22yV/eDzXNNMrQZNySVlqUvgKMBheyCZSy m731TrXzhW6sw== Date: Wed, 5 Mar 2025 00:24:58 +0200 From: Jarkko Sakkinen To: Paul Moore Cc: Eric Snowberg , Mimi Zohar , David Howells , "open list:SECURITY SUBSYSTEM" , David Woodhouse , "herbert@gondor.apana.org.au" , "davem@davemloft.net" , Ard Biesheuvel , James Morris , "Serge E. Hallyn" , Roberto Sassu , Dmitry Kasatkin , =?iso-8859-1?Q?Micka=EBl_Sala=FCn?= , "casey@schaufler-ca.com" , Stefan Berger , "ebiggers@kernel.org" , Randy Dunlap , open list , "keyrings@vger.kernel.org" , "linux-crypto@vger.kernel.org" , "linux-efi@vger.kernel.org" , "linux-integrity@vger.kernel.org" Subject: Re: [RFC PATCH v3 00/13] Clavis LSM Message-ID: References: <72F52F71-C7F3-402D-8441-3D636A093FE8@oracle.com> <506e8e58e5236a4525b18d84bafa9aae80b24452.camel@linux.ibm.com> Precedence: bulk X-Mailing-List: linux-security-module@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Mon, Mar 03, 2025 at 05:40:54PM -0500, Paul Moore wrote: > On Fri, Feb 28, 2025 at 12:52 PM Eric Snowberg wrote: > > > On Feb 28, 2025, at 9:14 AM, Paul Moore wrote: > > > On Fri, Feb 28, 2025 at 9:09 AM Mimi Zohar wrote: > > >> On Thu, 2025-02-27 at 17:22 -0500, Paul Moore wrote: > > >>> > > >>> I'd still also like to see some discussion about moving towards the > > >>> addition of keyrings oriented towards usage instead of limiting > > >>> ourselves to keyrings that are oriented on the source of the keys. > > >>> Perhaps I'm missing some important detail which makes this > > >>> impractical, but it seems like an obvious improvement to me and would > > >>> go a long way towards solving some of the problems that we typically > > >>> see with kernel keys. > > > > The intent is not to limit ourselves to the source of the key. The main > > point of Clavis is to allow the end-user to determine what kernel keys > > they want to trust and for what purpose, irrespective of the originating > > source (.builtin_trusted, .secondary, .machine, or .platform). If we could > > go back in time, individual keyrings could be created that are oriented > > toward usage. The idea for introducing Clavis is to bridge what we > > have today with kernel keys and allow them to be usage based. > > While it is unlikely that the current well known keyrings could be > removed, I see no reason why new usage oriented keyrings could not be > introduced. We've seen far more significant shifts in the kernel over > the years. Could we implement such change in a way that these new imaginary (at this point) usage oriented keyrings would be used to create the "legacy" keyrings? > > -- > paul-moore.com > BR, Jarkko