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=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no 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 5B6CEC433E0 for ; Tue, 9 Feb 2021 07:17:45 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0E7EC64EC2 for ; Tue, 9 Feb 2021 07:17:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229789AbhBIHR2 (ORCPT ); Tue, 9 Feb 2021 02:17:28 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33094 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229558AbhBIHRX (ORCPT ); Tue, 9 Feb 2021 02:17:23 -0500 Received: from metis.ext.pengutronix.de (metis.ext.pengutronix.de [IPv6:2001:67c:670:201:290:27ff:fe1d:cc33]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 78341C061786 for ; Mon, 8 Feb 2021 23:16:42 -0800 (PST) Received: from ptx.hi.pengutronix.de ([2001:67c:670:100:1d::c0]) by metis.ext.pengutronix.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1l9NGC-0006mV-H4; Tue, 09 Feb 2021 08:16:32 +0100 Received: from localhost ([127.0.0.1]) by ptx.hi.pengutronix.de with esmtp (Exim 4.92) (envelope-from ) id 1l9NGB-0000sq-8K; Tue, 09 Feb 2021 08:16:31 +0100 Message-ID: Subject: Re: Migration to trusted keys: sealing user-provided key? From: Jan =?ISO-8859-1?Q?L=FCbbe?= To: Mimi Zohar , Jarkko Sakkinen , Ahmad Fatoum , James Bottomley , David Howells , keyrings@vger.kernel.org, Sumit Garg Cc: linux-integrity@vger.kernel.org, linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org, kernel@pengutronix.de Date: Tue, 09 Feb 2021 08:16:30 +0100 In-Reply-To: <9bd1eaab236f095f1dbdc01752c3c6f487f33525.camel@linux.ibm.com> References: <74830d4f-5a76-8ba8-aad0-0d79f7c01af9@pengutronix.de> <6dc99fd9ffbc5f405c5f64d0802d1399fc6428e4.camel@kernel.org> <8b9477e150d7c939dc0def3ebb4443efcc83cd85.camel@pengutronix.de> <64472434a367060ddce6e03425156b8312a5ad6c.camel@pengutronix.de> <0be34899c9686b95cd22aa016f466523579cbeed.camel@pengutronix.de> <9bd1eaab236f095f1dbdc01752c3c6f487f33525.camel@linux.ibm.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.38.3-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 2001:67c:670:100:1d::c0 X-SA-Exim-Mail-From: jlu@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: keyrings@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: keyrings@vger.kernel.org On Mon, 2021-02-08 at 16:50 -0500, Mimi Zohar wrote: > On Mon, 2021-02-08 at 15:38 +0100, Jan Lübbe wrote: > > > As it seems that this feature would not be appropriate for all use-cases and > > threat models, I wonder if making it optional would be acceptable. Something > > like: > > > > config TRUSTED_KEYS_IMPORT > > To me "IMPORT" implies from a trusted source, which this is not. > Perhaps "UNSAFE_IMPORT", "DEBUGGING_IMPORT, "DEVELOPMENT_IMPORT", ... > > Defining a Kconfig with any of these names and the other changes below, > makes it very clear using predefined key data is not recommended. My > concern with extending trusted keys to new trust sources is the > implication that the security/integrity is equivalent to the existing > discrete TPM. > > >         bool "Allow creating TRUSTED KEYS from existing key material" > >         depends on TRUSTED_KEYS > > Missing "default n" According to Documentation/kbuild/kconfig-language.rst: "The default value deliberately defaults to 'n' in order to avoid bloating the build.". So an explicit "default n" should not be needed. I'll add it though, for now. > >         help > >           This option adds support for creating new trusted keys from > > existing > >           key material supplied by userspace, instead of using random > > numbers. > >           As with random trusted keys, userspace cannot extract the plain- > > text > > Once defined, as with random trusted keys, userspace cannot ... > > >           key material again and will only ever see encrypted blobs. > >            > > > >           This option should *only* be enabled for use in a trusted > >           environment (such as during debugging/development or in a secured > >           factory). Also, consider using 'keyctl padd' instead of 'keyctl > > add' > > Even the "secured factory" is not a good idea. Please limit the usage > to debugging/development. > > >           to avoid exposing the plain-text key on the process command line. > > > >           If you are unsure as to whether this is required, answer N. > > The above would be fine. OK, that would result in: config TRUSTED_KEYS_DEVELOPMENT_IMPORT         bool "Allow creating TRUSTED KEYS from existing key material for development"         depends on TRUSTED_KEYS default n         help           This option adds support for creating new trusted keys from existing key material supplied by userspace, instead of using random numbers. Once defined,  as with random trusted keys, userspace cannot extract the plain-text key material again and will only ever see encrypted blobs.                      This option should *only* be enabled for debugging/development. Also, consider using 'keyctl padd' instead of 'keyctl add' to avoid exposing the plain-text key on the process command line.           If you are unsure as to whether this is required, answer N. Thanks, Jan -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |