Migration to trusted keys: sealing user-provided key?
zohar at linux.ibm.com
Mon Feb 8 21:50:12 UTC 2021
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
> 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
> bool "Allow creating TRUSTED KEYS from existing key material"
> depends on TRUSTED_KEYS
Missing "default n"
> 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 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.
More information about the Linux-security-module-archive