KEYS: remove MODULE_LICENSE in non-modules

Since commit 8b41fc4454e ("kbuild: create modules.builtin without
Makefile.modbuiltin or tristate.conf"), MODULE_LICENSE declarations
are used to identify modules. As a consequence, uses of the macro
in non-modules will cause modprobe to misidentify their containing
object file as a module when it is not (false positives), and modprobe
might succeed rather than failing with a suitable error message.

So remove it in the files in this commit, none of which can be built as
modules.

Signed-off-by: Nick Alcock <nick.alcock@oracle.com>
Suggested-by: Luis Chamberlain <mcgrof@kernel.org>
Cc: Luis Chamberlain <mcgrof@kernel.org>
Cc: linux-modules@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: Hitomi Hasegawa <hasegawa-hitomi@fujitsu.com>
Cc: David Howells <dhowells@redhat.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: keyrings@vger.kernel.org
Cc: linux-crypto@vger.kernel.org
Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>

keys: X.509 public key issuer lookup without AKID

There are non-root X.509 v3 certificates in use out there that contain
no Authority Key Identifier extension (RFC5280 section 4.2.1.1). For
trust verification purposes the kernel asymmetric key type keeps two
struct asymmetric_key_id instances that the key can be looked up by,
and another two to look up the key's issuer. The x509 public key type
and the PKCS7 type generate them from the SKID and AKID extensions in
the certificate. In effect current code has no way to look up the
issuer certificate for verification without the AKID.

To remedy this, add a third asymmetric_key_id blob to the arrays in
both asymmetric_key_id's (for certficate subject) and in the
public_keys_signature's auth_ids (for issuer lookup), using just raw
subject and issuer DNs from the certificate. Adapt
asymmetric_key_ids() and its callers to use the third ID for lookups
when none of the other two are available. Attempt to keep the logic
intact when they are, to minimise behaviour changes. Adapt the
restrict functions' NULL-checks to include that ID too. Do not modify
the lookup logic in pkcs7_verify.c, the AKID extensions are still
required there.

Internally use a new "dn:" prefix to the search specifier string
generated for the key lookup in find_asymmetric_key(). This tells
asymmetric_key_match_preparse to only match the data against the raw
DN in the third ID and shouldn't conflict with search specifiers
already in use.

In effect implement what (2) in the struct asymmetric_key_id comment
(include/keys/asymmetric-type.h) is probably talking about already, so
do not modify that comment. It is also how "openssl verify" looks up
issuer certificates without the AKID available. Lookups by the raw
DN are unambiguous only provided that the CAs respect the condition in
RFC5280 4.2.1.1 that the AKID may only be omitted if the CA uses
a single signing key.

The following is an example of two things that this change enables.
A self-signed ceritficate is generated following the example from
https://letsencrypt.org/docs/certificates-for-localhost/, and can be
looked up by an identifier and verified against itself by linking to a
restricted keyring -- both things not possible before due to the missing
AKID extension:

$ openssl req -x509 -out localhost.crt -outform DER -keyout localhost.key \
-newkey rsa:2048 -nodes -sha256 \
-subj '/CN=localhost' -extensions EXT -config <( \
echo -e "[dn]\nCN=localhost\n[req]\ndistinguished_name = dn\n[EXT]\n" \
"subjectAltName=DNS:localhost\nkeyUsage=digitalSignature\n" \
"extendedKeyUsage=serverAuth")
$ keyring=`keyctl newring test @u`
$ trusted=`keyctl padd asymmetric trusted $keyring < localhost.crt`; \
echo $trusted
39726322
$ keyctl search $keyring asymmetric dn:3112301006035504030c096c6f63616c686f7374
39726322
$ keyctl restrict_keyring $keyring asymmetric key_or_keyring:$trusted
$ keyctl padd asymmetric verified $keyring < localhost.crt

Signed-off-by: Andrew Zaborowski <andrew.zaborowski@intel.com>
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
Acked-by: Jarkko Sakkinen <jarkko@kernel.org>
Acked-by: David Howells <dhowells@redhat.com>
Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>

KEYS: asymmetric: Fix kerneldoc

Fix W=1 compile warnings (invalid kerneldoc):

crypto/asymmetric_keys/asymmetric_type.c:160: warning: Function parameter or member 'kid1' not described in 'asymmetric_key_id_same'
crypto/asymmetric_keys/asymmetric_type.c:160: warning: Function parameter or member 'kid2' not described in 'asymmetric_key_id_same'
crypto/asymmetric_keys/asymmetric_type.c:160: warning: Excess function parameter 'kid_1' description in 'asymmetric_key_id_same'
crypto/asymmetric_keys/asymmetric_type.c:160: warning: Excess function parameter 'kid_2' description in 'asymmetric_key_id_same'

Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Reviewed-by: Ben Boeckel <mathstuf@gmail.com>
Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@iki.fi>

docs: crypto: convert asymmetric-keys.txt to ReST

This file is almost compatible with ReST. Just minor changes
were needed:

- Adjust document and titles markups;
- Adjust numbered list markups;
- Add a comments markup for the Contents section;
- Add markups for literal blocks.

Acked-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Link: https://lore.kernel.org/r/c2275ea94e0507a01b020ab66dfa824d8b1c2545.1592203650.git.mchehab+huawei@kernel.org
Signed-off-by: Jonathan Corbet <corbet@lwn.net>

keys: Add a 'recurse' flag for keyring searches

Add a 'recurse' flag for keyring searches so that the flag can be omitted
and recursion disabled, thereby allowing just the nominated keyring to be
searched and none of the children.

Signed-off-by: David Howells <dhowells@redhat.com>

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 36

Based on 1 normalized pattern(s):

this program is free software you can redistribute it and or modify
it under the terms of the gnu general public licence as published by
the free software foundation either version 2 of the licence or at
your option any later version

extracted by the scancode license scanner the SPDX license identifier

GPL-2.0-or-later

has been chosen to replace the boilerplate/reference in 114 file(s).

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Allison Randal <allison@lohutok.net>
Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190520170857.552531963@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

KEYS: Provide missing asymmetric key subops for new key type ops [ver #2]

Provide the missing asymmetric key subops for new key type ops. This
include query, encrypt, decrypt and create signature. Verify signature
already exists. Also provided are accessor functions for this:

int query_asymmetric_key(const struct key *key,
struct kernel_pkey_query *info);

int encrypt_blob(struct kernel_pkey_params *params,
const void *data, void *enc);
int decrypt_blob(struct kernel_pkey_params *params,
const void *enc, void *data);
int create_signature(struct kernel_pkey_params *params,
const void *data, void *enc);

The public_key_signature struct gains an encoding field to carry the
encoding for verify_signature().

Signed-off-by: David Howells <dhowells@redhat.com>
Tested-by: Marcel Holtmann <marcel@holtmann.org>
Reviewed-by: Marcel Holtmann <marcel@holtmann.org>
Reviewed-by: Denis Kenzior <denkenz@gmail.com>
Tested-by: Denis Kenzior <denkenz@gmail.com>
Signed-off-by: James Morris <james.morris@microsoft.com>

docs: Fix some broken references

As we move stuff around, some doc references are broken. Fix some of
them via this script:
./scripts/documentation-file-ref-check --fix

Manually checked if the produced result is valid, removing a few
false-positives.

Acked-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
Acked-by: Stephen Boyd <sboyd@kernel.org>
Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Reviewed-by: Coly Li <colyli@suse.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Acked-by: Jonathan Corbet <corbet@lwn.net>

KEYS: checking the input id parameters before finding asymmetric key

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 <dhowells@redhat.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: "David S. Miller" <davem@davemloft.net>
Signed-off-by: Chun-Yi Lee <jlee@suse.com>
Signed-off-by: David Howells <dhowells@redhat.com>

KEYS: Fix the wrong index when checking the existence of second id

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 <dhowells@redhat.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: "David S. Miller" <davem@davemloft.net>
Signed-off-by: Chun-Yi Lee <jlee@suse.com>
Signed-off-by: David Howells <dhowells@redhat.com>

KEYS: Keyring asymmetric key restrict method with chaining

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:<signing key>:chain");

Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com>

KEYS: Restrict asymmetric key linkage using a specific keychain

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 <mathew.j.martineau@linux.intel.com>

KEYS: Add a lookup_restriction function for the asymmetric key type

Look up asymmetric keyring restriction information using the key-type
lookup_restrict hook.

Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com>

KEYS: Generalise x509_request_asymmetric_key()

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 <dhowells@redhat.com>

KEYS: Move x509_request_asymmetric_key() to asymmetric_type.c

Move x509_request_asymmetric_key() to asymmetric_type.c so that it can be
generalised.

Signed-off-by: David Howells <dhowells@redhat.com>

KEYS: Allow authentication data to be stored in an asymmetric key

Allow authentication data to be stored in an asymmetric key in the 4th
element of the key payload and provide a way for it to be destroyed.

For the public key subtype, this will be a public_key_signature struct.

Signed-off-by: David Howells <dhowells@redhat.com>

KEYS: Merge the type-specific data with the payload data

Merge the type-specific data with the payload data into one four-word chunk
as it seems pointless to keep them separate.

Use user_key_payload() for accessing the payloads of overloaded
user-defined keys.

Signed-off-by: David Howells <dhowells@redhat.com>
cc: linux-cifs@vger.kernel.org
cc: ecryptfs@vger.kernel.org
cc: linux-ext4@vger.kernel.org
cc: linux-f2fs-devel@lists.sourceforge.net
cc: linux-nfs@vger.kernel.org
cc: ceph-devel@vger.kernel.org
cc: linux-ima-devel@lists.sourceforge.net

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>

KEYS: fix "ca_keys=" partial key matching

The call to asymmetric_key_hex_to_key_id() from ca_keys_setup()
silently fails with -ENOMEM. Instead of dynamically allocating
memory from a __setup function, this patch defines a variable
and calls __asymmetric_key_hex_to_key_id(), a new helper function,
directly.

This bug was introduced by 'commit 46963b774d44 ("KEYS: Overhaul
key identification when searching for asymmetric keys")'.

Changelog:
- for clarification, rename hexlen to asciihexlen in
asymmetric_key_hex_to_key_id()
- add size argument to __asymmetric_key_hex_to_key_id() - David Howells
- inline __asymmetric_key_hex_to_key_id() - David Howells
- remove duplicate strlen() calls

Acked-by: David Howells <dhowells@redhat.com>
Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
Cc: stable@vger.kernel.org # 3.18

KEYS: output last portion of fingerprint in /proc/keys

Previous version of KEYS used to output last 4 bytes of fingerprint.
Now it outputs 8 last bytes of raw subject, which does not make any
visual meaning at all. This patch restores old behavior.

Signed-off-by: Dmitry Kasatkin <d.kasatkin@samsung.com>
Signed-off-by: David Howells <dhowells@redhat.com>

KEYS: Restore partial ID matching functionality for asymmetric keys

Bring back the functionality whereby an asymmetric key can be matched with a
partial match on one of its IDs.

Whilst we're at it, allow for the possibility of having an increased number of
IDs.

Reported-by: Dmitry Kasatkin <d.kasatkin@samsung.com>
Signed-off-by: Dmitry Kasatkin <d.kasatkin@samsung.com>
Signed-off-by: David Howells <dhowells@redhat.com>

KEYS: handle error code encoded in pointer

If hexlen is odd then function returns an error.
Use IS_ERR to check for error, otherwise invalid pointer
is used and kernel gives oops:

[ 132.816522] BUG: unable to handle kernel paging request at
ffffffffffffffea
[ 132.819902] IP: [<ffffffff812bfc20>] asymmetric_key_id_same+0x14/0x36
[ 132.820302] PGD 1a12067 PUD 1a14067 PMD 0
[ 132.820302] Oops: 0000 [#1] SMP
[ 132.820302] Modules linked in: bridge(E) stp(E) llc(E) evdev(E)
serio_raw(E) i2c_piix4(E) button(E) fuse(E)
[ 132.820302] CPU: 0 PID: 2993 Comm: cat Tainted: G E
3.16.0-kds+ #2847
[ 132.820302] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[ 132.820302] task: ffff88004249a430 ti: ffff880056640000 task.ti:
ffff880056640000
[ 132.820302] RIP: 0010:[<ffffffff812bfc20>] [<ffffffff812bfc20>]
asymmetric_key_id_same+0x14/0x36
[ 132.820302] RSP: 0018:ffff880056643930 EFLAGS: 00010246
[ 132.820302] RAX: 0000000000000000 RBX: ffffffffffffffea RCX:
ffff880056643ae0
[ 132.820302] RDX: 000000000000005e RSI: ffffffffffffffea RDI:
ffff88005bac9300
[ 132.820302] RBP: ffff880056643948 R08: 0000000000000003 R09:
00000007504aa01a
[ 132.820302] R10: 0000000000000000 R11: 0000000000000000 R12:
ffff88005d68ca40
[ 132.820302] R13: 0000000000000101 R14: 0000000000000000 R15:
ffff88005bac5280
[ 132.820302] FS: 00007f67a153c740(0000) GS:ffff88005da00000(0000)
knlGS:0000000000000000
[ 132.820302] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 132.820302] CR2: ffffffffffffffea CR3: 000000002e663000 CR4:
00000000000006f0
[ 132.820302] Stack:
[ 132.820302] ffffffff812bfc66 ffff880056643ae0 ffff88005bac5280
ffff880056643958
[ 132.820302] ffffffff812bfc9d ffff880056643980 ffffffff812971d9
ffff88005ce930c1
[ 132.820302] ffff88005ce930c0 0000000000000000 ffff8800566439c8
ffffffff812fb753
[ 132.820302] Call Trace:
[ 132.820302] [<ffffffff812bfc66>] ? asymmetric_match_key_ids+0x24/0x42
[ 132.820302] [<ffffffff812bfc9d>] asymmetric_key_cmp+0x19/0x1b
[ 132.820302] [<ffffffff812971d9>] keyring_search_iterator+0x74/0xd7
[ 132.820302] [<ffffffff812fb753>] assoc_array_subtree_iterate+0x67/0xd2
[ 132.820302] [<ffffffff81297165>] ? key_default_cmp+0x20/0x20
[ 132.820302] [<ffffffff812fbaa1>] assoc_array_iterate+0x19/0x1e
[ 132.820302] [<ffffffff81297332>] search_nested_keyrings+0xf6/0x2b6
[ 132.820302] [<ffffffff810728da>] ? sched_clock_cpu+0x91/0xa2
[ 132.820302] [<ffffffff810860d2>] ? mark_held_locks+0x58/0x6e
[ 132.820302] [<ffffffff810a137d>] ? current_kernel_time+0x77/0xb8
[ 132.820302] [<ffffffff81297871>] keyring_search_aux+0xe1/0x14c
[ 132.820302] [<ffffffff812977fc>] ? keyring_search_aux+0x6c/0x14c
[ 132.820302] [<ffffffff8129796b>] keyring_search+0x8f/0xb6
[ 132.820302] [<ffffffff812bfc84>] ? asymmetric_match_key_ids+0x42/0x42
[ 132.820302] [<ffffffff81297165>] ? key_default_cmp+0x20/0x20
[ 132.820302] [<ffffffff812ab9e3>] asymmetric_verify+0xa4/0x214
[ 132.820302] [<ffffffff812ab90e>] integrity_digsig_verify+0xb1/0xe2
[ 132.820302] [<ffffffff812abe41>] ? evm_verifyxattr+0x6a/0x7a
[ 132.820302] [<ffffffff812b0390>] ima_appraise_measurement+0x160/0x370
[ 132.820302] [<ffffffff81161db2>] ? d_absolute_path+0x5b/0x7a
[ 132.820302] [<ffffffff812ada30>] process_measurement+0x322/0x404

Reported-by: Dmitry Kasatkin <d.kasatkin@samsung.com>
Signed-off-by: Dmitry Kasatkin <d.kasatkin@samsung.com>
Signed-off-by: David Howells <dhowells@redhat.com>

KEYS: Check hex2bin()'s return when generating an asymmetric key ID

As it stands, the code to generate an asymmetric key ID prechecks the hex
string it is given whilst determining the length, before it allocates the
buffer for hex2bin() to translate into - which mean that checking the result of
hex2bin() is redundant.

Unfortunately, hex2bin() is marked as __must_check, which means that the
following warning may be generated if the return value isn't checked:

crypto/asymmetric_keys/asymmetric_type.c: In function
asymmetric_key_hex_to_key_id:
crypto/asymmetric_keys/asymmetric_type.c:110: warning: ignoring return
value of hex2bin, declared with attribute warn_unused_result

The warning can't be avoided by casting the result to void.

Instead, use strlen() to check the length of the string and ignore the fact
that the string might not be entirely valid hex until after the allocation has
been done - in which case we can use the result of hex2bin() for this.

Signed-off-by: David Howells <dhowells@redhat.com>

KEYS: Overhaul key identification when searching for asymmetric keys

Make use of the new match string preparsing to overhaul key identification
when searching for asymmetric keys. The following changes are made:

(1) Use the previously created asymmetric_key_id struct to hold the following
key IDs derived from the X.509 certificate or PKCS#7 message:

id: serial number + issuer
skid: subjKeyId + subject
authority: authKeyId + issuer

(2) Replace the hex fingerprint attached to key->type_data[1] with an
asymmetric_key_ids struct containing the id and the skid (if present).

(3) Make the asymmetric_type match data preparse select one of two searches:

(a) An iterative search for the key ID given if prefixed with "id:". The
prefix is expected to be followed by a hex string giving the ID to
search for. The criterion key ID is checked against all key IDs
recorded on the key.

(b) A direct search if the key ID is not prefixed with "id:". This will
look for an exact match on the key description.

(4) Make x509_request_asymmetric_key() take a key ID. This is then converted
into "id:<hex>" and passed into keyring_search() where match preparsing
will turn it back into a binary ID.

(5) X.509 certificate verification then takes the authority key ID and looks
up a key that matches it to find the public key for the certificate
signature.

(6) PKCS#7 certificate verification then takes the id key ID and looks up a
key that matches it to find the public key for the signed information
block signature.

Additional changes:

(1) Multiple subjKeyId and authKeyId values on an X.509 certificate cause the
cert to be rejected with -EBADMSG.

(2) The 'fingerprint' ID is gone. This was primarily intended to convey PGP
public key fingerprints. If PGP is supported in future, this should
generate a key ID that carries the fingerprint.

(3) Th ca_keyid= kernel command line option is now converted to a key ID and
used to match the authority key ID. Possibly this should only match the
actual authKeyId part and not the issuer as well.

Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>

KEYS: Implement binary asymmetric key ID handling

Implement the first step in using binary key IDs for asymmetric keys rather
than hex string keys.

The previously added match data preparsing will be able to convert hex
criterion strings into binary which can then be compared more rapidly.

Further, we actually want more then one ID string per public key. The problem
is that X.509 certs refer to other X.509 certs by matching Issuer + AuthKeyId
to Subject + SubjKeyId, but PKCS#7 messages match against X.509 Issuer +
SerialNumber.

This patch just provides facilities for a later patch to make use of.

Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>

KEYS: Make the key matching functions return bool

Make the key matching functions pointed to by key_match_data::cmp return bool
rather than int.

Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>

KEYS: Remove key_type::match in favour of overriding default by match_preparse

A previous patch added a ->match_preparse() method to the key type. This is
allowed to override the function called by the iteration algorithm.
Therefore, we can just set a default that simply checks for an exact match of
the key description with the original criterion data and allow match_preparse
to override it as needed.

The key_type::match op is then redundant and can be removed, as can the
user_match() function.

Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>

KEYS: Remove key_type::def_lookup_type

Remove key_type::def_lookup_type as it's no longer used. The information now
defaults to KEYRING_SEARCH_LOOKUP_DIRECT but may be overridden by
type->match_preparse().

Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>

KEYS: Preparse match data

Preparse the match data. This provides several advantages:

(1) The preparser can reject invalid criteria up front.

(2) The preparser can convert the criteria to binary data if necessary (the
asymmetric key type really wants to do binary comparison of the key IDs).

(3) The preparser can set the type of search to be performed. This means
that it's not then a one-off setting in the key type.

(4) The preparser can set an appropriate comparator function.

Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>

KEYS: struct key_preparsed_payload should have two payload pointers

struct key_preparsed_payload should have two payload pointers to correspond
with those in struct key.

Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Steve Dickson <steved@redhat.com>
Acked-by: Jeff Layton <jlayton@primarydata.com>
Reviewed-by: Sage Weil <sage@redhat.com>

KEYS: Provide a generic instantiation function

Provide a generic instantiation function for key types that use the preparse
hook. This makes it easier to prereserve key quota before keyrings get locked
to retain the new key.

Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Steve Dickson <steved@redhat.com>
Acked-by: Jeff Layton <jlayton@primarydata.com>
Reviewed-by: Sage Weil <sage@redhat.com>

KEYS: validate certificate trust only with selected key

Instead of allowing public keys, with certificates signed by any
key on the system trusted keyring, to be added to a trusted keyring,
this patch further restricts the certificates to those signed by a
particular key on the system keyring.

This patch defines a new kernel parameter 'ca_keys' to identify the
specific key which must be used for trust validation of certificates.

Simplified Mimi's "KEYS: define an owner trusted keyring" patch.

Changelog:
- support for builtin x509 public keys only
- export "asymmetric_keyid_match"
- remove ifndefs MODULE
- rename kernel boot parameter from keys_ownerid to ca_keys

Signed-off-by: Dmitry Kasatkin <d.kasatkin@samsung.com>
Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>

KEYS: make partial key id matching as a dedicated function

To avoid code duplication this patch refactors asymmetric_key_match(),
making partial ID string match a separate function.

This patch also implicitly fixes a bug in the code. asymmetric_key_match()
allows to match the key by its subtype. But subtype matching could be
undone if asymmetric_key_id(key) would return NULL. This patch first
checks for matching spec and then for its value.

Signed-off-by: Dmitry Kasatkin <d.kasatkin@samsung.com>
Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>

KEYS: Set the asymmetric-key type default search method

The keyring expansion patches introduces a new search method by which
key_search() attempts to walk directly to the key that has exactly the same
description as the requested one.

However, this causes inexact matching of asymmetric keys to fail. The
solution to this is to select iterative rather than direct search as the
default search type for asymmetric keys.

As an example, the kernel might have a key like this:

Magrathea: Glacier signing key: 6a2a0f82bad7e396665f465e4e3e1f9bd24b1226

and:

keyctl search <keyring-ID> asymmetric id:d24b1226

should find the key, despite that not being its exact description.

Signed-off-by: David Howells <dhowells@redhat.com>

KEYS: Asymmetric key pluggable data parsers

The instantiation data passed to the asymmetric key type are expected to be
formatted in some way, and there are several possible standard ways to format
the data.

The two obvious standards are OpenPGP keys and X.509 certificates. The latter
is especially useful when dealing with UEFI, and the former might be useful
when dealing with, say, eCryptfs.

Further, it might be desirable to provide formatted blobs that indicate
hardware is to be accessed to retrieve the keys or that the keys live
unretrievably in a hardware store, but that the keys can be used by means of
the hardware.

From userspace, the keys can be loaded using the keyctl command, for example,
an X.509 binary certificate:

keyctl padd asymmetric foo @s <dhowells.pem

or a PGP key:

keyctl padd asymmetric bar @s <dhowells.pub

or a pointer into the contents of the TPM:

keyctl add asymmetric zebra "TPM:04982390582905f8" @s

Inside the kernel, pluggable parsers register themselves and then get to
examine the payload data to see if they can handle it. If they can, they get
to:

(1) Propose a name for the key, to be used it the name is "" or NULL.

(2) Specify the key subtype.

(3) Provide the data for the subtype.

The key type asks the parser to do its stuff before a key is allocated and thus
before the name is set. If successful, the parser stores the suggested data
into the key_preparsed_payload struct, which will be either used (if the key is
successfully created and instantiated or updated) or discarded.

Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

KEYS: Implement asymmetric key type

Create a key type that can be used to represent an asymmetric key type for use
in appropriate cryptographic operations, such as encryption, decryption,
signature generation and signature verification.

The key type is "asymmetric" and can provide access to a variety of
cryptographic algorithms.

Possibly, this would be better as "public_key" - but that has the disadvantage
that "public key" is an overloaded term.

Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>