| 1 | # SPDX-License-Identifier: GPL-2.0-only |
| 2 | # |
| 3 | # Key management configuration |
| 4 | # |
| 5 | |
| 6 | menuconfig KEYS |
| 7 | bool "Enable access key retention support" |
| 8 | select ASSOCIATIVE_ARRAY |
| 9 | help |
| 10 | This option provides support for retaining authentication tokens and |
| 11 | access keys in the kernel. |
| 12 | |
| 13 | It also includes provision of methods by which such keys might be |
| 14 | associated with a process so that network filesystems, encryption |
| 15 | support and the like can find them. |
| 16 | |
| 17 | Furthermore, a special type of key is available that acts as keyring: |
| 18 | a searchable sequence of keys. Each process is equipped with access |
| 19 | to five standard keyrings: UID-specific, GID-specific, session, |
| 20 | process and thread. |
| 21 | |
| 22 | If you are unsure as to whether this is required, answer N. |
| 23 | |
| 24 | if KEYS |
| 25 | |
| 26 | config KEYS_REQUEST_CACHE |
| 27 | bool "Enable temporary caching of the last request_key() result" |
| 28 | help |
| 29 | This option causes the result of the last successful request_key() |
| 30 | call that didn't upcall to the kernel to be cached temporarily in the |
| 31 | task_struct. The cache is cleared by exit and just prior to the |
| 32 | resumption of userspace. |
| 33 | |
| 34 | This allows the key used for multiple step processes where each step |
| 35 | wants to request a key that is likely the same as the one requested |
| 36 | by the last step to save on the searching. |
| 37 | |
| 38 | An example of such a process is a pathwalk through a network |
| 39 | filesystem in which each method needs to request an authentication |
| 40 | key. Pathwalk will call multiple methods for each dentry traversed |
| 41 | (permission, d_revalidate, lookup, getxattr, getacl, ...). |
| 42 | |
| 43 | config PERSISTENT_KEYRINGS |
| 44 | bool "Enable register of persistent per-UID keyrings" |
| 45 | help |
| 46 | This option provides a register of persistent per-UID keyrings, |
| 47 | primarily aimed at Kerberos key storage. The keyrings are persistent |
| 48 | in the sense that they stay around after all processes of that UID |
| 49 | have exited, not that they survive the machine being rebooted. |
| 50 | |
| 51 | A particular keyring may be accessed by either the user whose keyring |
| 52 | it is or by a process with administrative privileges. The active |
| 53 | LSMs gets to rule on which admin-level processes get to access the |
| 54 | cache. |
| 55 | |
| 56 | Keyrings are created and added into the register upon demand and get |
| 57 | removed if they expire (a default timeout is set upon creation). |
| 58 | |
| 59 | config BIG_KEYS |
| 60 | bool "Large payload keys" |
| 61 | depends on TMPFS |
| 62 | select CRYPTO_LIB_CHACHA20POLY1305 |
| 63 | help |
| 64 | This option provides support for holding large keys within the kernel |
| 65 | (for example Kerberos ticket caches). The data may be stored out to |
| 66 | swapspace by tmpfs. |
| 67 | |
| 68 | If you are unsure as to whether this is required, answer N. |
| 69 | |
| 70 | config TRUSTED_KEYS |
| 71 | tristate "TRUSTED KEYS" |
| 72 | help |
| 73 | This option provides support for creating, sealing, and unsealing |
| 74 | keys in the kernel. Trusted keys are random number symmetric keys, |
| 75 | generated and sealed by a trust source selected at kernel boot-time. |
| 76 | Userspace will only ever see encrypted blobs. |
| 77 | |
| 78 | If you are unsure as to whether this is required, answer N. |
| 79 | |
| 80 | if TRUSTED_KEYS |
| 81 | source "security/keys/trusted-keys/Kconfig" |
| 82 | endif |
| 83 | |
| 84 | config ENCRYPTED_KEYS |
| 85 | tristate "ENCRYPTED KEYS" |
| 86 | select CRYPTO |
| 87 | select CRYPTO_AES |
| 88 | select CRYPTO_CBC |
| 89 | select CRYPTO_LIB_SHA256 |
| 90 | help |
| 91 | This option provides support for create/encrypting/decrypting keys |
| 92 | in the kernel. Encrypted keys are instantiated using kernel |
| 93 | generated random numbers or provided decrypted data, and are |
| 94 | encrypted/decrypted with a 'master' symmetric key. The 'master' |
| 95 | key can be either a trusted-key or user-key type. Only encrypted |
| 96 | blobs are ever output to Userspace. |
| 97 | |
| 98 | If you are unsure as to whether this is required, answer N. |
| 99 | |
| 100 | config USER_DECRYPTED_DATA |
| 101 | bool "Allow encrypted keys with user decrypted data" |
| 102 | depends on ENCRYPTED_KEYS |
| 103 | help |
| 104 | This option provides support for instantiating encrypted keys using |
| 105 | user-provided decrypted data. The decrypted data must be hex-ascii |
| 106 | encoded. |
| 107 | |
| 108 | If you are unsure as to whether this is required, answer N. |
| 109 | |
| 110 | config KEY_DH_OPERATIONS |
| 111 | bool "Diffie-Hellman operations on retained keys" |
| 112 | select CRYPTO |
| 113 | select CRYPTO_KDF800108_CTR |
| 114 | select CRYPTO_DH |
| 115 | help |
| 116 | This option provides support for calculating Diffie-Hellman |
| 117 | public keys and shared secrets using values stored as keys |
| 118 | in the kernel. |
| 119 | |
| 120 | If you are unsure as to whether this is required, answer N. |
| 121 | |
| 122 | config KEY_NOTIFICATIONS |
| 123 | bool "Provide key/keyring change notifications" |
| 124 | depends on WATCH_QUEUE |
| 125 | help |
| 126 | This option provides support for getting change notifications |
| 127 | on keys and keyrings on which the caller has View permission. |
| 128 | This makes use of pipes to handle the notification buffer and |
| 129 | provides KEYCTL_WATCH_KEY to enable/disable watches. |
| 130 | |
| 131 | endif # KEYS |