kernel/linux.git/security/integrity/digsig.c, branch v5.0.15

integrity: Remove references to module keyring

2018-12-17T22:09:39+00:00

From what I can tell, it has never been used. Mimi: This was introduced prior to Rusty's decision to use appended signatures for kernel modules. Signed-off-by: Thiago Jung Bauermann Acked-by: Mimi Zohar Signed-off-by: James Morris

integrity: Load certs to the platform keyring

2018-12-13T03:02:54+00:00

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 Reviewed-by: Mimi Zohar Acked-by: Serge Hallyn Reviewed-by: James Morris Reviewed-by: Thiago Jung Bauermann Signed-off-by: Mimi Zohar

integrity: Define a trusted platform keyring

2018-12-13T03:02:28+00:00

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 Reviewed-by: Mimi Zohar Acked-by: Serge Hallyn Reviewed-by: James Morris Reviewed-by: Thiago Jung Bauermann Signed-off-by: Mimi Zohar

security/integrity: remove unnecessary 'init_keyring' variable

2018-10-10T16:56:15+00:00

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 Signed-off-by: Mimi Zohar

security/integrity: constify some read-only data

2018-10-10T16:56:15+00:00

Constify some static data that is never modified, so that it is placed in .rodata. Signed-off-by: Eric Biggers Signed-off-by: Mimi Zohar

integrity/security: fix digsig.c build error with header file

2018-02-23T04:09:08+00:00

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 Signed-off-by: Randy Dunlap Cc: Mimi Zohar Cc: linux-integrity@vger.kernel.org Link: http://kisskb.ellerman.id.au/kisskb/head/13396/ Signed-off-by: James Morris

integrity: use kernel_read_file_from_path() to read x509 certs

2017-11-08T20:16:36+00:00

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 Signed-off-by: Mimi Zohar

KEYS: Use structure to capture key restriction function and data

2017-04-04T21:10:10+00:00

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

security/integrity: Harden against malformed xattrs

2016-11-14T03:50:11+00:00

In general the handling of IMA/EVM xattrs is good, but I found a few locations where either the xattr size or the value of the type field in the xattr are not checked. Add a few simple checks to these locations to prevent malformed or malicious xattrs from causing problems. Signed-off-by: Seth Forshee Signed-off-by: Mimi Zohar

IMA: Use the the system trusted keyrings instead of .ima_mok

2016-04-11T21:49:15+00:00

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 Signed-off-by: Mimi Zohar