James Solner | 3cafea3 | 2013-11-06 12:53:36 -0600 | [diff] [blame] | 1 | ============================== |
| 2 | KERNEL MODULE SIGNING FACILITY |
| 3 | ============================== |
| 4 | |
| 5 | CONTENTS |
| 6 | |
| 7 | - Overview. |
| 8 | - Configuring module signing. |
| 9 | - Generating signing keys. |
| 10 | - Public keys in the kernel. |
| 11 | - Manually signing modules. |
| 12 | - Signed modules and stripping. |
| 13 | - Loading signed modules. |
| 14 | - Non-valid signatures and unsigned modules. |
| 15 | - Administering/protecting the private key. |
| 16 | |
| 17 | |
| 18 | ======== |
| 19 | OVERVIEW |
| 20 | ======== |
| 21 | |
| 22 | The kernel module signing facility cryptographically signs modules during |
| 23 | installation and then checks the signature upon loading the module. This |
| 24 | allows increased kernel security by disallowing the loading of unsigned modules |
| 25 | or modules signed with an invalid key. Module signing increases security by |
| 26 | making it harder to load a malicious module into the kernel. The module |
| 27 | signature checking is done by the kernel so that it is not necessary to have |
| 28 | trusted userspace bits. |
| 29 | |
| 30 | This facility uses X.509 ITU-T standard certificates to encode the public keys |
| 31 | involved. The signatures are not themselves encoded in any industrial standard |
| 32 | type. The facility currently only supports the RSA public key encryption |
| 33 | standard (though it is pluggable and permits others to be used). The possible |
| 34 | hash algorithms that can be used are SHA-1, SHA-224, SHA-256, SHA-384, and |
| 35 | SHA-512 (the algorithm is selected by data in the signature). |
| 36 | |
| 37 | |
| 38 | ========================== |
| 39 | CONFIGURING MODULE SIGNING |
| 40 | ========================== |
| 41 | |
| 42 | The module signing facility is enabled by going to the "Enable Loadable Module |
| 43 | Support" section of the kernel configuration and turning on |
| 44 | |
| 45 | CONFIG_MODULE_SIG "Module signature verification" |
| 46 | |
| 47 | This has a number of options available: |
| 48 | |
| 49 | (1) "Require modules to be validly signed" (CONFIG_MODULE_SIG_FORCE) |
| 50 | |
| 51 | This specifies how the kernel should deal with a module that has a |
| 52 | signature for which the key is not known or a module that is unsigned. |
| 53 | |
| 54 | If this is off (ie. "permissive"), then modules for which the key is not |
| 55 | available and modules that are unsigned are permitted, but the kernel will |
Mathieu Desnoyers | 66cc69e | 2014-03-13 12:11:30 +1030 | [diff] [blame] | 56 | be marked as being tainted, and the concerned modules will be marked as |
Rusty Russell | 57673c2 | 2014-03-31 14:39:57 +1030 | [diff] [blame] | 57 | tainted, shown with the character 'E'. |
James Solner | 3cafea3 | 2013-11-06 12:53:36 -0600 | [diff] [blame] | 58 | |
| 59 | If this is on (ie. "restrictive"), only modules that have a valid |
| 60 | signature that can be verified by a public key in the kernel's possession |
| 61 | will be loaded. All other modules will generate an error. |
| 62 | |
| 63 | Irrespective of the setting here, if the module has a signature block that |
| 64 | cannot be parsed, it will be rejected out of hand. |
| 65 | |
| 66 | |
| 67 | (2) "Automatically sign all modules" (CONFIG_MODULE_SIG_ALL) |
| 68 | |
| 69 | If this is on then modules will be automatically signed during the |
| 70 | modules_install phase of a build. If this is off, then the modules must |
| 71 | be signed manually using: |
| 72 | |
| 73 | scripts/sign-file |
| 74 | |
| 75 | |
| 76 | (3) "Which hash algorithm should modules be signed with?" |
| 77 | |
| 78 | This presents a choice of which hash algorithm the installation phase will |
| 79 | sign the modules with: |
| 80 | |
Paul Bolle | 7df2482 | 2014-02-12 10:28:05 +0100 | [diff] [blame] | 81 | CONFIG_MODULE_SIG_SHA1 "Sign modules with SHA-1" |
| 82 | CONFIG_MODULE_SIG_SHA224 "Sign modules with SHA-224" |
| 83 | CONFIG_MODULE_SIG_SHA256 "Sign modules with SHA-256" |
| 84 | CONFIG_MODULE_SIG_SHA384 "Sign modules with SHA-384" |
| 85 | CONFIG_MODULE_SIG_SHA512 "Sign modules with SHA-512" |
James Solner | 3cafea3 | 2013-11-06 12:53:36 -0600 | [diff] [blame] | 86 | |
| 87 | The algorithm selected here will also be built into the kernel (rather |
| 88 | than being a module) so that modules signed with that algorithm can have |
| 89 | their signatures checked without causing a dependency loop. |
| 90 | |
David Woodhouse | 19e91b6 | 2015-07-20 21:16:29 +0100 | [diff] [blame] | 91 | (4) "File name or PKCS#11 URI of module signing key" (CONFIG_MODULE_SIG_KEY) |
| 92 | |
| 93 | Setting this option to something other than its default of |
| 94 | "signing_key.priv" will disable the autogeneration of signing keys and |
| 95 | allow the kernel modules to be signed with a key of your choosing. |
David Woodhouse | 1329e8c | 2015-07-20 21:16:30 +0100 | [diff] [blame^] | 96 | The string provided should identify a file containing both a private |
| 97 | key and its corresponding X.509 certificate in PEM form, or — on |
| 98 | systems where the OpenSSL ENGINE_pkcs11 is functional — a PKCS#11 URI |
| 99 | as defined by RFC7512. In the latter case, the PKCS#11 URI should |
| 100 | reference both a certificate and a private key. |
David Woodhouse | 19e91b6 | 2015-07-20 21:16:29 +0100 | [diff] [blame] | 101 | |
| 102 | If the PEM file containing the private key is encrypted, or if the |
| 103 | PKCS#11 token requries a PIN, this can be provided at build time by |
| 104 | means of the KBUILD_SIGN_PIN variable. |
| 105 | |
James Solner | 3cafea3 | 2013-11-06 12:53:36 -0600 | [diff] [blame] | 106 | |
| 107 | ======================= |
| 108 | GENERATING SIGNING KEYS |
| 109 | ======================= |
| 110 | |
| 111 | Cryptographic keypairs are required to generate and check signatures. A |
| 112 | private key is used to generate a signature and the corresponding public key is |
| 113 | used to check it. The private key is only needed during the build, after which |
| 114 | it can be deleted or stored securely. The public key gets built into the |
| 115 | kernel so that it can be used to check the signatures as the modules are |
| 116 | loaded. |
| 117 | |
David Woodhouse | 19e91b6 | 2015-07-20 21:16:29 +0100 | [diff] [blame] | 118 | Under normal conditions, when CONFIG_MODULE_SIG_KEY is unchanged from its |
| 119 | default of "signing_key.priv", the kernel build will automatically generate |
| 120 | a new keypair using openssl if one does not exist in the files: |
James Solner | 3cafea3 | 2013-11-06 12:53:36 -0600 | [diff] [blame] | 121 | |
| 122 | signing_key.priv |
| 123 | signing_key.x509 |
| 124 | |
| 125 | during the building of vmlinux (the public part of the key needs to be built |
| 126 | into vmlinux) using parameters in the: |
| 127 | |
| 128 | x509.genkey |
| 129 | |
| 130 | file (which is also generated if it does not already exist). |
| 131 | |
| 132 | It is strongly recommended that you provide your own x509.genkey file. |
| 133 | |
| 134 | Most notably, in the x509.genkey file, the req_distinguished_name section |
| 135 | should be altered from the default: |
| 136 | |
| 137 | [ req_distinguished_name ] |
David Howells | 9c4249c | 2015-04-30 14:58:43 +0100 | [diff] [blame] | 138 | #O = Unspecified company |
| 139 | CN = Build time autogenerated kernel key |
| 140 | #emailAddress = unspecified.user@unspecified.company |
James Solner | 3cafea3 | 2013-11-06 12:53:36 -0600 | [diff] [blame] | 141 | |
| 142 | The generated RSA key size can also be set with: |
| 143 | |
| 144 | [ req ] |
| 145 | default_bits = 4096 |
| 146 | |
| 147 | |
| 148 | It is also possible to manually generate the key private/public files using the |
| 149 | x509.genkey key generation configuration file in the root node of the Linux |
| 150 | kernel sources tree and the openssl command. The following is an example to |
| 151 | generate the public/private key files: |
| 152 | |
| 153 | openssl req -new -nodes -utf8 -sha256 -days 36500 -batch -x509 \ |
David Woodhouse | 19e91b6 | 2015-07-20 21:16:29 +0100 | [diff] [blame] | 154 | -config x509.genkey -outform PEM -out kernel_key.pem \ |
| 155 | -keyout kernel_key.pem |
| 156 | |
| 157 | The full pathname for the resulting kernel_key.pem file can then be specified |
| 158 | in the CONFIG_MODULE_SIG_KEY option, and the certificate and key therein will |
| 159 | be used instead of an autogenerated keypair. |
James Solner | 3cafea3 | 2013-11-06 12:53:36 -0600 | [diff] [blame] | 160 | |
| 161 | |
| 162 | ========================= |
| 163 | PUBLIC KEYS IN THE KERNEL |
| 164 | ========================= |
| 165 | |
| 166 | The kernel contains a ring of public keys that can be viewed by root. They're |
| 167 | in a keyring called ".system_keyring" that can be seen by: |
| 168 | |
| 169 | [root@deneb ~]# cat /proc/keys |
| 170 | ... |
| 171 | 223c7853 I------ 1 perm 1f030000 0 0 keyring .system_keyring: 1 |
| 172 | 302d2d52 I------ 1 perm 1f010000 0 0 asymmetri Fedora kernel signing key: d69a84e6bce3d216b979e9505b3e3ef9a7118079: X509.RSA a7118079 [] |
| 173 | ... |
| 174 | |
| 175 | Beyond the public key generated specifically for module signing, any file |
| 176 | placed in the kernel source root directory or the kernel build root directory |
| 177 | whose name is suffixed with ".x509" will be assumed to be an X.509 public key |
| 178 | and will be added to the keyring. |
| 179 | |
| 180 | Further, the architecture code may take public keys from a hardware store and |
| 181 | add those in also (e.g. from the UEFI key database). |
| 182 | |
| 183 | Finally, it is possible to add additional public keys by doing: |
| 184 | |
| 185 | keyctl padd asymmetric "" [.system_keyring-ID] <[key-file] |
| 186 | |
| 187 | e.g.: |
| 188 | |
| 189 | keyctl padd asymmetric "" 0x223c7853 <my_public_key.x509 |
| 190 | |
| 191 | Note, however, that the kernel will only permit keys to be added to |
| 192 | .system_keyring _if_ the new key's X.509 wrapper is validly signed by a key |
| 193 | that is already resident in the .system_keyring at the time the key was added. |
| 194 | |
| 195 | |
| 196 | ========================= |
| 197 | MANUALLY SIGNING MODULES |
| 198 | ========================= |
| 199 | |
| 200 | To manually sign a module, use the scripts/sign-file tool available in |
| 201 | the Linux kernel source tree. The script requires 4 arguments: |
| 202 | |
| 203 | 1. The hash algorithm (e.g., sha256) |
David Woodhouse | 19e91b6 | 2015-07-20 21:16:29 +0100 | [diff] [blame] | 204 | 2. The private key filename or PKCS#11 URI |
James Solner | 3cafea3 | 2013-11-06 12:53:36 -0600 | [diff] [blame] | 205 | 3. The public key filename |
| 206 | 4. The kernel module to be signed |
| 207 | |
| 208 | The following is an example to sign a kernel module: |
| 209 | |
| 210 | scripts/sign-file sha512 kernel-signkey.priv \ |
| 211 | kernel-signkey.x509 module.ko |
| 212 | |
| 213 | The hash algorithm used does not have to match the one configured, but if it |
| 214 | doesn't, you should make sure that hash algorithm is either built into the |
| 215 | kernel or can be loaded without requiring itself. |
| 216 | |
David Woodhouse | af1eb29 | 2015-07-20 21:16:28 +0100 | [diff] [blame] | 217 | If the private key requires a passphrase or PIN, it can be provided in the |
| 218 | $KBUILD_SIGN_PIN environment variable. |
| 219 | |
James Solner | 3cafea3 | 2013-11-06 12:53:36 -0600 | [diff] [blame] | 220 | |
| 221 | ============================ |
| 222 | SIGNED MODULES AND STRIPPING |
| 223 | ============================ |
| 224 | |
| 225 | A signed module has a digital signature simply appended at the end. The string |
| 226 | "~Module signature appended~." at the end of the module's file confirms that a |
| 227 | signature is present but it does not confirm that the signature is valid! |
| 228 | |
| 229 | Signed modules are BRITTLE as the signature is outside of the defined ELF |
| 230 | container. Thus they MAY NOT be stripped once the signature is computed and |
| 231 | attached. Note the entire module is the signed payload, including any and all |
| 232 | debug information present at the time of signing. |
| 233 | |
| 234 | |
| 235 | ====================== |
| 236 | LOADING SIGNED MODULES |
| 237 | ====================== |
| 238 | |
| 239 | Modules are loaded with insmod, modprobe, init_module() or finit_module(), |
| 240 | exactly as for unsigned modules as no processing is done in userspace. The |
| 241 | signature checking is all done within the kernel. |
| 242 | |
| 243 | |
| 244 | ========================================= |
| 245 | NON-VALID SIGNATURES AND UNSIGNED MODULES |
| 246 | ========================================= |
| 247 | |
| 248 | If CONFIG_MODULE_SIG_FORCE is enabled or enforcemodulesig=1 is supplied on |
| 249 | the kernel command line, the kernel will only load validly signed modules |
| 250 | for which it has a public key. Otherwise, it will also load modules that are |
| 251 | unsigned. Any module for which the kernel has a key, but which proves to have |
| 252 | a signature mismatch will not be permitted to load. |
| 253 | |
| 254 | Any module that has an unparseable signature will be rejected. |
| 255 | |
| 256 | |
| 257 | ========================================= |
| 258 | ADMINISTERING/PROTECTING THE PRIVATE KEY |
| 259 | ========================================= |
| 260 | |
| 261 | Since the private key is used to sign modules, viruses and malware could use |
| 262 | the private key to sign modules and compromise the operating system. The |
| 263 | private key must be either destroyed or moved to a secure location and not kept |
| 264 | in the root node of the kernel source tree. |