10 Sep, 2018
1 commit
-
commit 817aef260037f33ee0f44c17fe341323d3aebd6d upstream.
Replace the use of a magic number that indicates that verify_*_signature()
should use the secondary keyring with a symbol.Signed-off-by: Yannik Sembritzki
Signed-off-by: David Howells
Cc: keyrings@vger.kernel.org
Cc: linux-security-module@vger.kernel.org
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman
03 Jul, 2018
1 commit
-
commit b65c32ec5a942ab3ada93a048089a938918aba7f upstream.
The signatureValue field of a X.509 certificate is encoded as a BIT STRING.
For RSA signatures this BIT STRING is of so-called primitive subtype, which
contains a u8 prefix indicating a count of unused bits in the encoding.We have to strip this prefix from signature data, just as we already do for
key data in x509_extract_key_data() function.This wasn't noticed earlier because this prefix byte is zero for RSA key
sizes divisible by 8. Since BIT STRING is a big-endian encoding adding zero
prefixes has no bearing on its value.The signature length, however was incorrect, which is a problem for RSA
implementations that need it to be exactly correct (like AMD CCP).Signed-off-by: Maciej S. Szmigiero
Fixes: c26fd69fa009 ("X.509: Add a crypto key parser for binary (DER) X.509 certificates")
Cc: stable@vger.kernel.org
Signed-off-by: James Morris
Signed-off-by: Greg Kroah-Hartman
30 May, 2018
1 commit
-
[ Upstream commit 6459ae386699a5fe0dc52cf30255f75274fa43a4 ]
If none of the certificates in a SignerInfo's certificate chain match a
trusted key, nor is the last certificate signed by a trusted key, then
pkcs7_validate_trust_one() tries to check whether the SignerInfo's
signature was made directly by a trusted key. But, it actually fails to
set the 'sig' variable correctly, so it actually verifies the last
signature seen. That will only be the SignerInfo's signature if the
certificate chain is empty; otherwise it will actually be the last
certificate's signature.This is not by itself a security problem, since verifying any of the
certificates in the chain should be sufficient to verify the SignerInfo.
Still, it's not working as intended so it should be fixed.Fix it by setting 'sig' correctly for the direct verification case.
Fixes: 757932e6da6d ("PKCS#7: Handle PKCS#7 messages that contain no X.509 certs")
Signed-off-by: Eric Biggers
Signed-off-by: David Howells
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
28 Feb, 2018
4 commits
-
commit 29f4a67c17e19314b7d74b8569be935e6c7edf50 upstream.
If there is a blacklisted certificate in a SignerInfo's certificate
chain, then pkcs7_verify_sig_chain() sets sinfo->blacklisted and returns
0. But, pkcs7_verify() fails to handle this case appropriately, as it
actually continues on to the line 'actual_ret = 0;', indicating that the
SignerInfo has passed verification. Consequently, PKCS#7 signature
verification ignores the certificate blacklist.Fix this by not considering blacklisted SignerInfos to have passed
verification.Also fix the function comment with regards to when 0 is returned.
Fixes: 03bb79315ddc ("PKCS#7: Handle blacklisted certificates")
Cc: # v4.12+
Signed-off-by: Eric Biggers
Signed-off-by: David Howells
Signed-off-by: Greg Kroah-Hartman -
commit 971b42c038dc83e3327872d294fe7131bab152fc upstream.
When pkcs7_verify_sig_chain() is building the certificate chain for a
SignerInfo using the certificates in the PKCS#7 message, it is passing
the wrong arguments to public_key_verify_signature(). Consequently,
when the next certificate is supposed to be used to verify the previous
certificate, the next certificate is actually used to verify itself.An attacker can use this bug to create a bogus certificate chain that
has no cryptographic relationship between the beginning and end.Fortunately I couldn't quite find a way to use this to bypass the
overall signature verification, though it comes very close. Here's the
reasoning: due to the bug, every certificate in the chain beyond the
first actually has to be self-signed (where "self-signed" here refers to
the actual key and signature; an attacker might still manipulate the
certificate fields such that the self_signed flag doesn't actually get
set, and thus the chain doesn't end immediately). But to pass trust
validation (pkcs7_validate_trust()), either the SignerInfo or one of the
certificates has to actually be signed by a trusted key. Since only
self-signed certificates can be added to the chain, the only way for an
attacker to introduce a trusted signature is to include a self-signed
trusted certificate.But, when pkcs7_validate_trust_one() reaches that certificate, instead
of trying to verify the signature on that certificate, it will actually
look up the corresponding trusted key, which will succeed, and then try
to verify the *previous* certificate, which will fail. Thus, disaster
is narrowly averted (as far as I could tell).Fixes: 6c2dc5ae4ab7 ("X.509: Extract signature digest and make self-signed cert checks earlier")
Cc: # v4.7+
Signed-off-by: Eric Biggers
Signed-off-by: David Howells
Signed-off-by: Greg Kroah-Hartman -
commit 4b34968e77ad09628cfb3c4a7daf2adc2cefc6e8 upstream.
The asymmetric key type allows an X.509 certificate to be added even if
its signature's hash algorithm is not available in the crypto API. In
that case 'payload.data[asym_auth]' will be NULL. But the key
restriction code failed to check for this case before trying to use the
signature, resulting in a NULL pointer dereference in
key_or_keyring_common() or in restrict_link_by_signature().Fix this by returning -ENOPKG when the signature is unsupported.
Reproducer when all the CONFIG_CRYPTO_SHA512* options are disabled and
keyctl has support for the 'restrict_keyring' command:keyctl new_session
keyctl restrict_keyring @s asymmetric builtin_trusted
openssl req -new -sha512 -x509 -batch -nodes -outform der \
| keyctl padd asymmetric desc @sFixes: a511e1af8b12 ("KEYS: Move the point of trust determination to __key_link()")
Cc: # v4.7+
Signed-off-by: Eric Biggers
Signed-off-by: David Howells
Signed-off-by: Greg Kroah-Hartman -
commit 437499eea4291ae9621e8763a41df027c110a1ef upstream.
The X.509 parser mishandles the case where the certificate's signature's
hash algorithm is not available in the crypto API. In this case,
x509_get_sig_params() doesn't allocate the cert->sig->digest buffer;
this part seems to be intentional. However,
public_key_verify_signature() is still called via
x509_check_for_self_signed(), which triggers the 'BUG_ON(!sig->digest)'.Fix this by making public_key_verify_signature() return -ENOPKG if the
hash buffer has not been allocated.Reproducer when all the CONFIG_CRYPTO_SHA512* options are disabled:
openssl req -new -sha512 -x509 -batch -nodes -outform der \
| keyctl padd asymmetric desc @sFixes: 6c2dc5ae4ab7 ("X.509: Extract signature digest and make self-signed cert checks earlier")
Reported-by: Paolo Valente
Cc: Paolo Valente
Cc: # v4.7+
Signed-off-by: Eric Biggers
Signed-off-by: David Howells
Signed-off-by: Greg Kroah-Hartman
14 Dec, 2017
2 commits
-
commit 54c1fb39fe0495f846539ab765925b008f86801c upstream.
->pkey_algo used to be an enum, but was changed to a string by commit
4e8ae72a75aa ("X.509: Make algo identifiers text instead of enum"). But
two comparisons were not updated. Fix them to use strcmp().This bug broke signature verification in certain configurations,
depending on whether the string constants were deduplicated or not.Fixes: 4e8ae72a75aa ("X.509: Make algo identifiers text instead of enum")
Signed-off-by: Eric Biggers
Signed-off-by: David Howells
Signed-off-by: Greg Kroah-Hartman -
commit 0f30cbea005bd3077bd98cd29277d7fc2699c1da upstream.
Adding a specially crafted X.509 certificate whose subjectPublicKey
ASN.1 value is zero-length caused x509_extract_key_data() to set the
public key size to SIZE_MAX, as it subtracted the nonexistent BIT STRING
metadata byte. Then, x509_cert_parse() called kmemdup() with that bogus
size, triggering the WARN_ON_ONCE() in kmalloc_slab().This appears to be harmless, but it still must be fixed since WARNs are
never supposed to be user-triggerable.Fix it by updating x509_cert_parse() to validate that the value has a
BIT STRING metadata byte, and that the byte is 0 which indicates that
the number of bits in the bitstring is a multiple of 8.It would be nice to handle the metadata byte in asn1_ber_decoder()
instead. But that would be tricky because in the general case a BIT
STRING could be implicitly tagged, and/or could legitimately have a
length that is not a whole number of bytes.Here was the WARN (cleaned up slightly):
WARNING: CPU: 1 PID: 202 at mm/slab_common.c:971 kmalloc_slab+0x5d/0x70 mm/slab_common.c:971
Modules linked in:
CPU: 1 PID: 202 Comm: keyctl Tainted: G B 4.14.0-09238-g1d3b78bbc6e9 #26
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-20171110_100015-anatol 04/01/2014
task: ffff880033014180 task.stack: ffff8800305c8000
Call Trace:
__do_kmalloc mm/slab.c:3706 [inline]
__kmalloc_track_caller+0x22/0x2e0 mm/slab.c:3726
kmemdup+0x17/0x40 mm/util.c:118
kmemdup include/linux/string.h:414 [inline]
x509_cert_parse+0x2cb/0x620 crypto/asymmetric_keys/x509_cert_parser.c:106
x509_key_preparse+0x61/0x750 crypto/asymmetric_keys/x509_public_key.c:174
asymmetric_key_preparse+0xa4/0x150 crypto/asymmetric_keys/asymmetric_type.c:388
key_create_or_update+0x4d4/0x10a0 security/keys/key.c:850
SYSC_add_key security/keys/keyctl.c:122 [inline]
SyS_add_key+0xe8/0x290 security/keys/keyctl.c:62
entry_SYSCALL_64_fastpath+0x1f/0x96Fixes: 42d5ec27f873 ("X.509: Add an ASN.1 decoder")
Signed-off-by: Eric Biggers
Signed-off-by: David Howells
Reviewed-by: James Morris
Signed-off-by: Greg Kroah-Hartman
02 Nov, 2017
1 commit
-
Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.By default all files without license information are under the default
license of the kernel, which is GPL version 2.Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if
Reviewed-by: Philippe Ombredanne
Reviewed-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman
18 Oct, 2017
3 commits
-
The ASN.1 parser does not necessarily set the sinfo field,
this patch prevents a NULL pointer dereference on broken
input.Fixes: 99db44350672 ("PKCS#7: Appropriately restrict authenticated attributes and content type")
Signed-off-by: Eric Sesterhenn
Signed-off-by: David Howells
cc: stable@vger.kernel.org # 4.3+ -
For finding asymmetric key, the input id_0 and id_1 parameters can
not be NULL at the same time. This patch adds the BUG_ON checking
for id_0 and id_1.Cc: David Howells
Cc: Herbert Xu
Cc: "David S. Miller"
Signed-off-by: Chun-Yi Lee
Signed-off-by: David Howells -
Fix the wrong index number when checking the existence of second
id in function of finding asymmetric key. The id_1 is the second
id that the index in array must be 1 but not 0.Fixes: 9eb029893ad5 (KEYS: Generalise x509_request_asymmetric_key())
Cc: David Howells
Cc: Herbert Xu
Cc: "David S. Miller"
Signed-off-by: Chun-Yi Lee
Signed-off-by: David Howells
09 Jun, 2017
2 commits
-
Signed-off-by: Loganaden Velvindron
Signed-off-by: Yasir Auleear
Signed-off-by: David Howells
Signed-off-by: James Morris -
We forgot to set the error code on this path so it could result in
returning NULL which leads to a NULL dereference.Fixes: db6c43bd2132 ("crypto: KEYS: convert public key and digsig asym to the akcipher api")
Signed-off-by: Dan Carpenter
Signed-off-by: David Howells
Signed-off-by: James Morris
23 May, 2017
1 commit
-
public_key_verify_signature() was passing the CRYPTO_TFM_REQ_MAY_BACKLOG
flag to akcipher_request_set_callback() but was not handling correctly
the case where a -EBUSY error could be returned from the call to
crypto_akcipher_verify() if backlog was used, possibly casuing
data corruption due to use-after-free of buffers.Resolve this by handling -EBUSY correctly.
Signed-off-by: Gilad Ben-Yossef
CC: stable@vger.kernel.org
Signed-off-by: Herbert Xu
05 Apr, 2017
3 commits
-
Add a restrict_link_by_key_or_keyring_chain link restriction that
searches for signing keys in the destination keyring in addition to the
signing key or keyring designated when the destination keyring was
created. Userspace enables this behavior by including the "chain" option
in the keyring restriction:keyctl(KEYCTL_RESTRICT_KEYRING, keyring, "asymmetric",
"key_or_keyring::chain");Signed-off-by: Mat Martineau
-
Adds restrict_link_by_signature_keyring(), which uses the restrict_key
member of the provided destination_keyring data structure as the
key or keyring to search for signing keys.Signed-off-by: Mat Martineau
-
Look up asymmetric keyring restriction information using the key-type
lookup_restrict hook.Signed-off-by: Mat Martineau
04 Apr, 2017
1 commit
-
The first argument to the restrict_link_func_t functions was a keyring
pointer. These functions are called by the key subsystem with this
argument set to the destination keyring, but restrict_link_by_signature
expects a pointer to the relevant trusted keyring.Restrict functions may need something other than a single struct key
pointer to allow or reject key linkage, so the data used to make that
decision (such as the trust keyring) is moved to a new, fourth
argument. The first argument is now always the destination keyring.Signed-off-by: Mat Martineau
03 Apr, 2017
2 commits
-
PKCS#7: Handle certificates that are blacklisted when verifying the chain
of trust on the signatures on a PKCS#7 message.Signed-off-by: David Howells
-
Allow X.509 certs to be blacklisted based on their TBSCertificate hash.
This is convenient since we have to determine this anyway to be able to
check the signature on an X.509 certificate. This is also what UEFI uses
in its blacklist.If a certificate built into the kernel is blacklisted, something like the
following might then be seen during boot:X.509: Cert 123412341234c55c1dcc601ab8e172917706aa32fb5eaf826813547fdf02dd46 is blacklisted
Problem loading in-kernel X.509 certificate (-129)where the hex string shown is the blacklisted hash.
Signed-off-by: David Howells
16 Dec, 2016
1 commit
-
Pull crypto fixes from Herbert Xu:
"This fixes the following issues:- a crash regression in the new skcipher walker
- incorrect return value in public_key_verify_signature
- fix for in-place signing in the sign-file utility"
* 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6:
crypto: skcipher - fix crash in virtual walk
sign-file: Fix inplace signing when src and dst names are both specified
crypto: asymmetric_keys - set error code on failure
14 Dec, 2016
1 commit
-
In function public_key_verify_signature(), returns variable ret on
error paths. When the call to kmalloc() fails, the value of ret is 0,
and it is not set to an errno before returning. This patch fixes the
bug.Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=188891
Signed-off-by: Pan Bian
Signed-off-by: David Howells
Signed-off-by: Herbert Xu
25 Nov, 2016
1 commit
-
We shouldn't free cert->pub->key in x509_cert_parse() because
x509_free_certificate() also does this:
BUG: Double free or freeing an invalid pointer
...
Call Trace:
[] dump_stack+0x63/0x83
[] kasan_object_err+0x21/0x70
[] kasan_report_double_free+0x49/0x60
[] kasan_slab_free+0x9d/0xc0
[] kfree+0x8a/0x1a0
[] public_key_free+0x1f/0x30
[] x509_free_certificate+0x24/0x90
[] x509_cert_parse+0x2bc/0x300
[] x509_key_preparse+0x3e/0x330
[] asymmetric_key_preparse+0x6f/0x100
[] key_create_or_update+0x260/0x5f0
[] SyS_add_key+0x199/0x2a0
[] entry_SYSCALL_64_fastpath+0x1e/0xad
Object at ffff880110bd1900, in cache kmalloc-512 size: 512
....
Freed:
PID = 2579
[] save_stack_trace+0x1b/0x20
[] save_stack+0x46/0xd0
[] kasan_slab_free+0x73/0xc0
[] kfree+0x8a/0x1a0
[] x509_cert_parse+0x2a3/0x300
[] x509_key_preparse+0x3e/0x330
[] asymmetric_key_preparse+0x6f/0x100
[] key_create_or_update+0x260/0x5f0
[] SyS_add_key+0x199/0x2a0
[] entry_SYSCALL_64_fastpath+0x1e/0xadFixes: db6c43bd2132 ("crypto: KEYS: convert public key and digsig asym to the akcipher api")
Signed-off-by: Andrey Ryabinin
Cc:
Signed-off-by: David Howells
Signed-off-by: James Morris
18 Jul, 2016
3 commits
-
Arbitrary X.509 certificates without authority key identifiers (AKIs)
can be added to "trusted" keyrings, including IMA or EVM certs loaded
from the filesystem. Signature verification is currently bypassed for
certs without AKIs.Trusted keys were recently refactored, and this bug is not present in
4.6.restrict_link_by_signature should return -ENOKEY (no matching parent
certificate found) if the certificate being evaluated has no AKIs,
instead of bypassing signature checks and returning 0 (new certificate
accepted).Reported-by: Petko Manolov
Signed-off-by: Mat Martineau
Signed-off-by: David Howells
Signed-off-by: James Morris -
Commit e68503bd68 forgot to set digest_len and thus cause the following
error reported by kexec when launching a crash kernel:kexec_file_load failed: Bad message
Fixes: e68503bd68 (KEYS: Generalise system_verify_data() to provide access to internal content)
Signed-off-by: Lans Zhang
Tested-by: Dave Young
Signed-off-by: David Howells
Cc: Baoquan He
Cc: Vivek Goyal
cc: kexec@lists.infradead.org
cc: linux-crypto@vger.kernel.org
Signed-off-by: James Morris -
This fix resolves the following kernel panic if an empty or missing
AuthorityKeyIdentifier is encountered and DEBUG is defined in
pkcs7_verify.c.[ 459.041989] PKEY: pkcs7_verify_sig_chain()
[ 459.041999] PKCS7: verify Sample DB Certificate for SCP: 01
[ 459.042002] PKCS7: - issuer Sample KEK Certificate for SCP
[ 459.042014] BUG: unable to handle kernel NULL pointer dereference at (null)
[ 459.042135] IP: [] pkcs7_verify+0x72c/0x7f0
[ 459.042217] PGD 739e6067 PUD 77719067 PMD 0
[ 459.042286] Oops: 0000 [#1] PREEMPT SMP
[ 459.042328] Modules linked in:
[ 459.042368] CPU: 0 PID: 474 Comm: kexec Not tainted 4.7.0-rc7-WR8.0.0.0_standard+ #18
[ 459.042462] Hardware name: To be filled by O.E.M. To be filled by O.E.M./Aptio CRB, BIOS 5.6.5 10/09/2014
[ 459.042586] task: ffff880073a50000 ti: ffff8800738e8000 task.ti: ffff8800738e8000
[ 459.042675] RIP: 0010:[] [] pkcs7_verify+0x72c/0x7f0
[ 459.042784] RSP: 0018:ffff8800738ebd58 EFLAGS: 00010246
[ 459.042845] RAX: 0000000000000000 RBX: ffff880076b7da80 RCX: 0000000000000006
[ 459.042929] RDX: 0000000000000001 RSI: ffffffff81c85001 RDI: ffffffff81ca00a9
[ 459.043014] RBP: ffff8800738ebd98 R08: 0000000000000400 R09: ffff8800788a304c
[ 459.043098] R10: 0000000000000000 R11: 00000000000060ca R12: ffff8800769a2bc0
[ 459.043182] R13: ffff880077358300 R14: 0000000000000000 R15: ffff8800769a2dc0
[ 459.043268] FS: 00007f24cc741700(0000) GS:ffff880074e00000(0000) knlGS:0000000000000000
[ 459.043365] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 459.043431] CR2: 0000000000000000 CR3: 0000000073a36000 CR4: 00000000001006f0
[ 459.043514] Stack:
[ 459.043530] 0000000000000000 ffffffbf00000020 31ffffff813e68b0 0000000000000002
[ 459.043644] ffff8800769a2bc0 0000000000000000 00000000007197b8 0000000000000002
[ 459.043756] ffff8800738ebdd8 ffffffff81153fb1 0000000000000000 0000000000000000
[ 459.043869] Call Trace:
[ 459.043898] [] verify_pkcs7_signature+0x61/0x140
[ 459.043974] [] verify_pefile_signature+0x2cb/0x830
[ 459.044052] [] ? verify_pefile_signature+0x830/0x830
[ 459.044134] [] bzImage64_verify_sig+0x15/0x20
[ 459.046332] [] arch_kexec_kernel_verify_sig+0x29/0x40
[ 459.048552] [] SyS_kexec_file_load+0x1f4/0x6c0
[ 459.050768] [] ? __do_page_fault+0x1b6/0x550
[ 459.052996] [] entry_SYSCALL_64_fastpath+0x17/0x93
[ 459.055242] Code: e8 0a d6 ff ff 85 c0 0f 88 7a fb ff ff 4d 39 fd 4d 89 7d 08 74 45 4d 89 fd e9 14 fe ff ff 4d 8b 76 08 31 c0 48 c7 c7 a9 00 ca 81 0f b7 36 49 8d 56 02 e8 d0 91 d6 ff 4d 8b 3c 24 4d 85 ff 0f
[ 459.060535] RIP [] pkcs7_verify+0x72c/0x7f0
[ 459.063040] RSP
[ 459.065456] CR2: 0000000000000000
[ 459.075998] ---[ end trace c15f0e897cda28dc ]---Signed-off-by: Lans Zhang
Signed-off-by: David Howells
Cc: Dave Young
Cc: Baoquan He
Cc: Vivek Goyal
cc: linux-crypto@vger.kernel.org
cc: kexec@lists.infradead.org
Signed-off-by: James Morris
31 May, 2016
1 commit
-
Pull crypto fixes from Herbert Xu:
"This fixes the following issues:- missing selection in public_key that may result in a build failure
- Potential crash in error path in omap-sham
- ccp AES XTS bug that affects requests larger than 4096"
* 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6:
crypto: ccp - Fix AES XTS error for request sizes above 4096
crypto: public_key: select CRYPTO_AKCIPHER
crypto: omap-sham - potential Oops on error in probe
19 May, 2016
1 commit
-
In some rare randconfig builds, we can end up with
ASYMMETRIC_PUBLIC_KEY_SUBTYPE enabled but CRYPTO_AKCIPHER disabled,
which fails to link because of the reference to crypto_alloc_akcipher:crypto/built-in.o: In function `public_key_verify_signature':
:(.text+0x110e4): undefined reference to `crypto_alloc_akcipher'This adds a Kconfig 'select' statement to ensure the dependency
is always there.Cc:
Signed-off-by: Arnd Bergmann
Signed-off-by: Herbert Xu
11 May, 2016
1 commit
-
The PKCS#7 test key type should use the secondary keyring instead of the
built-in keyring if available as the source of trustworthy keys.Signed-off-by: David Howells
12 Apr, 2016
6 commits
-
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
-
Make the system trusted keyring depend on the asymmetric key type as
there's not a lot of point having it if you can't then load asymmetric keys
onto it.This requires the ASYMMETRIC_KEY_TYPE to be made a bool, not a tristate, as
the Kconfig language doesn't then correctly force ASYMMETRIC_KEY_TYPE to
'y' rather than 'm' if SYSTEM_TRUSTED_KEYRING is 'y'.Making SYSTEM_TRUSTED_KEYRING *select* ASYMMETRIC_KEY_TYPE instead doesn't
work as the Kconfig interpreter then wrongly complains about dependency
loops.Signed-off-by: David Howells
-
Move the X.509 trust validation code out to its own file so that it can be
generalised.Signed-off-by: David Howells
-
We should call verify_signature() rather than directly calling
public_key_verify_signature() if we have a struct key to use as we
shouldn't be poking around in the private data of the key struct as that's
subtype dependent.Signed-off-by: David Howells
-
Generalise x509_request_asymmetric_key(). It doesn't really have any
dependencies on X.509 features as it uses generalised IDs and the
public_key structs that contain data extracted from X.509.Signed-off-by: David Howells
-
Move x509_request_asymmetric_key() to asymmetric_type.c so that it can be
generalised.Signed-off-by: David Howells
06 Apr, 2016
3 commits
-
Make the determination of the trustworthiness of a key dependent on whether
a key that can verify it is present in the supplied ring of trusted keys
rather than whether or not the verifying key has KEY_FLAG_TRUSTED set.verify_pkcs7_signature() will return -ENOKEY if the PKCS#7 message trust
chain cannot be verified.Signed-off-by: David Howells
-
Generalise system_verify_data() to provide access to internal content
through a callback. This allows all the PKCS#7 stuff to be hidden inside
this function and removed from the PE file parser and the PKCS#7 test key.If external content is not required, NULL should be passed as data to the
function. If the callback is not required, that can be set to NULL.The function is now called verify_pkcs7_signature() to contrast with
verify_pefile_signature() and the definitions of both have been moved into
linux/verification.h along with the key_being_used_for enum.Signed-off-by: David Howells
-
There's a bug in the code determining whether a certificate is self-signed
or not: if they have neither AKID nor SKID then we just assume that the
cert is self-signed, which may not be true.Fix this by checking that the raw subject name matches the raw issuer name
and that the public key algorithm for the key and signature are both the
same in addition to requiring that the AKID bits match.Signed-off-by: David Howells