KEYS: Drop the permissions argument from __keyring_search_one()

Drop the permissions argument from __keyring_search_one() as the only caller
passes 0 here - which causes all checks to be skipped.

Signed-off-by: David Howells <dhowells@redhat.com>
Add a generic associative array implementation.

Add a generic associative array implementation that can be used as the
container for keyrings, thereby massively increasing the capacity available
whilst also speeding up searching in keyrings that contain a lot of keys.

This may also be useful in FS-Cache for tracking cookies.

Documentation is added into Documentation/associative_array.txt

Some of the properties of the implementation are:

 (1) Objects are opaque pointers.  The implementation does not care where they
     point (if anywhere) or what they point to (if anything).

     [!] NOTE: Pointers to objects _must_ be zero in the two least significant
     	       bits.

 (2) Objects do not need to contain linkage blocks for use by the array.  This
     permits an object to be located in multiple arrays simultaneously.
     Rather, the array is made up of metadata blocks that point to objects.

 (3) Objects are labelled as being one of two types (the type is a bool value).
     This information is stored in the array, but has no consequence to the
     array itself or its algorithms.

 (4) Objects require index keys to locate them within the array.

 (5) Index keys must be unique.  Inserting an object with the same key as one
     already in the array will replace the old object.

 (6) Index keys can be of any length and can be of different lengths.

 (7) Index keys should encode the length early on, before any variation due to
     length is seen.

 (8) Index keys can include a hash to scatter objects throughout the array.

 (9) The array can iterated over.  The objects will not necessarily come out in
     key order.

(10) The array can be iterated whilst it is being modified, provided the RCU
     readlock is being held by the iterator.  Note, however, under these
     circumstances, some objects may be seen more than once.  If this is a
     problem, the iterator should lock against modification.  Objects will not
     be missed, however, unless deleted.

(11) Objects in the array can be looked up by means of their index key.

(12) Objects can be looked up whilst the array is being modified, provided the
     RCU readlock is being held by the thread doing the look up.

The implementation uses a tree of 16-pointer nodes internally that are indexed
on each level by nibbles from the index key.  To improve memory efficiency,
shortcuts can be emplaced to skip over what would otherwise be a series of
single-occupancy nodes.  Further, nodes pack leaf object pointers into spare
space in the node rather than making an extra branch until as such time an
object needs to be added to a full node.

Signed-off-by: David Howells <dhowells@redhat.com>
KEYS: Expand the capacity of a keyring

Expand the capacity of a keyring to be able to hold a lot more keys by using
the previously added associative array implementation.  Currently the maximum
capacity is:

	(PAGE_SIZE - sizeof(header)) / sizeof(struct key *)

which, on a 64-bit system, is a little more 500.  However, since this is being
used for the NFS uid mapper, we need more than that.  The new implementation
gives us effectively unlimited capacity.

With some alterations, the keyutils testsuite runs successfully to completion
after this patch is applied.  The alterations are because (a) keyrings that
are simply added to no longer appear ordered and (b) some of the errors have
changed a bit.

Signed-off-by: David Howells <dhowells@redhat.com>
KEYS: Implement a big key type that can save to tmpfs

Implement a big key type that can save its contents to tmpfs and thus
swapspace when memory is tight.  This is useful for Kerberos ticket caches.

Signed-off-by: David Howells <dhowells@redhat.com>
Tested-by: Simo Sorce <simo@redhat.com>
KEYS: Add per-user_namespace registers for persistent per-UID kerberos caches

Add support for per-user_namespace registers of persistent per-UID kerberos
caches held within the kernel.

This allows the kerberos cache to be retained beyond the life of all a user's
processes so that the user's cron jobs can work.

The kerberos cache is envisioned as a keyring/key tree looking something like:

	struct user_namespace
	  \___ .krb_cache keyring		- The register
		\___ _krb.0 keyring		- Root's Kerberos cache
		\___ _krb.5000 keyring		- User 5000's Kerberos cache
		\___ _krb.5001 keyring		- User 5001's Kerberos cache
			\___ tkt785 big_key	- A ccache blob
			\___ tkt12345 big_key	- Another ccache blob

Or possibly:

	struct user_namespace
	  \___ .krb_cache keyring		- The register
		\___ _krb.0 keyring		- Root's Kerberos cache
		\___ _krb.5000 keyring		- User 5000's Kerberos cache
		\___ _krb.5001 keyring		- User 5001's Kerberos cache
			\___ tkt785 keyring	- A ccache
				\___ krbtgt/REDHAT.COM@REDHAT.COM big_key
				\___ http/REDHAT.COM@REDHAT.COM user
				\___ afs/REDHAT.COM@REDHAT.COM user
				\___ nfs/REDHAT.COM@REDHAT.COM user
				\___ krbtgt/KERNEL.ORG@KERNEL.ORG big_key
				\___ http/KERNEL.ORG@KERNEL.ORG big_key

What goes into a particular Kerberos cache is entirely up to userspace.  Kernel
support is limited to giving you the Kerberos cache keyring that you want.

The user asks for their Kerberos cache by:

	krb_cache = keyctl_get_krbcache(uid, dest_keyring);

The uid is -1 or the user's own UID for the user's own cache or the uid of some
other user's cache (requires CAP_SETUID).  This permits rpc.gssd or whatever to
mess with the cache.

The cache returned is a keyring named "_krb.<uid>" that the possessor can read,
search, clear, invalidate, unlink from and add links to.  Active LSMs get a
chance to rule on whether the caller is permitted to make a link.

Each uid's cache keyring is created when it first accessed and is given a
timeout that is extended each time this function is called so that the keyring
goes away after a while.  The timeout is configurable by sysctl but defaults to
three days.

Each user_namespace struct gets a lazily-created keyring that serves as the
register.  The cache keyrings are added to it.  This means that standard key
search and garbage collection facilities are available.

The user_namespace struct's register goes away when it does and anything left
in it is then automatically gc'd.

Signed-off-by: David Howells <dhowells@redhat.com>
Tested-by: Simo Sorce <simo@redhat.com>
cc: Serge E. Hallyn <serge.hallyn@ubuntu.com>
cc: Eric W. Biederman <ebiederm@xmission.com>
KEYS: Rename public key parameter name arrays

Rename the arrays of public key parameters (public key algorithm names, hash
algorithm names and ID type names) so that the array name ends in "_name".

Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Josh Boyer <jwboyer@redhat.com>
KEYS: Move the algorithm pointer array from x509 to public_key.c

Move the public-key algorithm pointer array from x509_public_key.c to
public_key.c as it isn't X.509 specific.

Note that to make this configure correctly, the public key part must be
dependent on the RSA module rather than the other way round.  This needs a
further patch to make use of the crypto module loading stuff rather than using
a fixed table.

Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Josh Boyer <jwboyer@redhat.com>
KEYS: Store public key algo ID in public_key struct

Store public key algo ID in public_key struct for reference purposes.  This
allows it to be removed from the x509_certificate struct and used to find a
default in public_key_verify_signature().

Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Josh Boyer <jwboyer@redhat.com>
KEYS: Split public_key_verify_signature() and make available

Modify public_key_verify_signature() so that it now takes a public_key struct
rather than a key struct and supply a wrapper that takes a key struct.  The
wrapper is then used by the asymmetric key subtype and the modified function is
used by X.509 self-signature checking and can be used by other things also.

Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Josh Boyer <jwboyer@redhat.com>
KEYS: Store public key algo ID in public_key_signature struct

Store public key algorithm ID in public_key_signature struct for reference
purposes.  This allows a public_key_signature struct to be embedded in
struct x509_certificate and other places more easily.

Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Josh Boyer <jwboyer@redhat.com>
X.509: struct x509_certificate needs struct tm declaring

struct x509_certificate needs struct tm declaring by #inclusion of linux/time.h
prior to its definition.

Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Josh Boyer <jwboyer@redhat.com>
X.509: Embed public_key_signature struct and create filler function

Embed a public_key_signature struct in struct x509_certificate, eliminating
now unnecessary fields, and split x509_check_signature() to create a filler
function for it that attaches a digest of the signed data and an MPI that
represents the signature data.  x509_free_certificate() is then modified to
deal with these.

Whilst we're at it, export both x509_check_signature() and the new
x509_get_sig_params().

Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Josh Boyer <jwboyer@redhat.com>
X.509: Check the algorithm IDs obtained from parsing an X.509 certificate

Check that the algorithm IDs obtained from the ASN.1 parse by OID lookup
corresponds to algorithms that are available to us.

Reported-by: Kees Cook <keescook@chromium.org>
Signed-off-by: David Howells <dhowells@redhat.com>
X.509: Handle certificates that lack an authorityKeyIdentifier field

Handle certificates that lack an authorityKeyIdentifier field by assuming
they're self-signed and checking their signatures against themselves.

Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Josh Boyer <jwboyer@redhat.com>
X.509: Remove certificate date checks

Remove the certificate date checks that are performed when a certificate is
parsed.  There are two checks: a valid from and a valid to.  The first check is
causing a lot of problems with system clocks that don't keep good time and the
second places an implicit expiry date upon the kernel when used for module
signing, so do we really need them?

Signed-off-by: David Howells <dhowells@redhat.com>
cc: David Woodhouse <dwmw2@infradead.org>
cc: Rusty Russell <rusty@rustcorp.com.au>
cc: Josh Boyer <jwboyer@redhat.com>
cc: Alexander Holler <holler@ahsoftware.de>
cc: stable@vger.kernel.org
KEYS: Load *.x509 files into kernel keyring

Load all the files matching the pattern "*.x509" that are to be found in kernel
base source dir and base build dir into the module signing keyring.

The "extra_certificates" file is then redundant.

Signed-off-by: David Howells <dhowells@redhat.com>
KEYS: Have make canonicalise the paths of the X.509 certs better to deduplicate

Have make canonicalise the paths of the X.509 certificates before we sort them
as this allows $(sort) to better remove duplicates.

Signed-off-by: David Howells <dhowells@redhat.com>
KEYS: Separate the kernel signature checking keyring from module signing

Separate the kernel signature checking keyring from module signing so that it
can be used by code other than the module-signing code.

Signed-off-by: David Howells <dhowells@redhat.com>
KEYS: Add a 'trusted' flag and a 'trusted only' flag

Add KEY_FLAG_TRUSTED to indicate that a key either comes from a trusted source
or had a cryptographic signature chain that led back to a trusted key the
kernel already possessed.

Add KEY_FLAGS_TRUSTED_ONLY to indicate that a keyring will only accept links to
keys marked with KEY_FLAGS_TRUSTED.

Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
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>