kernel/linux
0
Fork 0
mirror of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ synced 2026-11-10 20:48:12 +00:00
Code Issues Releases Packages Activity
linux/security/integrity/digsig.c

228 lines
5.4 KiB
Raw Permalink Normal View History

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 441 Based on 1 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public license as published by the free software foundation version 2 of the license extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference in 315 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Allison Randal <allison@lohutok.net> Reviewed-by: Armijn Hemel <armijn@tjaldur.nl> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190531190115.503150771@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-01 10:08:55 +02:00
integrity: digital signature verification using multiple keyrings Define separate keyrings for each of the different use cases - evm, ima, and modules. Using different keyrings improves search performance, and also allows "locking" specific keyring to prevent adding new keys. This is useful for evm and module keyrings, when keys are usually only added from initramfs. Signed-off-by: Dmitry Kasatkin <dmitry.kasatkin@intel.com>
2011-10-05 11:54:46 +03:00
ima: define '.ima' as a builtin 'trusted' keyring Require all keys added to the IMA keyring be signed by an existing trusted key on the system trusted keyring. Changelog v6: - remove ifdef CONFIG_IMA_TRUSTED_KEYRING in C code - Dmitry - update Kconfig dependency and help - select KEYS_DEBUG_PROC_KEYS - Dmitry Changelog v5: - Move integrity_init_keyring() to init_ima() - Dmitry - reset keyring[id] on failure - Dmitry Changelog v1: - don't link IMA trusted keyring to user keyring Changelog: - define stub integrity_init_keyring() function (reported-by Fengguang Wu) - differentiate between regular and trusted keyring names. - replace printk with pr_info (D. Kasatkin) - only make the IMA keyring a trusted keyring (reported-by D. Kastatkin) - define stub integrity_init_keyring() definition based on CONFIG_INTEGRITY_SIGNATURE, not CONFIG_INTEGRITY_ASYMMETRIC_KEYS. (reported-by Jim Davis) Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com> Signed-off-by: Dmitry Kasatkin <d.kasatkin@samsung.com> Acked-by: David Howells <dhowells@redhat.com>
2013-08-13 08:47:43 -04:00
integrity: provide a function to load x509 certificate from the kernel Provide the function to load x509 certificates from the kernel into the integrity kernel keyring. Changes in v2: * configuration option removed * function declared as '__init' Signed-off-by: Dmitry Kasatkin <d.kasatkin@samsung.com> Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
2014-11-05 17:01:13 +02:00
ima: define '.ima' as a builtin 'trusted' keyring Require all keys added to the IMA keyring be signed by an existing trusted key on the system trusted keyring. Changelog v6: - remove ifdef CONFIG_IMA_TRUSTED_KEYRING in C code - Dmitry - update Kconfig dependency and help - select KEYS_DEBUG_PROC_KEYS - Dmitry Changelog v5: - Move integrity_init_keyring() to init_ima() - Dmitry - reset keyring[id] on failure - Dmitry Changelog v1: - don't link IMA trusted keyring to user keyring Changelog: - define stub integrity_init_keyring() function (reported-by Fengguang Wu) - differentiate between regular and trusted keyring names. - replace printk with pr_info (D. Kasatkin) - only make the IMA keyring a trusted keyring (reported-by D. Kastatkin) - define stub integrity_init_keyring() definition based on CONFIG_INTEGRITY_SIGNATURE, not CONFIG_INTEGRITY_ASYMMETRIC_KEYS. (reported-by Jim Davis) Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com> Signed-off-by: Dmitry Kasatkin <d.kasatkin@samsung.com> Acked-by: David Howells <dhowells@redhat.com>
2013-08-13 08:47:43 -04:00
fs/kernel_read_file: Split into separate include file Move kernel_read_file* out of linux/fs.h to its own linux/kernel_read_file.h include file. That header gets pulled in just about everywhere and doesn't really need functions not related to the general fs interface. Suggested-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Scott Branden <scott.branden@broadcom.com> Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Mimi Zohar <zohar@linux.ibm.com> Reviewed-by: Luis Chamberlain <mcgrof@kernel.org> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: James Morris <jamorris@linux.microsoft.com> Link: https://lore.kernel.org/r/20200706232309.12010-2-scott.branden@broadcom.com Link: https://lore.kernel.org/r/20201002173828.2099543-4-keescook@chromium.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-10-02 10:38:15 -07:00
integrity: digital signature verification using multiple keyrings Define separate keyrings for each of the different use cases - evm, ima, and modules. Using different keyrings improves search performance, and also allows "locking" specific keyring to prevent adding new keys. This is useful for evm and module keyrings, when keys are usually only added from initramfs. Signed-off-by: Dmitry Kasatkin <dmitry.kasatkin@intel.com>
2011-10-05 11:54:46 +03:00
integrity/security: fix digsig.c build error with header file security/integrity/digsig.c has build errors on some $ARCH due to a missing header file, so add it. security/integrity/digsig.c:146:2: error: implicit declaration of function 'vfree' [-Werror=implicit-function-declaration] Reported-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: Mimi Zohar <zohar@linux.vnet.ibm.com> Cc: linux-integrity@vger.kernel.org Link: http://kisskb.ellerman.id.au/kisskb/head/13396/ Signed-off-by: James Morris <james.morris@microsoft.com>
2018-02-12 17:26:20 -08:00
KEYS: Move the point of trust determination to __key_link() Move the point at which a key is determined to be trustworthy to __key_link() so that we use the contents of the keyring being linked in to to determine whether the key being linked in is trusted or not. What is 'trusted' then becomes a matter of what's in the keyring. Currently, the test is done when the key is parsed, but given that at that point we can only sensibly refer to the contents of the system trusted keyring, we can only use that as the basis for working out the trustworthiness of a new key. With this change, a trusted keyring is a set of keys that once the trusted-only flag is set cannot be added to except by verification through one of the contained keys. Further, adding a key into a trusted keyring, whilst it might grant trustworthiness in the context of that keyring, does not automatically grant trustworthiness in the context of a second keyring to which it could be secondarily linked. To accomplish this, the authentication data associated with the key source must now be retained. For an X.509 cert, this means the contents of the AuthorityKeyIdentifier and the signature data. If system keyrings are disabled then restrict_link_by_builtin_trusted() resolves to restrict_link_reject(). The integrity digital signature code still works correctly with this as it was previously using KEY_FLAG_TRUSTED_ONLY, which doesn't permit anything to be added if there is no system keyring against which trust can be determined. Signed-off-by: David Howells <dhowells@redhat.com>
2016-04-06 16:14:26 +01:00
integrity: digital signature verification using multiple keyrings Define separate keyrings for each of the different use cases - evm, ima, and modules. Using different keyrings improves search performance, and also allows "locking" specific keyring to prevent adding new keys. This is useful for evm and module keyrings, when keys are usually only added from initramfs. Signed-off-by: Dmitry Kasatkin <dmitry.kasatkin@intel.com>
2011-10-05 11:54:46 +03:00
security/integrity: constify some read-only data Constify some static data that is never modified, so that it is placed in .rodata. Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
2018-09-07 13:22:23 -07:00
integrity: define '.evm' as a builtin 'trusted' keyring Require all keys added to the EVM keyring be signed by an existing trusted key on the system trusted keyring. This patch also switches IMA to use integrity_init_keyring(). Changes in v3: * Added 'init_keyring' config based variable to skip initializing keyring instead of using __integrity_init_keyring() wrapper. * Added dependency back to CONFIG_IMA_TRUSTED_KEYRING Changes in v2: * Replace CONFIG_EVM_TRUSTED_KEYRING with IMA and EVM common CONFIG_INTEGRITY_TRUSTED_KEYRING configuration option * Deprecate CONFIG_IMA_TRUSTED_KEYRING but keep it for config file compatibility. (Mimi Zohar) Signed-off-by: Dmitry Kasatkin <dmitry.kasatkin@huawei.com> Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
2015-10-22 21:26:10 +03:00
integrity: digital signature verification using multiple keyrings Define separate keyrings for each of the different use cases - evm, ima, and modules. Using different keyrings improves search performance, and also allows "locking" specific keyring to prevent adding new keys. This is useful for evm and module keyrings, when keys are usually only added from initramfs. Signed-off-by: Dmitry Kasatkin <dmitry.kasatkin@intel.com>
2011-10-05 11:54:46 +03:00
ima: define '.ima' as a builtin 'trusted' keyring Require all keys added to the IMA keyring be signed by an existing trusted key on the system trusted keyring. Changelog v6: - remove ifdef CONFIG_IMA_TRUSTED_KEYRING in C code - Dmitry - update Kconfig dependency and help - select KEYS_DEBUG_PROC_KEYS - Dmitry Changelog v5: - Move integrity_init_keyring() to init_ima() - Dmitry - reset keyring[id] on failure - Dmitry Changelog v1: - don't link IMA trusted keyring to user keyring Changelog: - define stub integrity_init_keyring() function (reported-by Fengguang Wu) - differentiate between regular and trusted keyring names. - replace printk with pr_info (D. Kasatkin) - only make the IMA keyring a trusted keyring (reported-by D. Kastatkin) - define stub integrity_init_keyring() definition based on CONFIG_INTEGRITY_SIGNATURE, not CONFIG_INTEGRITY_ASYMMETRIC_KEYS. (reported-by Jim Davis) Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com> Signed-off-by: Dmitry Kasatkin <d.kasatkin@samsung.com> Acked-by: David Howells <dhowells@redhat.com>
2013-08-13 08:47:43 -04:00
integrity: define '.evm' as a builtin 'trusted' keyring Require all keys added to the EVM keyring be signed by an existing trusted key on the system trusted keyring. This patch also switches IMA to use integrity_init_keyring(). Changes in v3: * Added 'init_keyring' config based variable to skip initializing keyring instead of using __integrity_init_keyring() wrapper. * Added dependency back to CONFIG_IMA_TRUSTED_KEYRING Changes in v2: * Replace CONFIG_EVM_TRUSTED_KEYRING with IMA and EVM common CONFIG_INTEGRITY_TRUSTED_KEYRING configuration option * Deprecate CONFIG_IMA_TRUSTED_KEYRING but keep it for config file compatibility. (Mimi Zohar) Signed-off-by: Dmitry Kasatkin <dmitry.kasatkin@huawei.com> Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
2015-10-22 21:26:10 +03:00
ima: define '.ima' as a builtin 'trusted' keyring Require all keys added to the IMA keyring be signed by an existing trusted key on the system trusted keyring. Changelog v6: - remove ifdef CONFIG_IMA_TRUSTED_KEYRING in C code - Dmitry - update Kconfig dependency and help - select KEYS_DEBUG_PROC_KEYS - Dmitry Changelog v5: - Move integrity_init_keyring() to init_ima() - Dmitry - reset keyring[id] on failure - Dmitry Changelog v1: - don't link IMA trusted keyring to user keyring Changelog: - define stub integrity_init_keyring() function (reported-by Fengguang Wu) - differentiate between regular and trusted keyring names. - replace printk with pr_info (D. Kasatkin) - only make the IMA keyring a trusted keyring (reported-by D. Kastatkin) - define stub integrity_init_keyring() definition based on CONFIG_INTEGRITY_SIGNATURE, not CONFIG_INTEGRITY_ASYMMETRIC_KEYS. (reported-by Jim Davis) Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com> Signed-off-by: Dmitry Kasatkin <d.kasatkin@samsung.com> Acked-by: David Howells <dhowells@redhat.com>
2013-08-13 08:47:43 -04:00
integrity: Define a trusted platform keyring On secure boot enabled systems, a verified kernel may need to kexec additional kernels. For example, it may be used as a bootloader needing to kexec a target kernel or it may need to kexec a crashdump kernel. In such cases, it may want to verify the signature of the next kernel image. It is further possible that the kernel image is signed with third party keys which are stored as platform or firmware keys in the 'db' variable. The kernel, however, can not directly verify these platform keys, and an administrator may therefore not want to trust them for arbitrary usage. In order to differentiate platform keys from other keys and provide the necessary separation of trust, the kernel needs an additional keyring to store platform keys. This patch creates the new keyring called ".platform" to isolate keys provided by platform from keys by kernel. These keys are used to facilitate signature verification during kexec. Since the scope of this keyring is only the platform/firmware keys, it cannot be updated from userspace. This keyring can be enabled by setting CONFIG_INTEGRITY_PLATFORM_KEYRING. Signed-off-by: Nayna Jain <nayna@linux.ibm.com> Reviewed-by: Mimi Zohar <zohar@linux.ibm.com> Acked-by: Serge Hallyn <serge@hallyn.com> Reviewed-by: James Morris <james.morris@microsoft.com> Reviewed-by: Thiago Jung Bauermann <bauerman@linux.ibm.com> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
2018-12-09 01:56:59 +05:30
integrity: Introduce a Linux keyring called machine Many UEFI Linux distributions boot using shim. The UEFI shim provides what is called Machine Owner Keys (MOK). Shim uses both the UEFI Secure Boot DB and MOK keys to validate the next step in the boot chain. The MOK facility can be used to import user generated keys. These keys can be used to sign an end-users development kernel build. When Linux boots, both UEFI Secure Boot DB and MOK keys get loaded in the Linux .platform keyring. Define a new Linux keyring called machine. This keyring shall contain just MOK keys and not the remaining keys in the platform keyring. This new machine keyring will be used in follow on patches. Unlike keys in the platform keyring, keys contained in the machine keyring will be trusted within the kernel if the end-user has chosen to do so. Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com> Tested-by: Jarkko Sakkinen <jarkko@kernel.org> Tested-by: Mimi Zohar <zohar@linux.ibm.com> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2022-01-25 21:58:28 -05:00
integrity: digital signature verification using multiple keyrings Define separate keyrings for each of the different use cases - evm, ima, and modules. Using different keyrings improves search performance, and also allows "locking" specific keyring to prevent adding new keys. This is useful for evm and module keyrings, when keys are usually only added from initramfs. Signed-off-by: Dmitry Kasatkin <dmitry.kasatkin@intel.com>
2011-10-05 11:54:46 +03:00
IMA: Use the the system trusted keyrings instead of .ima_mok Add a config option (IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY) that, when enabled, allows keys to be added to the IMA keyrings by userspace - with the restriction that each must be signed by a key in the system trusted keyrings. EPERM will be returned if this option is disabled, ENOKEY will be returned if no authoritative key can be found and EKEYREJECTED will be returned if the signature doesn't match. Other errors such as ENOPKG may also be returned. If this new option is enabled, the builtin system keyring is searched, as is the secondary system keyring if that is also enabled. Intermediate keys between the builtin system keyring and the key being added can be added to the secondary keyring (which replaces .ima_mok) to form a trust chain - provided they are also validly signed by a key in one of the trusted keyrings. The .ima_mok keyring is then removed and the IMA blacklist keyring gets its own config option (IMA_BLACKLIST_KEYRING). Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
2016-04-07 09:45:23 +01:00
integrity: Enforce digitalSignature usage in the ima and evm keyrings After being vouched for by a system keyring, only allow keys into the .ima and .evm keyrings that have the digitalSignature usage field set. Link: https://lore.kernel.org/all/41dffdaeb7eb7840f7e38bc691fbda836635c9f9.camel@linux.ibm.com Suggested-by: Mimi Zohar <zohar@linux.ibm.com> Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com> Acked-and-tested-by: Mimi Zohar <zohar@linux.ibm.com> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2023-05-22 19:09:43 -04:00
KEYS: Move the point of trust determination to __key_link() Move the point at which a key is determined to be trustworthy to __key_link() so that we use the contents of the keyring being linked in to to determine whether the key being linked in is trusted or not. What is 'trusted' then becomes a matter of what's in the keyring. Currently, the test is done when the key is parsed, but given that at that point we can only sensibly refer to the contents of the system trusted keyring, we can only use that as the basis for working out the trustworthiness of a new key. With this change, a trusted keyring is a set of keys that once the trusted-only flag is set cannot be added to except by verification through one of the contained keys. Further, adding a key into a trusted keyring, whilst it might grant trustworthiness in the context of that keyring, does not automatically grant trustworthiness in the context of a second keyring to which it could be secondarily linked. To accomplish this, the authentication data associated with the key source must now be retained. For an X.509 cert, this means the contents of the AuthorityKeyIdentifier and the signature data. If system keyrings are disabled then restrict_link_by_builtin_trusted() resolves to restrict_link_reject(). The integrity digital signature code still works correctly with this as it was previously using KEY_FLAG_TRUSTED_ONLY, which doesn't permit anything to be added if there is no system keyring against which trust can be determined. Signed-off-by: David Howells <dhowells@redhat.com>
2016-04-06 16:14:26 +01:00
integrity: Enforce digitalSignature usage in the ima and evm keyrings After being vouched for by a system keyring, only allow keys into the .ima and .evm keyrings that have the digitalSignature usage field set. Link: https://lore.kernel.org/all/41dffdaeb7eb7840f7e38bc691fbda836635c9f9.camel@linux.ibm.com Suggested-by: Mimi Zohar <zohar@linux.ibm.com> Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com> Acked-and-tested-by: Mimi Zohar <zohar@linux.ibm.com> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2023-05-22 19:09:43 -04:00
KEYS: Move the point of trust determination to __key_link() Move the point at which a key is determined to be trustworthy to __key_link() so that we use the contents of the keyring being linked in to to determine whether the key being linked in is trusted or not. What is 'trusted' then becomes a matter of what's in the keyring. Currently, the test is done when the key is parsed, but given that at that point we can only sensibly refer to the contents of the system trusted keyring, we can only use that as the basis for working out the trustworthiness of a new key. With this change, a trusted keyring is a set of keys that once the trusted-only flag is set cannot be added to except by verification through one of the contained keys. Further, adding a key into a trusted keyring, whilst it might grant trustworthiness in the context of that keyring, does not automatically grant trustworthiness in the context of a second keyring to which it could be secondarily linked. To accomplish this, the authentication data associated with the key source must now be retained. For an X.509 cert, this means the contents of the AuthorityKeyIdentifier and the signature data. If system keyrings are disabled then restrict_link_by_builtin_trusted() resolves to restrict_link_reject(). The integrity digital signature code still works correctly with this as it was previously using KEY_FLAG_TRUSTED_ONLY, which doesn't permit anything to be added if there is no system keyring against which trust can be determined. Signed-off-by: David Howells <dhowells@redhat.com>
2016-04-06 16:14:26 +01:00
ima: Implement support for module-style appended signatures Implement the appraise_type=imasig|modsig option, allowing IMA to read and verify modsig signatures. In case a file has both an xattr signature and an appended modsig, IMA will only use the appended signature if the key used by the xattr signature isn't present in the IMA or platform keyring. Because modsig verification needs to convert from an integrity keyring id to the keyring itself, add an integrity_keyring_from_id() function in digsig.c so that integrity_modsig_verify() can use it. Signed-off-by: Thiago Jung Bauermann <bauerman@linux.ibm.com> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
2019-06-27 23:19:30 -03:00
integrity: digital signature verification using multiple keyrings Define separate keyrings for each of the different use cases - evm, ima, and modules. Using different keyrings improves search performance, and also allows "locking" specific keyring to prevent adding new keys. This is useful for evm and module keyrings, when keys are usually only added from initramfs. Signed-off-by: Dmitry Kasatkin <dmitry.kasatkin@intel.com>
2011-10-05 11:54:46 +03:00
ima: Implement support for module-style appended signatures Implement the appraise_type=imasig|modsig option, allowing IMA to read and verify modsig signatures. In case a file has both an xattr signature and an appended modsig, IMA will only use the appended signature if the key used by the xattr signature isn't present in the IMA or platform keyring. Because modsig verification needs to convert from an integrity keyring id to the keyring itself, add an integrity_keyring_from_id() function in digsig.c so that integrity_modsig_verify() can use it. Signed-off-by: Thiago Jung Bauermann <bauerman@linux.ibm.com> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
2019-06-27 23:19:30 -03:00
integrity: digital signature verification using multiple keyrings Define separate keyrings for each of the different use cases - evm, ima, and modules. Using different keyrings improves search performance, and also allows "locking" specific keyring to prevent adding new keys. This is useful for evm and module keyrings, when keys are usually only added from initramfs. Signed-off-by: Dmitry Kasatkin <dmitry.kasatkin@intel.com>
2011-10-05 11:54:46 +03:00
Revert "Merge tag 'keys-acl-20190703' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs" This reverts merge 0f75ef6a9cff49ff612f7ce0578bced9d0b38325 (and thus effectively commits 7a1ade847596 ("keys: Provide KEYCTL_GRANT_PERMISSION") 2e12256b9a76 ("keys: Replace uid/gid/perm permissions checking with an ACL") that the merge brought in). It turns out that it breaks booting with an encrypted volume, and Eric biggers reports that it also breaks the fscrypt tests [1] and loading of in-kernel X.509 certificates [2]. The root cause of all the breakage is likely the same, but David Howells is off email so rather than try to work it out it's getting reverted in order to not impact the rest of the merge window. [1] https://lore.kernel.org/lkml/20190710011559.GA7973@sol.localdomain/ [2] https://lore.kernel.org/lkml/20190710013225.GB7973@sol.localdomain/ Link: https://lore.kernel.org/lkml/CAHk-=wjxoeMJfeBahnWH=9zShKp2bsVy527vo3_y8HfOdhwAAw@mail.gmail.com/ Reported-by: Eric Biggers <ebiggers@kernel.org> Cc: David Howells <dhowells@redhat.com> Cc: James Morris <jmorris@namei.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-07-10 18:43:43 -07:00
integrity: digital signature verification using multiple keyrings Define separate keyrings for each of the different use cases - evm, ima, and modules. Using different keyrings improves search performance, and also allows "locking" specific keyring to prevent adding new keys. This is useful for evm and module keyrings, when keys are usually only added from initramfs. Signed-off-by: Dmitry Kasatkin <dmitry.kasatkin@intel.com>
2011-10-05 11:54:46 +03:00
ima: Implement support for module-style appended signatures Implement the appraise_type=imasig|modsig option, allowing IMA to read and verify modsig signatures. In case a file has both an xattr signature and an appended modsig, IMA will only use the appended signature if the key used by the xattr signature isn't present in the IMA or platform keyring. Because modsig verification needs to convert from an integrity keyring id to the keyring itself, add an integrity_keyring_from_id() function in digsig.c so that integrity_modsig_verify() can use it. Signed-off-by: Thiago Jung Bauermann <bauerman@linux.ibm.com> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
2019-06-27 23:19:30 -03:00
integrity: digital signature verification using multiple keyrings Define separate keyrings for each of the different use cases - evm, ima, and modules. Using different keyrings improves search performance, and also allows "locking" specific keyring to prevent adding new keys. This is useful for evm and module keyrings, when keys are usually only added from initramfs. Signed-off-by: Dmitry Kasatkin <dmitry.kasatkin@intel.com>
2011-10-05 11:54:46 +03:00
ima: Implement support for module-style appended signatures Implement the appraise_type=imasig|modsig option, allowing IMA to read and verify modsig signatures. In case a file has both an xattr signature and an appended modsig, IMA will only use the appended signature if the key used by the xattr signature isn't present in the IMA or platform keyring. Because modsig verification needs to convert from an integrity keyring id to the keyring itself, add an integrity_keyring_from_id() function in digsig.c so that integrity_modsig_verify() can use it. Signed-off-by: Thiago Jung Bauermann <bauerman@linux.ibm.com> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
2019-06-27 23:19:30 -03:00
ima: Define asymmetric_verify_v3() to verify IMA sigv3 signatures Define asymmetric_verify_v3() to calculate the hash of the struct ima_file_id, before calling asymmetric_verify() to verify the signature. Move and update the existing calc_file_id_hash() function with a simpler, self contained version. In addition to the existing hash data and hash data length arguments, also pass the hash algorithm. Suggested-by: Stefan Berger <stefanb@linux.ibm.com> Tested-by: Stefan Berger <stefanb@linux.ibm.com> Acked-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
2026-03-10 19:42:07 -04:00
ima: Implement support for module-style appended signatures Implement the appraise_type=imasig|modsig option, allowing IMA to read and verify modsig signatures. In case a file has both an xattr signature and an appended modsig, IMA will only use the appended signature if the key used by the xattr signature isn't present in the IMA or platform keyring. Because modsig verification needs to convert from an integrity keyring id to the keyring itself, add an integrity_keyring_from_id() function in digsig.c so that integrity_modsig_verify() can use it. Signed-off-by: Thiago Jung Bauermann <bauerman@linux.ibm.com> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
2019-06-27 23:19:30 -03:00
ima: pass full xattr with the signature For possibility to use xattr type for new signature formats, pass full xattr to the signature verification function. Signed-off-by: Dmitry Kasatkin <d.kasatkin@samsung.com> Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
2013-10-10 16:12:03 +09:00
ima: digital signature verification using asymmetric keys Asymmetric keys were introduced in linux-3.7 to verify the signature on signed kernel modules. The asymmetric keys infrastructure abstracts the signature verification from the crypto details. This patch adds IMA/EVM signature verification using asymmetric keys. Support for additional signature verification methods can now be delegated to the asymmetric key infrastructure. Although the module signature header and the IMA/EVM signature header could use the same format, to minimize the signature length and save space in the extended attribute, this patch defines a new IMA/EVM header format. The main difference is that the key identifier is a sha1[12 - 19] hash of the key modulus and exponent, similar to the current implementation. The only purpose of the key identifier is to identify the corresponding key in the kernel keyring. ima-evm-utils was updated to support the new signature format. While asymmetric signature verification functionality supports many different hash algorithms, the hash used in this patch is calculated during the IMA collection phase, based on the configured algorithm. The default algorithm is sha1, but for backwards compatibility md5 is supported. Due to this current limitation, signatures should be generated using a sha1 hash algorithm. Changes in this patch: - Functionality has been moved to separate source file in order to get rid of in source #ifdefs. - keyid is derived according to the RFC 3280. It does not require to assign IMA/EVM specific "description" when loading X509 certificate. Kernel asymmetric key subsystem automatically generate the description. Also loading a certificate does not require using of ima-evm-utils and can be done using keyctl only. - keyid size is reduced to 32 bits to save xattr space. Key search is done using partial match functionality of asymmetric_key_match(). - Kconfig option title was changed Signed-off-by: Dmitry Kasatkin <dmitry.kasatkin@intel.com> Acked-by: David Howells <dhowells@redhat.com> Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
2013-02-07 00:12:08 +02:00
ima: pass full xattr with the signature For possibility to use xattr type for new signature formats, pass full xattr to the signature verification function. Signed-off-by: Dmitry Kasatkin <d.kasatkin@samsung.com> Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
2013-10-10 16:12:03 +09:00
ima: Implement support for module-style appended signatures Implement the appraise_type=imasig|modsig option, allowing IMA to read and verify modsig signatures. In case a file has both an xattr signature and an appended modsig, IMA will only use the appended signature if the key used by the xattr signature isn't present in the IMA or platform keyring. Because modsig verification needs to convert from an integrity keyring id to the keyring itself, add an integrity_keyring_from_id() function in digsig.c so that integrity_modsig_verify() can use it. Signed-off-by: Thiago Jung Bauermann <bauerman@linux.ibm.com> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
2019-06-27 23:19:30 -03:00
ima: support fs-verity file digest based version 3 signatures IMA may verify a file's integrity against a "good" value stored in the 'security.ima' xattr or as an appended signature, based on policy. When the "good value" is stored in the xattr, the xattr may contain a file hash or signature. In either case, the "good" value is preceded by a header. The first byte of the xattr header indicates the type of data - hash, signature - stored in the xattr. To support storing fs-verity signatures in the 'security.ima' xattr requires further differentiating the fs-verity signature from the existing IMA signature. In addition the signatures stored in 'security.ima' xattr, need to be disambiguated. Instead of directly signing the fs-verity digest, a new signature format version 3 is defined as the hash of the ima_file_id structure, which identifies the type of signature and the digest. The IMA policy defines "which" files are to be measured, verified, and/or audited. For those files being verified, the policy rules indicate "how" the file should be verified. For example to require a file be signed, the appraise policy rule must include the 'appraise_type' option. appraise_type:= [imasig] | [imasig|modsig] | [sigv3] where 'imasig' is the original or signature format v2 (default), where 'modsig' is an appended signature, where 'sigv3' is the signature format v3. The policy rule must also indicate the type of digest, if not the IMA default, by first specifying the digest type: digest_type:= [verity] The following policy rule requires fsverity signatures. The rule may be constrained, for example based on a fsuuid or LSM label. appraise func=BPRM_CHECK digest_type=verity appraise_type=sigv3 Acked-by: Stefan Berger <stefanb@linux.ibm.com> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
2021-11-24 10:56:33 -05:00
ima: Implement support for module-style appended signatures Implement the appraise_type=imasig|modsig option, allowing IMA to read and verify modsig signatures. In case a file has both an xattr signature and an appended modsig, IMA will only use the appended signature if the key used by the xattr signature isn't present in the IMA or platform keyring. Because modsig verification needs to convert from an integrity keyring id to the keyring itself, add an integrity_keyring_from_id() function in digsig.c so that integrity_modsig_verify() can use it. Signed-off-by: Thiago Jung Bauermann <bauerman@linux.ibm.com> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
2019-06-27 23:19:30 -03:00
ima: Define asymmetric_verify_v3() to verify IMA sigv3 signatures Define asymmetric_verify_v3() to calculate the hash of the struct ima_file_id, before calling asymmetric_verify() to verify the signature. Move and update the existing calc_file_id_hash() function with a simpler, self contained version. In addition to the existing hash data and hash data length arguments, also pass the hash algorithm. Suggested-by: Stefan Berger <stefanb@linux.ibm.com> Tested-by: Stefan Berger <stefanb@linux.ibm.com> Acked-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
2026-03-10 19:42:07 -04:00
ima: digital signature verification using asymmetric keys Asymmetric keys were introduced in linux-3.7 to verify the signature on signed kernel modules. The asymmetric keys infrastructure abstracts the signature verification from the crypto details. This patch adds IMA/EVM signature verification using asymmetric keys. Support for additional signature verification methods can now be delegated to the asymmetric key infrastructure. Although the module signature header and the IMA/EVM signature header could use the same format, to minimize the signature length and save space in the extended attribute, this patch defines a new IMA/EVM header format. The main difference is that the key identifier is a sha1[12 - 19] hash of the key modulus and exponent, similar to the current implementation. The only purpose of the key identifier is to identify the corresponding key in the kernel keyring. ima-evm-utils was updated to support the new signature format. While asymmetric signature verification functionality supports many different hash algorithms, the hash used in this patch is calculated during the IMA collection phase, based on the configured algorithm. The default algorithm is sha1, but for backwards compatibility md5 is supported. Due to this current limitation, signatures should be generated using a sha1 hash algorithm. Changes in this patch: - Functionality has been moved to separate source file in order to get rid of in source #ifdefs. - keyid is derived according to the RFC 3280. It does not require to assign IMA/EVM specific "description" when loading X509 certificate. Kernel asymmetric key subsystem automatically generate the description. Also loading a certificate does not require using of ima-evm-utils and can be done using keyctl only. - keyid size is reduced to 32 bits to save xattr space. Key search is done using partial match functionality of asymmetric_key_match(). - Kconfig option title was changed Signed-off-by: Dmitry Kasatkin <dmitry.kasatkin@intel.com> Acked-by: David Howells <dhowells@redhat.com> Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
2013-02-07 00:12:08 +02:00
integrity: digital signature verification using multiple keyrings Define separate keyrings for each of the different use cases - evm, ima, and modules. Using different keyrings improves search performance, and also allows "locking" specific keyring to prevent adding new keys. This is useful for evm and module keyrings, when keys are usually only added from initramfs. Signed-off-by: Dmitry Kasatkin <dmitry.kasatkin@intel.com>
2011-10-05 11:54:46 +03:00
ima: define '.ima' as a builtin 'trusted' keyring Require all keys added to the IMA keyring be signed by an existing trusted key on the system trusted keyring. Changelog v6: - remove ifdef CONFIG_IMA_TRUSTED_KEYRING in C code - Dmitry - update Kconfig dependency and help - select KEYS_DEBUG_PROC_KEYS - Dmitry Changelog v5: - Move integrity_init_keyring() to init_ima() - Dmitry - reset keyring[id] on failure - Dmitry Changelog v1: - don't link IMA trusted keyring to user keyring Changelog: - define stub integrity_init_keyring() function (reported-by Fengguang Wu) - differentiate between regular and trusted keyring names. - replace printk with pr_info (D. Kasatkin) - only make the IMA keyring a trusted keyring (reported-by D. Kastatkin) - define stub integrity_init_keyring() definition based on CONFIG_INTEGRITY_SIGNATURE, not CONFIG_INTEGRITY_ASYMMETRIC_KEYS. (reported-by Jim Davis) Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com> Signed-off-by: Dmitry Kasatkin <d.kasatkin@samsung.com> Acked-by: David Howells <dhowells@redhat.com>
2013-08-13 08:47:43 -04:00
ima: Implement support for module-style appended signatures Implement the appraise_type=imasig|modsig option, allowing IMA to read and verify modsig signatures. In case a file has both an xattr signature and an appended modsig, IMA will only use the appended signature if the key used by the xattr signature isn't present in the IMA or platform keyring. Because modsig verification needs to convert from an integrity keyring id to the keyring itself, add an integrity_keyring_from_id() function in digsig.c so that integrity_modsig_verify() can use it. Signed-off-by: Thiago Jung Bauermann <bauerman@linux.ibm.com> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
2019-06-27 23:19:30 -03:00
integrity: Fix __integrity_init_keyring() section mismatch With gcc-4.6.3: WARNING: vmlinux.o(.text.unlikely+0x24c64): Section mismatch in reference from the function __integrity_init_keyring() to the function .init.text:set_platform_trusted_keys() The function __integrity_init_keyring() references the function __init set_platform_trusted_keys(). This is often because __integrity_init_keyring lacks a __init annotation or the annotation of set_platform_trusted_keys is wrong. Indeed, if the compiler decides not to inline __integrity_init_keyring(), a warning is issued. Fix this by adding the missing __init annotation. Fixes: 9dc92c45177ab70e ("integrity: Define a trusted platform keyring") Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Reviewed-by: Nayna Jain <nayna@linux.ibm.com> Reviewed-by: James Morris <jamorris@linux.microsoft.com> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
2019-06-17 09:44:52 +02:00
Revert "Merge tag 'keys-acl-20190703' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs" This reverts merge 0f75ef6a9cff49ff612f7ce0578bced9d0b38325 (and thus effectively commits 7a1ade847596 ("keys: Provide KEYCTL_GRANT_PERMISSION") 2e12256b9a76 ("keys: Replace uid/gid/perm permissions checking with an ACL") that the merge brought in). It turns out that it breaks booting with an encrypted volume, and Eric biggers reports that it also breaks the fscrypt tests [1] and loading of in-kernel X.509 certificates [2]. The root cause of all the breakage is likely the same, but David Howells is off email so rather than try to work it out it's getting reverted in order to not impact the rest of the merge window. [1] https://lore.kernel.org/lkml/20190710011559.GA7973@sol.localdomain/ [2] https://lore.kernel.org/lkml/20190710013225.GB7973@sol.localdomain/ Link: https://lore.kernel.org/lkml/CAHk-=wjxoeMJfeBahnWH=9zShKp2bsVy527vo3_y8HfOdhwAAw@mail.gmail.com/ Reported-by: Eric Biggers <ebiggers@kernel.org> Cc: David Howells <dhowells@redhat.com> Cc: James Morris <jmorris@namei.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-07-10 18:43:43 -07:00
integrity: Fix __integrity_init_keyring() section mismatch With gcc-4.6.3: WARNING: vmlinux.o(.text.unlikely+0x24c64): Section mismatch in reference from the function __integrity_init_keyring() to the function .init.text:set_platform_trusted_keys() The function __integrity_init_keyring() references the function __init set_platform_trusted_keys(). This is often because __integrity_init_keyring lacks a __init annotation or the annotation of set_platform_trusted_keys is wrong. Indeed, if the compiler decides not to inline __integrity_init_keyring(), a warning is issued. Fix this by adding the missing __init annotation. Fixes: 9dc92c45177ab70e ("integrity: Define a trusted platform keyring") Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Reviewed-by: Nayna Jain <nayna@linux.ibm.com> Reviewed-by: James Morris <jamorris@linux.microsoft.com> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
2019-06-17 09:44:52 +02:00
ima: define '.ima' as a builtin 'trusted' keyring Require all keys added to the IMA keyring be signed by an existing trusted key on the system trusted keyring. Changelog v6: - remove ifdef CONFIG_IMA_TRUSTED_KEYRING in C code - Dmitry - update Kconfig dependency and help - select KEYS_DEBUG_PROC_KEYS - Dmitry Changelog v5: - Move integrity_init_keyring() to init_ima() - Dmitry - reset keyring[id] on failure - Dmitry Changelog v1: - don't link IMA trusted keyring to user keyring Changelog: - define stub integrity_init_keyring() function (reported-by Fengguang Wu) - differentiate between regular and trusted keyring names. - replace printk with pr_info (D. Kasatkin) - only make the IMA keyring a trusted keyring (reported-by D. Kastatkin) - define stub integrity_init_keyring() definition based on CONFIG_INTEGRITY_SIGNATURE, not CONFIG_INTEGRITY_ASYMMETRIC_KEYS. (reported-by Jim Davis) Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com> Signed-off-by: Dmitry Kasatkin <d.kasatkin@samsung.com> Acked-by: David Howells <dhowells@redhat.com>
2013-08-13 08:47:43 -04:00
integrity: Define a trusted platform keyring On secure boot enabled systems, a verified kernel may need to kexec additional kernels. For example, it may be used as a bootloader needing to kexec a target kernel or it may need to kexec a crashdump kernel. In such cases, it may want to verify the signature of the next kernel image. It is further possible that the kernel image is signed with third party keys which are stored as platform or firmware keys in the 'db' variable. The kernel, however, can not directly verify these platform keys, and an administrator may therefore not want to trust them for arbitrary usage. In order to differentiate platform keys from other keys and provide the necessary separation of trust, the kernel needs an additional keyring to store platform keys. This patch creates the new keyring called ".platform" to isolate keys provided by platform from keys by kernel. These keys are used to facilitate signature verification during kexec. Since the scope of this keyring is only the platform/firmware keys, it cannot be updated from userspace. This keyring can be enabled by setting CONFIG_INTEGRITY_PLATFORM_KEYRING. Signed-off-by: Nayna Jain <nayna@linux.ibm.com> Reviewed-by: Mimi Zohar <zohar@linux.ibm.com> Acked-by: Serge Hallyn <serge@hallyn.com> Reviewed-by: James Morris <james.morris@microsoft.com> Reviewed-by: Thiago Jung Bauermann <bauerman@linux.ibm.com> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
2018-12-09 01:56:59 +05:30
Revert "Merge tag 'keys-acl-20190703' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs" This reverts merge 0f75ef6a9cff49ff612f7ce0578bced9d0b38325 (and thus effectively commits 7a1ade847596 ("keys: Provide KEYCTL_GRANT_PERMISSION") 2e12256b9a76 ("keys: Replace uid/gid/perm permissions checking with an ACL") that the merge brought in). It turns out that it breaks booting with an encrypted volume, and Eric biggers reports that it also breaks the fscrypt tests [1] and loading of in-kernel X.509 certificates [2]. The root cause of all the breakage is likely the same, but David Howells is off email so rather than try to work it out it's getting reverted in order to not impact the rest of the merge window. [1] https://lore.kernel.org/lkml/20190710011559.GA7973@sol.localdomain/ [2] https://lore.kernel.org/lkml/20190710013225.GB7973@sol.localdomain/ Link: https://lore.kernel.org/lkml/CAHk-=wjxoeMJfeBahnWH=9zShKp2bsVy527vo3_y8HfOdhwAAw@mail.gmail.com/ Reported-by: Eric Biggers <ebiggers@kernel.org> Cc: David Howells <dhowells@redhat.com> Cc: James Morris <jmorris@namei.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-07-10 18:43:43 -07:00
integrity: Load certs to the platform keyring The patch refactors integrity_load_x509(), making it a wrapper for a new function named integrity_add_key(). This patch also defines a new function named integrity_load_cert() for loading the platform keys. Signed-off-by: Nayna Jain <nayna@linux.ibm.com> Reviewed-by: Mimi Zohar <zohar@linux.ibm.com> Acked-by: Serge Hallyn <serge@hallyn.com> Reviewed-by: James Morris <james.morris@microsoft.com> Reviewed-by: Thiago Jung Bauermann <bauerman@linux.ibm.com> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
2018-12-09 01:57:00 +05:30
integrity: Define a trusted platform keyring On secure boot enabled systems, a verified kernel may need to kexec additional kernels. For example, it may be used as a bootloader needing to kexec a target kernel or it may need to kexec a crashdump kernel. In such cases, it may want to verify the signature of the next kernel image. It is further possible that the kernel image is signed with third party keys which are stored as platform or firmware keys in the 'db' variable. The kernel, however, can not directly verify these platform keys, and an administrator may therefore not want to trust them for arbitrary usage. In order to differentiate platform keys from other keys and provide the necessary separation of trust, the kernel needs an additional keyring to store platform keys. This patch creates the new keyring called ".platform" to isolate keys provided by platform from keys by kernel. These keys are used to facilitate signature verification during kexec. Since the scope of this keyring is only the platform/firmware keys, it cannot be updated from userspace. This keyring can be enabled by setting CONFIG_INTEGRITY_PLATFORM_KEYRING. Signed-off-by: Nayna Jain <nayna@linux.ibm.com> Reviewed-by: Mimi Zohar <zohar@linux.ibm.com> Acked-by: Serge Hallyn <serge@hallyn.com> Reviewed-by: James Morris <james.morris@microsoft.com> Reviewed-by: Thiago Jung Bauermann <bauerman@linux.ibm.com> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
2018-12-09 01:56:59 +05:30
integrity, KEYS: add a reference to platform keyring commit 9dc92c45177a ("integrity: Define a trusted platform keyring") introduced a .platform keyring for storing preboot keys, used for verifying kernel image signatures. Currently only IMA-appraisal is able to use the keyring to verify kernel images that have their signature stored in xattr. This patch exposes the .platform keyring, making it accessible for verifying PE signed kernel images as well. Suggested-by: Mimi Zohar <zohar@linux.ibm.com> Signed-off-by: Kairui Song <kasong@redhat.com> Cc: David Howells <dhowells@redhat.com> [zohar@linux.ibm.com: fixed checkpatch errors, squashed with patch fix] Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
2019-01-21 17:59:28 +08:00
integrity: check whether imputed trust is enabled trust_moklist() is specific to UEFI enabled systems. Other platforms rely only on the Kconfig. Define a generic wrapper named imputed_trust_enabled(). Signed-off-by: Nayna Jain <nayna@linux.ibm.com> Reviewed-by: Mimi Zohar <zohar@linux.ibm.com> Tested-by: Nageswara R Sastry <rnsastry@linux.ibm.com> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2023-08-15 07:27:20 -04:00
KEYS: store reference to machine keyring Expose the .machine keyring created in integrity code by adding a reference. Store a reference to the machine keyring in system keyring code. The system keyring code needs this to complete the keyring link to the machine keyring. Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Tested-by: Mimi Zohar <zohar@linux.ibm.com> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2022-01-25 21:58:30 -05:00
ima: enable loading of build time generated key on .ima keyring The kernel currently only loads the kernel module signing key onto the builtin trusted keyring. Load the module signing key onto the IMA keyring as well. Signed-off-by: Nayna Jain <nayna@linux.ibm.com> Acked-by: Stefan Berger <stefanb@linux.ibm.com> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
2021-04-09 10:35:07 -04:00
integrity: Define a trusted platform keyring On secure boot enabled systems, a verified kernel may need to kexec additional kernels. For example, it may be used as a bootloader needing to kexec a target kernel or it may need to kexec a crashdump kernel. In such cases, it may want to verify the signature of the next kernel image. It is further possible that the kernel image is signed with third party keys which are stored as platform or firmware keys in the 'db' variable. The kernel, however, can not directly verify these platform keys, and an administrator may therefore not want to trust them for arbitrary usage. In order to differentiate platform keys from other keys and provide the necessary separation of trust, the kernel needs an additional keyring to store platform keys. This patch creates the new keyring called ".platform" to isolate keys provided by platform from keys by kernel. These keys are used to facilitate signature verification during kexec. Since the scope of this keyring is only the platform/firmware keys, it cannot be updated from userspace. This keyring can be enabled by setting CONFIG_INTEGRITY_PLATFORM_KEYRING. Signed-off-by: Nayna Jain <nayna@linux.ibm.com> Reviewed-by: Mimi Zohar <zohar@linux.ibm.com> Acked-by: Serge Hallyn <serge@hallyn.com> Reviewed-by: James Morris <james.morris@microsoft.com> Reviewed-by: Thiago Jung Bauermann <bauerman@linux.ibm.com> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
2018-12-09 01:56:59 +05:30
Revert "Merge tag 'keys-acl-20190703' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs" This reverts merge 0f75ef6a9cff49ff612f7ce0578bced9d0b38325 (and thus effectively commits 7a1ade847596 ("keys: Provide KEYCTL_GRANT_PERMISSION") 2e12256b9a76 ("keys: Replace uid/gid/perm permissions checking with an ACL") that the merge brought in). It turns out that it breaks booting with an encrypted volume, and Eric biggers reports that it also breaks the fscrypt tests [1] and loading of in-kernel X.509 certificates [2]. The root cause of all the breakage is likely the same, but David Howells is off email so rather than try to work it out it's getting reverted in order to not impact the rest of the merge window. [1] https://lore.kernel.org/lkml/20190710011559.GA7973@sol.localdomain/ [2] https://lore.kernel.org/lkml/20190710013225.GB7973@sol.localdomain/ Link: https://lore.kernel.org/lkml/CAHk-=wjxoeMJfeBahnWH=9zShKp2bsVy527vo3_y8HfOdhwAAw@mail.gmail.com/ Reported-by: Eric Biggers <ebiggers@kernel.org> Cc: David Howells <dhowells@redhat.com> Cc: James Morris <jmorris@namei.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-07-10 18:43:43 -07:00
integrity: Fix memory leakage in keyring allocation error path Key restriction is allocated in integrity_init_keyring(). However, if keyring allocation failed, it is not freed, causing memory leaks. Fixes: 2b6aa412ff23 ("KEYS: Use structure to capture key restriction function and data") Signed-off-by: GUO Zihua <guozihua@huawei.com> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
2022-11-11 18:13:17 +08:00
Revert "Merge tag 'keys-acl-20190703' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs" This reverts merge 0f75ef6a9cff49ff612f7ce0578bced9d0b38325 (and thus effectively commits 7a1ade847596 ("keys: Provide KEYCTL_GRANT_PERMISSION") 2e12256b9a76 ("keys: Replace uid/gid/perm permissions checking with an ACL") that the merge brought in). It turns out that it breaks booting with an encrypted volume, and Eric biggers reports that it also breaks the fscrypt tests [1] and loading of in-kernel X.509 certificates [2]. The root cause of all the breakage is likely the same, but David Howells is off email so rather than try to work it out it's getting reverted in order to not impact the rest of the merge window. [1] https://lore.kernel.org/lkml/20190710011559.GA7973@sol.localdomain/ [2] https://lore.kernel.org/lkml/20190710013225.GB7973@sol.localdomain/ Link: https://lore.kernel.org/lkml/CAHk-=wjxoeMJfeBahnWH=9zShKp2bsVy527vo3_y8HfOdhwAAw@mail.gmail.com/ Reported-by: Eric Biggers <ebiggers@kernel.org> Cc: David Howells <dhowells@redhat.com> Cc: James Morris <jmorris@namei.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-07-10 18:43:43 -07:00
integrity: Define a trusted platform keyring On secure boot enabled systems, a verified kernel may need to kexec additional kernels. For example, it may be used as a bootloader needing to kexec a target kernel or it may need to kexec a crashdump kernel. In such cases, it may want to verify the signature of the next kernel image. It is further possible that the kernel image is signed with third party keys which are stored as platform or firmware keys in the 'db' variable. The kernel, however, can not directly verify these platform keys, and an administrator may therefore not want to trust them for arbitrary usage. In order to differentiate platform keys from other keys and provide the necessary separation of trust, the kernel needs an additional keyring to store platform keys. This patch creates the new keyring called ".platform" to isolate keys provided by platform from keys by kernel. These keys are used to facilitate signature verification during kexec. Since the scope of this keyring is only the platform/firmware keys, it cannot be updated from userspace. This keyring can be enabled by setting CONFIG_INTEGRITY_PLATFORM_KEYRING. Signed-off-by: Nayna Jain <nayna@linux.ibm.com> Reviewed-by: Mimi Zohar <zohar@linux.ibm.com> Acked-by: Serge Hallyn <serge@hallyn.com> Reviewed-by: James Morris <james.morris@microsoft.com> Reviewed-by: Thiago Jung Bauermann <bauerman@linux.ibm.com> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
2018-12-09 01:56:59 +05:30
integrity: Introduce a Linux keyring called machine Many UEFI Linux distributions boot using shim. The UEFI shim provides what is called Machine Owner Keys (MOK). Shim uses both the UEFI Secure Boot DB and MOK keys to validate the next step in the boot chain. The MOK facility can be used to import user generated keys. These keys can be used to sign an end-users development kernel build. When Linux boots, both UEFI Secure Boot DB and MOK keys get loaded in the Linux .platform keyring. Define a new Linux keyring called machine. This keyring shall contain just MOK keys and not the remaining keys in the platform keyring. This new machine keyring will be used in follow on patches. Unlike keys in the platform keyring, keys contained in the machine keyring will be trusted within the kernel if the end-user has chosen to do so. Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com> Tested-by: Jarkko Sakkinen <jarkko@kernel.org> Tested-by: Mimi Zohar <zohar@linux.ibm.com> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2022-01-25 21:58:28 -05:00
integrity: machine keyring CA configuration Add machine keyring CA restriction options to control the type of keys that may be added to it. The motivation is separation of certificate signing from code signing keys. Subsquent work will limit certificates being loaded into the IMA keyring to code signing keys used for signature verification. When no restrictions are selected, all Machine Owner Keys (MOK) are added to the machine keyring. When CONFIG_INTEGRITY_CA_MACHINE_KEYRING is selected, the CA bit must be true. Also the key usage must contain keyCertSign, any other usage field may be set as well. When CONFIG_INTEGRITY_CA_MACHINE_KEYRING_MAX is selected, the CA bit must be true. Also the key usage must contain keyCertSign and the digitialSignature usage may not be set. Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com> Acked-by: Mimi Zohar <zohar@linux.ibm.com> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Tested-by: Mimi Zohar <zohar@linux.ibm.com> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2023-03-02 11:46:52 -05:00
integrity: Define a trusted platform keyring On secure boot enabled systems, a verified kernel may need to kexec additional kernels. For example, it may be used as a bootloader needing to kexec a target kernel or it may need to kexec a crashdump kernel. In such cases, it may want to verify the signature of the next kernel image. It is further possible that the kernel image is signed with third party keys which are stored as platform or firmware keys in the 'db' variable. The kernel, however, can not directly verify these platform keys, and an administrator may therefore not want to trust them for arbitrary usage. In order to differentiate platform keys from other keys and provide the necessary separation of trust, the kernel needs an additional keyring to store platform keys. This patch creates the new keyring called ".platform" to isolate keys provided by platform from keys by kernel. These keys are used to facilitate signature verification during kexec. Since the scope of this keyring is only the platform/firmware keys, it cannot be updated from userspace. This keyring can be enabled by setting CONFIG_INTEGRITY_PLATFORM_KEYRING. Signed-off-by: Nayna Jain <nayna@linux.ibm.com> Reviewed-by: Mimi Zohar <zohar@linux.ibm.com> Acked-by: Serge Hallyn <serge@hallyn.com> Reviewed-by: James Morris <james.morris@microsoft.com> Reviewed-by: Thiago Jung Bauermann <bauerman@linux.ibm.com> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
2018-12-09 01:56:59 +05:30
security/integrity: remove unnecessary 'init_keyring' variable The 'init_keyring' variable actually just gave the value of CONFIG_INTEGRITY_TRUSTED_KEYRING. We should check the config option directly instead. No change in behavior; this just simplifies the code. Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
2018-10-03 17:15:44 -07:00
integrity: define '.evm' as a builtin 'trusted' keyring Require all keys added to the EVM keyring be signed by an existing trusted key on the system trusted keyring. This patch also switches IMA to use integrity_init_keyring(). Changes in v3: * Added 'init_keyring' config based variable to skip initializing keyring instead of using __integrity_init_keyring() wrapper. * Added dependency back to CONFIG_IMA_TRUSTED_KEYRING Changes in v2: * Replace CONFIG_EVM_TRUSTED_KEYRING with IMA and EVM common CONFIG_INTEGRITY_TRUSTED_KEYRING configuration option * Deprecate CONFIG_IMA_TRUSTED_KEYRING but keep it for config file compatibility. (Mimi Zohar) Signed-off-by: Dmitry Kasatkin <dmitry.kasatkin@huawei.com> Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
2015-10-22 21:26:10 +03:00
Convert 'alloc_obj' family to use the new default GFP_KERNEL argument This was done entirely with mindless brute force, using git grep -l '\<k[vmz]*alloc_objs*(.*, GFP_KERNEL)' | xargs sed -i 's/\(alloc_objs*(.*\), GFP_KERNEL)/\1)/' to convert the new alloc_obj() users that had a simple GFP_KERNEL argument to just drop that argument. Note that due to the extreme simplicity of the scripting, any slightly more complex cases spread over multiple lines would not be triggered: they definitely exist, but this covers the vast bulk of the cases, and the resulting diff is also then easier to check automatically. For the same reason the 'flex' versions will be done as a separate conversion. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2026-02-21 16:37:42 -08:00
KEYS: Use structure to capture key restriction function and data Replace struct key's restrict_link function pointer with a pointer to the new struct key_restriction. The structure contains pointers to the restriction function as well as relevant data for evaluating the restriction. The garbage collector checks restrict_link->keytype when key types are unregistered. Restrictions involving a removed key type are converted to use restrict_link_reject so that restrictions cannot be removed by unregistering key types. Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
2016-08-31 16:05:43 -07:00
integrity: machine keyring CA configuration Add machine keyring CA restriction options to control the type of keys that may be added to it. The motivation is separation of certificate signing from code signing keys. Subsquent work will limit certificates being loaded into the IMA keyring to code signing keys used for signature verification. When no restrictions are selected, all Machine Owner Keys (MOK) are added to the machine keyring. When CONFIG_INTEGRITY_CA_MACHINE_KEYRING is selected, the CA bit must be true. Also the key usage must contain keyCertSign, any other usage field may be set as well. When CONFIG_INTEGRITY_CA_MACHINE_KEYRING_MAX is selected, the CA bit must be true. Also the key usage must contain keyCertSign and the digitialSignature usage may not be set. Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com> Acked-by: Mimi Zohar <zohar@linux.ibm.com> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Tested-by: Mimi Zohar <zohar@linux.ibm.com> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2023-03-02 11:46:52 -05:00
integrity: Introduce a Linux keyring called machine Many UEFI Linux distributions boot using shim. The UEFI shim provides what is called Machine Owner Keys (MOK). Shim uses both the UEFI Secure Boot DB and MOK keys to validate the next step in the boot chain. The MOK facility can be used to import user generated keys. These keys can be used to sign an end-users development kernel build. When Linux boots, both UEFI Secure Boot DB and MOK keys get loaded in the Linux .platform keyring. Define a new Linux keyring called machine. This keyring shall contain just MOK keys and not the remaining keys in the platform keyring. This new machine keyring will be used in follow on patches. Unlike keys in the platform keyring, keys contained in the machine keyring will be trusted within the kernel if the end-user has chosen to do so. Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com> Tested-by: Jarkko Sakkinen <jarkko@kernel.org> Tested-by: Mimi Zohar <zohar@linux.ibm.com> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2022-01-25 21:58:28 -05:00
KEYS: Use structure to capture key restriction function and data Replace struct key's restrict_link function pointer with a pointer to the new struct key_restriction. The structure contains pointers to the restriction function as well as relevant data for evaluating the restriction. The garbage collector checks restrict_link->keytype when key types are unregistered. Restrictions involving a removed key type are converted to use restrict_link_reject so that restrictions cannot be removed by unregistering key types. Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
2016-08-31 16:05:43 -07:00
integrity: Define a trusted platform keyring On secure boot enabled systems, a verified kernel may need to kexec additional kernels. For example, it may be used as a bootloader needing to kexec a target kernel or it may need to kexec a crashdump kernel. In such cases, it may want to verify the signature of the next kernel image. It is further possible that the kernel image is signed with third party keys which are stored as platform or firmware keys in the 'db' variable. The kernel, however, can not directly verify these platform keys, and an administrator may therefore not want to trust them for arbitrary usage. In order to differentiate platform keys from other keys and provide the necessary separation of trust, the kernel needs an additional keyring to store platform keys. This patch creates the new keyring called ".platform" to isolate keys provided by platform from keys by kernel. These keys are used to facilitate signature verification during kexec. Since the scope of this keyring is only the platform/firmware keys, it cannot be updated from userspace. This keyring can be enabled by setting CONFIG_INTEGRITY_PLATFORM_KEYRING. Signed-off-by: Nayna Jain <nayna@linux.ibm.com> Reviewed-by: Mimi Zohar <zohar@linux.ibm.com> Acked-by: Serge Hallyn <serge@hallyn.com> Reviewed-by: James Morris <james.morris@microsoft.com> Reviewed-by: Thiago Jung Bauermann <bauerman@linux.ibm.com> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
2018-12-09 01:56:59 +05:30
integrity: Fix memory leakage in keyring allocation error path Key restriction is allocated in integrity_init_keyring(). However, if keyring allocation failed, it is not freed, causing memory leaks. Fixes: 2b6aa412ff23 ("KEYS: Use structure to capture key restriction function and data") Signed-off-by: GUO Zihua <guozihua@huawei.com> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
2022-11-11 18:13:17 +08:00
ima: define '.ima' as a builtin 'trusted' keyring Require all keys added to the IMA keyring be signed by an existing trusted key on the system trusted keyring. Changelog v6: - remove ifdef CONFIG_IMA_TRUSTED_KEYRING in C code - Dmitry - update Kconfig dependency and help - select KEYS_DEBUG_PROC_KEYS - Dmitry Changelog v5: - Move integrity_init_keyring() to init_ima() - Dmitry - reset keyring[id] on failure - Dmitry Changelog v1: - don't link IMA trusted keyring to user keyring Changelog: - define stub integrity_init_keyring() function (reported-by Fengguang Wu) - differentiate between regular and trusted keyring names. - replace printk with pr_info (D. Kasatkin) - only make the IMA keyring a trusted keyring (reported-by D. Kastatkin) - define stub integrity_init_keyring() definition based on CONFIG_INTEGRITY_SIGNATURE, not CONFIG_INTEGRITY_ASYMMETRIC_KEYS. (reported-by Jim Davis) Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com> Signed-off-by: Dmitry Kasatkin <d.kasatkin@samsung.com> Acked-by: David Howells <dhowells@redhat.com>
2013-08-13 08:47:43 -04:00
integrity: provide a function to load x509 certificate from the kernel Provide the function to load x509 certificates from the kernel into the integrity kernel keyring. Changes in v2: * configuration option removed * function declared as '__init' Signed-off-by: Dmitry Kasatkin <d.kasatkin@samsung.com> Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
2014-11-05 17:01:13 +02:00
integrity: Make function integrity_add_key() static The sparse tool complains as follows: security/integrity/digsig.c:146:12: warning: symbol 'integrity_add_key' was not declared. Should it be static? This function is not used outside of digsig.c, so this commit marks it static. Reported-by: Hulk Robot <hulkci@huawei.com> Fixes: 60740accf784 ("integrity: Load certs to the platform keyring") Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com> Reviewed-by: Kees Cook <keescook@chromium.org> Reviewed-by: Nayna Jain <nayna@linux.ibm.com> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
2021-02-10 08:01:31 +00:00
integrity: provide a function to load x509 certificate from the kernel Provide the function to load x509 certificates from the kernel into the integrity kernel keyring. Changes in v2: * configuration option removed * function declared as '__init' Signed-off-by: Dmitry Kasatkin <d.kasatkin@samsung.com> Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
2014-11-05 17:01:13 +02:00
integrity: Load certs to the platform keyring The patch refactors integrity_load_x509(), making it a wrapper for a new function named integrity_add_key(). This patch also defines a new function named integrity_load_cert() for loading the platform keys. Signed-off-by: Nayna Jain <nayna@linux.ibm.com> Reviewed-by: Mimi Zohar <zohar@linux.ibm.com> Acked-by: Serge Hallyn <serge@hallyn.com> Reviewed-by: James Morris <james.morris@microsoft.com> Reviewed-by: Thiago Jung Bauermann <bauerman@linux.ibm.com> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
2018-12-09 01:57:00 +05:30
integrity: provide a function to load x509 certificate from the kernel Provide the function to load x509 certificates from the kernel into the integrity kernel keyring. Changes in v2: * configuration option removed * function declared as '__init' Signed-off-by: Dmitry Kasatkin <d.kasatkin@samsung.com> Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
2014-11-05 17:01:13 +02:00
integrity: Load certs to the platform keyring The patch refactors integrity_load_x509(), making it a wrapper for a new function named integrity_add_key(). This patch also defines a new function named integrity_load_cert() for loading the platform keys. Signed-off-by: Nayna Jain <nayna@linux.ibm.com> Reviewed-by: Mimi Zohar <zohar@linux.ibm.com> Acked-by: Serge Hallyn <serge@hallyn.com> Reviewed-by: James Morris <james.morris@microsoft.com> Reviewed-by: Thiago Jung Bauermann <bauerman@linux.ibm.com> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
2018-12-09 01:57:00 +05:30
Revert "Merge tag 'keys-acl-20190703' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs" This reverts merge 0f75ef6a9cff49ff612f7ce0578bced9d0b38325 (and thus effectively commits 7a1ade847596 ("keys: Provide KEYCTL_GRANT_PERMISSION") 2e12256b9a76 ("keys: Replace uid/gid/perm permissions checking with an ACL") that the merge brought in). It turns out that it breaks booting with an encrypted volume, and Eric biggers reports that it also breaks the fscrypt tests [1] and loading of in-kernel X.509 certificates [2]. The root cause of all the breakage is likely the same, but David Howells is off email so rather than try to work it out it's getting reverted in order to not impact the rest of the merge window. [1] https://lore.kernel.org/lkml/20190710011559.GA7973@sol.localdomain/ [2] https://lore.kernel.org/lkml/20190710013225.GB7973@sol.localdomain/ Link: https://lore.kernel.org/lkml/CAHk-=wjxoeMJfeBahnWH=9zShKp2bsVy527vo3_y8HfOdhwAAw@mail.gmail.com/ Reported-by: Eric Biggers <ebiggers@kernel.org> Cc: David Howells <dhowells@redhat.com> Cc: James Morris <jmorris@namei.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-07-10 18:43:43 -07:00
integrity: Load certs to the platform keyring The patch refactors integrity_load_x509(), making it a wrapper for a new function named integrity_add_key(). This patch also defines a new function named integrity_load_cert() for loading the platform keys. Signed-off-by: Nayna Jain <nayna@linux.ibm.com> Reviewed-by: Mimi Zohar <zohar@linux.ibm.com> Acked-by: Serge Hallyn <serge@hallyn.com> Reviewed-by: James Morris <james.morris@microsoft.com> Reviewed-by: Thiago Jung Bauermann <bauerman@linux.ibm.com> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
2018-12-09 01:57:00 +05:30
integrity: eliminate unnecessary "Problem loading X.509 certificate" msg Currently when the kernel fails to add a cert to the .machine keyring, it will throw an error immediately in the function integrity_add_key. Since the kernel will try adding to the .platform keyring next or throw an error (in the caller of integrity_add_key i.e. add_to_machine_keyring), so there is no need to throw an error immediately in integrity_add_key. Reported-by: itrymybest80@protonmail.com Closes: https://bugzilla.redhat.com/show_bug.cgi?id=2239331 Fixes: d19967764ba8 ("integrity: Introduce a Linux keyring called machine") Reviewed-by: Eric Snowberg <eric.snowberg@oracle.com> Signed-off-by: Coiby Xu <coxu@redhat.com> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
2024-01-09 08:24:28 +08:00
integrity: Load certs to the platform keyring The patch refactors integrity_load_x509(), making it a wrapper for a new function named integrity_add_key(). This patch also defines a new function named integrity_load_cert() for loading the platform keys. Signed-off-by: Nayna Jain <nayna@linux.ibm.com> Reviewed-by: Mimi Zohar <zohar@linux.ibm.com> Acked-by: Serge Hallyn <serge@hallyn.com> Reviewed-by: James Morris <james.morris@microsoft.com> Reviewed-by: Thiago Jung Bauermann <bauerman@linux.ibm.com> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
2018-12-09 01:57:00 +05:30
fs/kernel_read_file: Remove FIRMWARE_PREALLOC_BUFFER enum FIRMWARE_PREALLOC_BUFFER is a "how", not a "what", and confuses the LSMs that are interested in filtering between types of things. The "how" should be an internal detail made uninteresting to the LSMs. Fixes: a098ecd2fa7d ("firmware: support loading into a pre-allocated buffer") Fixes: fd90bc559bfb ("ima: based on policy verify firmware signatures (pre-allocated buffer)") Fixes: 4f0496d8ffa3 ("ima: based on policy warn about loading firmware (pre-allocated buffer)") Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Mimi Zohar <zohar@linux.ibm.com> Reviewed-by: Luis Chamberlain <mcgrof@kernel.org> Acked-by: Scott Branden <scott.branden@broadcom.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20201002173828.2099543-2-keescook@chromium.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-10-02 10:38:13 -07:00
fs/kernel_read_file: Remove redundant size argument In preparation for refactoring kernel_read_file*(), remove the redundant "size" argument which is not needed: it can be included in the return code, with callers adjusted. (VFS reads already cannot be larger than INT_MAX.) Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Mimi Zohar <zohar@linux.ibm.com> Reviewed-by: Luis Chamberlain <mcgrof@kernel.org> Reviewed-by: James Morris <jamorris@linux.microsoft.com> Acked-by: Scott Branden <scott.branden@broadcom.com> Link: https://lore.kernel.org/r/20201002173828.2099543-6-keescook@chromium.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-10-02 10:38:17 -07:00
integrity: Load certs to the platform keyring The patch refactors integrity_load_x509(), making it a wrapper for a new function named integrity_add_key(). This patch also defines a new function named integrity_load_cert() for loading the platform keys. Signed-off-by: Nayna Jain <nayna@linux.ibm.com> Reviewed-by: Mimi Zohar <zohar@linux.ibm.com> Acked-by: Serge Hallyn <serge@hallyn.com> Reviewed-by: James Morris <james.morris@microsoft.com> Reviewed-by: Thiago Jung Bauermann <bauerman@linux.ibm.com> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
2018-12-09 01:57:00 +05:30
Revert "Merge tag 'keys-acl-20190703' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs" This reverts merge 0f75ef6a9cff49ff612f7ce0578bced9d0b38325 (and thus effectively commits 7a1ade847596 ("keys: Provide KEYCTL_GRANT_PERMISSION") 2e12256b9a76 ("keys: Replace uid/gid/perm permissions checking with an ACL") that the merge brought in). It turns out that it breaks booting with an encrypted volume, and Eric biggers reports that it also breaks the fscrypt tests [1] and loading of in-kernel X.509 certificates [2]. The root cause of all the breakage is likely the same, but David Howells is off email so rather than try to work it out it's getting reverted in order to not impact the rest of the merge window. [1] https://lore.kernel.org/lkml/20190710011559.GA7973@sol.localdomain/ [2] https://lore.kernel.org/lkml/20190710013225.GB7973@sol.localdomain/ Link: https://lore.kernel.org/lkml/CAHk-=wjxoeMJfeBahnWH=9zShKp2bsVy527vo3_y8HfOdhwAAw@mail.gmail.com/ Reported-by: Eric Biggers <ebiggers@kernel.org> Cc: David Howells <dhowells@redhat.com> Cc: James Morris <jmorris@namei.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-07-10 18:43:43 -07:00
integrity: Load certs to the platform keyring The patch refactors integrity_load_x509(), making it a wrapper for a new function named integrity_add_key(). This patch also defines a new function named integrity_load_cert() for loading the platform keys. Signed-off-by: Nayna Jain <nayna@linux.ibm.com> Reviewed-by: Mimi Zohar <zohar@linux.ibm.com> Acked-by: Serge Hallyn <serge@hallyn.com> Reviewed-by: James Morris <james.morris@microsoft.com> Reviewed-by: Thiago Jung Bauermann <bauerman@linux.ibm.com> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
2018-12-09 01:57:00 +05:30
fs/kernel_file_read: Add "offset" arg for partial reads To perform partial reads, callers of kernel_read_file*() must have a non-NULL file_size argument and a preallocated buffer. The new "offset" argument can then be used to seek to specific locations in the file to fill the buffer to, at most, "buf_size" per call. Where possible, the LSM hooks can report whether a full file has been read or not so that the contents can be reasoned about. Signed-off-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20201002173828.2099543-14-keescook@chromium.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-10-02 10:38:25 -07:00
integrity: use kernel_read_file_from_path() to read x509 certs The CONFIG_IMA_LOAD_X509 and CONFIG_EVM_LOAD_X509 options permit loading x509 signed certificates onto the trusted keyrings without verifying the x509 certificate file's signature. This patch replaces the call to the integrity_read_file() specific function with the common kernel_read_file_from_path() function. To avoid verifying the file signature, this patch defines READING_X509_CERTFICATE. Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
2017-09-10 09:49:45 +02:00
integrity: provide a function to load x509 certificate from the kernel Provide the function to load x509 certificates from the kernel into the integrity kernel keyring. Changes in v2: * configuration option removed * function declared as '__init' Signed-off-by: Dmitry Kasatkin <d.kasatkin@samsung.com> Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
2014-11-05 17:01:13 +02:00
integrity: use kernel_read_file_from_path() to read x509 certs The CONFIG_IMA_LOAD_X509 and CONFIG_EVM_LOAD_X509 options permit loading x509 signed certificates onto the trusted keyrings without verifying the x509 certificate file's signature. This patch replaces the call to the integrity_read_file() specific function with the common kernel_read_file_from_path() function. To avoid verifying the file signature, this patch defines READING_X509_CERTFICATE. Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
2017-09-10 09:49:45 +02:00
fs/kernel_read_file: Remove redundant size argument In preparation for refactoring kernel_read_file*(), remove the redundant "size" argument which is not needed: it can be included in the return code, with callers adjusted. (VFS reads already cannot be larger than INT_MAX.) Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Mimi Zohar <zohar@linux.ibm.com> Reviewed-by: Luis Chamberlain <mcgrof@kernel.org> Reviewed-by: James Morris <jamorris@linux.microsoft.com> Acked-by: Scott Branden <scott.branden@broadcom.com> Link: https://lore.kernel.org/r/20201002173828.2099543-6-keescook@chromium.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-10-02 10:38:17 -07:00
integrity: provide a function to load x509 certificate from the kernel Provide the function to load x509 certificates from the kernel into the integrity kernel keyring. Changes in v2: * configuration option removed * function declared as '__init' Signed-off-by: Dmitry Kasatkin <d.kasatkin@samsung.com> Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
2014-11-05 17:01:13 +02:00
Revert "Merge tag 'keys-acl-20190703' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs" This reverts merge 0f75ef6a9cff49ff612f7ce0578bced9d0b38325 (and thus effectively commits 7a1ade847596 ("keys: Provide KEYCTL_GRANT_PERMISSION") 2e12256b9a76 ("keys: Replace uid/gid/perm permissions checking with an ACL") that the merge brought in). It turns out that it breaks booting with an encrypted volume, and Eric biggers reports that it also breaks the fscrypt tests [1] and loading of in-kernel X.509 certificates [2]. The root cause of all the breakage is likely the same, but David Howells is off email so rather than try to work it out it's getting reverted in order to not impact the rest of the merge window. [1] https://lore.kernel.org/lkml/20190710011559.GA7973@sol.localdomain/ [2] https://lore.kernel.org/lkml/20190710013225.GB7973@sol.localdomain/ Link: https://lore.kernel.org/lkml/CAHk-=wjxoeMJfeBahnWH=9zShKp2bsVy527vo3_y8HfOdhwAAw@mail.gmail.com/ Reported-by: Eric Biggers <ebiggers@kernel.org> Cc: David Howells <dhowells@redhat.com> Cc: James Morris <jmorris@namei.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-07-10 18:43:43 -07:00
integrity: Load certs to the platform keyring The patch refactors integrity_load_x509(), making it a wrapper for a new function named integrity_add_key(). This patch also defines a new function named integrity_load_cert() for loading the platform keys. Signed-off-by: Nayna Jain <nayna@linux.ibm.com> Reviewed-by: Mimi Zohar <zohar@linux.ibm.com> Acked-by: Serge Hallyn <serge@hallyn.com> Reviewed-by: James Morris <james.morris@microsoft.com> Reviewed-by: Thiago Jung Bauermann <bauerman@linux.ibm.com> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
2018-12-09 01:57:00 +05:30
Revert "Merge tag 'keys-acl-20190703' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs" This reverts merge 0f75ef6a9cff49ff612f7ce0578bced9d0b38325 (and thus effectively commits 7a1ade847596 ("keys: Provide KEYCTL_GRANT_PERMISSION") 2e12256b9a76 ("keys: Replace uid/gid/perm permissions checking with an ACL") that the merge brought in). It turns out that it breaks booting with an encrypted volume, and Eric biggers reports that it also breaks the fscrypt tests [1] and loading of in-kernel X.509 certificates [2]. The root cause of all the breakage is likely the same, but David Howells is off email so rather than try to work it out it's getting reverted in order to not impact the rest of the merge window. [1] https://lore.kernel.org/lkml/20190710011559.GA7973@sol.localdomain/ [2] https://lore.kernel.org/lkml/20190710013225.GB7973@sol.localdomain/ Link: https://lore.kernel.org/lkml/CAHk-=wjxoeMJfeBahnWH=9zShKp2bsVy527vo3_y8HfOdhwAAw@mail.gmail.com/ Reported-by: Eric Biggers <ebiggers@kernel.org> Cc: David Howells <dhowells@redhat.com> Cc: James Morris <jmorris@namei.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-07-10 18:43:43 -07:00
integrity: Load certs to the platform keyring The patch refactors integrity_load_x509(), making it a wrapper for a new function named integrity_add_key(). This patch also defines a new function named integrity_load_cert() for loading the platform keys. Signed-off-by: Nayna Jain <nayna@linux.ibm.com> Reviewed-by: Mimi Zohar <zohar@linux.ibm.com> Acked-by: Serge Hallyn <serge@hallyn.com> Reviewed-by: James Morris <james.morris@microsoft.com> Reviewed-by: Thiago Jung Bauermann <bauerman@linux.ibm.com> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
2018-12-09 01:57:00 +05:30
integrity: use kernel_read_file_from_path() to read x509 certs The CONFIG_IMA_LOAD_X509 and CONFIG_EVM_LOAD_X509 options permit loading x509 signed certificates onto the trusted keyrings without verifying the x509 certificate file's signature. This patch replaces the call to the integrity_read_file() specific function with the common kernel_read_file_from_path() function. To avoid verifying the file signature, this patch defines READING_X509_CERTFICATE. Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
2017-09-10 09:49:45 +02:00
integrity: Load certs to the platform keyring The patch refactors integrity_load_x509(), making it a wrapper for a new function named integrity_add_key(). This patch also defines a new function named integrity_load_cert() for loading the platform keys. Signed-off-by: Nayna Jain <nayna@linux.ibm.com> Reviewed-by: Mimi Zohar <zohar@linux.ibm.com> Acked-by: Serge Hallyn <serge@hallyn.com> Reviewed-by: James Morris <james.morris@microsoft.com> Reviewed-by: Thiago Jung Bauermann <bauerman@linux.ibm.com> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
2018-12-09 01:57:00 +05:30
Revert "Merge tag 'keys-acl-20190703' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs" This reverts merge 0f75ef6a9cff49ff612f7ce0578bced9d0b38325 (and thus effectively commits 7a1ade847596 ("keys: Provide KEYCTL_GRANT_PERMISSION") 2e12256b9a76 ("keys: Replace uid/gid/perm permissions checking with an ACL") that the merge brought in). It turns out that it breaks booting with an encrypted volume, and Eric biggers reports that it also breaks the fscrypt tests [1] and loading of in-kernel X.509 certificates [2]. The root cause of all the breakage is likely the same, but David Howells is off email so rather than try to work it out it's getting reverted in order to not impact the rest of the merge window. [1] https://lore.kernel.org/lkml/20190710011559.GA7973@sol.localdomain/ [2] https://lore.kernel.org/lkml/20190710013225.GB7973@sol.localdomain/ Link: https://lore.kernel.org/lkml/CAHk-=wjxoeMJfeBahnWH=9zShKp2bsVy527vo3_y8HfOdhwAAw@mail.gmail.com/ Reported-by: Eric Biggers <ebiggers@kernel.org> Cc: David Howells <dhowells@redhat.com> Cc: James Morris <jmorris@namei.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-07-10 18:43:43 -07:00
integrity: Load certs to the platform keyring The patch refactors integrity_load_x509(), making it a wrapper for a new function named integrity_add_key(). This patch also defines a new function named integrity_load_cert() for loading the platform keys. Signed-off-by: Nayna Jain <nayna@linux.ibm.com> Reviewed-by: Mimi Zohar <zohar@linux.ibm.com> Acked-by: Serge Hallyn <serge@hallyn.com> Reviewed-by: James Morris <james.morris@microsoft.com> Reviewed-by: Thiago Jung Bauermann <bauerman@linux.ibm.com> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
2018-12-09 01:57:00 +05:30
Revert "Merge tag 'keys-acl-20190703' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs" This reverts merge 0f75ef6a9cff49ff612f7ce0578bced9d0b38325 (and thus effectively commits 7a1ade847596 ("keys: Provide KEYCTL_GRANT_PERMISSION") 2e12256b9a76 ("keys: Replace uid/gid/perm permissions checking with an ACL") that the merge brought in). It turns out that it breaks booting with an encrypted volume, and Eric biggers reports that it also breaks the fscrypt tests [1] and loading of in-kernel X.509 certificates [2]. The root cause of all the breakage is likely the same, but David Howells is off email so rather than try to work it out it's getting reverted in order to not impact the rest of the merge window. [1] https://lore.kernel.org/lkml/20190710011559.GA7973@sol.localdomain/ [2] https://lore.kernel.org/lkml/20190710013225.GB7973@sol.localdomain/ Link: https://lore.kernel.org/lkml/CAHk-=wjxoeMJfeBahnWH=9zShKp2bsVy527vo3_y8HfOdhwAAw@mail.gmail.com/ Reported-by: Eric Biggers <ebiggers@kernel.org> Cc: David Howells <dhowells@redhat.com> Cc: James Morris <jmorris@namei.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-07-10 18:43:43 -07:00
integrity: provide a function to load x509 certificate from the kernel Provide the function to load x509 certificates from the kernel into the integrity kernel keyring. Changes in v2: * configuration option removed * function declared as '__init' Signed-off-by: Dmitry Kasatkin <d.kasatkin@samsung.com> Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
2014-11-05 17:01:13 +02:00