Add a config option (IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY)
that, when enabled, allows keys to be added to the IMA keyrings by
userspace - with the restriction that each must be signed by a key in the
system trusted keyrings.
EPERM will be returned if this option is disabled, ENOKEY will be returned if
no authoritative key can be found and EKEYREJECTED will be returned if the
signature doesn't match. Other errors such as ENOPKG may also be returned.
If this new option is enabled, the builtin system keyring is searched, as is
the secondary system keyring if that is also enabled. Intermediate keys
between the builtin system keyring and the key being added can be added to
the secondary keyring (which replaces .ima_mok) to form a trust chain -
provided they are also validly signed by a key in one of the trusted keyrings.
The .ima_mok keyring is then removed and the IMA blacklist keyring gets its
own config option (IMA_BLACKLIST_KEYRING).
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
Remove KEY_FLAG_TRUSTED and KEY_ALLOC_TRUSTED as they're no longer
meaningful. Also we can drop the trusted flag from the preparse structure.
Given this, we no longer need to pass the key flags through to
restrict_link().
Further, we can now get rid of keyring_restrict_trusted_only() also.
Signed-off-by: David Howells <dhowells@redhat.com>
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>
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>
Require all keys added to the EVM keyring be signed by an
existing trusted key on the system trusted keyring.
This patch also switches IMA to use integrity_init_keyring().
Changes in v3:
* Added 'init_keyring' config based variable to skip initializing
keyring instead of using __integrity_init_keyring() wrapper.
* Added dependency back to CONFIG_IMA_TRUSTED_KEYRING
Changes in v2:
* Replace CONFIG_EVM_TRUSTED_KEYRING with IMA and EVM common
CONFIG_INTEGRITY_TRUSTED_KEYRING configuration option
* Deprecate CONFIG_IMA_TRUSTED_KEYRING but keep it for config
file compatibility. (Mimi Zohar)
Signed-off-by: Dmitry Kasatkin <dmitry.kasatkin@huawei.com>
Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
If IMA_LOAD_X509 is enabled, either directly or indirectly via
IMA_APPRAISE_SIGNED_INIT, certificates are loaded onto the IMA
trusted keyring by the kernel via key_create_or_update(). When
the KEY_ALLOC_TRUSTED flag is provided, certificates are loaded
without first verifying the certificate is properly signed by a
trusted key on the system keyring. This patch removes the
KEY_ALLOC_TRUSTED flag.
Signed-off-by: Dmitry Kasatkin <dmitry.kasatkin@huawei.com>
Cc: <stable@vger.kernel.org> # 3.19+
Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
This patch adds validity checks for 'path' parameter and
makes it const.
Signed-off-by: Dmitry Kasatkin <d.kasatkin@samsung.com>
Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
Provide the function to load x509 certificates from the kernel into the
integrity kernel keyring.
Changes in v2:
* configuration option removed
* function declared as '__init'
Signed-off-by: Dmitry Kasatkin <d.kasatkin@samsung.com>
Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
integrity_init_keyring() is used only from kernel '__init'
functions. Add it there as well.
Signed-off-by: Dmitry Kasatkin <d.kasatkin@samsung.com>
Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
Require all keys added to the IMA keyring be signed by an
existing trusted key on the system trusted keyring.
Changelog v6:
- remove ifdef CONFIG_IMA_TRUSTED_KEYRING in C code - Dmitry
- update Kconfig dependency and help
- select KEYS_DEBUG_PROC_KEYS - Dmitry
Changelog v5:
- Move integrity_init_keyring() to init_ima() - Dmitry
- reset keyring[id] on failure - Dmitry
Changelog v1:
- don't link IMA trusted keyring to user keyring
Changelog:
- define stub integrity_init_keyring() function (reported-by Fengguang Wu)
- differentiate between regular and trusted keyring names.
- replace printk with pr_info (D. Kasatkin)
- only make the IMA keyring a trusted keyring (reported-by D. Kastatkin)
- define stub integrity_init_keyring() definition based on
CONFIG_INTEGRITY_SIGNATURE, not CONFIG_INTEGRITY_ASYMMETRIC_KEYS.
(reported-by Jim Davis)
Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
Signed-off-by: Dmitry Kasatkin <d.kasatkin@samsung.com>
Acked-by: David Howells <dhowells@redhat.com>
This reverts commit 217091dd7a, which
caused the following build error:
security/integrity/digsig.c:70:5: error: redefinition of ‘integrity_init_keyring’
security/integrity/integrity.h:149:12: note: previous definition of ‘integrity_init_keyring’ w
security/integrity/integrity.h:149:12: warning: ‘integrity_init_keyring’ defined but not used
reported by Krzysztof Kolasa. Mimi says:
"I made the classic mistake of requesting this patch to be upstreamed
at the last second, rather than waiting until the next open window.
At this point, the best course would probably be to revert the two
commits and fix them for the next open window"
Reported-by: Krzysztof Kolasa <kkolasa@winsoft.pl>
Acked-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Require all keys added to the IMA keyring be signed by an
existing trusted key on the system trusted keyring.
Changelog:
- define stub integrity_init_keyring() function (reported-by Fengguang Wu)
- differentiate between regular and trusted keyring names.
- replace printk with pr_info (D. Kasatkin)
Signed-off-by: Mimi Zohar <zohar@us.ibm.com>
For possibility to use xattr type for new signature formats,
pass full xattr to the signature verification function.
Signed-off-by: Dmitry Kasatkin <d.kasatkin@samsung.com>
Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
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>
Define separate keyrings for each of the different use cases - evm, ima,
and modules. Using different keyrings improves search performance, and also
allows "locking" specific keyring to prevent adding new keys.
This is useful for evm and module keyrings, when keys are usually only
added from initramfs.
Signed-off-by: Dmitry Kasatkin <dmitry.kasatkin@intel.com>
David Howells
Dmitry Kasatkin
Dmitry Kasatkin
Dmitry Kasatkin
Mimi Zohar
Linus Torvalds
Dmitry Kasatkin