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