Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Content-Type: text/plain; charset=us-ascii
Subject: Re: [PATCH v6 00/13] Enroll kernel keys thru MOK
From:   Eric Snowberg <eric.snowberg@oracle.com>
In-Reply-To: <7e83a42f-22ff-350a-2017-d286b1b1b02c@linux.vnet.ibm.com>
Date:   Thu, 16 Sep 2021 19:55:00 -0600
Cc:     keyrings@vger.kernel.org,
        linux-integrity <linux-integrity@vger.kernel.org>,
        Mimi Zohar <zohar@linux.ibm.com>,
        David Howells <dhowells@redhat.com>,
        David Woodhouse <dwmw2@infradead.org>,
        Herbert Xu <herbert@gondor.apana.org.au>,
        "David S . Miller" <davem@davemloft.net>,
        Jarkko Sakkinen <jarkko@kernel.org>,
        James Morris <jmorris@namei.org>,
        "Serge E . Hallyn" <serge@hallyn.com>, keescook@chromium.org,
        gregkh@linuxfoundation.org, torvalds@linux-foundation.org,
        scott.branden@broadcom.com, weiyongjun1@huawei.com,
        nayna@linux.ibm.com, ebiggers@google.com, ardb@kernel.org,
        nramas@linux.microsoft.com, lszubowi@redhat.com,
        linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org,
        linux-security-module@vger.kernel.org,
        James.Bottomley@HansenPartnership.com, pjones@redhat.com,
        "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <37D6AC4A-372D-497A-AF97-CEA03EFC9BBA@oracle.com>
References: <20210914211416.34096-1-eric.snowberg@oracle.com>
 <7e83a42f-22ff-350a-2017-d286b1b1b02c@linux.vnet.ibm.com>
To:     Nayna <nayna@linux.vnet.ibm.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?BJ6k5RoFrjtlJoq1JqiIM99N3+NcW1NqCwlpQ8NFIv7iXmQ2yT3IPmD26k9P?=
 =?us-ascii?Q?+FpFJG12Ve/bNpOYh0wDYkGST4WHtVojeeP5bA+wyhQhKnF9OsaoTtgOdXbK?=
 =?us-ascii?Q?C7u685w/8kglIT1LF51eZM3Ij2cm5A9kddQ7I7MXjp6Hlm3cQZf6+kUgUEgc?=
 =?us-ascii?Q?1u1imiR3/lZL5xId6A3p8pw4P73IWBgrBbd2H/xvtOEPus7fjM0U+BiMRriX?=
 =?us-ascii?Q?kaAUBEzLOTkI5LUdVMONgWcUPcO9Kh07i+rqrf90d1dt+bCOWI4qbVCPE8gr?=
 =?us-ascii?Q?B/086+/0UraIOtBIInynY+w39cTNv3Ra2BdtjlL6KfJUpni500TmGG/0oTo6?=
 =?us-ascii?Q?GZjjSOV/yZqxpTe1gZgABN8KGDnGlW3qdP2YTMPVfDBUueUq48vnw2vtIlGn?=
 =?us-ascii?Q?RgPCw69Xi6ljIYylu2kBBdc9aAnva+utAQg1oVx66FrcC4bDBefjEdvPVxcA?=
 =?us-ascii?Q?3BlhLi24/87x5GWk3B+OSJfH1hL3+EvDavtIj8cvXg6Y7d2RZwA1ko5qSRHL?=
 =?us-ascii?Q?HpxTkJsRMDBuP2jqPsVVpQ8TuwbFnx50VLR1ZfOEc7B2iPsYVq5FCgHa1Jli?=
 =?us-ascii?Q?UcQz3NqH7FowXO40F10UPj05Lv2T06c0W+9YVBdZyaAS5T6F2qoPMZ4eQord?=
 =?us-ascii?Q?xbokXasdksz6SzJrAMzOTBtROVPXTBblknhE9v0+Vhb+CpMKLWazzof0We5F?=
 =?us-ascii?Q?EvJcqVGNpHSH+eb8Nllbfu8lwEklctYQ4sJvCwNtijffECMhmDHKCZLyD2Ad?=
 =?us-ascii?Q?3h1h3DXhESoifjE1RDbmUApvYzAfJGxMpi8sWCWuvQqEj7sA2yf4Xtm5omzg?=
 =?us-ascii?Q?SChrbx123KV+QnZxbvrHbadHmppNc3YwfU6lMcxrxzmSpZe/H99bTKNgGVf8?=
 =?us-ascii?Q?/YQ61s/QF81jWuoaN4mMp66NhI6FXeQaTHb5IpKOmMkysmLycMZ+DNPyx3XH?=
 =?us-ascii?Q?2r6/lm/e1zGA3rOdHMWbYulqNoKmGyi/DVTekO4vtf7qvGZRauC2UYMF9r8O?=
 =?us-ascii?Q?RLjA9m+4vNie83KJQCdKYo/nP6WNUMWHIeltIMrR+H4IuxKTzu4+dsQkHYnK?=
 =?us-ascii?Q?PhPIHx7jI+h3pAutPwBkUv8uwZJbxwVcLK1ocCRKz8BGXcLDpMEqCxMpg8ka?=
 =?us-ascii?Q?Ur6JuaVnVrqUhqp13JeqZ2JJ4Oj/IycCEvZ7ANBhvO5yu0lBX1D263h9Vtml?=
 =?us-ascii?Q?o0GW76Jfyng7Y4jZ5oOT1PfsQKgCdFU17/Cbjs9vdbFTYOy21pu5U4lrBmvk?=
 =?us-ascii?Q?zwvPpWnlMQMK5zjqY5sMyrfg14nt/Jdj3qiGG8qokvnigW4Hy8P/OjnrCvbc?=
 =?us-ascii?Q?bkCrrIUZ7nIrTCd7KvudeFMUM3GouauEqcUyiRmqYaUe6A=3D=3D?=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: bf4506ba-250c-4390-aa5a-08d9797e2edd
X-MS-Exchange-CrossTenant-AuthSource: CH2PR10MB4150.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Sep 2021 01:55:11.1891
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: XTzMCZxVW8G6KymepVbY/xGmxfxAHlzPW3kheH3waSaAKyUEfaURUvYtxgZZqNTfXU5MWzQbTvbRBvmIkufFy28vHjw7/h7WiXaf7GQJPAk=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH0PR10MB4844
X-Proofpoint-Virus-Version: vendor=nai engine=6300 definitions=10109 signatures=668682
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 mlxscore=0
 mlxlogscore=999 adultscore=0 bulkscore=0 spamscore=0 phishscore=0
 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2109030001 definitions=main-2109170010
X-Proofpoint-GUID: rNj8B_LUWm-sNFLxOfjAsU9Qestxp808
X-Proofpoint-ORIG-GUID: rNj8B_LUWm-sNFLxOfjAsU9Qestxp808
Precedence: bulk
List-ID: <linux-crypto.vger.kernel.org>
X-Mailing-List: linux-crypto@vger.kernel.org


> On Sep 16, 2021, at 2:03 PM, Nayna <nayna@linux.vnet.ibm.com> wrote:
>=20
>=20
> On 9/14/21 5:14 PM, Eric Snowberg wrote:
>> Back in 2013 Linus requested a feature to allow end-users to have the
>> ability "to add their own keys and sign modules they trust". This was
>> his *second* order outlined here [1]. There have been many attempts
>> over the years to solve this problem, all have been rejected.  Many
>> of the failed attempts loaded all preboot firmware keys into the kernel,
>> including the Secure Boot keys. Many distributions carry one of these
>> rejected attempts [2], [3], [4]. This series tries to solve this problem
>> with a solution that takes into account all the problems brought up in
>> the previous attempts.
>>=20
>> On UEFI based systems, this series introduces a new Linux kernel keyring
>> containing the Machine Owner Keys (MOK) called machine. It also defines
>> a new MOK variable in shim. This variable allows the end-user to decide
>> if they want to load MOK keys into the machine keyring. Mimi has suggest=
ed
>> that only CA keys contained within the MOK be loaded into the machine
>> keyring. All other certs will load into the platform keyring instead.
>>=20
>> By default, nothing changes; MOK keys are not loaded into the machine
>> keyring.  They are only loaded after the end-user makes the decision
>> themselves.  The end-user would set this through mokutil using a new
>> --trust-mok option [5]. This would work similar to how the kernel uses
>> MOK variables to enable/disable signature validation as well as use/igno=
re
>> the db. Any kernel operation that uses either the builtin or secondary
>> trusted keys as a trust source shall also reference the new machine
>> keyring as a trust source.
>>=20
>> Secure Boot keys will never be loaded into the machine keyring.  They
>> will always be loaded into the platform keyring.  If an end-user wanted
>> to load one, they would need to enroll it into the MOK.
>>=20
>> Steps required by the end user:
>>=20
>> Sign kernel module with user created key:
>> $ /usr/src/kernels/$(uname -r)/scripts/sign-file sha512 \
>>    machine_signing_key.priv machine_signing_key.x509 my_module.ko
>>=20
>> Import the key into the MOK
>> $ mokutil --import machine_signing_key.x509
>>=20
>> Setup the kernel to load MOK keys into the .machine keyring
>> $ mokutil --trust-mok
>>=20
>> Then reboot, the MokManager will load and ask if you want to trust the
>> MOK key and enroll the MOK into the MOKList.  Afterwards the signed kern=
el
>> module will load.
>=20
> machine_signing_key.x509 appears to be a code-signing, self-signed key.  =
It's not a CA key, but the intent of the patchset is to load only CA keys t=
o .machine keyring.
>=20
> Shouldn't there be two steps: one to load the CA key into MOK, and a seco=
nd one to load the code-signing key which is signed by this CA ?

I think that would depend on how the end-user wants to do things. If they=20
are just looking to quickly self-sign their own kernel module, I doubt they=
=20
would go through the effort of having two keys.  This is what I tried to=20
document in the example above.=20

If they do want to use multiple keys, nothing in this approach prevents it.
Their CA will be loaded into the machine keyring.  Now that the machine=20
keyring is a new trust source,  they could simply load their intermediate=20
or leaf cert signed by their CA into the secondary trusted keyring. Afterwa=
rds
their signed kernel module would load.