kernel/linux.git/certs/Kconfig, branch v6.6.132

certs: make system keyring depend on built-in x509 parser

2022-09-23T19:31:18+00:00

Commit e90886291c7c ("certs: make system keyring depend on x509 parser") is not the right fix because x509_load_certificate_list() can be modular. The combination of CONFIG_SYSTEM_TRUSTED_KEYRING=y and CONFIG_X509_CERTIFICATE_PARSER=m still results in the following error: LD .tmp_vmlinux.kallsyms1 ld: certs/system_keyring.o: in function `load_system_certificate_list': system_keyring.c:(.init.text+0x8c): undefined reference to `x509_load_certificate_list' make: *** [Makefile:1169: vmlinux] Error 1 Fixes: e90886291c7c ("certs: make system keyring depend on x509 parser") Signed-off-by: Masahiro Yamada Tested-by: Adam Borowski

certs: make system keyring depend on x509 parser

2022-07-24T19:53:55+00:00

This code requires x509_load_certificate_list() to be built-in. Fixes: 60050ffe3d77 ("certs: Move load_certificate_list() to be with the asymmetric keys code") Reported-by: kernel test robot Reported-by: Steven Rostedt Link: https://lore.kernel.org/all/202206221515.DqpUuvbQ-lkp@intel.com/ Link: https://lore.kernel.org/all/20220712104554.408dbf42@gandalf.local.home/ Signed-off-by: Adam Borowski Signed-off-by: Linus Torvalds

certs: Allow root user to append signed hashes to the blacklist keyring

2022-05-23T15:47:49+00:00

Add a kernel option SYSTEM_BLACKLIST_AUTH_UPDATE to enable the root user to dynamically add new keys to the blacklist keyring. This enables to invalidate new certificates, either from being loaded in a keyring, or from being trusted in a PKCS#7 certificate chain. This also enables to add new file hashes to be denied by the integrity infrastructure. Being able to untrust a certificate which could have normaly been trusted is a sensitive operation. This is why adding new hashes to the blacklist keyring is only allowed when these hashes are signed and vouched by the builtin trusted keyring. A blacklist hash is stored as a key description. The PKCS#7 signature of this description must be provided as the key payload. Marking a certificate as untrusted should be enforced while the system is running. It is then forbiden to remove such blacklist keys. Update blacklist keyring, blacklist key and revoked certificate access rights: * allows the root user to search for a specific blacklisted hash, which make sense because the descriptions are already viewable; * forbids key update (blacklist and asymmetric ones); * restricts kernel rights on the blacklist keyring to align with the root user rights. See help in tools/certs/print-cert-tbs-hash.sh . Cc: David Howells Cc: David Woodhouse Cc: Eric Snowberg Cc: Jarkko Sakkinen Signed-off-by: Mickaël Salaün Link: https://lore.kernel.org/r/20210712170313.884724-6-mic@digikod.net Reviewed-by: Jarkko Sakkinen Tested-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen

certs: Check that builtin blacklist hashes are valid

2022-05-23T15:47:49+00:00

Add and use a check-blacklist-hashes.awk script to make sure that the builtin blacklist hashes set with CONFIG_SYSTEM_BLACKLIST_HASH_LIST will effectively be taken into account as blacklisted hashes. This is useful to debug invalid hash formats, and it make sure that previous hashes which could have been loaded in the kernel, but silently ignored, are now noticed and deal with by the user at kernel build time. This also prevent stricter blacklist key description checking (provided by following commits) to failed for builtin hashes. Update CONFIG_SYSTEM_BLACKLIST_HASH_LIST help to explain the content of a hash string and how to generate certificate ones. Cc: David Howells Cc: David Woodhouse Cc: Eric Snowberg Cc: Jarkko Sakkinen Signed-off-by: Mickaël Salaün Link: https://lore.kernel.org/r/20210712170313.884724-3-mic@digikod.net Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen

certs: move the 'depends on' to the choice of module signing keys

2021-12-11T13:09:14+00:00

When the condition "MODULE_SIG || (IMA_APPRAISE_MODSIG && MODULES)" is unmet, you cannot choose anything in the choice, but the choice menu is still displayed in the menuconfig etc. Move the 'depends on' to the choice to hide the meaningless menu. Also delete the redundant 'default'. In a choice, the first entry is the default. Signed-off-by: Masahiro Yamada

certs: Add support for using elliptic curve keys for signing modules

2021-08-23T16:55:42+00:00

Add support for using elliptic curve keys for signing modules. It uses a NIST P384 (secp384r1) key if the user chooses an elliptic curve key and will have ECDSA support built into the kernel. Note: A developer choosing an ECDSA key for signing modules should still delete the signing key (rm certs/signing_key.*) when building an older version of a kernel that only supports RSA keys. Unless kbuild automati- cally detects and generates a new kernel module key, ECDSA-signed kernel modules will fail signature verification. Cc: David Howells Cc: David Woodhouse Signed-off-by: Stefan Berger Reviewed-by: Jarkko Sakkinen Tested-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen

Merge tag 'integrity-v5.13' of git://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity

2021-05-01T22:32:18+00:00

Pull IMA updates from Mimi Zohar: "In addition to loading the kernel module signing key onto the builtin keyring, load it onto the IMA keyring as well. Also six trivial changes and bug fixes" * tag 'integrity-v5.13' of git://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity: ima: ensure IMA_APPRAISE_MODSIG has necessary dependencies ima: Fix fall-through warnings for Clang integrity: Add declarations to init_once void arguments. ima: Fix function name error in comment. ima: enable loading of build time generated key on .ima keyring ima: enable signing of modules with build time generated key keys: cleanup build time module signing keys ima: Fix the error code for restoring the PCR value ima: without an IMA policy loaded, return quickly

ima: ensure IMA_APPRAISE_MODSIG has necessary dependencies

2021-04-27T01:54:23+00:00

IMA_APPRAISE_MODSIG is used for verifying the integrity of both kernel and modules. Enabling IMA_APPRAISE_MODSIG without MODULES causes a build break. Ensure the build time kernel signing key is only generated if both IMA_APPRAISE_MODSIG and MODULES are enabled. Fixes: 0165f4ca223b ("ima: enable signing of modules with build time generated key") Reported-by: Randy Dunlap Reported-by: Stephen Rothwell Acked-by: Randy Dunlap # build-tested Signed-off-by: Nayna Jain Signed-off-by: Mimi Zohar

ima: enable signing of modules with build time generated key

2021-04-09T14:40:20+00:00

The kernel build process currently only signs kernel modules when MODULE_SIG is enabled. Also, sign the kernel modules at build time when IMA_APPRAISE_MODSIG is enabled. Signed-off-by: Nayna Jain Acked-by: Stefan Berger Signed-off-by: Mimi Zohar

certs: Add ability to preload revocation certs

2021-03-11T16:33:49+00:00

Add a new Kconfig option called SYSTEM_REVOCATION_KEYS. If set, this option should be the filename of a PEM-formated file containing X.509 certificates to be included in the default blacklist keyring. DH Changes: - Make the new Kconfig option depend on SYSTEM_REVOCATION_LIST. - Fix SYSTEM_REVOCATION_KEYS=n, but CONFIG_SYSTEM_REVOCATION_LIST=y[1][2]. - Use CONFIG_SYSTEM_REVOCATION_LIST for extract-cert[3]. - Use CONFIG_SYSTEM_REVOCATION_LIST for revocation_certificates.o[3]. Signed-off-by: Eric Snowberg Acked-by: Jarkko Sakkinen Signed-off-by: David Howells cc: Randy Dunlap cc: keyrings@vger.kernel.org Link: https://lore.kernel.org/r/e1c15c74-82ce-3a69-44de-a33af9b320ea@infradead.org/ [1] Link: https://lore.kernel.org/r/20210303034418.106762-1-eric.snowberg@oracle.com/ [2] Link: https://lore.kernel.org/r/20210304175030.184131-1-eric.snowberg@oracle.com/ [3] Link: https://lore.kernel.org/r/20200930201508.35113-3-eric.snowberg@oracle.com/ Link: https://lore.kernel.org/r/20210122181054.32635-4-eric.snowberg@oracle.com/ # v5 Link: https://lore.kernel.org/r/161428673564.677100.4112098280028451629.stgit@warthog.procyon.org.uk/ Link: https://lore.kernel.org/r/161433312452.902181.4146169951896577982.stgit@warthog.procyon.org.uk/ # v2 Link: https://lore.kernel.org/r/161529606657.163428.3340689182456495390.stgit@warthog.procyon.org.uk/ # v3