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

[Mimi Zohar <zohar@linux.ibm.com>]

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