136 lines
4.7 KiB
Plaintext
136 lines
4.7 KiB
Plaintext
|
# SPDX-License-Identifier: GPL-2.0-only
|
||
|
#
|
||
|
# Key management configuration
|
||
|
#
|
||
|
|
||
|
config KEYS
|
||
|
bool "Enable access key retention support"
|
||
|
select ASSOCIATIVE_ARRAY
|
||
|
help
|
||
|
This option provides support for retaining authentication tokens and
|
||
|
access keys in the kernel.
|
||
|
|
||
|
It also includes provision of methods by which such keys might be
|
||
|
associated with a process so that network filesystems, encryption
|
||
|
support and the like can find them.
|
||
|
|
||
|
Furthermore, a special type of key is available that acts as keyring:
|
||
|
a searchable sequence of keys. Each process is equipped with access
|
||
|
to five standard keyrings: UID-specific, GID-specific, session,
|
||
|
process and thread.
|
||
|
|
||
|
If you are unsure as to whether this is required, answer N.
|
||
|
|
||
|
config KEYS_REQUEST_CACHE
|
||
|
bool "Enable temporary caching of the last request_key() result"
|
||
|
depends on KEYS
|
||
|
help
|
||
|
This option causes the result of the last successful request_key()
|
||
|
call that didn't upcall to the kernel to be cached temporarily in the
|
||
|
task_struct. The cache is cleared by exit and just prior to the
|
||
|
resumption of userspace.
|
||
|
|
||
|
This allows the key used for multiple step processes where each step
|
||
|
wants to request a key that is likely the same as the one requested
|
||
|
by the last step to save on the searching.
|
||
|
|
||
|
An example of such a process is a pathwalk through a network
|
||
|
filesystem in which each method needs to request an authentication
|
||
|
key. Pathwalk will call multiple methods for each dentry traversed
|
||
|
(permission, d_revalidate, lookup, getxattr, getacl, ...).
|
||
|
|
||
|
config PERSISTENT_KEYRINGS
|
||
|
bool "Enable register of persistent per-UID keyrings"
|
||
|
depends on KEYS
|
||
|
help
|
||
|
This option provides a register of persistent per-UID keyrings,
|
||
|
primarily aimed at Kerberos key storage. The keyrings are persistent
|
||
|
in the sense that they stay around after all processes of that UID
|
||
|
have exited, not that they survive the machine being rebooted.
|
||
|
|
||
|
A particular keyring may be accessed by either the user whose keyring
|
||
|
it is or by a process with administrative privileges. The active
|
||
|
LSMs gets to rule on which admin-level processes get to access the
|
||
|
cache.
|
||
|
|
||
|
Keyrings are created and added into the register upon demand and get
|
||
|
removed if they expire (a default timeout is set upon creation).
|
||
|
|
||
|
config BIG_KEYS
|
||
|
bool "Large payload keys"
|
||
|
depends on KEYS
|
||
|
depends on TMPFS
|
||
|
depends on CRYPTO_LIB_CHACHA20POLY1305 = y
|
||
|
help
|
||
|
This option provides support for holding large keys within the kernel
|
||
|
(for example Kerberos ticket caches). The data may be stored out to
|
||
|
swapspace by tmpfs.
|
||
|
|
||
|
If you are unsure as to whether this is required, answer N.
|
||
|
|
||
|
config TRUSTED_KEYS
|
||
|
tristate "TRUSTED KEYS"
|
||
|
depends on KEYS
|
||
|
help
|
||
|
This option provides support for creating, sealing, and unsealing
|
||
|
keys in the kernel. Trusted keys are random number symmetric keys,
|
||
|
generated and sealed by a trust source selected at kernel boot-time.
|
||
|
Userspace will only ever see encrypted blobs.
|
||
|
|
||
|
If you are unsure as to whether this is required, answer N.
|
||
|
|
||
|
if TRUSTED_KEYS
|
||
|
source "security/keys/trusted-keys/Kconfig"
|
||
|
endif
|
||
|
|
||
|
config ENCRYPTED_KEYS
|
||
|
tristate "ENCRYPTED KEYS"
|
||
|
depends on KEYS
|
||
|
select CRYPTO
|
||
|
select CRYPTO_HMAC
|
||
|
select CRYPTO_AES
|
||
|
select CRYPTO_CBC
|
||
|
select CRYPTO_SHA256
|
||
|
select CRYPTO_RNG
|
||
|
help
|
||
|
This option provides support for create/encrypting/decrypting keys
|
||
|
in the kernel. Encrypted keys are instantiated using kernel
|
||
|
generated random numbers or provided decrypted data, and are
|
||
|
encrypted/decrypted with a 'master' symmetric key. The 'master'
|
||
|
key can be either a trusted-key or user-key type. Only encrypted
|
||
|
blobs are ever output to Userspace.
|
||
|
|
||
|
If you are unsure as to whether this is required, answer N.
|
||
|
|
||
|
config USER_DECRYPTED_DATA
|
||
|
bool "Allow encrypted keys with user decrypted data"
|
||
|
depends on ENCRYPTED_KEYS
|
||
|
help
|
||
|
This option provides support for instantiating encrypted keys using
|
||
|
user-provided decrypted data. The decrypted data must be hex-ascii
|
||
|
encoded.
|
||
|
|
||
|
If you are unsure as to whether this is required, answer N.
|
||
|
|
||
|
config KEY_DH_OPERATIONS
|
||
|
bool "Diffie-Hellman operations on retained keys"
|
||
|
depends on KEYS
|
||
|
select CRYPTO
|
||
|
select CRYPTO_KDF800108_CTR
|
||
|
select CRYPTO_DH
|
||
|
help
|
||
|
This option provides support for calculating Diffie-Hellman
|
||
|
public keys and shared secrets using values stored as keys
|
||
|
in the kernel.
|
||
|
|
||
|
If you are unsure as to whether this is required, answer N.
|
||
|
|
||
|
config KEY_NOTIFICATIONS
|
||
|
bool "Provide key/keyring change notifications"
|
||
|
depends on KEYS && WATCH_QUEUE
|
||
|
help
|
||
|
This option provides support for getting change notifications
|
||
|
on keys and keyrings on which the caller has View permission.
|
||
|
This makes use of pipes to handle the notification buffer and
|
||
|
provides KEYCTL_WATCH_KEY to enable/disable watches.
|