2019-05-20 13:08:01 -04:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-or-later
|
2016-04-06 11:14:26 -04:00
|
|
|
/* Instantiate a public key crypto key from an X.509 Certificate
|
|
|
|
*
|
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 11:14:26 -04:00
|
|
|
* Copyright (C) 2012, 2016 Red Hat, Inc. All Rights Reserved.
|
2016-04-06 11:14:26 -04:00
|
|
|
* Written by David Howells (dhowells@redhat.com)
|
|
|
|
*/
|
|
|
|
|
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 11:14:26 -04:00
|
|
|
#define pr_fmt(fmt) "ASYM: "fmt
|
2016-04-06 11:14:26 -04:00
|
|
|
#include <linux/module.h>
|
|
|
|
#include <linux/kernel.h>
|
|
|
|
#include <linux/err.h>
|
|
|
|
#include <crypto/public_key.h>
|
|
|
|
#include "asymmetric_keys.h"
|
|
|
|
|
|
|
|
static bool use_builtin_keys;
|
|
|
|
static struct asymmetric_key_id *ca_keyid;
|
|
|
|
|
|
|
|
#ifndef MODULE
|
|
|
|
static struct {
|
|
|
|
struct asymmetric_key_id id;
|
|
|
|
unsigned char data[10];
|
|
|
|
} cakey;
|
|
|
|
|
|
|
|
static int __init ca_keys_setup(char *str)
|
|
|
|
{
|
|
|
|
if (!str) /* default system keyring */
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
if (strncmp(str, "id:", 3) == 0) {
|
|
|
|
struct asymmetric_key_id *p = &cakey.id;
|
|
|
|
size_t hexlen = (strlen(str) - 3) / 2;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
if (hexlen == 0 || hexlen > sizeof(cakey.data)) {
|
|
|
|
pr_err("Missing or invalid ca_keys id\n");
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
ret = __asymmetric_key_hex_to_key_id(str + 3, p, hexlen);
|
|
|
|
if (ret < 0)
|
|
|
|
pr_err("Unparsable ca_keys id hex string\n");
|
|
|
|
else
|
|
|
|
ca_keyid = p; /* owner key 'id:xxxxxx' */
|
|
|
|
} else if (strcmp(str, "builtin") == 0) {
|
|
|
|
use_builtin_keys = true;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
__setup("ca_keys=", ca_keys_setup);
|
|
|
|
#endif
|
|
|
|
|
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 11:14:26 -04:00
|
|
|
/**
|
|
|
|
* restrict_link_by_signature - Restrict additions to a ring of public keys
|
2016-08-30 14:33:13 -04:00
|
|
|
* @dest_keyring: Keyring being linked to.
|
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 11:14:26 -04:00
|
|
|
* @type: The type of key being added.
|
|
|
|
* @payload: The payload of the new key.
|
2016-08-30 14:33:13 -04:00
|
|
|
* @trust_keyring: A ring of keys that can be used to vouch for the new cert.
|
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 11:14:26 -04:00
|
|
|
*
|
2016-04-06 11:14:26 -04:00
|
|
|
* Check the new certificate against the ones in the trust keyring. If one of
|
|
|
|
* those is the signing key and validates the new certificate, then mark the
|
|
|
|
* new certificate as being trusted.
|
|
|
|
*
|
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 11:14:26 -04:00
|
|
|
* Returns 0 if the new certificate was accepted, -ENOKEY if we couldn't find a
|
|
|
|
* matching parent certificate in the trusted list, -EKEYREJECTED if the
|
2018-02-22 09:38:34 -05:00
|
|
|
* signature check fails or the key is blacklisted, -ENOPKG if the signature
|
|
|
|
* uses unsupported crypto, or some other error if there is a matching
|
|
|
|
* certificate but the signature check cannot be performed.
|
2016-04-06 11:14:26 -04:00
|
|
|
*/
|
2016-08-30 14:33:13 -04:00
|
|
|
int restrict_link_by_signature(struct key *dest_keyring,
|
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 11:14:26 -04:00
|
|
|
const struct key_type *type,
|
2016-08-30 14:33:13 -04:00
|
|
|
const union key_payload *payload,
|
|
|
|
struct key *trust_keyring)
|
2016-04-06 11:14:26 -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 11:14:26 -04:00
|
|
|
const struct public_key_signature *sig;
|
2016-04-06 11:14:26 -04:00
|
|
|
struct key *key;
|
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 11:14:26 -04:00
|
|
|
int ret;
|
2016-04-06 11:14:26 -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 11:14:26 -04:00
|
|
|
pr_devel("==>%s()\n", __func__);
|
2016-04-06 11:14:26 -04:00
|
|
|
|
|
|
|
if (!trust_keyring)
|
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 11:14:26 -04:00
|
|
|
return -ENOKEY;
|
|
|
|
|
|
|
|
if (type != &key_type_asymmetric)
|
2016-04-06 11:14:26 -04:00
|
|
|
return -EOPNOTSUPP;
|
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 11:14:26 -04:00
|
|
|
|
|
|
|
sig = payload->data[asym_auth];
|
2018-02-22 09:38:34 -05:00
|
|
|
if (!sig)
|
|
|
|
return -ENOPKG;
|
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 11:14:26 -04:00
|
|
|
if (!sig->auth_ids[0] && !sig->auth_ids[1])
|
2016-07-17 19:10:55 -04:00
|
|
|
return -ENOKEY;
|
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 11:14:26 -04:00
|
|
|
|
2016-04-06 11:14:26 -04:00
|
|
|
if (ca_keyid && !asymmetric_key_id_partial(sig->auth_ids[1], ca_keyid))
|
|
|
|
return -EPERM;
|
|
|
|
|
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 11:14:26 -04:00
|
|
|
/* See if we have a key that signed this one. */
|
2016-04-06 11:14:26 -04:00
|
|
|
key = find_asymmetric_key(trust_keyring,
|
|
|
|
sig->auth_ids[0], sig->auth_ids[1],
|
|
|
|
false);
|
|
|
|
if (IS_ERR(key))
|
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 11:14:26 -04:00
|
|
|
return -ENOKEY;
|
2016-04-06 11:14:26 -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 11:14:26 -04:00
|
|
|
if (use_builtin_keys && !test_bit(KEY_FLAG_BUILTIN, &key->flags))
|
|
|
|
ret = -ENOKEY;
|
|
|
|
else
|
|
|
|
ret = verify_signature(key, sig);
|
2016-04-06 11:14:26 -04:00
|
|
|
key_put(key);
|
|
|
|
return ret;
|
|
|
|
}
|
2016-06-27 19:45:16 -04:00
|
|
|
|
2016-10-04 19:42:45 -04:00
|
|
|
static bool match_either_id(const struct asymmetric_key_ids *pair,
|
|
|
|
const struct asymmetric_key_id *single)
|
|
|
|
{
|
|
|
|
return (asymmetric_key_id_same(pair->id[0], single) ||
|
|
|
|
asymmetric_key_id_same(pair->id[1], single));
|
|
|
|
}
|
|
|
|
|
|
|
|
static int key_or_keyring_common(struct key *dest_keyring,
|
|
|
|
const struct key_type *type,
|
|
|
|
const union key_payload *payload,
|
|
|
|
struct key *trusted, bool check_dest)
|
2016-06-27 19:45:16 -04:00
|
|
|
{
|
|
|
|
const struct public_key_signature *sig;
|
2016-10-04 19:42:45 -04:00
|
|
|
struct key *key = NULL;
|
2016-06-27 19:45:16 -04:00
|
|
|
int ret;
|
|
|
|
|
|
|
|
pr_devel("==>%s()\n", __func__);
|
|
|
|
|
|
|
|
if (!dest_keyring)
|
|
|
|
return -ENOKEY;
|
|
|
|
else if (dest_keyring->type != &key_type_keyring)
|
|
|
|
return -EOPNOTSUPP;
|
|
|
|
|
2016-10-04 19:42:45 -04:00
|
|
|
if (!trusted && !check_dest)
|
2016-06-27 19:45:16 -04:00
|
|
|
return -ENOKEY;
|
|
|
|
|
|
|
|
if (type != &key_type_asymmetric)
|
|
|
|
return -EOPNOTSUPP;
|
|
|
|
|
|
|
|
sig = payload->data[asym_auth];
|
2018-02-22 09:38:34 -05:00
|
|
|
if (!sig)
|
|
|
|
return -ENOPKG;
|
2016-06-27 19:45:16 -04:00
|
|
|
if (!sig->auth_ids[0] && !sig->auth_ids[1])
|
|
|
|
return -ENOKEY;
|
|
|
|
|
2016-10-04 19:42:45 -04:00
|
|
|
if (trusted) {
|
|
|
|
if (trusted->type == &key_type_keyring) {
|
|
|
|
/* See if we have a key that signed this one. */
|
|
|
|
key = find_asymmetric_key(trusted, sig->auth_ids[0],
|
|
|
|
sig->auth_ids[1], false);
|
|
|
|
if (IS_ERR(key))
|
|
|
|
key = NULL;
|
|
|
|
} else if (trusted->type == &key_type_asymmetric) {
|
|
|
|
const struct asymmetric_key_ids *signer_ids;
|
2016-06-27 19:45:16 -04:00
|
|
|
|
2016-10-04 19:42:45 -04:00
|
|
|
signer_ids = asymmetric_key_ids(trusted);
|
2016-06-27 19:45:16 -04:00
|
|
|
|
2016-10-04 19:42:45 -04:00
|
|
|
/*
|
|
|
|
* The auth_ids come from the candidate key (the
|
|
|
|
* one that is being considered for addition to
|
|
|
|
* dest_keyring) and identify the key that was
|
|
|
|
* used to sign.
|
|
|
|
*
|
|
|
|
* The signer_ids are identifiers for the
|
|
|
|
* signing key specified for dest_keyring.
|
|
|
|
*
|
|
|
|
* The first auth_id is the preferred id, and
|
|
|
|
* the second is the fallback. If only one
|
|
|
|
* auth_id is present, it may match against
|
|
|
|
* either signer_id. If two auth_ids are
|
|
|
|
* present, the first auth_id must match one
|
|
|
|
* signer_id and the second auth_id must match
|
|
|
|
* the second signer_id.
|
|
|
|
*/
|
|
|
|
if (!sig->auth_ids[0] || !sig->auth_ids[1]) {
|
|
|
|
const struct asymmetric_key_id *auth_id;
|
2016-06-27 19:45:16 -04:00
|
|
|
|
2016-10-04 19:42:45 -04:00
|
|
|
auth_id = sig->auth_ids[0] ?: sig->auth_ids[1];
|
|
|
|
if (match_either_id(signer_ids, auth_id))
|
|
|
|
key = __key_get(trusted);
|
|
|
|
|
|
|
|
} else if (asymmetric_key_id_same(signer_ids->id[1],
|
|
|
|
sig->auth_ids[1]) &&
|
|
|
|
match_either_id(signer_ids,
|
|
|
|
sig->auth_ids[0])) {
|
|
|
|
key = __key_get(trusted);
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
return -EOPNOTSUPP;
|
|
|
|
}
|
2016-06-27 19:45:16 -04:00
|
|
|
}
|
|
|
|
|
2016-10-04 19:42:45 -04:00
|
|
|
if (check_dest && !key) {
|
|
|
|
/* See if the destination has a key that signed this one. */
|
|
|
|
key = find_asymmetric_key(dest_keyring, sig->auth_ids[0],
|
|
|
|
sig->auth_ids[1], false);
|
|
|
|
if (IS_ERR(key))
|
|
|
|
key = NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!key)
|
|
|
|
return -ENOKEY;
|
|
|
|
|
2016-06-27 19:45:16 -04:00
|
|
|
ret = key_validate(key);
|
|
|
|
if (ret == 0)
|
|
|
|
ret = verify_signature(key, sig);
|
|
|
|
|
|
|
|
key_put(key);
|
|
|
|
return ret;
|
|
|
|
}
|
2016-10-04 19:42:45 -04:00
|
|
|
|
|
|
|
/**
|
|
|
|
* restrict_link_by_key_or_keyring - Restrict additions to a ring of public
|
|
|
|
* keys using the restrict_key information stored in the ring.
|
|
|
|
* @dest_keyring: Keyring being linked to.
|
|
|
|
* @type: The type of key being added.
|
|
|
|
* @payload: The payload of the new key.
|
|
|
|
* @trusted: A key or ring of keys that can be used to vouch for the new cert.
|
|
|
|
*
|
|
|
|
* Check the new certificate only against the key or keys passed in the data
|
|
|
|
* parameter. If one of those is the signing key and validates the new
|
|
|
|
* certificate, then mark the new certificate as being ok to link.
|
|
|
|
*
|
|
|
|
* Returns 0 if the new certificate was accepted, -ENOKEY if we
|
|
|
|
* couldn't find a matching parent certificate in the trusted list,
|
2018-02-22 09:38:34 -05:00
|
|
|
* -EKEYREJECTED if the signature check fails, -ENOPKG if the signature uses
|
|
|
|
* unsupported crypto, or some other error if there is a matching certificate
|
|
|
|
* but the signature check cannot be performed.
|
2016-10-04 19:42:45 -04:00
|
|
|
*/
|
|
|
|
int restrict_link_by_key_or_keyring(struct key *dest_keyring,
|
|
|
|
const struct key_type *type,
|
|
|
|
const union key_payload *payload,
|
|
|
|
struct key *trusted)
|
|
|
|
{
|
|
|
|
return key_or_keyring_common(dest_keyring, type, payload, trusted,
|
|
|
|
false);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* restrict_link_by_key_or_keyring_chain - Restrict additions to a ring of
|
|
|
|
* public keys using the restrict_key information stored in the ring.
|
|
|
|
* @dest_keyring: Keyring being linked to.
|
|
|
|
* @type: The type of key being added.
|
|
|
|
* @payload: The payload of the new key.
|
|
|
|
* @trusted: A key or ring of keys that can be used to vouch for the new cert.
|
|
|
|
*
|
|
|
|
* Check the new certificate only against the key or keys passed in the data
|
|
|
|
* parameter. If one of those is the signing key and validates the new
|
|
|
|
* certificate, then mark the new certificate as being ok to link.
|
|
|
|
*
|
|
|
|
* Returns 0 if the new certificate was accepted, -ENOKEY if we
|
|
|
|
* couldn't find a matching parent certificate in the trusted list,
|
2018-02-22 09:38:34 -05:00
|
|
|
* -EKEYREJECTED if the signature check fails, -ENOPKG if the signature uses
|
|
|
|
* unsupported crypto, or some other error if there is a matching certificate
|
|
|
|
* but the signature check cannot be performed.
|
2016-10-04 19:42:45 -04:00
|
|
|
*/
|
|
|
|
int restrict_link_by_key_or_keyring_chain(struct key *dest_keyring,
|
|
|
|
const struct key_type *type,
|
|
|
|
const union key_payload *payload,
|
|
|
|
struct key *trusted)
|
|
|
|
{
|
|
|
|
return key_or_keyring_common(dest_keyring, type, payload, trusted,
|
|
|
|
true);
|
|
|
|
}
|