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 X-Spam-Level: X-Spam-Status: No, score=-8.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 33006C43381 for ; Mon, 15 Mar 2021 18:03:00 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 06C3364F2F for ; Mon, 15 Mar 2021 18:03:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230403AbhCOSC1 (ORCPT ); Mon, 15 Mar 2021 14:02:27 -0400 Received: from smtp-190f.mail.infomaniak.ch ([185.125.25.15]:60447 "EHLO smtp-190f.mail.infomaniak.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231354AbhCOSB4 (ORCPT ); Mon, 15 Mar 2021 14:01:56 -0400 Received: from smtp-3-0001.mail.infomaniak.ch (unknown [10.4.36.108]) by smtp-2-3000.mail.infomaniak.ch (Postfix) with ESMTPS id 4Dzkl642lMzMqGSq; Mon, 15 Mar 2021 19:01:54 +0100 (CET) Received: from ns3096276.ip-94-23-54.eu (unknown [23.97.221.149]) by smtp-3-0001.mail.infomaniak.ch (Postfix) with ESMTPA id 4Dzkl16VGbzlh8T3; Mon, 15 Mar 2021 19:01:49 +0100 (CET) Subject: Re: [PATCH v7 5/5] certs: Allow root user to append signed hashes to the blacklist keyring To: Eric Snowberg Cc: David Howells , David Woodhouse , Jarkko Sakkinen , "David S . Miller" , Herbert Xu , James Morris , =?UTF-8?Q?Micka=c3=abl_Sala=c3=bcn?= , Mimi Zohar , "Serge E . Hallyn" , Tyler Hicks , keyrings@vger.kernel.org, linux-crypto@vger.kernel.org, linux-integrity@vger.kernel.org, linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org References: <20210312171232.2681989-1-mic@digikod.net> <20210312171232.2681989-6-mic@digikod.net> From: =?UTF-8?Q?Micka=c3=abl_Sala=c3=bcn?= Message-ID: Date: Mon, 15 Mar 2021 19:01:36 +0100 User-Agent: MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: On 15/03/2021 17:59, Eric Snowberg wrote: > >> On Mar 12, 2021, at 10:12 AM, Mickaël Salaün wrote: >> >> From: Mickaël Salaün >> >> Add a kernel option SYSTEM_BLACKLIST_AUTH_UPDATE to enable the root user >> to dynamically add new keys to the blacklist keyring. This enables to >> invalidate new certificates, either from being loaded in a keyring, or >> from being trusted in a PKCS#7 certificate chain. This also enables to >> add new file hashes to be denied by the integrity infrastructure. >> >> Being able to untrust a certificate which could have normaly been >> trusted is a sensitive operation. This is why adding new hashes to the >> blacklist keyring is only allowed when these hashes are signed and >> vouched by the builtin trusted keyring. A blacklist hash is stored as a >> key description. The PKCS#7 signature of this description must be >> provided as the key payload. >> >> Marking a certificate as untrusted should be enforced while the system >> is running. It is then forbiden to remove such blacklist keys. >> >> Update blacklist keyring, blacklist key and revoked certificate access rights: >> * allows the root user to search for a specific blacklisted hash, which >> make sense because the descriptions are already viewable; >> * forbids key update (blacklist and asymmetric ones); >> * restricts kernel rights on the blacklist keyring to align with the >> root user rights. >> >> See help in tools/certs/print-cert-tbs-hash.sh . >> >> Cc: David Howells >> Cc: David Woodhouse >> Cc: Eric Snowberg >> Cc: Jarkko Sakkinen >> Signed-off-by: Mickaël Salaün >> Link: https://lore.kernel.org/r/20210312171232.2681989-6-mic@digikod.net > > I tried testing this, it doesn’t work as I would expect. > Here is my test setup: > > Kernel built with two keys compiled into the builtin_trusted_keys keyring > > Generated a tbs cert from one of the keys and signed it with the other key > > As root, added the tbs cert hash to the blacklist keyring > > Verified the tbs hash is in the blacklist keyring > > Enabled lockdown to enforce kernel module signature checking > > Signed a kernel module with the key I just blacklisted > > Load the kernel module > > I’m seeing the kernel module load, I would expect this to fail, since the > key is now blacklisted. Or is this change just supposed to prevent new keys > from being added in the future? This is the expected behavior and the way the blacklist keyring is currently used, as explained in the commit message: "This enables to invalidate new certificates, either from being loaded in a keyring, or from being trusted in a PKCS#7 certificate chain." If you want a (trusted root) key to be untrusted, you need to remove it from the keyring, which is not allowed for the builtin trusted keyring.