| Kyle Swenson | 8d8f654 | 2021-03-15 11:02:55 -0600 | [diff] [blame] | 1 | # |
| 2 | # Key management configuration |
| 3 | # |
| 4 | |
| 5 | config KEYS |
| 6 | bool "Enable access key retention support" |
| 7 | select ASSOCIATIVE_ARRAY |
| 8 | help |
| 9 | This option provides support for retaining authentication tokens and |
| 10 | access keys in the kernel. |
| 11 | |
| 12 | It also includes provision of methods by which such keys might be |
| 13 | associated with a process so that network filesystems, encryption |
| 14 | support and the like can find them. |
| 15 | |
| 16 | Furthermore, a special type of key is available that acts as keyring: |
| 17 | a searchable sequence of keys. Each process is equipped with access |
| 18 | to five standard keyrings: UID-specific, GID-specific, session, |
| 19 | process and thread. |
| 20 | |
| 21 | If you are unsure as to whether this is required, answer N. |
| 22 | |
| 23 | config KEYS_COMPAT |
| 24 | def_bool y |
| 25 | depends on COMPAT && KEYS |
| 26 | |
| 27 | config PERSISTENT_KEYRINGS |
| 28 | bool "Enable register of persistent per-UID keyrings" |
| 29 | depends on KEYS |
| 30 | help |
| 31 | This option provides a register of persistent per-UID keyrings, |
| 32 | primarily aimed at Kerberos key storage. The keyrings are persistent |
| 33 | in the sense that they stay around after all processes of that UID |
| 34 | have exited, not that they survive the machine being rebooted. |
| 35 | |
| 36 | A particular keyring may be accessed by either the user whose keyring |
| 37 | it is or by a process with administrative privileges. The active |
| 38 | LSMs gets to rule on which admin-level processes get to access the |
| 39 | cache. |
| 40 | |
| 41 | Keyrings are created and added into the register upon demand and get |
| 42 | removed if they expire (a default timeout is set upon creation). |
| 43 | |
| 44 | config BIG_KEYS |
| 45 | bool "Large payload keys" |
| 46 | depends on KEYS |
| 47 | depends on TMPFS |
| 48 | help |
| 49 | This option provides support for holding large keys within the kernel |
| 50 | (for example Kerberos ticket caches). The data may be stored out to |
| 51 | swapspace by tmpfs. |
| 52 | |
| 53 | If you are unsure as to whether this is required, answer N. |
| 54 | |
| 55 | config TRUSTED_KEYS |
| 56 | tristate "TRUSTED KEYS" |
| 57 | depends on KEYS && TCG_TPM |
| 58 | select CRYPTO |
| 59 | select CRYPTO_HMAC |
| 60 | select CRYPTO_SHA1 |
| 61 | help |
| 62 | This option provides support for creating, sealing, and unsealing |
| 63 | keys in the kernel. Trusted keys are random number symmetric keys, |
| 64 | generated and RSA-sealed by the TPM. The TPM only unseals the keys, |
| 65 | if the boot PCRs and other criteria match. Userspace will only ever |
| 66 | see encrypted blobs. |
| 67 | |
| 68 | If you are unsure as to whether this is required, answer N. |
| 69 | |
| 70 | config ENCRYPTED_KEYS |
| 71 | tristate "ENCRYPTED KEYS" |
| 72 | depends on KEYS |
| 73 | select CRYPTO |
| 74 | select CRYPTO_HMAC |
| 75 | select CRYPTO_AES |
| 76 | select CRYPTO_CBC |
| 77 | select CRYPTO_SHA256 |
| 78 | select CRYPTO_RNG |
| 79 | help |
| 80 | This option provides support for create/encrypting/decrypting keys |
| 81 | in the kernel. Encrypted keys are kernel generated random numbers, |
| 82 | which are encrypted/decrypted with a 'master' symmetric key. The |
| 83 | 'master' key can be either a trusted-key or user-key type. |
| 84 | Userspace only ever sees/stores encrypted blobs. |
| 85 | |
| 86 | If you are unsure as to whether this is required, answer N. |