2019-05-21 01:08:01 +08:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-or-later
|
2013-08-30 23:07:30 +08:00
|
|
|
/* System trusted keyring for trusted public keys
|
|
|
|
*
|
|
|
|
* Copyright (C) 2012 Red Hat, Inc. All Rights Reserved.
|
|
|
|
* Written by David Howells (dhowells@redhat.com)
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/export.h>
|
|
|
|
#include <linux/kernel.h>
|
|
|
|
#include <linux/sched.h>
|
|
|
|
#include <linux/cred.h>
|
|
|
|
#include <linux/err.h>
|
2016-09-01 07:05:43 +08:00
|
|
|
#include <linux/slab.h>
|
2018-08-16 21:05:10 +08:00
|
|
|
#include <linux/verification.h>
|
2013-08-30 23:07:30 +08:00
|
|
|
#include <keys/asymmetric-type.h>
|
|
|
|
#include <keys/system_keyring.h>
|
2015-07-21 04:16:28 +08:00
|
|
|
#include <crypto/pkcs7.h>
|
2013-08-30 23:07:30 +08:00
|
|
|
|
2016-04-06 23:14:27 +08:00
|
|
|
static struct key *builtin_trusted_keys;
|
|
|
|
#ifdef CONFIG_SECONDARY_TRUSTED_KEYRING
|
|
|
|
static struct key *secondary_trusted_keys;
|
|
|
|
#endif
|
2019-01-21 17:59:28 +08:00
|
|
|
#ifdef CONFIG_INTEGRITY_PLATFORM_KEYRING
|
|
|
|
static struct key *platform_trusted_keys;
|
|
|
|
#endif
|
2013-08-30 23:07:30 +08:00
|
|
|
|
|
|
|
extern __initconst const u8 system_certificate_list[];
|
2013-12-05 21:48:22 +08:00
|
|
|
extern __initconst const unsigned long system_certificate_list_size;
|
2013-08-30 23:07:30 +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 23:14:26 +08:00
|
|
|
/**
|
2016-04-06 23:14:27 +08:00
|
|
|
* restrict_link_to_builtin_trusted - Restrict keyring addition by built in CA
|
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 23:14:26 +08:00
|
|
|
*
|
|
|
|
* Restrict the addition of keys into a keyring based on the key-to-be-added
|
2016-04-06 23:14:27 +08:00
|
|
|
* being vouched for by a key in the built in system 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 23:14:26 +08:00
|
|
|
*/
|
2016-08-31 02:33:13 +08:00
|
|
|
int restrict_link_by_builtin_trusted(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 23:14:26 +08:00
|
|
|
const struct key_type *type,
|
2016-08-31 02:33:13 +08:00
|
|
|
const union key_payload *payload,
|
|
|
|
struct key *restriction_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 23:14:26 +08:00
|
|
|
{
|
2016-08-31 02:33:13 +08:00
|
|
|
return restrict_link_by_signature(dest_keyring, type, payload,
|
|
|
|
builtin_trusted_keys);
|
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 23:14:26 +08:00
|
|
|
}
|
|
|
|
|
2016-04-06 23:14:27 +08:00
|
|
|
#ifdef CONFIG_SECONDARY_TRUSTED_KEYRING
|
|
|
|
/**
|
|
|
|
* restrict_link_by_builtin_and_secondary_trusted - Restrict keyring
|
|
|
|
* addition by both builtin and secondary keyrings
|
|
|
|
*
|
|
|
|
* Restrict the addition of keys into a keyring based on the key-to-be-added
|
|
|
|
* being vouched for by a key in either the built-in or the secondary system
|
|
|
|
* keyrings.
|
|
|
|
*/
|
|
|
|
int restrict_link_by_builtin_and_secondary_trusted(
|
2016-08-31 02:33:13 +08:00
|
|
|
struct key *dest_keyring,
|
2016-04-06 23:14:27 +08:00
|
|
|
const struct key_type *type,
|
2016-08-31 02:33:13 +08:00
|
|
|
const union key_payload *payload,
|
|
|
|
struct key *restrict_key)
|
2016-04-06 23:14:27 +08:00
|
|
|
{
|
|
|
|
/* If we have a secondary trusted keyring, then that contains a link
|
|
|
|
* through to the builtin keyring and the search will follow that link.
|
|
|
|
*/
|
|
|
|
if (type == &key_type_keyring &&
|
2016-08-31 02:33:13 +08:00
|
|
|
dest_keyring == secondary_trusted_keys &&
|
2016-04-06 23:14:27 +08:00
|
|
|
payload == &builtin_trusted_keys->payload)
|
|
|
|
/* Allow the builtin keyring to be added to the secondary */
|
|
|
|
return 0;
|
|
|
|
|
2016-08-31 02:33:13 +08:00
|
|
|
return restrict_link_by_signature(dest_keyring, type, payload,
|
|
|
|
secondary_trusted_keys);
|
2016-04-06 23:14:27 +08:00
|
|
|
}
|
2016-09-01 07:05:43 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Allocate a struct key_restriction for the "builtin and secondary trust"
|
|
|
|
* keyring. Only for use in system_trusted_keyring_init().
|
|
|
|
*/
|
|
|
|
static __init struct key_restriction *get_builtin_and_secondary_restriction(void)
|
|
|
|
{
|
|
|
|
struct key_restriction *restriction;
|
|
|
|
|
|
|
|
restriction = kzalloc(sizeof(struct key_restriction), GFP_KERNEL);
|
|
|
|
|
|
|
|
if (!restriction)
|
|
|
|
panic("Can't allocate secondary trusted keyring restriction\n");
|
|
|
|
|
|
|
|
restriction->check = restrict_link_by_builtin_and_secondary_trusted;
|
|
|
|
|
|
|
|
return restriction;
|
|
|
|
}
|
2016-04-06 23:14:27 +08:00
|
|
|
#endif
|
|
|
|
|
2013-08-30 23:07:30 +08:00
|
|
|
/*
|
2016-04-06 23:14:27 +08:00
|
|
|
* Create the trusted keyrings
|
2013-08-30 23:07:30 +08:00
|
|
|
*/
|
|
|
|
static __init int system_trusted_keyring_init(void)
|
|
|
|
{
|
2016-04-06 23:14:27 +08:00
|
|
|
pr_notice("Initialise system trusted keyrings\n");
|
2013-08-30 23:07:30 +08:00
|
|
|
|
2016-04-06 23:14:27 +08:00
|
|
|
builtin_trusted_keys =
|
|
|
|
keyring_alloc(".builtin_trusted_keys",
|
2013-08-30 23:07:30 +08:00
|
|
|
KUIDT_INIT(0), KGIDT_INIT(0), current_cred(),
|
keys: Replace uid/gid/perm permissions checking with an ACL
Replace the uid/gid/perm permissions checking on a key with an ACL to allow
the SETATTR and SEARCH permissions to be split. This will also allow a
greater range of subjects to represented.
============
WHY DO THIS?
============
The problem is that SETATTR and SEARCH cover a slew of actions, not all of
which should be grouped together.
For SETATTR, this includes actions that are about controlling access to a
key:
(1) Changing a key's ownership.
(2) Changing a key's security information.
(3) Setting a keyring's restriction.
And actions that are about managing a key's lifetime:
(4) Setting an expiry time.
(5) Revoking a key.
and (proposed) managing a key as part of a cache:
(6) Invalidating a key.
Managing a key's lifetime doesn't really have anything to do with
controlling access to that key.
Expiry time is awkward since it's more about the lifetime of the content
and so, in some ways goes better with WRITE permission. It can, however,
be set unconditionally by a process with an appropriate authorisation token
for instantiating a key, and can also be set by the key type driver when a
key is instantiated, so lumping it with the access-controlling actions is
probably okay.
As for SEARCH permission, that currently covers:
(1) Finding keys in a keyring tree during a search.
(2) Permitting keyrings to be joined.
(3) Invalidation.
But these don't really belong together either, since these actions really
need to be controlled separately.
Finally, there are number of special cases to do with granting the
administrator special rights to invalidate or clear keys that I would like
to handle with the ACL rather than key flags and special checks.
===============
WHAT IS CHANGED
===============
The SETATTR permission is split to create two new permissions:
(1) SET_SECURITY - which allows the key's owner, group and ACL to be
changed and a restriction to be placed on a keyring.
(2) REVOKE - which allows a key to be revoked.
The SEARCH permission is split to create:
(1) SEARCH - which allows a keyring to be search and a key to be found.
(2) JOIN - which allows a keyring to be joined as a session keyring.
(3) INVAL - which allows a key to be invalidated.
The WRITE permission is also split to create:
(1) WRITE - which allows a key's content to be altered and links to be
added, removed and replaced in a keyring.
(2) CLEAR - which allows a keyring to be cleared completely. This is
split out to make it possible to give just this to an administrator.
(3) REVOKE - see above.
Keys acquire ACLs which consist of a series of ACEs, and all that apply are
unioned together. An ACE specifies a subject, such as:
(*) Possessor - permitted to anyone who 'possesses' a key
(*) Owner - permitted to the key owner
(*) Group - permitted to the key group
(*) Everyone - permitted to everyone
Note that 'Other' has been replaced with 'Everyone' on the assumption that
you wouldn't grant a permit to 'Other' that you wouldn't also grant to
everyone else.
Further subjects may be made available by later patches.
The ACE also specifies a permissions mask. The set of permissions is now:
VIEW Can view the key metadata
READ Can read the key content
WRITE Can update/modify the key content
SEARCH Can find the key by searching/requesting
LINK Can make a link to the key
SET_SECURITY Can change owner, ACL, expiry
INVAL Can invalidate
REVOKE Can revoke
JOIN Can join this keyring
CLEAR Can clear this keyring
The KEYCTL_SETPERM function is then deprecated.
The KEYCTL_SET_TIMEOUT function then is permitted if SET_SECURITY is set,
or if the caller has a valid instantiation auth token.
The KEYCTL_INVALIDATE function then requires INVAL.
The KEYCTL_REVOKE function then requires REVOKE.
The KEYCTL_JOIN_SESSION_KEYRING function then requires JOIN to join an
existing keyring.
The JOIN permission is enabled by default for session keyrings and manually
created keyrings only.
======================
BACKWARD COMPATIBILITY
======================
To maintain backward compatibility, KEYCTL_SETPERM will translate the
permissions mask it is given into a new ACL for a key - unless
KEYCTL_SET_ACL has been called on that key, in which case an error will be
returned.
It will convert possessor, owner, group and other permissions into separate
ACEs, if each portion of the mask is non-zero.
SETATTR permission turns on all of INVAL, REVOKE and SET_SECURITY. WRITE
permission turns on WRITE, REVOKE and, if a keyring, CLEAR. JOIN is turned
on if a keyring is being altered.
The KEYCTL_DESCRIBE function translates the ACL back into a permissions
mask to return depending on possessor, owner, group and everyone ACEs.
It will make the following mappings:
(1) INVAL, JOIN -> SEARCH
(2) SET_SECURITY -> SETATTR
(3) REVOKE -> WRITE if SETATTR isn't already set
(4) CLEAR -> WRITE
Note that the value subsequently returned by KEYCTL_DESCRIBE may not match
the value set with KEYCTL_SETATTR.
=======
TESTING
=======
This passes the keyutils testsuite for all but a couple of tests:
(1) tests/keyctl/dh_compute/badargs: The first wrong-key-type test now
returns EOPNOTSUPP rather than ENOKEY as READ permission isn't removed
if the type doesn't have ->read(). You still can't actually read the
key.
(2) tests/keyctl/permitting/valid: The view-other-permissions test doesn't
work as Other has been replaced with Everyone in the ACL.
Signed-off-by: David Howells <dhowells@redhat.com>
2019-06-28 06:03:07 +08:00
|
|
|
&internal_key_acl, KEY_ALLOC_NOT_IN_QUOTA,
|
2016-04-06 23:14:27 +08:00
|
|
|
NULL, NULL);
|
|
|
|
if (IS_ERR(builtin_trusted_keys))
|
|
|
|
panic("Can't allocate builtin trusted keyring\n");
|
|
|
|
|
|
|
|
#ifdef CONFIG_SECONDARY_TRUSTED_KEYRING
|
|
|
|
secondary_trusted_keys =
|
|
|
|
keyring_alloc(".secondary_trusted_keys",
|
|
|
|
KUIDT_INIT(0), KGIDT_INIT(0), current_cred(),
|
keys: Replace uid/gid/perm permissions checking with an ACL
Replace the uid/gid/perm permissions checking on a key with an ACL to allow
the SETATTR and SEARCH permissions to be split. This will also allow a
greater range of subjects to represented.
============
WHY DO THIS?
============
The problem is that SETATTR and SEARCH cover a slew of actions, not all of
which should be grouped together.
For SETATTR, this includes actions that are about controlling access to a
key:
(1) Changing a key's ownership.
(2) Changing a key's security information.
(3) Setting a keyring's restriction.
And actions that are about managing a key's lifetime:
(4) Setting an expiry time.
(5) Revoking a key.
and (proposed) managing a key as part of a cache:
(6) Invalidating a key.
Managing a key's lifetime doesn't really have anything to do with
controlling access to that key.
Expiry time is awkward since it's more about the lifetime of the content
and so, in some ways goes better with WRITE permission. It can, however,
be set unconditionally by a process with an appropriate authorisation token
for instantiating a key, and can also be set by the key type driver when a
key is instantiated, so lumping it with the access-controlling actions is
probably okay.
As for SEARCH permission, that currently covers:
(1) Finding keys in a keyring tree during a search.
(2) Permitting keyrings to be joined.
(3) Invalidation.
But these don't really belong together either, since these actions really
need to be controlled separately.
Finally, there are number of special cases to do with granting the
administrator special rights to invalidate or clear keys that I would like
to handle with the ACL rather than key flags and special checks.
===============
WHAT IS CHANGED
===============
The SETATTR permission is split to create two new permissions:
(1) SET_SECURITY - which allows the key's owner, group and ACL to be
changed and a restriction to be placed on a keyring.
(2) REVOKE - which allows a key to be revoked.
The SEARCH permission is split to create:
(1) SEARCH - which allows a keyring to be search and a key to be found.
(2) JOIN - which allows a keyring to be joined as a session keyring.
(3) INVAL - which allows a key to be invalidated.
The WRITE permission is also split to create:
(1) WRITE - which allows a key's content to be altered and links to be
added, removed and replaced in a keyring.
(2) CLEAR - which allows a keyring to be cleared completely. This is
split out to make it possible to give just this to an administrator.
(3) REVOKE - see above.
Keys acquire ACLs which consist of a series of ACEs, and all that apply are
unioned together. An ACE specifies a subject, such as:
(*) Possessor - permitted to anyone who 'possesses' a key
(*) Owner - permitted to the key owner
(*) Group - permitted to the key group
(*) Everyone - permitted to everyone
Note that 'Other' has been replaced with 'Everyone' on the assumption that
you wouldn't grant a permit to 'Other' that you wouldn't also grant to
everyone else.
Further subjects may be made available by later patches.
The ACE also specifies a permissions mask. The set of permissions is now:
VIEW Can view the key metadata
READ Can read the key content
WRITE Can update/modify the key content
SEARCH Can find the key by searching/requesting
LINK Can make a link to the key
SET_SECURITY Can change owner, ACL, expiry
INVAL Can invalidate
REVOKE Can revoke
JOIN Can join this keyring
CLEAR Can clear this keyring
The KEYCTL_SETPERM function is then deprecated.
The KEYCTL_SET_TIMEOUT function then is permitted if SET_SECURITY is set,
or if the caller has a valid instantiation auth token.
The KEYCTL_INVALIDATE function then requires INVAL.
The KEYCTL_REVOKE function then requires REVOKE.
The KEYCTL_JOIN_SESSION_KEYRING function then requires JOIN to join an
existing keyring.
The JOIN permission is enabled by default for session keyrings and manually
created keyrings only.
======================
BACKWARD COMPATIBILITY
======================
To maintain backward compatibility, KEYCTL_SETPERM will translate the
permissions mask it is given into a new ACL for a key - unless
KEYCTL_SET_ACL has been called on that key, in which case an error will be
returned.
It will convert possessor, owner, group and other permissions into separate
ACEs, if each portion of the mask is non-zero.
SETATTR permission turns on all of INVAL, REVOKE and SET_SECURITY. WRITE
permission turns on WRITE, REVOKE and, if a keyring, CLEAR. JOIN is turned
on if a keyring is being altered.
The KEYCTL_DESCRIBE function translates the ACL back into a permissions
mask to return depending on possessor, owner, group and everyone ACEs.
It will make the following mappings:
(1) INVAL, JOIN -> SEARCH
(2) SET_SECURITY -> SETATTR
(3) REVOKE -> WRITE if SETATTR isn't already set
(4) CLEAR -> WRITE
Note that the value subsequently returned by KEYCTL_DESCRIBE may not match
the value set with KEYCTL_SETATTR.
=======
TESTING
=======
This passes the keyutils testsuite for all but a couple of tests:
(1) tests/keyctl/dh_compute/badargs: The first wrong-key-type test now
returns EOPNOTSUPP rather than ENOKEY as READ permission isn't removed
if the type doesn't have ->read(). You still can't actually read the
key.
(2) tests/keyctl/permitting/valid: The view-other-permissions test doesn't
work as Other has been replaced with Everyone in the ACL.
Signed-off-by: David Howells <dhowells@redhat.com>
2019-06-28 06:03:07 +08:00
|
|
|
&internal_writable_keyring_acl, KEY_ALLOC_NOT_IN_QUOTA,
|
2016-09-01 07:05:43 +08:00
|
|
|
get_builtin_and_secondary_restriction(),
|
2016-04-06 23:14:27 +08:00
|
|
|
NULL);
|
|
|
|
if (IS_ERR(secondary_trusted_keys))
|
|
|
|
panic("Can't allocate secondary trusted keyring\n");
|
|
|
|
|
|
|
|
if (key_link(secondary_trusted_keys, builtin_trusted_keys) < 0)
|
|
|
|
panic("Can't link trusted keyrings\n");
|
|
|
|
#endif
|
|
|
|
|
2013-08-30 23:07:30 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Must be initialised before we try and load the keys into the keyring.
|
|
|
|
*/
|
|
|
|
device_initcall(system_trusted_keyring_init);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Load the compiled-in list of X.509 certificates.
|
|
|
|
*/
|
|
|
|
static __init int load_system_certificate_list(void)
|
|
|
|
{
|
|
|
|
key_ref_t key;
|
|
|
|
const u8 *p, *end;
|
|
|
|
size_t plen;
|
|
|
|
|
|
|
|
pr_notice("Loading compiled-in X.509 certificates\n");
|
|
|
|
|
|
|
|
p = system_certificate_list;
|
2013-12-05 21:48:22 +08:00
|
|
|
end = p + system_certificate_list_size;
|
2013-08-30 23:07:30 +08:00
|
|
|
while (p < end) {
|
|
|
|
/* Each cert begins with an ASN.1 SEQUENCE tag and must be more
|
|
|
|
* than 256 bytes in size.
|
|
|
|
*/
|
|
|
|
if (end - p < 4)
|
|
|
|
goto dodgy_cert;
|
|
|
|
if (p[0] != 0x30 &&
|
|
|
|
p[1] != 0x82)
|
|
|
|
goto dodgy_cert;
|
|
|
|
plen = (p[2] << 8) | p[3];
|
|
|
|
plen += 4;
|
|
|
|
if (plen > end - p)
|
|
|
|
goto dodgy_cert;
|
|
|
|
|
2016-04-06 23:14:27 +08:00
|
|
|
key = key_create_or_update(make_key_ref(builtin_trusted_keys, 1),
|
2013-08-30 23:07:30 +08:00
|
|
|
"asymmetric",
|
|
|
|
NULL,
|
|
|
|
p,
|
|
|
|
plen,
|
keys: Replace uid/gid/perm permissions checking with an ACL
Replace the uid/gid/perm permissions checking on a key with an ACL to allow
the SETATTR and SEARCH permissions to be split. This will also allow a
greater range of subjects to represented.
============
WHY DO THIS?
============
The problem is that SETATTR and SEARCH cover a slew of actions, not all of
which should be grouped together.
For SETATTR, this includes actions that are about controlling access to a
key:
(1) Changing a key's ownership.
(2) Changing a key's security information.
(3) Setting a keyring's restriction.
And actions that are about managing a key's lifetime:
(4) Setting an expiry time.
(5) Revoking a key.
and (proposed) managing a key as part of a cache:
(6) Invalidating a key.
Managing a key's lifetime doesn't really have anything to do with
controlling access to that key.
Expiry time is awkward since it's more about the lifetime of the content
and so, in some ways goes better with WRITE permission. It can, however,
be set unconditionally by a process with an appropriate authorisation token
for instantiating a key, and can also be set by the key type driver when a
key is instantiated, so lumping it with the access-controlling actions is
probably okay.
As for SEARCH permission, that currently covers:
(1) Finding keys in a keyring tree during a search.
(2) Permitting keyrings to be joined.
(3) Invalidation.
But these don't really belong together either, since these actions really
need to be controlled separately.
Finally, there are number of special cases to do with granting the
administrator special rights to invalidate or clear keys that I would like
to handle with the ACL rather than key flags and special checks.
===============
WHAT IS CHANGED
===============
The SETATTR permission is split to create two new permissions:
(1) SET_SECURITY - which allows the key's owner, group and ACL to be
changed and a restriction to be placed on a keyring.
(2) REVOKE - which allows a key to be revoked.
The SEARCH permission is split to create:
(1) SEARCH - which allows a keyring to be search and a key to be found.
(2) JOIN - which allows a keyring to be joined as a session keyring.
(3) INVAL - which allows a key to be invalidated.
The WRITE permission is also split to create:
(1) WRITE - which allows a key's content to be altered and links to be
added, removed and replaced in a keyring.
(2) CLEAR - which allows a keyring to be cleared completely. This is
split out to make it possible to give just this to an administrator.
(3) REVOKE - see above.
Keys acquire ACLs which consist of a series of ACEs, and all that apply are
unioned together. An ACE specifies a subject, such as:
(*) Possessor - permitted to anyone who 'possesses' a key
(*) Owner - permitted to the key owner
(*) Group - permitted to the key group
(*) Everyone - permitted to everyone
Note that 'Other' has been replaced with 'Everyone' on the assumption that
you wouldn't grant a permit to 'Other' that you wouldn't also grant to
everyone else.
Further subjects may be made available by later patches.
The ACE also specifies a permissions mask. The set of permissions is now:
VIEW Can view the key metadata
READ Can read the key content
WRITE Can update/modify the key content
SEARCH Can find the key by searching/requesting
LINK Can make a link to the key
SET_SECURITY Can change owner, ACL, expiry
INVAL Can invalidate
REVOKE Can revoke
JOIN Can join this keyring
CLEAR Can clear this keyring
The KEYCTL_SETPERM function is then deprecated.
The KEYCTL_SET_TIMEOUT function then is permitted if SET_SECURITY is set,
or if the caller has a valid instantiation auth token.
The KEYCTL_INVALIDATE function then requires INVAL.
The KEYCTL_REVOKE function then requires REVOKE.
The KEYCTL_JOIN_SESSION_KEYRING function then requires JOIN to join an
existing keyring.
The JOIN permission is enabled by default for session keyrings and manually
created keyrings only.
======================
BACKWARD COMPATIBILITY
======================
To maintain backward compatibility, KEYCTL_SETPERM will translate the
permissions mask it is given into a new ACL for a key - unless
KEYCTL_SET_ACL has been called on that key, in which case an error will be
returned.
It will convert possessor, owner, group and other permissions into separate
ACEs, if each portion of the mask is non-zero.
SETATTR permission turns on all of INVAL, REVOKE and SET_SECURITY. WRITE
permission turns on WRITE, REVOKE and, if a keyring, CLEAR. JOIN is turned
on if a keyring is being altered.
The KEYCTL_DESCRIBE function translates the ACL back into a permissions
mask to return depending on possessor, owner, group and everyone ACEs.
It will make the following mappings:
(1) INVAL, JOIN -> SEARCH
(2) SET_SECURITY -> SETATTR
(3) REVOKE -> WRITE if SETATTR isn't already set
(4) CLEAR -> WRITE
Note that the value subsequently returned by KEYCTL_DESCRIBE may not match
the value set with KEYCTL_SETATTR.
=======
TESTING
=======
This passes the keyutils testsuite for all but a couple of tests:
(1) tests/keyctl/dh_compute/badargs: The first wrong-key-type test now
returns EOPNOTSUPP rather than ENOKEY as READ permission isn't removed
if the type doesn't have ->read(). You still can't actually read the
key.
(2) tests/keyctl/permitting/valid: The view-other-permissions test doesn't
work as Other has been replaced with Everyone in the ACL.
Signed-off-by: David Howells <dhowells@redhat.com>
2019-06-28 06:03:07 +08:00
|
|
|
&internal_key_acl,
|
2013-08-30 23:07:37 +08:00
|
|
|
KEY_ALLOC_NOT_IN_QUOTA |
|
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 23:14:24 +08:00
|
|
|
KEY_ALLOC_BUILT_IN |
|
|
|
|
KEY_ALLOC_BYPASS_RESTRICTION);
|
2013-08-30 23:07:30 +08:00
|
|
|
if (IS_ERR(key)) {
|
|
|
|
pr_err("Problem loading in-kernel X.509 certificate (%ld)\n",
|
|
|
|
PTR_ERR(key));
|
|
|
|
} else {
|
|
|
|
pr_notice("Loaded X.509 cert '%s'\n",
|
|
|
|
key_ref_to_ptr(key)->description);
|
|
|
|
key_ref_put(key);
|
|
|
|
}
|
|
|
|
p += plen;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
dodgy_cert:
|
|
|
|
pr_err("Problem parsing in-kernel X.509 certificate list\n");
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
late_initcall(load_system_certificate_list);
|
2015-07-21 04:16:28 +08:00
|
|
|
|
|
|
|
#ifdef CONFIG_SYSTEM_DATA_VERIFICATION
|
|
|
|
|
|
|
|
/**
|
2016-04-06 23:14:24 +08:00
|
|
|
* verify_pkcs7_signature - Verify a PKCS#7-based signature on system data.
|
|
|
|
* @data: The data to be verified (NULL if expecting internal data).
|
2015-07-21 04:16:28 +08:00
|
|
|
* @len: Size of @data.
|
|
|
|
* @raw_pkcs7: The PKCS#7 message that is the signature.
|
|
|
|
* @pkcs7_len: The size of @raw_pkcs7.
|
2016-04-06 23:14:27 +08:00
|
|
|
* @trusted_keys: Trusted keys to use (NULL for builtin trusted keys only,
|
|
|
|
* (void *)1UL for all trusted keys).
|
PKCS#7: Appropriately restrict authenticated attributes and content type
A PKCS#7 or CMS message can have per-signature authenticated attributes
that are digested as a lump and signed by the authorising key for that
signature. If such attributes exist, the content digest isn't itself
signed, but rather it is included in a special authattr which then
contributes to the signature.
Further, we already require the master message content type to be
pkcs7_signedData - but there's also a separate content type for the data
itself within the SignedData object and this must be repeated inside the
authattrs for each signer [RFC2315 9.2, RFC5652 11.1].
We should really validate the authattrs if they exist or forbid them
entirely as appropriate. To this end:
(1) Alter the PKCS#7 parser to reject any message that has more than one
signature where at least one signature has authattrs and at least one
that does not.
(2) Validate authattrs if they are present and strongly restrict them.
Only the following authattrs are permitted and all others are
rejected:
(a) contentType. This is checked to be an OID that matches the
content type in the SignedData object.
(b) messageDigest. This must match the crypto digest of the data.
(c) signingTime. If present, we check that this is a valid, parseable
UTCTime or GeneralTime and that the date it encodes fits within
the validity window of the matching X.509 cert.
(d) S/MIME capabilities. We don't check the contents.
(e) Authenticode SP Opus Info. We don't check the contents.
(f) Authenticode Statement Type. We don't check the contents.
The message is rejected if (a) or (b) are missing. If the message is
an Authenticode type, the message is rejected if (e) is missing; if
not Authenticode, the message is rejected if (d) - (f) are present.
The S/MIME capabilities authattr (d) unfortunately has to be allowed
to support kernels already signed by the pesign program. This only
affects kexec. sign-file suppresses them (CMS_NOSMIMECAP).
The message is also rejected if an authattr is given more than once or
if it contains more than one element in its set of values.
(3) Add a parameter to pkcs7_verify() to select one of the following
restrictions and pass in the appropriate option from the callers:
(*) VERIFYING_MODULE_SIGNATURE
This requires that the SignedData content type be pkcs7-data and
forbids authattrs. sign-file sets CMS_NOATTR. We could be more
flexible and permit authattrs optionally, but only permit minimal
content.
(*) VERIFYING_FIRMWARE_SIGNATURE
This requires that the SignedData content type be pkcs7-data and
requires authattrs. In future, this will require an attribute
holding the target firmware name in addition to the minimal set.
(*) VERIFYING_UNSPECIFIED_SIGNATURE
This requires that the SignedData content type be pkcs7-data but
allows either no authattrs or only permits the minimal set.
(*) VERIFYING_KEXEC_PE_SIGNATURE
This only supports the Authenticode SPC_INDIRECT_DATA content type
and requires at least an SpcSpOpusInfo authattr in addition to the
minimal set. It also permits an SPC_STATEMENT_TYPE authattr (and
an S/MIME capabilities authattr because the pesign program doesn't
remove these).
(*) VERIFYING_KEY_SIGNATURE
(*) VERIFYING_KEY_SELF_SIGNATURE
These are invalid in this context but are included for later use
when limiting the use of X.509 certs.
(4) The pkcs7_test key type is given a module parameter to select between
the above options for testing purposes. For example:
echo 1 >/sys/module/pkcs7_test_key/parameters/usage
keyctl padd pkcs7_test foo @s </tmp/stuff.pkcs7
will attempt to check the signature on stuff.pkcs7 as if it contains a
firmware blob (1 being VERIFYING_FIRMWARE_SIGNATURE).
Suggested-by: Andy Lutomirski <luto@kernel.org>
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: Marcel Holtmann <marcel@holtmann.org>
Reviewed-by: David Woodhouse <David.Woodhouse@intel.com>
2015-08-05 22:22:27 +08:00
|
|
|
* @usage: The use to which the key is being put.
|
2016-04-06 23:14:24 +08:00
|
|
|
* @view_content: Callback to gain access to content.
|
|
|
|
* @ctx: Context for callback.
|
2015-07-21 04:16:28 +08:00
|
|
|
*/
|
2016-04-06 23:14:24 +08:00
|
|
|
int verify_pkcs7_signature(const void *data, size_t len,
|
|
|
|
const void *raw_pkcs7, size_t pkcs7_len,
|
|
|
|
struct key *trusted_keys,
|
|
|
|
enum key_being_used_for usage,
|
|
|
|
int (*view_content)(void *ctx,
|
|
|
|
const void *data, size_t len,
|
|
|
|
size_t asn1hdrlen),
|
|
|
|
void *ctx)
|
2015-07-21 04:16:28 +08:00
|
|
|
{
|
|
|
|
struct pkcs7_message *pkcs7;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
pkcs7 = pkcs7_parse_message(raw_pkcs7, pkcs7_len);
|
|
|
|
if (IS_ERR(pkcs7))
|
|
|
|
return PTR_ERR(pkcs7);
|
|
|
|
|
|
|
|
/* The data should be detached - so we need to supply it. */
|
2016-04-06 23:14:24 +08:00
|
|
|
if (data && pkcs7_supply_detached_data(pkcs7, data, len) < 0) {
|
2015-07-21 04:16:28 +08:00
|
|
|
pr_err("PKCS#7 signature with non-detached data\n");
|
|
|
|
ret = -EBADMSG;
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
|
PKCS#7: Appropriately restrict authenticated attributes and content type
A PKCS#7 or CMS message can have per-signature authenticated attributes
that are digested as a lump and signed by the authorising key for that
signature. If such attributes exist, the content digest isn't itself
signed, but rather it is included in a special authattr which then
contributes to the signature.
Further, we already require the master message content type to be
pkcs7_signedData - but there's also a separate content type for the data
itself within the SignedData object and this must be repeated inside the
authattrs for each signer [RFC2315 9.2, RFC5652 11.1].
We should really validate the authattrs if they exist or forbid them
entirely as appropriate. To this end:
(1) Alter the PKCS#7 parser to reject any message that has more than one
signature where at least one signature has authattrs and at least one
that does not.
(2) Validate authattrs if they are present and strongly restrict them.
Only the following authattrs are permitted and all others are
rejected:
(a) contentType. This is checked to be an OID that matches the
content type in the SignedData object.
(b) messageDigest. This must match the crypto digest of the data.
(c) signingTime. If present, we check that this is a valid, parseable
UTCTime or GeneralTime and that the date it encodes fits within
the validity window of the matching X.509 cert.
(d) S/MIME capabilities. We don't check the contents.
(e) Authenticode SP Opus Info. We don't check the contents.
(f) Authenticode Statement Type. We don't check the contents.
The message is rejected if (a) or (b) are missing. If the message is
an Authenticode type, the message is rejected if (e) is missing; if
not Authenticode, the message is rejected if (d) - (f) are present.
The S/MIME capabilities authattr (d) unfortunately has to be allowed
to support kernels already signed by the pesign program. This only
affects kexec. sign-file suppresses them (CMS_NOSMIMECAP).
The message is also rejected if an authattr is given more than once or
if it contains more than one element in its set of values.
(3) Add a parameter to pkcs7_verify() to select one of the following
restrictions and pass in the appropriate option from the callers:
(*) VERIFYING_MODULE_SIGNATURE
This requires that the SignedData content type be pkcs7-data and
forbids authattrs. sign-file sets CMS_NOATTR. We could be more
flexible and permit authattrs optionally, but only permit minimal
content.
(*) VERIFYING_FIRMWARE_SIGNATURE
This requires that the SignedData content type be pkcs7-data and
requires authattrs. In future, this will require an attribute
holding the target firmware name in addition to the minimal set.
(*) VERIFYING_UNSPECIFIED_SIGNATURE
This requires that the SignedData content type be pkcs7-data but
allows either no authattrs or only permits the minimal set.
(*) VERIFYING_KEXEC_PE_SIGNATURE
This only supports the Authenticode SPC_INDIRECT_DATA content type
and requires at least an SpcSpOpusInfo authattr in addition to the
minimal set. It also permits an SPC_STATEMENT_TYPE authattr (and
an S/MIME capabilities authattr because the pesign program doesn't
remove these).
(*) VERIFYING_KEY_SIGNATURE
(*) VERIFYING_KEY_SELF_SIGNATURE
These are invalid in this context but are included for later use
when limiting the use of X.509 certs.
(4) The pkcs7_test key type is given a module parameter to select between
the above options for testing purposes. For example:
echo 1 >/sys/module/pkcs7_test_key/parameters/usage
keyctl padd pkcs7_test foo @s </tmp/stuff.pkcs7
will attempt to check the signature on stuff.pkcs7 as if it contains a
firmware blob (1 being VERIFYING_FIRMWARE_SIGNATURE).
Suggested-by: Andy Lutomirski <luto@kernel.org>
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: Marcel Holtmann <marcel@holtmann.org>
Reviewed-by: David Woodhouse <David.Woodhouse@intel.com>
2015-08-05 22:22:27 +08:00
|
|
|
ret = pkcs7_verify(pkcs7, usage);
|
2015-07-21 04:16:28 +08:00
|
|
|
if (ret < 0)
|
|
|
|
goto error;
|
|
|
|
|
2016-04-06 23:14:27 +08:00
|
|
|
if (!trusted_keys) {
|
|
|
|
trusted_keys = builtin_trusted_keys;
|
2018-08-16 21:05:10 +08:00
|
|
|
} else if (trusted_keys == VERIFY_USE_SECONDARY_KEYRING) {
|
2016-04-06 23:14:27 +08:00
|
|
|
#ifdef CONFIG_SECONDARY_TRUSTED_KEYRING
|
|
|
|
trusted_keys = secondary_trusted_keys;
|
|
|
|
#else
|
|
|
|
trusted_keys = builtin_trusted_keys;
|
|
|
|
#endif
|
2019-01-21 17:59:29 +08:00
|
|
|
} else if (trusted_keys == VERIFY_USE_PLATFORM_KEYRING) {
|
|
|
|
#ifdef CONFIG_INTEGRITY_PLATFORM_KEYRING
|
|
|
|
trusted_keys = platform_trusted_keys;
|
|
|
|
#else
|
|
|
|
trusted_keys = NULL;
|
|
|
|
#endif
|
|
|
|
if (!trusted_keys) {
|
|
|
|
ret = -ENOKEY;
|
|
|
|
pr_devel("PKCS#7 platform keyring is not available\n");
|
|
|
|
goto error;
|
|
|
|
}
|
2016-04-06 23:14:27 +08:00
|
|
|
}
|
2016-04-06 23:14:24 +08:00
|
|
|
ret = pkcs7_validate_trust(pkcs7, trusted_keys);
|
|
|
|
if (ret < 0) {
|
|
|
|
if (ret == -ENOKEY)
|
2019-01-21 17:59:29 +08:00
|
|
|
pr_devel("PKCS#7 signature not signed with a trusted key\n");
|
2016-04-06 23:14:24 +08:00
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (view_content) {
|
|
|
|
size_t asn1hdrlen;
|
|
|
|
|
|
|
|
ret = pkcs7_get_content_data(pkcs7, &data, &len, &asn1hdrlen);
|
|
|
|
if (ret < 0) {
|
|
|
|
if (ret == -ENODATA)
|
|
|
|
pr_devel("PKCS#7 message does not contain data\n");
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
|
|
|
|
ret = view_content(ctx, data, len, asn1hdrlen);
|
2015-07-21 04:16:28 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
error:
|
|
|
|
pkcs7_free_message(pkcs7);
|
|
|
|
pr_devel("<==%s() = %d\n", __func__, ret);
|
|
|
|
return ret;
|
|
|
|
}
|
2016-04-06 23:14:24 +08:00
|
|
|
EXPORT_SYMBOL_GPL(verify_pkcs7_signature);
|
2015-07-21 04:16:28 +08:00
|
|
|
|
|
|
|
#endif /* CONFIG_SYSTEM_DATA_VERIFICATION */
|
2019-01-21 17:59:28 +08:00
|
|
|
|
|
|
|
#ifdef CONFIG_INTEGRITY_PLATFORM_KEYRING
|
|
|
|
void __init set_platform_trusted_keys(struct key *keyring)
|
|
|
|
{
|
|
|
|
platform_trusted_keys = keyring;
|
|
|
|
}
|
|
|
|
#endif
|