kernel-fxtec-pro1x/security/integrity/digsig.c

130 lines
2.8 KiB
C
Raw Normal View History

/*
* Copyright (C) 2011 Intel Corporation
*
* Author:
* Dmitry Kasatkin <dmitry.kasatkin@intel.com>
*
* 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.
*
*/
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
#include <linux/err.h>
#include <linux/sched.h>
#include <linux/slab.h>
#include <linux/cred.h>
#include <linux/key-type.h>
#include <linux/digsig.h>
#include "integrity.h"
static struct key *keyring[INTEGRITY_KEYRING_MAX];
static const char *keyring_name[INTEGRITY_KEYRING_MAX] = {
#ifndef CONFIG_INTEGRITY_TRUSTED_KEYRING
"_evm",
"_ima",
#else
".evm",
".ima",
#endif
"_module",
};
#ifdef CONFIG_INTEGRITY_TRUSTED_KEYRING
static bool init_keyring __initdata = true;
#else
static bool init_keyring __initdata;
#endif
int integrity_digsig_verify(const unsigned int id, const char *sig, int siglen,
const char *digest, int digestlen)
{
if (id >= INTEGRITY_KEYRING_MAX)
return -EINVAL;
if (!keyring[id]) {
keyring[id] =
request_key(&key_type_keyring, keyring_name[id], NULL);
if (IS_ERR(keyring[id])) {
int err = PTR_ERR(keyring[id]);
pr_err("no %s keyring: %d\n", keyring_name[id], err);
keyring[id] = NULL;
return err;
}
}
switch (sig[1]) {
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-06 15:12:08 -07:00
case 1:
/* v1 API expect signature without xattr type */
return digsig_verify(keyring[id], sig + 1, siglen - 1,
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-06 15:12:08 -07:00
digest, digestlen);
case 2:
return asymmetric_verify(keyring[id], sig, siglen,
digest, digestlen);
}
return -EOPNOTSUPP;
}
int __init integrity_init_keyring(const unsigned int id)
{
const struct cred *cred = current_cred();
int err = 0;
if (!init_keyring)
return 0;
keyring[id] = keyring_alloc(keyring_name[id], KUIDT_INIT(0),
KGIDT_INIT(0), cred,
((KEY_POS_ALL & ~KEY_POS_SETATTR) |
KEY_USR_VIEW | KEY_USR_READ |
KEY_USR_WRITE | KEY_USR_SEARCH),
KEYS: Add a facility to restrict new links into a keyring Add a facility whereby proposed new links to be added to a keyring can be vetted, permitting them to be rejected if necessary. This can be used to block public keys from which the signature cannot be verified or for which the signature verification fails. It could also be used to provide blacklisting. This affects operations like add_key(), KEYCTL_LINK and KEYCTL_INSTANTIATE. To this end: (1) A function pointer is added to the key struct that, if set, points to the vetting function. This is called as: int (*restrict_link)(struct key *keyring, const struct key_type *key_type, unsigned long key_flags, const union key_payload *key_payload), where 'keyring' will be the keyring being added to, key_type and key_payload will describe the key being added and key_flags[*] can be AND'ed with KEY_FLAG_TRUSTED. [*] This parameter will be removed in a later patch when KEY_FLAG_TRUSTED is removed. The function should return 0 to allow the link to take place or an error (typically -ENOKEY, -ENOPKG or -EKEYREJECTED) to reject the link. The pointer should not be set directly, but rather should be set through keyring_alloc(). Note that if called during add_key(), preparse is called before this method, but a key isn't actually allocated until after this function is called. (2) KEY_ALLOC_BYPASS_RESTRICTION is added. This can be passed to key_create_or_update() or key_instantiate_and_link() to bypass the restriction check. (3) KEY_FLAG_TRUSTED_ONLY is removed. The entire contents of a keyring with this restriction emplaced can be considered 'trustworthy' by virtue of being in the keyring when that keyring is consulted. (4) key_alloc() and keyring_alloc() take an extra argument that will be used to set restrict_link in the new key. This ensures that the pointer is set before the key is published, thus preventing a window of unrestrictedness. Normally this argument will be NULL. (5) As a temporary affair, keyring_restrict_trusted_only() is added. It should be passed to keyring_alloc() as the extra argument instead of setting KEY_FLAG_TRUSTED_ONLY on a keyring. This will be replaced in a later patch with functions that look in the appropriate places for authoritative keys. Signed-off-by: David Howells <dhowells@redhat.com> Reviewed-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
2016-04-06 09:14:24 -06:00
KEY_ALLOC_NOT_IN_QUOTA,
NULL, NULL);
if (IS_ERR(keyring[id])) {
err = PTR_ERR(keyring[id]);
pr_info("Can't allocate %s keyring (%d)\n",
keyring_name[id], err);
keyring[id] = NULL;
}
return err;
}
int __init integrity_load_x509(const unsigned int id, const char *path)
{
key_ref_t key;
char *data;
int rc;
if (!keyring[id])
return -EINVAL;
rc = integrity_read_file(path, &data);
if (rc < 0)
return rc;
key = key_create_or_update(make_key_ref(keyring[id], 1),
"asymmetric",
NULL,
data,
rc,
((KEY_POS_ALL & ~KEY_POS_SETATTR) |
KEY_USR_VIEW | KEY_USR_READ),
KEY_ALLOC_NOT_IN_QUOTA);
if (IS_ERR(key)) {
rc = PTR_ERR(key);
pr_err("Problem loading X.509 certificate (%d): %s\n",
rc, path);
} else {
pr_notice("Loaded X.509 cert '%s': %s\n",
key_ref_to_ptr(key)->description, path);
key_ref_put(key);
}
kfree(data);
return 0;
}