Lines Matching refs:the

10  - Public keys in the kernel.
15 - Administering/protecting the private key.
23 installation and then checks the signature upon loading the module. This
24 allows increased kernel security by disallowing the loading of unsigned modules
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
30 This facility uses X.509 ITU-T standard certificates to encode the public keys
32 type. The facility currently only supports the RSA public key encryption
35 SHA-512 (the algorithm is selected by data in the signature).
42 The module signing facility is enabled by going to the "Enable Loadable Module
43 Support" section of the kernel configuration and turning on
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.
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
56 be marked as being tainted, and the concerned modules will be marked as
57 tainted, shown with the character 'E'.
60 signature that can be verified by a public key in the kernel's possession
63 Irrespective of the setting here, if the module has a signature block that
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
78 This presents a choice of which hash algorithm the installation phase will
79 sign the modules with:
87 The algorithm selected here will also be built into the kernel (rather
97 private key is used to generate a signature and the corresponding public key is
98 used to check it. The private key is only needed during the build, after which
99 it can be deleted or stored securely. The public key gets built into the
100 kernel so that it can be used to check the signatures as the modules are
103 Under normal conditions, the kernel build will automatically generate a new
104 keypair using openssl if one does not exist in the files:
109 during the building of vmlinux (the public part of the key needs to be built
110 into vmlinux) using parameters in the:
118 Most notably, in the x509.genkey file, the req_distinguished_name section
119 should be altered from the default:
132 It is also possible to manually generate the key private/public files using the
133 x509.genkey key generation configuration file in the root node of the Linux
134 kernel sources tree and the openssl command. The following is an example to
135 generate the public/private key files:
155 Beyond the public key generated specifically for module signing, any file
156 placed in the kernel source root directory or the kernel build root directory
158 and will be added to the keyring.
160 Further, the architecture code may take public keys from a hardware store and
161 add those in also (e.g. from the UEFI key database).
171 Note, however, that the kernel will only permit keys to be added to
172 .system_keyring _if_ the new key's X.509 wrapper is validly signed by a key
173 that is already resident in the .system_keyring at the time the key was added.
180 To manually sign a module, use the scripts/sign-file tool available in
181 the Linux kernel source tree. The script requires 4 arguments:
193 The hash algorithm used does not have to match the one configured, but if it
194 doesn't, you should make sure that hash algorithm is either built into the
202 A signed module has a digital signature simply appended at the end. The string
203 "~Module signature appended~." at the end of the module's file confirms that a
204 signature is present but it does not confirm that the signature is valid!
206 Signed modules are BRITTLE as the signature is outside of the defined ELF
207 container. Thus they MAY NOT be stripped once the signature is computed and
208 attached. Note the entire module is the signed payload, including any and all
209 debug information present at the time of signing.
218 signature checking is all done within the kernel.
226 the kernel command line, the kernel will only load validly signed modules
228 unsigned. Any module for which the kernel has a key, but which proves to have
238 Since the private key is used to sign modules, viruses and malware could use
239 the private key to sign modules and compromise the operating system. The
241 in the root node of the kernel source tree.