linux-kernel - Re: Migration to trusted keys: sealing user-provided key?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 08 Feb 2021 16:50:12 -0500
From:   Mimi Zohar <zohar@...ux.ibm.com>
To:     Jan Lübbe <jlu@...gutronix.de>,
        Jarkko Sakkinen <jarkko@...nel.org>,
        Ahmad Fatoum <a.fatoum@...gutronix.de>,
        James Bottomley <jejb@...ux.ibm.com>,
        David Howells <dhowells@...hat.com>, keyrings@...r.kernel.org,
        Sumit Garg <sumit.garg@...aro.org>
Cc:     linux-integrity@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-security-module@...r.kernel.org, kernel@...gutronix.de
Subject: Re: Migration to trusted keys: sealing user-provided key?

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"

>         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.

thanks,

Mimi