linux-stable.git/Documentation/security/keys.txt, branch linux-4.2.y

KEYS: Make /proc/keys unconditional if CONFIG_KEYS=y

2015-01-22T22:34:32+00:00

Now that /proc/keys is used by libkeyutils to look up a key by type and
description, we should make it unconditional and remove
CONFIG_DEBUG_PROC_KEYS.

Reported-by: Jiri Kosina 
Signed-off-by: David Howells 
Tested-by: Jiri Kosina

KEYS: Update the keyrings documentation for match changes

2014-09-16T16:36:09+00:00

Signed-off-by: David Howells 
Acked-by: Vivek Goyal

KEYS: Call ->free_preparse() even after ->preparse() returns an error

2014-07-22T20:46:12+00:00

Call the ->free_preparse() key type op even after ->preparse() returns an
error as it does cleaning up type stuff.

Signed-off-by: David Howells 
Acked-by: Steve Dickson 
Acked-by: Jeff Layton 
Reviewed-by: Sage Weil

KEYS: Allow expiry time to be set when preparsing a key

2014-07-22T20:46:08+00:00

Allow a key type's preparsing routine to set the expiry time for a key.

Signed-off-by: David Howells 
Acked-by: Steve Dickson 
Acked-by: Jeff Layton 
Reviewed-by: Sage Weil

KEYS: Define a __key_get() wrapper to use rather than atomic_inc()

2013-09-24T09:35:16+00:00

Define a __key_get() wrapper to use rather than atomic_inc() on the key usage
count as this makes it easier to hook in refcount error debugging.

Signed-off-by: David Howells

KEYS: Use bool in make_key_ref() and is_key_possessed()

2013-09-24T09:35:14+00:00

Make make_key_ref() take a bool possession parameter and make
is_key_possessed() return a bool.

Signed-off-by: David Howells

Merge branch 'modsign-keys-devel' into security-next-keys

2012-10-02T18:30:19+00:00

Signed-off-by: David Howells

KEYS: Use keyring_alloc() to create special keyrings

2012-10-02T18:24:56+00:00

Use keyring_alloc() to create special keyrings now that it has a permissions
parameter rather than using key_alloc() + key_instantiate_and_link().

Also document and export keyring_alloc() so that modules can use it too.

Signed-off-by: David Howells

KEYS: Add payload preparsing opportunity prior to key instantiate or update

2012-09-13T12:06:29+00:00

Give the key type the opportunity to preparse the payload prior to the
instantiation and update routines being called.  This is done with the
provision of two new key type operations:

	int (*preparse)(struct key_preparsed_payload *prep);
	void (*free_preparse)(struct key_preparsed_payload *prep);

If the first operation is present, then it is called before key creation (in
the add/update case) or before the key semaphore is taken (in the update and
instantiate cases).  The second operation is called to clean up if the first
was called.

preparse() is given the opportunity to fill in the following structure:

	struct key_preparsed_payload {
		char		*description;
		void		*type_data[2];
		void		*payload;
		const void	*data;
		size_t		datalen;
		size_t		quotalen;
	};

Before the preparser is called, the first three fields will have been cleared,
the payload pointer and size will be stored in data and datalen and the default
quota size from the key_type struct will be stored into quotalen.

The preparser may parse the payload in any way it likes and may store data in
the type_data[] and payload fields for use by the instantiate() and update()
ops.

The preparser may also propose a description for the key by attaching it as a
string to the description field.  This can be used by passing a NULL or ""
description to the add_key() system call or the key_create_or_update()
function.  This cannot work with request_key() as that required the description
to tell the upcall about the key to be created.

This, for example permits keys that store PGP public keys to generate their own
name from the user ID and public key fingerprint in the key.

The instantiate() and update() operations are then modified to look like this:

	int (*instantiate)(struct key *key, struct key_preparsed_payload *prep);
	int (*update)(struct key *key, struct key_preparsed_payload *prep);

and the new payload data is passed in *prep, whether or not it was preparsed.

Signed-off-by: David Howells

KEYS: Add invalidation support

2012-05-11T09:56:56+00:00

Add support for invalidating a key - which renders it immediately invisible to
further searches and causes the garbage collector to immediately wake up,
remove it from keyrings and then destroy it when it's no longer referenced.

It's better not to do this with keyctl_revoke() as that marks the key to start
returning -EKEYREVOKED to searches when what is actually desired is to have the
key refetched.

To invalidate a key the caller must be granted SEARCH permission by the key.
This may be too strict.  It may be better to also permit invalidation if the
caller has any of READ, WRITE or SETATTR permission.

The primary use for this is to evict keys that are cached in special keyrings,
such as the DNS resolver or an ID mapper.

Signed-off-by: David Howells