| 
									
										
										
										
											2007-10-16 23:29:46 -07:00
										 |  |  | /* Request a key from userspace
 | 
					
						
							| 
									
										
										
										
											2005-04-16 15:20:36 -07:00
										 |  |  |  * | 
					
						
							| 
									
										
										
										
											2007-10-16 23:29:46 -07:00
										 |  |  |  * Copyright (C) 2004-2007 Red Hat, Inc. All Rights Reserved. | 
					
						
							| 
									
										
										
										
											2005-04-16 15:20:36 -07:00
										 |  |  |  * Written by David Howells (dhowells@redhat.com) | 
					
						
							|  |  |  |  * | 
					
						
							|  |  |  |  * This program is free software; you can redistribute it and/or | 
					
						
							|  |  |  |  * modify it under the terms of the GNU General Public License | 
					
						
							|  |  |  |  * as published by the Free Software Foundation; either version | 
					
						
							|  |  |  |  * 2 of the License, or (at your option) any later version. | 
					
						
							| 
									
										
										
										
											2005-10-07 15:04:52 +01:00
										 |  |  |  * | 
					
						
							|  |  |  |  * See Documentation/keys-request-key.txt | 
					
						
							| 
									
										
										
										
											2005-04-16 15:20:36 -07:00
										 |  |  |  */ | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | #include <linux/module.h>
 | 
					
						
							|  |  |  | #include <linux/sched.h>
 | 
					
						
							|  |  |  | #include <linux/kmod.h>
 | 
					
						
							|  |  |  | #include <linux/err.h>
 | 
					
						
							| 
									
										
											  
											
												[PATCH] Keys: Make request-key create an authorisation key
The attached patch makes the following changes:
 (1) There's a new special key type called ".request_key_auth".
     This is an authorisation key for when one process requests a key and
     another process is started to construct it. This type of key cannot be
     created by the user; nor can it be requested by kernel services.
     Authorisation keys hold two references:
     (a) Each refers to a key being constructed. When the key being
     	 constructed is instantiated the authorisation key is revoked,
     	 rendering it of no further use.
     (b) The "authorising process". This is either:
     	 (i) the process that called request_key(), or:
     	 (ii) if the process that called request_key() itself had an
     	      authorisation key in its session keyring, then the authorising
     	      process referred to by that authorisation key will also be
     	      referred to by the new authorisation key.
	 This means that the process that initiated a chain of key requests
	 will authorise the lot of them, and will, by default, wind up with
	 the keys obtained from them in its keyrings.
 (2) request_key() creates an authorisation key which is then passed to
     /sbin/request-key in as part of a new session keyring.
 (3) When request_key() is searching for a key to hand back to the caller, if
     it comes across an authorisation key in the session keyring of the
     calling process, it will also search the keyrings of the process
     specified therein and it will use the specified process's credentials
     (fsuid, fsgid, groups) to do that rather than the calling process's
     credentials.
     This allows a process started by /sbin/request-key to find keys belonging
     to the authorising process.
 (4) A key can be read, even if the process executing KEYCTL_READ doesn't have
     direct read or search permission if that key is contained within the
     keyrings of a process specified by an authorisation key found within the
     calling process's session keyring, and is searchable using the
     credentials of the authorising process.
     This allows a process started by /sbin/request-key to read keys belonging
     to the authorising process.
 (5) The magic KEY_SPEC_*_KEYRING key IDs when passed to KEYCTL_INSTANTIATE or
     KEYCTL_NEGATE will specify a keyring of the authorising process, rather
     than the process doing the instantiation.
 (6) One of the process keyrings can be nominated as the default to which
     request_key() should attach new keys if not otherwise specified. This is
     done with KEYCTL_SET_REQKEY_KEYRING and one of the KEY_REQKEY_DEFL_*
     constants. The current setting can also be read using this call.
 (7) request_key() is partially interruptible. If it is waiting for another
     process to finish constructing a key, it can be interrupted. This permits
     a request-key cycle to be broken without recourse to rebooting.
Signed-Off-By: David Howells <dhowells@redhat.com>
Signed-Off-By: Benoit Boissinot <benoit.boissinot@ens-lyon.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
											
										 
											2005-06-23 22:00:56 -07:00
										 |  |  | #include <linux/keyctl.h>
 | 
					
						
							| 
									
										
										
										
											2008-04-29 01:01:32 -07:00
										 |  |  | #include <linux/slab.h>
 | 
					
						
							| 
									
										
										
										
											2005-04-16 15:20:36 -07:00
										 |  |  | #include "internal.h"
 | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2008-11-14 10:39:13 +11:00
										 |  |  | #define key_negative_timeout	60	/* default timeout on a negative key's existence */
 | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2007-10-16 23:29:46 -07:00
										 |  |  | /*
 | 
					
						
							|  |  |  |  * wait_on_bit() sleep function for uninterruptible waiting | 
					
						
							|  |  |  |  */ | 
					
						
							|  |  |  | static int key_wait_bit(void *flags) | 
					
						
							|  |  |  | { | 
					
						
							|  |  |  | 	schedule(); | 
					
						
							|  |  |  | 	return 0; | 
					
						
							|  |  |  | } | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | /*
 | 
					
						
							|  |  |  |  * wait_on_bit() sleep function for interruptible waiting | 
					
						
							|  |  |  |  */ | 
					
						
							|  |  |  | static int key_wait_bit_intr(void *flags) | 
					
						
							|  |  |  | { | 
					
						
							|  |  |  | 	schedule(); | 
					
						
							|  |  |  | 	return signal_pending(current) ? -ERESTARTSYS : 0; | 
					
						
							|  |  |  | } | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | /*
 | 
					
						
							|  |  |  |  * call to complete the construction of a key | 
					
						
							|  |  |  |  */ | 
					
						
							|  |  |  | void complete_request_key(struct key_construction *cons, int error) | 
					
						
							|  |  |  | { | 
					
						
							|  |  |  | 	kenter("{%d,%d},%d", cons->key->serial, cons->authkey->serial, error); | 
					
						
							| 
									
										
										
										
											2005-04-16 15:20:36 -07:00
										 |  |  | 
 | 
					
						
							| 
									
										
										
										
											2007-10-16 23:29:46 -07:00
										 |  |  | 	if (error < 0) | 
					
						
							|  |  |  | 		key_negate_and_link(cons->key, key_negative_timeout, NULL, | 
					
						
							|  |  |  | 				    cons->authkey); | 
					
						
							|  |  |  | 	else | 
					
						
							|  |  |  | 		key_revoke(cons->authkey); | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | 	key_put(cons->key); | 
					
						
							|  |  |  | 	key_put(cons->authkey); | 
					
						
							|  |  |  | 	kfree(cons); | 
					
						
							|  |  |  | } | 
					
						
							|  |  |  | EXPORT_SYMBOL(complete_request_key); | 
					
						
							| 
									
										
										
										
											2005-04-16 15:20:36 -07:00
										 |  |  | 
 | 
					
						
							|  |  |  | /*
 | 
					
						
							|  |  |  |  * request userspace finish the construction of a key | 
					
						
							| 
									
										
										
										
											2006-01-08 01:02:47 -08:00
										 |  |  |  * - execute "/sbin/request-key <op> <key> <uid> <gid> <keyring> <keyring> <keyring>" | 
					
						
							| 
									
										
										
										
											2005-04-16 15:20:36 -07:00
										 |  |  |  */ | 
					
						
							| 
									
										
										
										
											2007-10-16 23:29:46 -07:00
										 |  |  | static int call_sbin_request_key(struct key_construction *cons, | 
					
						
							| 
									
										
										
										
											2006-06-29 02:24:28 -07:00
										 |  |  | 				 const char *op, | 
					
						
							|  |  |  | 				 void *aux) | 
					
						
							| 
									
										
										
										
											2005-04-16 15:20:36 -07:00
										 |  |  | { | 
					
						
							| 
									
										
										
										
											2008-11-14 10:39:18 +11:00
										 |  |  | 	const struct cred *cred = current_cred(); | 
					
						
							| 
									
										
										
										
											2005-04-16 15:20:36 -07:00
										 |  |  | 	key_serial_t prkey, sskey; | 
					
						
							| 
									
										
										
										
											2010-04-23 13:18:00 -04:00
										 |  |  | 	struct key *key = cons->key, *authkey = cons->authkey, *keyring, | 
					
						
							|  |  |  | 		*session; | 
					
						
							| 
									
										
										
										
											2006-01-08 01:02:47 -08:00
										 |  |  | 	char *argv[9], *envp[3], uid_str[12], gid_str[12]; | 
					
						
							| 
									
										
										
										
											2005-04-16 15:20:36 -07:00
										 |  |  | 	char key_str[12], keyring_str[3][12]; | 
					
						
							| 
									
										
										
										
											2006-01-08 01:02:47 -08:00
										 |  |  | 	char desc[20]; | 
					
						
							| 
									
										
											  
											
												[PATCH] Keys: Make request-key create an authorisation key
The attached patch makes the following changes:
 (1) There's a new special key type called ".request_key_auth".
     This is an authorisation key for when one process requests a key and
     another process is started to construct it. This type of key cannot be
     created by the user; nor can it be requested by kernel services.
     Authorisation keys hold two references:
     (a) Each refers to a key being constructed. When the key being
     	 constructed is instantiated the authorisation key is revoked,
     	 rendering it of no further use.
     (b) The "authorising process". This is either:
     	 (i) the process that called request_key(), or:
     	 (ii) if the process that called request_key() itself had an
     	      authorisation key in its session keyring, then the authorising
     	      process referred to by that authorisation key will also be
     	      referred to by the new authorisation key.
	 This means that the process that initiated a chain of key requests
	 will authorise the lot of them, and will, by default, wind up with
	 the keys obtained from them in its keyrings.
 (2) request_key() creates an authorisation key which is then passed to
     /sbin/request-key in as part of a new session keyring.
 (3) When request_key() is searching for a key to hand back to the caller, if
     it comes across an authorisation key in the session keyring of the
     calling process, it will also search the keyrings of the process
     specified therein and it will use the specified process's credentials
     (fsuid, fsgid, groups) to do that rather than the calling process's
     credentials.
     This allows a process started by /sbin/request-key to find keys belonging
     to the authorising process.
 (4) A key can be read, even if the process executing KEYCTL_READ doesn't have
     direct read or search permission if that key is contained within the
     keyrings of a process specified by an authorisation key found within the
     calling process's session keyring, and is searchable using the
     credentials of the authorising process.
     This allows a process started by /sbin/request-key to read keys belonging
     to the authorising process.
 (5) The magic KEY_SPEC_*_KEYRING key IDs when passed to KEYCTL_INSTANTIATE or
     KEYCTL_NEGATE will specify a keyring of the authorising process, rather
     than the process doing the instantiation.
 (6) One of the process keyrings can be nominated as the default to which
     request_key() should attach new keys if not otherwise specified. This is
     done with KEYCTL_SET_REQKEY_KEYRING and one of the KEY_REQKEY_DEFL_*
     constants. The current setting can also be read using this call.
 (7) request_key() is partially interruptible. If it is waiting for another
     process to finish constructing a key, it can be interrupted. This permits
     a request-key cycle to be broken without recourse to rebooting.
Signed-Off-By: David Howells <dhowells@redhat.com>
Signed-Off-By: Benoit Boissinot <benoit.boissinot@ens-lyon.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
											
										 
											2005-06-23 22:00:56 -07:00
										 |  |  | 	int ret, i; | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2006-01-08 01:02:47 -08:00
										 |  |  | 	kenter("{%d},{%d},%s", key->serial, authkey->serial, op); | 
					
						
							| 
									
										
											  
											
												[PATCH] Keys: Make request-key create an authorisation key
The attached patch makes the following changes:
 (1) There's a new special key type called ".request_key_auth".
     This is an authorisation key for when one process requests a key and
     another process is started to construct it. This type of key cannot be
     created by the user; nor can it be requested by kernel services.
     Authorisation keys hold two references:
     (a) Each refers to a key being constructed. When the key being
     	 constructed is instantiated the authorisation key is revoked,
     	 rendering it of no further use.
     (b) The "authorising process". This is either:
     	 (i) the process that called request_key(), or:
     	 (ii) if the process that called request_key() itself had an
     	      authorisation key in its session keyring, then the authorising
     	      process referred to by that authorisation key will also be
     	      referred to by the new authorisation key.
	 This means that the process that initiated a chain of key requests
	 will authorise the lot of them, and will, by default, wind up with
	 the keys obtained from them in its keyrings.
 (2) request_key() creates an authorisation key which is then passed to
     /sbin/request-key in as part of a new session keyring.
 (3) When request_key() is searching for a key to hand back to the caller, if
     it comes across an authorisation key in the session keyring of the
     calling process, it will also search the keyrings of the process
     specified therein and it will use the specified process's credentials
     (fsuid, fsgid, groups) to do that rather than the calling process's
     credentials.
     This allows a process started by /sbin/request-key to find keys belonging
     to the authorising process.
 (4) A key can be read, even if the process executing KEYCTL_READ doesn't have
     direct read or search permission if that key is contained within the
     keyrings of a process specified by an authorisation key found within the
     calling process's session keyring, and is searchable using the
     credentials of the authorising process.
     This allows a process started by /sbin/request-key to read keys belonging
     to the authorising process.
 (5) The magic KEY_SPEC_*_KEYRING key IDs when passed to KEYCTL_INSTANTIATE or
     KEYCTL_NEGATE will specify a keyring of the authorising process, rather
     than the process doing the instantiation.
 (6) One of the process keyrings can be nominated as the default to which
     request_key() should attach new keys if not otherwise specified. This is
     done with KEYCTL_SET_REQKEY_KEYRING and one of the KEY_REQKEY_DEFL_*
     constants. The current setting can also be read using this call.
 (7) request_key() is partially interruptible. If it is waiting for another
     process to finish constructing a key, it can be interrupted. This permits
     a request-key cycle to be broken without recourse to rebooting.
Signed-Off-By: David Howells <dhowells@redhat.com>
Signed-Off-By: Benoit Boissinot <benoit.boissinot@ens-lyon.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
											
										 
											2005-06-23 22:00:56 -07:00
										 |  |  | 
 | 
					
						
							| 
									
										
											  
											
												KEYS: Alter use of key instantiation link-to-keyring argument
Alter the use of the key instantiation and negation functions' link-to-keyring
arguments.  Currently this specifies a keyring in the target process to link
the key into, creating the keyring if it doesn't exist.  This, however, can be
a problem for copy-on-write credentials as it means that the instantiating
process can alter the credentials of the requesting process.
This patch alters the behaviour such that:
 (1) If keyctl_instantiate_key() or keyctl_negate_key() are given a specific
     keyring by ID (ringid >= 0), then that keyring will be used.
 (2) If keyctl_instantiate_key() or keyctl_negate_key() are given one of the
     special constants that refer to the requesting process's keyrings
     (KEY_SPEC_*_KEYRING, all <= 0), then:
     (a) If sys_request_key() was given a keyring to use (destringid) then the
     	 key will be attached to that keyring.
     (b) If sys_request_key() was given a NULL keyring, then the key being
     	 instantiated will be attached to the default keyring as set by
     	 keyctl_set_reqkey_keyring().
 (3) No extra link will be made.
Decision point (1) follows current behaviour, and allows those instantiators
who've searched for a specifically named keyring in the requestor's keyring so
as to partition the keys by type to still have their named keyrings.
Decision point (2) allows the requestor to make sure that the key or keys that
get produced by request_key() go where they want, whilst allowing the
instantiator to request that the key is retained.  This is mainly useful for
situations where the instantiator makes a secondary request, the key for which
should be retained by the initial requestor:
	+-----------+        +--------------+        +--------------+
	|           |        |              |        |              |
	| Requestor |------->| Instantiator |------->| Instantiator |
	|           |        |              |        |              |
	+-----------+        +--------------+        +--------------+
	           request_key()           request_key()
This might be useful, for example, in Kerberos, where the requestor requests a
ticket, and then the ticket instantiator requests the TGT, which someone else
then has to go and fetch.  The TGT, however, should be retained in the
keyrings of the requestor, not the first instantiator.  To make this explict
an extra special keyring constant is also added.
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: James Morris <jmorris@namei.org>
Signed-off-by: James Morris <jmorris@namei.org>
											
										 
											2008-11-14 10:39:14 +11:00
										 |  |  | 	ret = install_user_keyrings(); | 
					
						
							|  |  |  | 	if (ret < 0) | 
					
						
							|  |  |  | 		goto error_alloc; | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2006-01-08 01:02:47 -08:00
										 |  |  | 	/* allocate a new session keyring */ | 
					
						
							|  |  |  | 	sprintf(desc, "_req.%u", key->serial); | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
											  
											
												CRED: Inaugurate COW credentials
Inaugurate copy-on-write credentials management.  This uses RCU to manage the
credentials pointer in the task_struct with respect to accesses by other tasks.
A process may only modify its own credentials, and so does not need locking to
access or modify its own credentials.
A mutex (cred_replace_mutex) is added to the task_struct to control the effect
of PTRACE_ATTACHED on credential calculations, particularly with respect to
execve().
With this patch, the contents of an active credentials struct may not be
changed directly; rather a new set of credentials must be prepared, modified
and committed using something like the following sequence of events:
	struct cred *new = prepare_creds();
	int ret = blah(new);
	if (ret < 0) {
		abort_creds(new);
		return ret;
	}
	return commit_creds(new);
There are some exceptions to this rule: the keyrings pointed to by the active
credentials may be instantiated - keyrings violate the COW rule as managing
COW keyrings is tricky, given that it is possible for a task to directly alter
the keys in a keyring in use by another task.
To help enforce this, various pointers to sets of credentials, such as those in
the task_struct, are declared const.  The purpose of this is compile-time
discouragement of altering credentials through those pointers.  Once a set of
credentials has been made public through one of these pointers, it may not be
modified, except under special circumstances:
  (1) Its reference count may incremented and decremented.
  (2) The keyrings to which it points may be modified, but not replaced.
The only safe way to modify anything else is to create a replacement and commit
using the functions described in Documentation/credentials.txt (which will be
added by a later patch).
This patch and the preceding patches have been tested with the LTP SELinux
testsuite.
This patch makes several logical sets of alteration:
 (1) execve().
     This now prepares and commits credentials in various places in the
     security code rather than altering the current creds directly.
 (2) Temporary credential overrides.
     do_coredump() and sys_faccessat() now prepare their own credentials and
     temporarily override the ones currently on the acting thread, whilst
     preventing interference from other threads by holding cred_replace_mutex
     on the thread being dumped.
     This will be replaced in a future patch by something that hands down the
     credentials directly to the functions being called, rather than altering
     the task's objective credentials.
 (3) LSM interface.
     A number of functions have been changed, added or removed:
     (*) security_capset_check(), ->capset_check()
     (*) security_capset_set(), ->capset_set()
     	 Removed in favour of security_capset().
     (*) security_capset(), ->capset()
     	 New.  This is passed a pointer to the new creds, a pointer to the old
     	 creds and the proposed capability sets.  It should fill in the new
     	 creds or return an error.  All pointers, barring the pointer to the
     	 new creds, are now const.
     (*) security_bprm_apply_creds(), ->bprm_apply_creds()
     	 Changed; now returns a value, which will cause the process to be
     	 killed if it's an error.
     (*) security_task_alloc(), ->task_alloc_security()
     	 Removed in favour of security_prepare_creds().
     (*) security_cred_free(), ->cred_free()
     	 New.  Free security data attached to cred->security.
     (*) security_prepare_creds(), ->cred_prepare()
     	 New. Duplicate any security data attached to cred->security.
     (*) security_commit_creds(), ->cred_commit()
     	 New. Apply any security effects for the upcoming installation of new
     	 security by commit_creds().
     (*) security_task_post_setuid(), ->task_post_setuid()
     	 Removed in favour of security_task_fix_setuid().
     (*) security_task_fix_setuid(), ->task_fix_setuid()
     	 Fix up the proposed new credentials for setuid().  This is used by
     	 cap_set_fix_setuid() to implicitly adjust capabilities in line with
     	 setuid() changes.  Changes are made to the new credentials, rather
     	 than the task itself as in security_task_post_setuid().
     (*) security_task_reparent_to_init(), ->task_reparent_to_init()
     	 Removed.  Instead the task being reparented to init is referred
     	 directly to init's credentials.
	 NOTE!  This results in the loss of some state: SELinux's osid no
	 longer records the sid of the thread that forked it.
     (*) security_key_alloc(), ->key_alloc()
     (*) security_key_permission(), ->key_permission()
     	 Changed.  These now take cred pointers rather than task pointers to
     	 refer to the security context.
 (4) sys_capset().
     This has been simplified and uses less locking.  The LSM functions it
     calls have been merged.
 (5) reparent_to_kthreadd().
     This gives the current thread the same credentials as init by simply using
     commit_thread() to point that way.
 (6) __sigqueue_alloc() and switch_uid()
     __sigqueue_alloc() can't stop the target task from changing its creds
     beneath it, so this function gets a reference to the currently applicable
     user_struct which it then passes into the sigqueue struct it returns if
     successful.
     switch_uid() is now called from commit_creds(), and possibly should be
     folded into that.  commit_creds() should take care of protecting
     __sigqueue_alloc().
 (7) [sg]et[ug]id() and co and [sg]et_current_groups.
     The set functions now all use prepare_creds(), commit_creds() and
     abort_creds() to build and check a new set of credentials before applying
     it.
     security_task_set[ug]id() is called inside the prepared section.  This
     guarantees that nothing else will affect the creds until we've finished.
     The calling of set_dumpable() has been moved into commit_creds().
     Much of the functionality of set_user() has been moved into
     commit_creds().
     The get functions all simply access the data directly.
 (8) security_task_prctl() and cap_task_prctl().
     security_task_prctl() has been modified to return -ENOSYS if it doesn't
     want to handle a function, or otherwise return the return value directly
     rather than through an argument.
     Additionally, cap_task_prctl() now prepares a new set of credentials, even
     if it doesn't end up using it.
 (9) Keyrings.
     A number of changes have been made to the keyrings code:
     (a) switch_uid_keyring(), copy_keys(), exit_keys() and suid_keys() have
     	 all been dropped and built in to the credentials functions directly.
     	 They may want separating out again later.
     (b) key_alloc() and search_process_keyrings() now take a cred pointer
     	 rather than a task pointer to specify the security context.
     (c) copy_creds() gives a new thread within the same thread group a new
     	 thread keyring if its parent had one, otherwise it discards the thread
     	 keyring.
     (d) The authorisation key now points directly to the credentials to extend
     	 the search into rather pointing to the task that carries them.
     (e) Installing thread, process or session keyrings causes a new set of
     	 credentials to be created, even though it's not strictly necessary for
     	 process or session keyrings (they're shared).
(10) Usermode helper.
     The usermode helper code now carries a cred struct pointer in its
     subprocess_info struct instead of a new session keyring pointer.  This set
     of credentials is derived from init_cred and installed on the new process
     after it has been cloned.
     call_usermodehelper_setup() allocates the new credentials and
     call_usermodehelper_freeinfo() discards them if they haven't been used.  A
     special cred function (prepare_usermodeinfo_creds()) is provided
     specifically for call_usermodehelper_setup() to call.
     call_usermodehelper_setkeys() adjusts the credentials to sport the
     supplied keyring as the new session keyring.
(11) SELinux.
     SELinux has a number of changes, in addition to those to support the LSM
     interface changes mentioned above:
     (a) selinux_setprocattr() no longer does its check for whether the
     	 current ptracer can access processes with the new SID inside the lock
     	 that covers getting the ptracer's SID.  Whilst this lock ensures that
     	 the check is done with the ptracer pinned, the result is only valid
     	 until the lock is released, so there's no point doing it inside the
     	 lock.
(12) is_single_threaded().
     This function has been extracted from selinux_setprocattr() and put into
     a file of its own in the lib/ directory as join_session_keyring() now
     wants to use it too.
     The code in SELinux just checked to see whether a task shared mm_structs
     with other tasks (CLONE_VM), but that isn't good enough.  We really want
     to know if they're part of the same thread group (CLONE_THREAD).
(13) nfsd.
     The NFS server daemon now has to use the COW credentials to set the
     credentials it is going to use.  It really needs to pass the credentials
     down to the functions it calls, but it can't do that until other patches
     in this series have been applied.
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: James Morris <jmorris@namei.org>
Signed-off-by: James Morris <jmorris@namei.org>
											
										 
											2008-11-14 10:39:23 +11:00
										 |  |  | 	cred = get_current_cred(); | 
					
						
							|  |  |  | 	keyring = keyring_alloc(desc, cred->fsuid, cred->fsgid, cred, | 
					
						
							| 
									
										
										
										
											2006-06-26 00:24:50 -07:00
										 |  |  | 				KEY_ALLOC_QUOTA_OVERRUN, NULL); | 
					
						
							| 
									
										
											  
											
												CRED: Inaugurate COW credentials
Inaugurate copy-on-write credentials management.  This uses RCU to manage the
credentials pointer in the task_struct with respect to accesses by other tasks.
A process may only modify its own credentials, and so does not need locking to
access or modify its own credentials.
A mutex (cred_replace_mutex) is added to the task_struct to control the effect
of PTRACE_ATTACHED on credential calculations, particularly with respect to
execve().
With this patch, the contents of an active credentials struct may not be
changed directly; rather a new set of credentials must be prepared, modified
and committed using something like the following sequence of events:
	struct cred *new = prepare_creds();
	int ret = blah(new);
	if (ret < 0) {
		abort_creds(new);
		return ret;
	}
	return commit_creds(new);
There are some exceptions to this rule: the keyrings pointed to by the active
credentials may be instantiated - keyrings violate the COW rule as managing
COW keyrings is tricky, given that it is possible for a task to directly alter
the keys in a keyring in use by another task.
To help enforce this, various pointers to sets of credentials, such as those in
the task_struct, are declared const.  The purpose of this is compile-time
discouragement of altering credentials through those pointers.  Once a set of
credentials has been made public through one of these pointers, it may not be
modified, except under special circumstances:
  (1) Its reference count may incremented and decremented.
  (2) The keyrings to which it points may be modified, but not replaced.
The only safe way to modify anything else is to create a replacement and commit
using the functions described in Documentation/credentials.txt (which will be
added by a later patch).
This patch and the preceding patches have been tested with the LTP SELinux
testsuite.
This patch makes several logical sets of alteration:
 (1) execve().
     This now prepares and commits credentials in various places in the
     security code rather than altering the current creds directly.
 (2) Temporary credential overrides.
     do_coredump() and sys_faccessat() now prepare their own credentials and
     temporarily override the ones currently on the acting thread, whilst
     preventing interference from other threads by holding cred_replace_mutex
     on the thread being dumped.
     This will be replaced in a future patch by something that hands down the
     credentials directly to the functions being called, rather than altering
     the task's objective credentials.
 (3) LSM interface.
     A number of functions have been changed, added or removed:
     (*) security_capset_check(), ->capset_check()
     (*) security_capset_set(), ->capset_set()
     	 Removed in favour of security_capset().
     (*) security_capset(), ->capset()
     	 New.  This is passed a pointer to the new creds, a pointer to the old
     	 creds and the proposed capability sets.  It should fill in the new
     	 creds or return an error.  All pointers, barring the pointer to the
     	 new creds, are now const.
     (*) security_bprm_apply_creds(), ->bprm_apply_creds()
     	 Changed; now returns a value, which will cause the process to be
     	 killed if it's an error.
     (*) security_task_alloc(), ->task_alloc_security()
     	 Removed in favour of security_prepare_creds().
     (*) security_cred_free(), ->cred_free()
     	 New.  Free security data attached to cred->security.
     (*) security_prepare_creds(), ->cred_prepare()
     	 New. Duplicate any security data attached to cred->security.
     (*) security_commit_creds(), ->cred_commit()
     	 New. Apply any security effects for the upcoming installation of new
     	 security by commit_creds().
     (*) security_task_post_setuid(), ->task_post_setuid()
     	 Removed in favour of security_task_fix_setuid().
     (*) security_task_fix_setuid(), ->task_fix_setuid()
     	 Fix up the proposed new credentials for setuid().  This is used by
     	 cap_set_fix_setuid() to implicitly adjust capabilities in line with
     	 setuid() changes.  Changes are made to the new credentials, rather
     	 than the task itself as in security_task_post_setuid().
     (*) security_task_reparent_to_init(), ->task_reparent_to_init()
     	 Removed.  Instead the task being reparented to init is referred
     	 directly to init's credentials.
	 NOTE!  This results in the loss of some state: SELinux's osid no
	 longer records the sid of the thread that forked it.
     (*) security_key_alloc(), ->key_alloc()
     (*) security_key_permission(), ->key_permission()
     	 Changed.  These now take cred pointers rather than task pointers to
     	 refer to the security context.
 (4) sys_capset().
     This has been simplified and uses less locking.  The LSM functions it
     calls have been merged.
 (5) reparent_to_kthreadd().
     This gives the current thread the same credentials as init by simply using
     commit_thread() to point that way.
 (6) __sigqueue_alloc() and switch_uid()
     __sigqueue_alloc() can't stop the target task from changing its creds
     beneath it, so this function gets a reference to the currently applicable
     user_struct which it then passes into the sigqueue struct it returns if
     successful.
     switch_uid() is now called from commit_creds(), and possibly should be
     folded into that.  commit_creds() should take care of protecting
     __sigqueue_alloc().
 (7) [sg]et[ug]id() and co and [sg]et_current_groups.
     The set functions now all use prepare_creds(), commit_creds() and
     abort_creds() to build and check a new set of credentials before applying
     it.
     security_task_set[ug]id() is called inside the prepared section.  This
     guarantees that nothing else will affect the creds until we've finished.
     The calling of set_dumpable() has been moved into commit_creds().
     Much of the functionality of set_user() has been moved into
     commit_creds().
     The get functions all simply access the data directly.
 (8) security_task_prctl() and cap_task_prctl().
     security_task_prctl() has been modified to return -ENOSYS if it doesn't
     want to handle a function, or otherwise return the return value directly
     rather than through an argument.
     Additionally, cap_task_prctl() now prepares a new set of credentials, even
     if it doesn't end up using it.
 (9) Keyrings.
     A number of changes have been made to the keyrings code:
     (a) switch_uid_keyring(), copy_keys(), exit_keys() and suid_keys() have
     	 all been dropped and built in to the credentials functions directly.
     	 They may want separating out again later.
     (b) key_alloc() and search_process_keyrings() now take a cred pointer
     	 rather than a task pointer to specify the security context.
     (c) copy_creds() gives a new thread within the same thread group a new
     	 thread keyring if its parent had one, otherwise it discards the thread
     	 keyring.
     (d) The authorisation key now points directly to the credentials to extend
     	 the search into rather pointing to the task that carries them.
     (e) Installing thread, process or session keyrings causes a new set of
     	 credentials to be created, even though it's not strictly necessary for
     	 process or session keyrings (they're shared).
(10) Usermode helper.
     The usermode helper code now carries a cred struct pointer in its
     subprocess_info struct instead of a new session keyring pointer.  This set
     of credentials is derived from init_cred and installed on the new process
     after it has been cloned.
     call_usermodehelper_setup() allocates the new credentials and
     call_usermodehelper_freeinfo() discards them if they haven't been used.  A
     special cred function (prepare_usermodeinfo_creds()) is provided
     specifically for call_usermodehelper_setup() to call.
     call_usermodehelper_setkeys() adjusts the credentials to sport the
     supplied keyring as the new session keyring.
(11) SELinux.
     SELinux has a number of changes, in addition to those to support the LSM
     interface changes mentioned above:
     (a) selinux_setprocattr() no longer does its check for whether the
     	 current ptracer can access processes with the new SID inside the lock
     	 that covers getting the ptracer's SID.  Whilst this lock ensures that
     	 the check is done with the ptracer pinned, the result is only valid
     	 until the lock is released, so there's no point doing it inside the
     	 lock.
(12) is_single_threaded().
     This function has been extracted from selinux_setprocattr() and put into
     a file of its own in the lib/ directory as join_session_keyring() now
     wants to use it too.
     The code in SELinux just checked to see whether a task shared mm_structs
     with other tasks (CLONE_VM), but that isn't good enough.  We really want
     to know if they're part of the same thread group (CLONE_THREAD).
(13) nfsd.
     The NFS server daemon now has to use the COW credentials to set the
     credentials it is going to use.  It really needs to pass the credentials
     down to the functions it calls, but it can't do that until other patches
     in this series have been applied.
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: James Morris <jmorris@namei.org>
Signed-off-by: James Morris <jmorris@namei.org>
											
										 
											2008-11-14 10:39:23 +11:00
										 |  |  | 	put_cred(cred); | 
					
						
							| 
									
										
										
										
											2006-01-08 01:02:47 -08:00
										 |  |  | 	if (IS_ERR(keyring)) { | 
					
						
							|  |  |  | 		ret = PTR_ERR(keyring); | 
					
						
							|  |  |  | 		goto error_alloc; | 
					
						
							| 
									
										
											  
											
												[PATCH] Keys: Make request-key create an authorisation key
The attached patch makes the following changes:
 (1) There's a new special key type called ".request_key_auth".
     This is an authorisation key for when one process requests a key and
     another process is started to construct it. This type of key cannot be
     created by the user; nor can it be requested by kernel services.
     Authorisation keys hold two references:
     (a) Each refers to a key being constructed. When the key being
     	 constructed is instantiated the authorisation key is revoked,
     	 rendering it of no further use.
     (b) The "authorising process". This is either:
     	 (i) the process that called request_key(), or:
     	 (ii) if the process that called request_key() itself had an
     	      authorisation key in its session keyring, then the authorising
     	      process referred to by that authorisation key will also be
     	      referred to by the new authorisation key.
	 This means that the process that initiated a chain of key requests
	 will authorise the lot of them, and will, by default, wind up with
	 the keys obtained from them in its keyrings.
 (2) request_key() creates an authorisation key which is then passed to
     /sbin/request-key in as part of a new session keyring.
 (3) When request_key() is searching for a key to hand back to the caller, if
     it comes across an authorisation key in the session keyring of the
     calling process, it will also search the keyrings of the process
     specified therein and it will use the specified process's credentials
     (fsuid, fsgid, groups) to do that rather than the calling process's
     credentials.
     This allows a process started by /sbin/request-key to find keys belonging
     to the authorising process.
 (4) A key can be read, even if the process executing KEYCTL_READ doesn't have
     direct read or search permission if that key is contained within the
     keyrings of a process specified by an authorisation key found within the
     calling process's session keyring, and is searchable using the
     credentials of the authorising process.
     This allows a process started by /sbin/request-key to read keys belonging
     to the authorising process.
 (5) The magic KEY_SPEC_*_KEYRING key IDs when passed to KEYCTL_INSTANTIATE or
     KEYCTL_NEGATE will specify a keyring of the authorising process, rather
     than the process doing the instantiation.
 (6) One of the process keyrings can be nominated as the default to which
     request_key() should attach new keys if not otherwise specified. This is
     done with KEYCTL_SET_REQKEY_KEYRING and one of the KEY_REQKEY_DEFL_*
     constants. The current setting can also be read using this call.
 (7) request_key() is partially interruptible. If it is waiting for another
     process to finish constructing a key, it can be interrupted. This permits
     a request-key cycle to be broken without recourse to rebooting.
Signed-Off-By: David Howells <dhowells@redhat.com>
Signed-Off-By: Benoit Boissinot <benoit.boissinot@ens-lyon.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
											
										 
											2005-06-23 22:00:56 -07:00
										 |  |  | 	} | 
					
						
							| 
									
										
										
										
											2005-04-16 15:20:36 -07:00
										 |  |  | 
 | 
					
						
							| 
									
										
										
										
											2006-01-08 01:02:47 -08:00
										 |  |  | 	/* attach the auth key to the session keyring */ | 
					
						
							|  |  |  | 	ret = __key_link(keyring, authkey); | 
					
						
							|  |  |  | 	if (ret < 0) | 
					
						
							|  |  |  | 		goto error_link; | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2005-04-16 15:20:36 -07:00
										 |  |  | 	/* record the UID and GID */ | 
					
						
							| 
									
										
										
										
											2008-11-14 10:39:18 +11:00
										 |  |  | 	sprintf(uid_str, "%d", cred->fsuid); | 
					
						
							|  |  |  | 	sprintf(gid_str, "%d", cred->fsgid); | 
					
						
							| 
									
										
										
										
											2005-04-16 15:20:36 -07:00
										 |  |  | 
 | 
					
						
							|  |  |  | 	/* we say which key is under construction */ | 
					
						
							|  |  |  | 	sprintf(key_str, "%d", key->serial); | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | 	/* we specify the process's default keyrings */ | 
					
						
							|  |  |  | 	sprintf(keyring_str[0], "%d", | 
					
						
							| 
									
										
											  
											
												CRED: Inaugurate COW credentials
Inaugurate copy-on-write credentials management.  This uses RCU to manage the
credentials pointer in the task_struct with respect to accesses by other tasks.
A process may only modify its own credentials, and so does not need locking to
access or modify its own credentials.
A mutex (cred_replace_mutex) is added to the task_struct to control the effect
of PTRACE_ATTACHED on credential calculations, particularly with respect to
execve().
With this patch, the contents of an active credentials struct may not be
changed directly; rather a new set of credentials must be prepared, modified
and committed using something like the following sequence of events:
	struct cred *new = prepare_creds();
	int ret = blah(new);
	if (ret < 0) {
		abort_creds(new);
		return ret;
	}
	return commit_creds(new);
There are some exceptions to this rule: the keyrings pointed to by the active
credentials may be instantiated - keyrings violate the COW rule as managing
COW keyrings is tricky, given that it is possible for a task to directly alter
the keys in a keyring in use by another task.
To help enforce this, various pointers to sets of credentials, such as those in
the task_struct, are declared const.  The purpose of this is compile-time
discouragement of altering credentials through those pointers.  Once a set of
credentials has been made public through one of these pointers, it may not be
modified, except under special circumstances:
  (1) Its reference count may incremented and decremented.
  (2) The keyrings to which it points may be modified, but not replaced.
The only safe way to modify anything else is to create a replacement and commit
using the functions described in Documentation/credentials.txt (which will be
added by a later patch).
This patch and the preceding patches have been tested with the LTP SELinux
testsuite.
This patch makes several logical sets of alteration:
 (1) execve().
     This now prepares and commits credentials in various places in the
     security code rather than altering the current creds directly.
 (2) Temporary credential overrides.
     do_coredump() and sys_faccessat() now prepare their own credentials and
     temporarily override the ones currently on the acting thread, whilst
     preventing interference from other threads by holding cred_replace_mutex
     on the thread being dumped.
     This will be replaced in a future patch by something that hands down the
     credentials directly to the functions being called, rather than altering
     the task's objective credentials.
 (3) LSM interface.
     A number of functions have been changed, added or removed:
     (*) security_capset_check(), ->capset_check()
     (*) security_capset_set(), ->capset_set()
     	 Removed in favour of security_capset().
     (*) security_capset(), ->capset()
     	 New.  This is passed a pointer to the new creds, a pointer to the old
     	 creds and the proposed capability sets.  It should fill in the new
     	 creds or return an error.  All pointers, barring the pointer to the
     	 new creds, are now const.
     (*) security_bprm_apply_creds(), ->bprm_apply_creds()
     	 Changed; now returns a value, which will cause the process to be
     	 killed if it's an error.
     (*) security_task_alloc(), ->task_alloc_security()
     	 Removed in favour of security_prepare_creds().
     (*) security_cred_free(), ->cred_free()
     	 New.  Free security data attached to cred->security.
     (*) security_prepare_creds(), ->cred_prepare()
     	 New. Duplicate any security data attached to cred->security.
     (*) security_commit_creds(), ->cred_commit()
     	 New. Apply any security effects for the upcoming installation of new
     	 security by commit_creds().
     (*) security_task_post_setuid(), ->task_post_setuid()
     	 Removed in favour of security_task_fix_setuid().
     (*) security_task_fix_setuid(), ->task_fix_setuid()
     	 Fix up the proposed new credentials for setuid().  This is used by
     	 cap_set_fix_setuid() to implicitly adjust capabilities in line with
     	 setuid() changes.  Changes are made to the new credentials, rather
     	 than the task itself as in security_task_post_setuid().
     (*) security_task_reparent_to_init(), ->task_reparent_to_init()
     	 Removed.  Instead the task being reparented to init is referred
     	 directly to init's credentials.
	 NOTE!  This results in the loss of some state: SELinux's osid no
	 longer records the sid of the thread that forked it.
     (*) security_key_alloc(), ->key_alloc()
     (*) security_key_permission(), ->key_permission()
     	 Changed.  These now take cred pointers rather than task pointers to
     	 refer to the security context.
 (4) sys_capset().
     This has been simplified and uses less locking.  The LSM functions it
     calls have been merged.
 (5) reparent_to_kthreadd().
     This gives the current thread the same credentials as init by simply using
     commit_thread() to point that way.
 (6) __sigqueue_alloc() and switch_uid()
     __sigqueue_alloc() can't stop the target task from changing its creds
     beneath it, so this function gets a reference to the currently applicable
     user_struct which it then passes into the sigqueue struct it returns if
     successful.
     switch_uid() is now called from commit_creds(), and possibly should be
     folded into that.  commit_creds() should take care of protecting
     __sigqueue_alloc().
 (7) [sg]et[ug]id() and co and [sg]et_current_groups.
     The set functions now all use prepare_creds(), commit_creds() and
     abort_creds() to build and check a new set of credentials before applying
     it.
     security_task_set[ug]id() is called inside the prepared section.  This
     guarantees that nothing else will affect the creds until we've finished.
     The calling of set_dumpable() has been moved into commit_creds().
     Much of the functionality of set_user() has been moved into
     commit_creds().
     The get functions all simply access the data directly.
 (8) security_task_prctl() and cap_task_prctl().
     security_task_prctl() has been modified to return -ENOSYS if it doesn't
     want to handle a function, or otherwise return the return value directly
     rather than through an argument.
     Additionally, cap_task_prctl() now prepares a new set of credentials, even
     if it doesn't end up using it.
 (9) Keyrings.
     A number of changes have been made to the keyrings code:
     (a) switch_uid_keyring(), copy_keys(), exit_keys() and suid_keys() have
     	 all been dropped and built in to the credentials functions directly.
     	 They may want separating out again later.
     (b) key_alloc() and search_process_keyrings() now take a cred pointer
     	 rather than a task pointer to specify the security context.
     (c) copy_creds() gives a new thread within the same thread group a new
     	 thread keyring if its parent had one, otherwise it discards the thread
     	 keyring.
     (d) The authorisation key now points directly to the credentials to extend
     	 the search into rather pointing to the task that carries them.
     (e) Installing thread, process or session keyrings causes a new set of
     	 credentials to be created, even though it's not strictly necessary for
     	 process or session keyrings (they're shared).
(10) Usermode helper.
     The usermode helper code now carries a cred struct pointer in its
     subprocess_info struct instead of a new session keyring pointer.  This set
     of credentials is derived from init_cred and installed on the new process
     after it has been cloned.
     call_usermodehelper_setup() allocates the new credentials and
     call_usermodehelper_freeinfo() discards them if they haven't been used.  A
     special cred function (prepare_usermodeinfo_creds()) is provided
     specifically for call_usermodehelper_setup() to call.
     call_usermodehelper_setkeys() adjusts the credentials to sport the
     supplied keyring as the new session keyring.
(11) SELinux.
     SELinux has a number of changes, in addition to those to support the LSM
     interface changes mentioned above:
     (a) selinux_setprocattr() no longer does its check for whether the
     	 current ptracer can access processes with the new SID inside the lock
     	 that covers getting the ptracer's SID.  Whilst this lock ensures that
     	 the check is done with the ptracer pinned, the result is only valid
     	 until the lock is released, so there's no point doing it inside the
     	 lock.
(12) is_single_threaded().
     This function has been extracted from selinux_setprocattr() and put into
     a file of its own in the lib/ directory as join_session_keyring() now
     wants to use it too.
     The code in SELinux just checked to see whether a task shared mm_structs
     with other tasks (CLONE_VM), but that isn't good enough.  We really want
     to know if they're part of the same thread group (CLONE_THREAD).
(13) nfsd.
     The NFS server daemon now has to use the COW credentials to set the
     credentials it is going to use.  It really needs to pass the credentials
     down to the functions it calls, but it can't do that until other patches
     in this series have been applied.
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: James Morris <jmorris@namei.org>
Signed-off-by: James Morris <jmorris@namei.org>
											
										 
											2008-11-14 10:39:23 +11:00
										 |  |  | 		cred->thread_keyring ? cred->thread_keyring->serial : 0); | 
					
						
							| 
									
										
										
										
											2005-04-16 15:20:36 -07:00
										 |  |  | 
 | 
					
						
							|  |  |  | 	prkey = 0; | 
					
						
							| 
									
										
										
										
											2008-11-14 10:39:20 +11:00
										 |  |  | 	if (cred->tgcred->process_keyring) | 
					
						
							|  |  |  | 		prkey = cred->tgcred->process_keyring->serial; | 
					
						
							| 
									
										
										
										
											2005-04-16 15:20:36 -07:00
										 |  |  | 
 | 
					
						
							| 
									
										
										
										
											2010-04-23 13:18:00 -04:00
										 |  |  | 	rcu_read_lock(); | 
					
						
							|  |  |  | 	session = rcu_dereference(cred->tgcred->session_keyring); | 
					
						
							|  |  |  | 	if (!session) | 
					
						
							|  |  |  | 		session = cred->user->session_keyring; | 
					
						
							|  |  |  | 	sskey = session->serial; | 
					
						
							|  |  |  | 	rcu_read_unlock(); | 
					
						
							| 
									
										
										
										
											2005-04-16 15:20:36 -07:00
										 |  |  | 
 | 
					
						
							|  |  |  | 	sprintf(keyring_str[2], "%d", sskey); | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | 	/* set up a minimal environment */ | 
					
						
							|  |  |  | 	i = 0; | 
					
						
							|  |  |  | 	envp[i++] = "HOME=/"; | 
					
						
							|  |  |  | 	envp[i++] = "PATH=/sbin:/bin:/usr/sbin:/usr/bin"; | 
					
						
							|  |  |  | 	envp[i] = NULL; | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | 	/* set up the argument list */ | 
					
						
							|  |  |  | 	i = 0; | 
					
						
							|  |  |  | 	argv[i++] = "/sbin/request-key"; | 
					
						
							|  |  |  | 	argv[i++] = (char *) op; | 
					
						
							|  |  |  | 	argv[i++] = key_str; | 
					
						
							|  |  |  | 	argv[i++] = uid_str; | 
					
						
							|  |  |  | 	argv[i++] = gid_str; | 
					
						
							|  |  |  | 	argv[i++] = keyring_str[0]; | 
					
						
							|  |  |  | 	argv[i++] = keyring_str[1]; | 
					
						
							|  |  |  | 	argv[i++] = keyring_str[2]; | 
					
						
							|  |  |  | 	argv[i] = NULL; | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | 	/* do it */ | 
					
						
							| 
									
										
										
										
											2007-07-17 18:37:03 -07:00
										 |  |  | 	ret = call_usermodehelper_keys(argv[0], argv, envp, keyring, | 
					
						
							|  |  |  | 				       UMH_WAIT_PROC); | 
					
						
							| 
									
										
										
										
											2007-10-16 23:29:46 -07:00
										 |  |  | 	kdebug("usermode -> 0x%x", ret); | 
					
						
							|  |  |  | 	if (ret >= 0) { | 
					
						
							|  |  |  | 		/* ret is the exit/wait code */ | 
					
						
							|  |  |  | 		if (test_bit(KEY_FLAG_USER_CONSTRUCT, &key->flags) || | 
					
						
							|  |  |  | 		    key_validate(key) < 0) | 
					
						
							|  |  |  | 			ret = -ENOKEY; | 
					
						
							|  |  |  | 		else | 
					
						
							|  |  |  | 			/* ignore any errors from userspace if the key was
 | 
					
						
							|  |  |  | 			 * instantiated */ | 
					
						
							|  |  |  | 			ret = 0; | 
					
						
							|  |  |  | 	} | 
					
						
							| 
									
										
											  
											
												[PATCH] Keys: Make request-key create an authorisation key
The attached patch makes the following changes:
 (1) There's a new special key type called ".request_key_auth".
     This is an authorisation key for when one process requests a key and
     another process is started to construct it. This type of key cannot be
     created by the user; nor can it be requested by kernel services.
     Authorisation keys hold two references:
     (a) Each refers to a key being constructed. When the key being
     	 constructed is instantiated the authorisation key is revoked,
     	 rendering it of no further use.
     (b) The "authorising process". This is either:
     	 (i) the process that called request_key(), or:
     	 (ii) if the process that called request_key() itself had an
     	      authorisation key in its session keyring, then the authorising
     	      process referred to by that authorisation key will also be
     	      referred to by the new authorisation key.
	 This means that the process that initiated a chain of key requests
	 will authorise the lot of them, and will, by default, wind up with
	 the keys obtained from them in its keyrings.
 (2) request_key() creates an authorisation key which is then passed to
     /sbin/request-key in as part of a new session keyring.
 (3) When request_key() is searching for a key to hand back to the caller, if
     it comes across an authorisation key in the session keyring of the
     calling process, it will also search the keyrings of the process
     specified therein and it will use the specified process's credentials
     (fsuid, fsgid, groups) to do that rather than the calling process's
     credentials.
     This allows a process started by /sbin/request-key to find keys belonging
     to the authorising process.
 (4) A key can be read, even if the process executing KEYCTL_READ doesn't have
     direct read or search permission if that key is contained within the
     keyrings of a process specified by an authorisation key found within the
     calling process's session keyring, and is searchable using the
     credentials of the authorising process.
     This allows a process started by /sbin/request-key to read keys belonging
     to the authorising process.
 (5) The magic KEY_SPEC_*_KEYRING key IDs when passed to KEYCTL_INSTANTIATE or
     KEYCTL_NEGATE will specify a keyring of the authorising process, rather
     than the process doing the instantiation.
 (6) One of the process keyrings can be nominated as the default to which
     request_key() should attach new keys if not otherwise specified. This is
     done with KEYCTL_SET_REQKEY_KEYRING and one of the KEY_REQKEY_DEFL_*
     constants. The current setting can also be read using this call.
 (7) request_key() is partially interruptible. If it is waiting for another
     process to finish constructing a key, it can be interrupted. This permits
     a request-key cycle to be broken without recourse to rebooting.
Signed-Off-By: David Howells <dhowells@redhat.com>
Signed-Off-By: Benoit Boissinot <benoit.boissinot@ens-lyon.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
											
										 
											2005-06-23 22:00:56 -07:00
										 |  |  | 
 | 
					
						
							| 
									
										
										
										
											2006-01-08 01:02:47 -08:00
										 |  |  | error_link: | 
					
						
							|  |  |  | 	key_put(keyring); | 
					
						
							| 
									
										
											  
											
												[PATCH] Keys: Make request-key create an authorisation key
The attached patch makes the following changes:
 (1) There's a new special key type called ".request_key_auth".
     This is an authorisation key for when one process requests a key and
     another process is started to construct it. This type of key cannot be
     created by the user; nor can it be requested by kernel services.
     Authorisation keys hold two references:
     (a) Each refers to a key being constructed. When the key being
     	 constructed is instantiated the authorisation key is revoked,
     	 rendering it of no further use.
     (b) The "authorising process". This is either:
     	 (i) the process that called request_key(), or:
     	 (ii) if the process that called request_key() itself had an
     	      authorisation key in its session keyring, then the authorising
     	      process referred to by that authorisation key will also be
     	      referred to by the new authorisation key.
	 This means that the process that initiated a chain of key requests
	 will authorise the lot of them, and will, by default, wind up with
	 the keys obtained from them in its keyrings.
 (2) request_key() creates an authorisation key which is then passed to
     /sbin/request-key in as part of a new session keyring.
 (3) When request_key() is searching for a key to hand back to the caller, if
     it comes across an authorisation key in the session keyring of the
     calling process, it will also search the keyrings of the process
     specified therein and it will use the specified process's credentials
     (fsuid, fsgid, groups) to do that rather than the calling process's
     credentials.
     This allows a process started by /sbin/request-key to find keys belonging
     to the authorising process.
 (4) A key can be read, even if the process executing KEYCTL_READ doesn't have
     direct read or search permission if that key is contained within the
     keyrings of a process specified by an authorisation key found within the
     calling process's session keyring, and is searchable using the
     credentials of the authorising process.
     This allows a process started by /sbin/request-key to read keys belonging
     to the authorising process.
 (5) The magic KEY_SPEC_*_KEYRING key IDs when passed to KEYCTL_INSTANTIATE or
     KEYCTL_NEGATE will specify a keyring of the authorising process, rather
     than the process doing the instantiation.
 (6) One of the process keyrings can be nominated as the default to which
     request_key() should attach new keys if not otherwise specified. This is
     done with KEYCTL_SET_REQKEY_KEYRING and one of the KEY_REQKEY_DEFL_*
     constants. The current setting can also be read using this call.
 (7) request_key() is partially interruptible. If it is waiting for another
     process to finish constructing a key, it can be interrupted. This permits
     a request-key cycle to be broken without recourse to rebooting.
Signed-Off-By: David Howells <dhowells@redhat.com>
Signed-Off-By: Benoit Boissinot <benoit.boissinot@ens-lyon.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
											
										 
											2005-06-23 22:00:56 -07:00
										 |  |  | 
 | 
					
						
							| 
									
										
										
										
											2006-01-08 01:02:47 -08:00
										 |  |  | error_alloc: | 
					
						
							| 
									
										
										
										
											2007-10-16 23:29:46 -07:00
										 |  |  | 	complete_request_key(cons, ret); | 
					
						
							| 
									
										
											  
											
												CRED: Inaugurate COW credentials
Inaugurate copy-on-write credentials management.  This uses RCU to manage the
credentials pointer in the task_struct with respect to accesses by other tasks.
A process may only modify its own credentials, and so does not need locking to
access or modify its own credentials.
A mutex (cred_replace_mutex) is added to the task_struct to control the effect
of PTRACE_ATTACHED on credential calculations, particularly with respect to
execve().
With this patch, the contents of an active credentials struct may not be
changed directly; rather a new set of credentials must be prepared, modified
and committed using something like the following sequence of events:
	struct cred *new = prepare_creds();
	int ret = blah(new);
	if (ret < 0) {
		abort_creds(new);
		return ret;
	}
	return commit_creds(new);
There are some exceptions to this rule: the keyrings pointed to by the active
credentials may be instantiated - keyrings violate the COW rule as managing
COW keyrings is tricky, given that it is possible for a task to directly alter
the keys in a keyring in use by another task.
To help enforce this, various pointers to sets of credentials, such as those in
the task_struct, are declared const.  The purpose of this is compile-time
discouragement of altering credentials through those pointers.  Once a set of
credentials has been made public through one of these pointers, it may not be
modified, except under special circumstances:
  (1) Its reference count may incremented and decremented.
  (2) The keyrings to which it points may be modified, but not replaced.
The only safe way to modify anything else is to create a replacement and commit
using the functions described in Documentation/credentials.txt (which will be
added by a later patch).
This patch and the preceding patches have been tested with the LTP SELinux
testsuite.
This patch makes several logical sets of alteration:
 (1) execve().
     This now prepares and commits credentials in various places in the
     security code rather than altering the current creds directly.
 (2) Temporary credential overrides.
     do_coredump() and sys_faccessat() now prepare their own credentials and
     temporarily override the ones currently on the acting thread, whilst
     preventing interference from other threads by holding cred_replace_mutex
     on the thread being dumped.
     This will be replaced in a future patch by something that hands down the
     credentials directly to the functions being called, rather than altering
     the task's objective credentials.
 (3) LSM interface.
     A number of functions have been changed, added or removed:
     (*) security_capset_check(), ->capset_check()
     (*) security_capset_set(), ->capset_set()
     	 Removed in favour of security_capset().
     (*) security_capset(), ->capset()
     	 New.  This is passed a pointer to the new creds, a pointer to the old
     	 creds and the proposed capability sets.  It should fill in the new
     	 creds or return an error.  All pointers, barring the pointer to the
     	 new creds, are now const.
     (*) security_bprm_apply_creds(), ->bprm_apply_creds()
     	 Changed; now returns a value, which will cause the process to be
     	 killed if it's an error.
     (*) security_task_alloc(), ->task_alloc_security()
     	 Removed in favour of security_prepare_creds().
     (*) security_cred_free(), ->cred_free()
     	 New.  Free security data attached to cred->security.
     (*) security_prepare_creds(), ->cred_prepare()
     	 New. Duplicate any security data attached to cred->security.
     (*) security_commit_creds(), ->cred_commit()
     	 New. Apply any security effects for the upcoming installation of new
     	 security by commit_creds().
     (*) security_task_post_setuid(), ->task_post_setuid()
     	 Removed in favour of security_task_fix_setuid().
     (*) security_task_fix_setuid(), ->task_fix_setuid()
     	 Fix up the proposed new credentials for setuid().  This is used by
     	 cap_set_fix_setuid() to implicitly adjust capabilities in line with
     	 setuid() changes.  Changes are made to the new credentials, rather
     	 than the task itself as in security_task_post_setuid().
     (*) security_task_reparent_to_init(), ->task_reparent_to_init()
     	 Removed.  Instead the task being reparented to init is referred
     	 directly to init's credentials.
	 NOTE!  This results in the loss of some state: SELinux's osid no
	 longer records the sid of the thread that forked it.
     (*) security_key_alloc(), ->key_alloc()
     (*) security_key_permission(), ->key_permission()
     	 Changed.  These now take cred pointers rather than task pointers to
     	 refer to the security context.
 (4) sys_capset().
     This has been simplified and uses less locking.  The LSM functions it
     calls have been merged.
 (5) reparent_to_kthreadd().
     This gives the current thread the same credentials as init by simply using
     commit_thread() to point that way.
 (6) __sigqueue_alloc() and switch_uid()
     __sigqueue_alloc() can't stop the target task from changing its creds
     beneath it, so this function gets a reference to the currently applicable
     user_struct which it then passes into the sigqueue struct it returns if
     successful.
     switch_uid() is now called from commit_creds(), and possibly should be
     folded into that.  commit_creds() should take care of protecting
     __sigqueue_alloc().
 (7) [sg]et[ug]id() and co and [sg]et_current_groups.
     The set functions now all use prepare_creds(), commit_creds() and
     abort_creds() to build and check a new set of credentials before applying
     it.
     security_task_set[ug]id() is called inside the prepared section.  This
     guarantees that nothing else will affect the creds until we've finished.
     The calling of set_dumpable() has been moved into commit_creds().
     Much of the functionality of set_user() has been moved into
     commit_creds().
     The get functions all simply access the data directly.
 (8) security_task_prctl() and cap_task_prctl().
     security_task_prctl() has been modified to return -ENOSYS if it doesn't
     want to handle a function, or otherwise return the return value directly
     rather than through an argument.
     Additionally, cap_task_prctl() now prepares a new set of credentials, even
     if it doesn't end up using it.
 (9) Keyrings.
     A number of changes have been made to the keyrings code:
     (a) switch_uid_keyring(), copy_keys(), exit_keys() and suid_keys() have
     	 all been dropped and built in to the credentials functions directly.
     	 They may want separating out again later.
     (b) key_alloc() and search_process_keyrings() now take a cred pointer
     	 rather than a task pointer to specify the security context.
     (c) copy_creds() gives a new thread within the same thread group a new
     	 thread keyring if its parent had one, otherwise it discards the thread
     	 keyring.
     (d) The authorisation key now points directly to the credentials to extend
     	 the search into rather pointing to the task that carries them.
     (e) Installing thread, process or session keyrings causes a new set of
     	 credentials to be created, even though it's not strictly necessary for
     	 process or session keyrings (they're shared).
(10) Usermode helper.
     The usermode helper code now carries a cred struct pointer in its
     subprocess_info struct instead of a new session keyring pointer.  This set
     of credentials is derived from init_cred and installed on the new process
     after it has been cloned.
     call_usermodehelper_setup() allocates the new credentials and
     call_usermodehelper_freeinfo() discards them if they haven't been used.  A
     special cred function (prepare_usermodeinfo_creds()) is provided
     specifically for call_usermodehelper_setup() to call.
     call_usermodehelper_setkeys() adjusts the credentials to sport the
     supplied keyring as the new session keyring.
(11) SELinux.
     SELinux has a number of changes, in addition to those to support the LSM
     interface changes mentioned above:
     (a) selinux_setprocattr() no longer does its check for whether the
     	 current ptracer can access processes with the new SID inside the lock
     	 that covers getting the ptracer's SID.  Whilst this lock ensures that
     	 the check is done with the ptracer pinned, the result is only valid
     	 until the lock is released, so there's no point doing it inside the
     	 lock.
(12) is_single_threaded().
     This function has been extracted from selinux_setprocattr() and put into
     a file of its own in the lib/ directory as join_session_keyring() now
     wants to use it too.
     The code in SELinux just checked to see whether a task shared mm_structs
     with other tasks (CLONE_VM), but that isn't good enough.  We really want
     to know if they're part of the same thread group (CLONE_THREAD).
(13) nfsd.
     The NFS server daemon now has to use the COW credentials to set the
     credentials it is going to use.  It really needs to pass the credentials
     down to the functions it calls, but it can't do that until other patches
     in this series have been applied.
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: James Morris <jmorris@namei.org>
Signed-off-by: James Morris <jmorris@namei.org>
											
										 
											2008-11-14 10:39:23 +11:00
										 |  |  | 	kleave(" = %d", ret); | 
					
						
							| 
									
										
											  
											
												[PATCH] Keys: Make request-key create an authorisation key
The attached patch makes the following changes:
 (1) There's a new special key type called ".request_key_auth".
     This is an authorisation key for when one process requests a key and
     another process is started to construct it. This type of key cannot be
     created by the user; nor can it be requested by kernel services.
     Authorisation keys hold two references:
     (a) Each refers to a key being constructed. When the key being
     	 constructed is instantiated the authorisation key is revoked,
     	 rendering it of no further use.
     (b) The "authorising process". This is either:
     	 (i) the process that called request_key(), or:
     	 (ii) if the process that called request_key() itself had an
     	      authorisation key in its session keyring, then the authorising
     	      process referred to by that authorisation key will also be
     	      referred to by the new authorisation key.
	 This means that the process that initiated a chain of key requests
	 will authorise the lot of them, and will, by default, wind up with
	 the keys obtained from them in its keyrings.
 (2) request_key() creates an authorisation key which is then passed to
     /sbin/request-key in as part of a new session keyring.
 (3) When request_key() is searching for a key to hand back to the caller, if
     it comes across an authorisation key in the session keyring of the
     calling process, it will also search the keyrings of the process
     specified therein and it will use the specified process's credentials
     (fsuid, fsgid, groups) to do that rather than the calling process's
     credentials.
     This allows a process started by /sbin/request-key to find keys belonging
     to the authorising process.
 (4) A key can be read, even if the process executing KEYCTL_READ doesn't have
     direct read or search permission if that key is contained within the
     keyrings of a process specified by an authorisation key found within the
     calling process's session keyring, and is searchable using the
     credentials of the authorising process.
     This allows a process started by /sbin/request-key to read keys belonging
     to the authorising process.
 (5) The magic KEY_SPEC_*_KEYRING key IDs when passed to KEYCTL_INSTANTIATE or
     KEYCTL_NEGATE will specify a keyring of the authorising process, rather
     than the process doing the instantiation.
 (6) One of the process keyrings can be nominated as the default to which
     request_key() should attach new keys if not otherwise specified. This is
     done with KEYCTL_SET_REQKEY_KEYRING and one of the KEY_REQKEY_DEFL_*
     constants. The current setting can also be read using this call.
 (7) request_key() is partially interruptible. If it is waiting for another
     process to finish constructing a key, it can be interrupted. This permits
     a request-key cycle to be broken without recourse to rebooting.
Signed-Off-By: David Howells <dhowells@redhat.com>
Signed-Off-By: Benoit Boissinot <benoit.boissinot@ens-lyon.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
											
										 
											2005-06-23 22:00:56 -07:00
										 |  |  | 	return ret; | 
					
						
							| 
									
										
										
										
											2007-10-16 23:29:46 -07:00
										 |  |  | } | 
					
						
							| 
									
										
										
										
											2005-04-16 15:20:36 -07:00
										 |  |  | 
 | 
					
						
							|  |  |  | /*
 | 
					
						
							| 
									
										
										
										
											2007-10-16 23:29:46 -07:00
										 |  |  |  * call out to userspace for key construction | 
					
						
							| 
									
										
										
										
											2005-04-16 15:20:36 -07:00
										 |  |  |  * - we ignore program failure and go on key status instead | 
					
						
							|  |  |  |  */ | 
					
						
							| 
									
										
										
										
											2008-04-29 01:01:24 -07:00
										 |  |  | static int construct_key(struct key *key, const void *callout_info, | 
					
						
							| 
									
										
											  
											
												KEYS: Alter use of key instantiation link-to-keyring argument
Alter the use of the key instantiation and negation functions' link-to-keyring
arguments.  Currently this specifies a keyring in the target process to link
the key into, creating the keyring if it doesn't exist.  This, however, can be
a problem for copy-on-write credentials as it means that the instantiating
process can alter the credentials of the requesting process.
This patch alters the behaviour such that:
 (1) If keyctl_instantiate_key() or keyctl_negate_key() are given a specific
     keyring by ID (ringid >= 0), then that keyring will be used.
 (2) If keyctl_instantiate_key() or keyctl_negate_key() are given one of the
     special constants that refer to the requesting process's keyrings
     (KEY_SPEC_*_KEYRING, all <= 0), then:
     (a) If sys_request_key() was given a keyring to use (destringid) then the
     	 key will be attached to that keyring.
     (b) If sys_request_key() was given a NULL keyring, then the key being
     	 instantiated will be attached to the default keyring as set by
     	 keyctl_set_reqkey_keyring().
 (3) No extra link will be made.
Decision point (1) follows current behaviour, and allows those instantiators
who've searched for a specifically named keyring in the requestor's keyring so
as to partition the keys by type to still have their named keyrings.
Decision point (2) allows the requestor to make sure that the key or keys that
get produced by request_key() go where they want, whilst allowing the
instantiator to request that the key is retained.  This is mainly useful for
situations where the instantiator makes a secondary request, the key for which
should be retained by the initial requestor:
	+-----------+        +--------------+        +--------------+
	|           |        |              |        |              |
	| Requestor |------->| Instantiator |------->| Instantiator |
	|           |        |              |        |              |
	+-----------+        +--------------+        +--------------+
	           request_key()           request_key()
This might be useful, for example, in Kerberos, where the requestor requests a
ticket, and then the ticket instantiator requests the TGT, which someone else
then has to go and fetch.  The TGT, however, should be retained in the
keyrings of the requestor, not the first instantiator.  To make this explict
an extra special keyring constant is also added.
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: James Morris <jmorris@namei.org>
Signed-off-by: James Morris <jmorris@namei.org>
											
										 
											2008-11-14 10:39:14 +11:00
										 |  |  | 			 size_t callout_len, void *aux, | 
					
						
							|  |  |  | 			 struct key *dest_keyring) | 
					
						
							| 
									
										
										
										
											2005-04-16 15:20:36 -07:00
										 |  |  | { | 
					
						
							| 
									
										
										
										
											2007-10-16 23:29:46 -07:00
										 |  |  | 	struct key_construction *cons; | 
					
						
							| 
									
										
										
										
											2006-01-08 01:02:47 -08:00
										 |  |  | 	request_key_actor_t actor; | 
					
						
							| 
									
										
										
										
											2007-10-16 23:29:46 -07:00
										 |  |  | 	struct key *authkey; | 
					
						
							|  |  |  | 	int ret; | 
					
						
							| 
									
										
										
										
											2005-04-16 15:20:36 -07:00
										 |  |  | 
 | 
					
						
							| 
									
										
										
										
											2008-04-29 01:01:24 -07:00
										 |  |  | 	kenter("%d,%p,%zu,%p", key->serial, callout_info, callout_len, aux); | 
					
						
							| 
									
										
											  
											
												[PATCH] Keys: Make request-key create an authorisation key
The attached patch makes the following changes:
 (1) There's a new special key type called ".request_key_auth".
     This is an authorisation key for when one process requests a key and
     another process is started to construct it. This type of key cannot be
     created by the user; nor can it be requested by kernel services.
     Authorisation keys hold two references:
     (a) Each refers to a key being constructed. When the key being
     	 constructed is instantiated the authorisation key is revoked,
     	 rendering it of no further use.
     (b) The "authorising process". This is either:
     	 (i) the process that called request_key(), or:
     	 (ii) if the process that called request_key() itself had an
     	      authorisation key in its session keyring, then the authorising
     	      process referred to by that authorisation key will also be
     	      referred to by the new authorisation key.
	 This means that the process that initiated a chain of key requests
	 will authorise the lot of them, and will, by default, wind up with
	 the keys obtained from them in its keyrings.
 (2) request_key() creates an authorisation key which is then passed to
     /sbin/request-key in as part of a new session keyring.
 (3) When request_key() is searching for a key to hand back to the caller, if
     it comes across an authorisation key in the session keyring of the
     calling process, it will also search the keyrings of the process
     specified therein and it will use the specified process's credentials
     (fsuid, fsgid, groups) to do that rather than the calling process's
     credentials.
     This allows a process started by /sbin/request-key to find keys belonging
     to the authorising process.
 (4) A key can be read, even if the process executing KEYCTL_READ doesn't have
     direct read or search permission if that key is contained within the
     keyrings of a process specified by an authorisation key found within the
     calling process's session keyring, and is searchable using the
     credentials of the authorising process.
     This allows a process started by /sbin/request-key to read keys belonging
     to the authorising process.
 (5) The magic KEY_SPEC_*_KEYRING key IDs when passed to KEYCTL_INSTANTIATE or
     KEYCTL_NEGATE will specify a keyring of the authorising process, rather
     than the process doing the instantiation.
 (6) One of the process keyrings can be nominated as the default to which
     request_key() should attach new keys if not otherwise specified. This is
     done with KEYCTL_SET_REQKEY_KEYRING and one of the KEY_REQKEY_DEFL_*
     constants. The current setting can also be read using this call.
 (7) request_key() is partially interruptible. If it is waiting for another
     process to finish constructing a key, it can be interrupted. This permits
     a request-key cycle to be broken without recourse to rebooting.
Signed-Off-By: David Howells <dhowells@redhat.com>
Signed-Off-By: Benoit Boissinot <benoit.boissinot@ens-lyon.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
											
										 
											2005-06-23 22:00:56 -07:00
										 |  |  | 
 | 
					
						
							| 
									
										
										
										
											2007-10-16 23:29:46 -07:00
										 |  |  | 	cons = kmalloc(sizeof(*cons), GFP_KERNEL); | 
					
						
							|  |  |  | 	if (!cons) | 
					
						
							|  |  |  | 		return -ENOMEM; | 
					
						
							| 
									
										
										
										
											2005-04-16 15:20:36 -07:00
										 |  |  | 
 | 
					
						
							| 
									
										
										
										
											2006-01-08 01:02:47 -08:00
										 |  |  | 	/* allocate an authorisation key */ | 
					
						
							| 
									
										
											  
											
												KEYS: Alter use of key instantiation link-to-keyring argument
Alter the use of the key instantiation and negation functions' link-to-keyring
arguments.  Currently this specifies a keyring in the target process to link
the key into, creating the keyring if it doesn't exist.  This, however, can be
a problem for copy-on-write credentials as it means that the instantiating
process can alter the credentials of the requesting process.
This patch alters the behaviour such that:
 (1) If keyctl_instantiate_key() or keyctl_negate_key() are given a specific
     keyring by ID (ringid >= 0), then that keyring will be used.
 (2) If keyctl_instantiate_key() or keyctl_negate_key() are given one of the
     special constants that refer to the requesting process's keyrings
     (KEY_SPEC_*_KEYRING, all <= 0), then:
     (a) If sys_request_key() was given a keyring to use (destringid) then the
     	 key will be attached to that keyring.
     (b) If sys_request_key() was given a NULL keyring, then the key being
     	 instantiated will be attached to the default keyring as set by
     	 keyctl_set_reqkey_keyring().
 (3) No extra link will be made.
Decision point (1) follows current behaviour, and allows those instantiators
who've searched for a specifically named keyring in the requestor's keyring so
as to partition the keys by type to still have their named keyrings.
Decision point (2) allows the requestor to make sure that the key or keys that
get produced by request_key() go where they want, whilst allowing the
instantiator to request that the key is retained.  This is mainly useful for
situations where the instantiator makes a secondary request, the key for which
should be retained by the initial requestor:
	+-----------+        +--------------+        +--------------+
	|           |        |              |        |              |
	| Requestor |------->| Instantiator |------->| Instantiator |
	|           |        |              |        |              |
	+-----------+        +--------------+        +--------------+
	           request_key()           request_key()
This might be useful, for example, in Kerberos, where the requestor requests a
ticket, and then the ticket instantiator requests the TGT, which someone else
then has to go and fetch.  The TGT, however, should be retained in the
keyrings of the requestor, not the first instantiator.  To make this explict
an extra special keyring constant is also added.
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: James Morris <jmorris@namei.org>
Signed-off-by: James Morris <jmorris@namei.org>
											
										 
											2008-11-14 10:39:14 +11:00
										 |  |  | 	authkey = request_key_auth_new(key, callout_info, callout_len, | 
					
						
							|  |  |  | 				       dest_keyring); | 
					
						
							| 
									
										
										
										
											2006-01-08 01:02:47 -08:00
										 |  |  | 	if (IS_ERR(authkey)) { | 
					
						
							| 
									
										
										
										
											2007-10-16 23:29:46 -07:00
										 |  |  | 		kfree(cons); | 
					
						
							| 
									
										
										
										
											2006-01-08 01:02:47 -08:00
										 |  |  | 		ret = PTR_ERR(authkey); | 
					
						
							|  |  |  | 		authkey = NULL; | 
					
						
							| 
									
										
										
										
											2007-10-16 23:29:46 -07:00
										 |  |  | 	} else { | 
					
						
							|  |  |  | 		cons->authkey = key_get(authkey); | 
					
						
							|  |  |  | 		cons->key = key_get(key); | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | 		/* make the call */ | 
					
						
							|  |  |  | 		actor = call_sbin_request_key; | 
					
						
							|  |  |  | 		if (key->type->request_key) | 
					
						
							|  |  |  | 			actor = key->type->request_key; | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | 		ret = actor(cons, "create", aux); | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | 		/* check that the actor called complete_request_key() prior to
 | 
					
						
							|  |  |  | 		 * returning an error */ | 
					
						
							|  |  |  | 		WARN_ON(ret < 0 && | 
					
						
							|  |  |  | 			!test_bit(KEY_FLAG_REVOKED, &authkey->flags)); | 
					
						
							|  |  |  | 		key_put(authkey); | 
					
						
							| 
									
										
										
										
											2005-04-16 15:20:36 -07:00
										 |  |  | 	} | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2007-10-16 23:29:46 -07:00
										 |  |  | 	kleave(" = %d", ret); | 
					
						
							|  |  |  | 	return ret; | 
					
						
							|  |  |  | } | 
					
						
							| 
									
										
										
										
											2005-04-16 15:20:36 -07:00
										 |  |  | 
 | 
					
						
							| 
									
										
											  
											
												[PATCH] Keys: Make request-key create an authorisation key
The attached patch makes the following changes:
 (1) There's a new special key type called ".request_key_auth".
     This is an authorisation key for when one process requests a key and
     another process is started to construct it. This type of key cannot be
     created by the user; nor can it be requested by kernel services.
     Authorisation keys hold two references:
     (a) Each refers to a key being constructed. When the key being
     	 constructed is instantiated the authorisation key is revoked,
     	 rendering it of no further use.
     (b) The "authorising process". This is either:
     	 (i) the process that called request_key(), or:
     	 (ii) if the process that called request_key() itself had an
     	      authorisation key in its session keyring, then the authorising
     	      process referred to by that authorisation key will also be
     	      referred to by the new authorisation key.
	 This means that the process that initiated a chain of key requests
	 will authorise the lot of them, and will, by default, wind up with
	 the keys obtained from them in its keyrings.
 (2) request_key() creates an authorisation key which is then passed to
     /sbin/request-key in as part of a new session keyring.
 (3) When request_key() is searching for a key to hand back to the caller, if
     it comes across an authorisation key in the session keyring of the
     calling process, it will also search the keyrings of the process
     specified therein and it will use the specified process's credentials
     (fsuid, fsgid, groups) to do that rather than the calling process's
     credentials.
     This allows a process started by /sbin/request-key to find keys belonging
     to the authorising process.
 (4) A key can be read, even if the process executing KEYCTL_READ doesn't have
     direct read or search permission if that key is contained within the
     keyrings of a process specified by an authorisation key found within the
     calling process's session keyring, and is searchable using the
     credentials of the authorising process.
     This allows a process started by /sbin/request-key to read keys belonging
     to the authorising process.
 (5) The magic KEY_SPEC_*_KEYRING key IDs when passed to KEYCTL_INSTANTIATE or
     KEYCTL_NEGATE will specify a keyring of the authorising process, rather
     than the process doing the instantiation.
 (6) One of the process keyrings can be nominated as the default to which
     request_key() should attach new keys if not otherwise specified. This is
     done with KEYCTL_SET_REQKEY_KEYRING and one of the KEY_REQKEY_DEFL_*
     constants. The current setting can also be read using this call.
 (7) request_key() is partially interruptible. If it is waiting for another
     process to finish constructing a key, it can be interrupted. This permits
     a request-key cycle to be broken without recourse to rebooting.
Signed-Off-By: David Howells <dhowells@redhat.com>
Signed-Off-By: Benoit Boissinot <benoit.boissinot@ens-lyon.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
											
										 
											2005-06-23 22:00:56 -07:00
										 |  |  | /*
 | 
					
						
							| 
									
										
											  
											
												KEYS: Alter use of key instantiation link-to-keyring argument
Alter the use of the key instantiation and negation functions' link-to-keyring
arguments.  Currently this specifies a keyring in the target process to link
the key into, creating the keyring if it doesn't exist.  This, however, can be
a problem for copy-on-write credentials as it means that the instantiating
process can alter the credentials of the requesting process.
This patch alters the behaviour such that:
 (1) If keyctl_instantiate_key() or keyctl_negate_key() are given a specific
     keyring by ID (ringid >= 0), then that keyring will be used.
 (2) If keyctl_instantiate_key() or keyctl_negate_key() are given one of the
     special constants that refer to the requesting process's keyrings
     (KEY_SPEC_*_KEYRING, all <= 0), then:
     (a) If sys_request_key() was given a keyring to use (destringid) then the
     	 key will be attached to that keyring.
     (b) If sys_request_key() was given a NULL keyring, then the key being
     	 instantiated will be attached to the default keyring as set by
     	 keyctl_set_reqkey_keyring().
 (3) No extra link will be made.
Decision point (1) follows current behaviour, and allows those instantiators
who've searched for a specifically named keyring in the requestor's keyring so
as to partition the keys by type to still have their named keyrings.
Decision point (2) allows the requestor to make sure that the key or keys that
get produced by request_key() go where they want, whilst allowing the
instantiator to request that the key is retained.  This is mainly useful for
situations where the instantiator makes a secondary request, the key for which
should be retained by the initial requestor:
	+-----------+        +--------------+        +--------------+
	|           |        |              |        |              |
	| Requestor |------->| Instantiator |------->| Instantiator |
	|           |        |              |        |              |
	+-----------+        +--------------+        +--------------+
	           request_key()           request_key()
This might be useful, for example, in Kerberos, where the requestor requests a
ticket, and then the ticket instantiator requests the TGT, which someone else
then has to go and fetch.  The TGT, however, should be retained in the
keyrings of the requestor, not the first instantiator.  To make this explict
an extra special keyring constant is also added.
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: James Morris <jmorris@namei.org>
Signed-off-by: James Morris <jmorris@namei.org>
											
										 
											2008-11-14 10:39:14 +11:00
										 |  |  |  * get the appropriate destination keyring for the request | 
					
						
							|  |  |  |  * - we return whatever keyring we select with an extra reference upon it which | 
					
						
							|  |  |  |  *   the caller must release | 
					
						
							| 
									
										
											  
											
												[PATCH] Keys: Make request-key create an authorisation key
The attached patch makes the following changes:
 (1) There's a new special key type called ".request_key_auth".
     This is an authorisation key for when one process requests a key and
     another process is started to construct it. This type of key cannot be
     created by the user; nor can it be requested by kernel services.
     Authorisation keys hold two references:
     (a) Each refers to a key being constructed. When the key being
     	 constructed is instantiated the authorisation key is revoked,
     	 rendering it of no further use.
     (b) The "authorising process". This is either:
     	 (i) the process that called request_key(), or:
     	 (ii) if the process that called request_key() itself had an
     	      authorisation key in its session keyring, then the authorising
     	      process referred to by that authorisation key will also be
     	      referred to by the new authorisation key.
	 This means that the process that initiated a chain of key requests
	 will authorise the lot of them, and will, by default, wind up with
	 the keys obtained from them in its keyrings.
 (2) request_key() creates an authorisation key which is then passed to
     /sbin/request-key in as part of a new session keyring.
 (3) When request_key() is searching for a key to hand back to the caller, if
     it comes across an authorisation key in the session keyring of the
     calling process, it will also search the keyrings of the process
     specified therein and it will use the specified process's credentials
     (fsuid, fsgid, groups) to do that rather than the calling process's
     credentials.
     This allows a process started by /sbin/request-key to find keys belonging
     to the authorising process.
 (4) A key can be read, even if the process executing KEYCTL_READ doesn't have
     direct read or search permission if that key is contained within the
     keyrings of a process specified by an authorisation key found within the
     calling process's session keyring, and is searchable using the
     credentials of the authorising process.
     This allows a process started by /sbin/request-key to read keys belonging
     to the authorising process.
 (5) The magic KEY_SPEC_*_KEYRING key IDs when passed to KEYCTL_INSTANTIATE or
     KEYCTL_NEGATE will specify a keyring of the authorising process, rather
     than the process doing the instantiation.
 (6) One of the process keyrings can be nominated as the default to which
     request_key() should attach new keys if not otherwise specified. This is
     done with KEYCTL_SET_REQKEY_KEYRING and one of the KEY_REQKEY_DEFL_*
     constants. The current setting can also be read using this call.
 (7) request_key() is partially interruptible. If it is waiting for another
     process to finish constructing a key, it can be interrupted. This permits
     a request-key cycle to be broken without recourse to rebooting.
Signed-Off-By: David Howells <dhowells@redhat.com>
Signed-Off-By: Benoit Boissinot <benoit.boissinot@ens-lyon.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
											
										 
											2005-06-23 22:00:56 -07:00
										 |  |  |  */ | 
					
						
							| 
									
										
											  
											
												KEYS: Alter use of key instantiation link-to-keyring argument
Alter the use of the key instantiation and negation functions' link-to-keyring
arguments.  Currently this specifies a keyring in the target process to link
the key into, creating the keyring if it doesn't exist.  This, however, can be
a problem for copy-on-write credentials as it means that the instantiating
process can alter the credentials of the requesting process.
This patch alters the behaviour such that:
 (1) If keyctl_instantiate_key() or keyctl_negate_key() are given a specific
     keyring by ID (ringid >= 0), then that keyring will be used.
 (2) If keyctl_instantiate_key() or keyctl_negate_key() are given one of the
     special constants that refer to the requesting process's keyrings
     (KEY_SPEC_*_KEYRING, all <= 0), then:
     (a) If sys_request_key() was given a keyring to use (destringid) then the
     	 key will be attached to that keyring.
     (b) If sys_request_key() was given a NULL keyring, then the key being
     	 instantiated will be attached to the default keyring as set by
     	 keyctl_set_reqkey_keyring().
 (3) No extra link will be made.
Decision point (1) follows current behaviour, and allows those instantiators
who've searched for a specifically named keyring in the requestor's keyring so
as to partition the keys by type to still have their named keyrings.
Decision point (2) allows the requestor to make sure that the key or keys that
get produced by request_key() go where they want, whilst allowing the
instantiator to request that the key is retained.  This is mainly useful for
situations where the instantiator makes a secondary request, the key for which
should be retained by the initial requestor:
	+-----------+        +--------------+        +--------------+
	|           |        |              |        |              |
	| Requestor |------->| Instantiator |------->| Instantiator |
	|           |        |              |        |              |
	+-----------+        +--------------+        +--------------+
	           request_key()           request_key()
This might be useful, for example, in Kerberos, where the requestor requests a
ticket, and then the ticket instantiator requests the TGT, which someone else
then has to go and fetch.  The TGT, however, should be retained in the
keyrings of the requestor, not the first instantiator.  To make this explict
an extra special keyring constant is also added.
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: James Morris <jmorris@namei.org>
Signed-off-by: James Morris <jmorris@namei.org>
											
										 
											2008-11-14 10:39:14 +11:00
										 |  |  | static void construct_get_dest_keyring(struct key **_dest_keyring) | 
					
						
							| 
									
										
											  
											
												[PATCH] Keys: Make request-key create an authorisation key
The attached patch makes the following changes:
 (1) There's a new special key type called ".request_key_auth".
     This is an authorisation key for when one process requests a key and
     another process is started to construct it. This type of key cannot be
     created by the user; nor can it be requested by kernel services.
     Authorisation keys hold two references:
     (a) Each refers to a key being constructed. When the key being
     	 constructed is instantiated the authorisation key is revoked,
     	 rendering it of no further use.
     (b) The "authorising process". This is either:
     	 (i) the process that called request_key(), or:
     	 (ii) if the process that called request_key() itself had an
     	      authorisation key in its session keyring, then the authorising
     	      process referred to by that authorisation key will also be
     	      referred to by the new authorisation key.
	 This means that the process that initiated a chain of key requests
	 will authorise the lot of them, and will, by default, wind up with
	 the keys obtained from them in its keyrings.
 (2) request_key() creates an authorisation key which is then passed to
     /sbin/request-key in as part of a new session keyring.
 (3) When request_key() is searching for a key to hand back to the caller, if
     it comes across an authorisation key in the session keyring of the
     calling process, it will also search the keyrings of the process
     specified therein and it will use the specified process's credentials
     (fsuid, fsgid, groups) to do that rather than the calling process's
     credentials.
     This allows a process started by /sbin/request-key to find keys belonging
     to the authorising process.
 (4) A key can be read, even if the process executing KEYCTL_READ doesn't have
     direct read or search permission if that key is contained within the
     keyrings of a process specified by an authorisation key found within the
     calling process's session keyring, and is searchable using the
     credentials of the authorising process.
     This allows a process started by /sbin/request-key to read keys belonging
     to the authorising process.
 (5) The magic KEY_SPEC_*_KEYRING key IDs when passed to KEYCTL_INSTANTIATE or
     KEYCTL_NEGATE will specify a keyring of the authorising process, rather
     than the process doing the instantiation.
 (6) One of the process keyrings can be nominated as the default to which
     request_key() should attach new keys if not otherwise specified. This is
     done with KEYCTL_SET_REQKEY_KEYRING and one of the KEY_REQKEY_DEFL_*
     constants. The current setting can also be read using this call.
 (7) request_key() is partially interruptible. If it is waiting for another
     process to finish constructing a key, it can be interrupted. This permits
     a request-key cycle to be broken without recourse to rebooting.
Signed-Off-By: David Howells <dhowells@redhat.com>
Signed-Off-By: Benoit Boissinot <benoit.boissinot@ens-lyon.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
											
										 
											2005-06-23 22:00:56 -07:00
										 |  |  | { | 
					
						
							| 
									
										
											  
											
												KEYS: Alter use of key instantiation link-to-keyring argument
Alter the use of the key instantiation and negation functions' link-to-keyring
arguments.  Currently this specifies a keyring in the target process to link
the key into, creating the keyring if it doesn't exist.  This, however, can be
a problem for copy-on-write credentials as it means that the instantiating
process can alter the credentials of the requesting process.
This patch alters the behaviour such that:
 (1) If keyctl_instantiate_key() or keyctl_negate_key() are given a specific
     keyring by ID (ringid >= 0), then that keyring will be used.
 (2) If keyctl_instantiate_key() or keyctl_negate_key() are given one of the
     special constants that refer to the requesting process's keyrings
     (KEY_SPEC_*_KEYRING, all <= 0), then:
     (a) If sys_request_key() was given a keyring to use (destringid) then the
     	 key will be attached to that keyring.
     (b) If sys_request_key() was given a NULL keyring, then the key being
     	 instantiated will be attached to the default keyring as set by
     	 keyctl_set_reqkey_keyring().
 (3) No extra link will be made.
Decision point (1) follows current behaviour, and allows those instantiators
who've searched for a specifically named keyring in the requestor's keyring so
as to partition the keys by type to still have their named keyrings.
Decision point (2) allows the requestor to make sure that the key or keys that
get produced by request_key() go where they want, whilst allowing the
instantiator to request that the key is retained.  This is mainly useful for
situations where the instantiator makes a secondary request, the key for which
should be retained by the initial requestor:
	+-----------+        +--------------+        +--------------+
	|           |        |              |        |              |
	| Requestor |------->| Instantiator |------->| Instantiator |
	|           |        |              |        |              |
	+-----------+        +--------------+        +--------------+
	           request_key()           request_key()
This might be useful, for example, in Kerberos, where the requestor requests a
ticket, and then the ticket instantiator requests the TGT, which someone else
then has to go and fetch.  The TGT, however, should be retained in the
keyrings of the requestor, not the first instantiator.  To make this explict
an extra special keyring constant is also added.
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: James Morris <jmorris@namei.org>
Signed-off-by: James Morris <jmorris@namei.org>
											
										 
											2008-11-14 10:39:14 +11:00
										 |  |  | 	struct request_key_auth *rka; | 
					
						
							| 
									
										
										
										
											2008-11-14 10:39:20 +11:00
										 |  |  | 	const struct cred *cred = current_cred(); | 
					
						
							| 
									
										
											  
											
												KEYS: Alter use of key instantiation link-to-keyring argument
Alter the use of the key instantiation and negation functions' link-to-keyring
arguments.  Currently this specifies a keyring in the target process to link
the key into, creating the keyring if it doesn't exist.  This, however, can be
a problem for copy-on-write credentials as it means that the instantiating
process can alter the credentials of the requesting process.
This patch alters the behaviour such that:
 (1) If keyctl_instantiate_key() or keyctl_negate_key() are given a specific
     keyring by ID (ringid >= 0), then that keyring will be used.
 (2) If keyctl_instantiate_key() or keyctl_negate_key() are given one of the
     special constants that refer to the requesting process's keyrings
     (KEY_SPEC_*_KEYRING, all <= 0), then:
     (a) If sys_request_key() was given a keyring to use (destringid) then the
     	 key will be attached to that keyring.
     (b) If sys_request_key() was given a NULL keyring, then the key being
     	 instantiated will be attached to the default keyring as set by
     	 keyctl_set_reqkey_keyring().
 (3) No extra link will be made.
Decision point (1) follows current behaviour, and allows those instantiators
who've searched for a specifically named keyring in the requestor's keyring so
as to partition the keys by type to still have their named keyrings.
Decision point (2) allows the requestor to make sure that the key or keys that
get produced by request_key() go where they want, whilst allowing the
instantiator to request that the key is retained.  This is mainly useful for
situations where the instantiator makes a secondary request, the key for which
should be retained by the initial requestor:
	+-----------+        +--------------+        +--------------+
	|           |        |              |        |              |
	| Requestor |------->| Instantiator |------->| Instantiator |
	|           |        |              |        |              |
	+-----------+        +--------------+        +--------------+
	           request_key()           request_key()
This might be useful, for example, in Kerberos, where the requestor requests a
ticket, and then the ticket instantiator requests the TGT, which someone else
then has to go and fetch.  The TGT, however, should be retained in the
keyrings of the requestor, not the first instantiator.  To make this explict
an extra special keyring constant is also added.
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: James Morris <jmorris@namei.org>
Signed-off-by: James Morris <jmorris@namei.org>
											
										 
											2008-11-14 10:39:14 +11:00
										 |  |  | 	struct key *dest_keyring = *_dest_keyring, *authkey; | 
					
						
							| 
									
										
											  
											
												[PATCH] Keys: Make request-key create an authorisation key
The attached patch makes the following changes:
 (1) There's a new special key type called ".request_key_auth".
     This is an authorisation key for when one process requests a key and
     another process is started to construct it. This type of key cannot be
     created by the user; nor can it be requested by kernel services.
     Authorisation keys hold two references:
     (a) Each refers to a key being constructed. When the key being
     	 constructed is instantiated the authorisation key is revoked,
     	 rendering it of no further use.
     (b) The "authorising process". This is either:
     	 (i) the process that called request_key(), or:
     	 (ii) if the process that called request_key() itself had an
     	      authorisation key in its session keyring, then the authorising
     	      process referred to by that authorisation key will also be
     	      referred to by the new authorisation key.
	 This means that the process that initiated a chain of key requests
	 will authorise the lot of them, and will, by default, wind up with
	 the keys obtained from them in its keyrings.
 (2) request_key() creates an authorisation key which is then passed to
     /sbin/request-key in as part of a new session keyring.
 (3) When request_key() is searching for a key to hand back to the caller, if
     it comes across an authorisation key in the session keyring of the
     calling process, it will also search the keyrings of the process
     specified therein and it will use the specified process's credentials
     (fsuid, fsgid, groups) to do that rather than the calling process's
     credentials.
     This allows a process started by /sbin/request-key to find keys belonging
     to the authorising process.
 (4) A key can be read, even if the process executing KEYCTL_READ doesn't have
     direct read or search permission if that key is contained within the
     keyrings of a process specified by an authorisation key found within the
     calling process's session keyring, and is searchable using the
     credentials of the authorising process.
     This allows a process started by /sbin/request-key to read keys belonging
     to the authorising process.
 (5) The magic KEY_SPEC_*_KEYRING key IDs when passed to KEYCTL_INSTANTIATE or
     KEYCTL_NEGATE will specify a keyring of the authorising process, rather
     than the process doing the instantiation.
 (6) One of the process keyrings can be nominated as the default to which
     request_key() should attach new keys if not otherwise specified. This is
     done with KEYCTL_SET_REQKEY_KEYRING and one of the KEY_REQKEY_DEFL_*
     constants. The current setting can also be read using this call.
 (7) request_key() is partially interruptible. If it is waiting for another
     process to finish constructing a key, it can be interrupted. This permits
     a request-key cycle to be broken without recourse to rebooting.
Signed-Off-By: David Howells <dhowells@redhat.com>
Signed-Off-By: Benoit Boissinot <benoit.boissinot@ens-lyon.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
											
										 
											2005-06-23 22:00:56 -07:00
										 |  |  | 
 | 
					
						
							| 
									
										
											  
											
												KEYS: Alter use of key instantiation link-to-keyring argument
Alter the use of the key instantiation and negation functions' link-to-keyring
arguments.  Currently this specifies a keyring in the target process to link
the key into, creating the keyring if it doesn't exist.  This, however, can be
a problem for copy-on-write credentials as it means that the instantiating
process can alter the credentials of the requesting process.
This patch alters the behaviour such that:
 (1) If keyctl_instantiate_key() or keyctl_negate_key() are given a specific
     keyring by ID (ringid >= 0), then that keyring will be used.
 (2) If keyctl_instantiate_key() or keyctl_negate_key() are given one of the
     special constants that refer to the requesting process's keyrings
     (KEY_SPEC_*_KEYRING, all <= 0), then:
     (a) If sys_request_key() was given a keyring to use (destringid) then the
     	 key will be attached to that keyring.
     (b) If sys_request_key() was given a NULL keyring, then the key being
     	 instantiated will be attached to the default keyring as set by
     	 keyctl_set_reqkey_keyring().
 (3) No extra link will be made.
Decision point (1) follows current behaviour, and allows those instantiators
who've searched for a specifically named keyring in the requestor's keyring so
as to partition the keys by type to still have their named keyrings.
Decision point (2) allows the requestor to make sure that the key or keys that
get produced by request_key() go where they want, whilst allowing the
instantiator to request that the key is retained.  This is mainly useful for
situations where the instantiator makes a secondary request, the key for which
should be retained by the initial requestor:
	+-----------+        +--------------+        +--------------+
	|           |        |              |        |              |
	| Requestor |------->| Instantiator |------->| Instantiator |
	|           |        |              |        |              |
	+-----------+        +--------------+        +--------------+
	           request_key()           request_key()
This might be useful, for example, in Kerberos, where the requestor requests a
ticket, and then the ticket instantiator requests the TGT, which someone else
then has to go and fetch.  The TGT, however, should be retained in the
keyrings of the requestor, not the first instantiator.  To make this explict
an extra special keyring constant is also added.
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: James Morris <jmorris@namei.org>
Signed-off-by: James Morris <jmorris@namei.org>
											
										 
											2008-11-14 10:39:14 +11:00
										 |  |  | 	kenter("%p", dest_keyring); | 
					
						
							| 
									
										
											  
											
												[PATCH] Keys: Make request-key create an authorisation key
The attached patch makes the following changes:
 (1) There's a new special key type called ".request_key_auth".
     This is an authorisation key for when one process requests a key and
     another process is started to construct it. This type of key cannot be
     created by the user; nor can it be requested by kernel services.
     Authorisation keys hold two references:
     (a) Each refers to a key being constructed. When the key being
     	 constructed is instantiated the authorisation key is revoked,
     	 rendering it of no further use.
     (b) The "authorising process". This is either:
     	 (i) the process that called request_key(), or:
     	 (ii) if the process that called request_key() itself had an
     	      authorisation key in its session keyring, then the authorising
     	      process referred to by that authorisation key will also be
     	      referred to by the new authorisation key.
	 This means that the process that initiated a chain of key requests
	 will authorise the lot of them, and will, by default, wind up with
	 the keys obtained from them in its keyrings.
 (2) request_key() creates an authorisation key which is then passed to
     /sbin/request-key in as part of a new session keyring.
 (3) When request_key() is searching for a key to hand back to the caller, if
     it comes across an authorisation key in the session keyring of the
     calling process, it will also search the keyrings of the process
     specified therein and it will use the specified process's credentials
     (fsuid, fsgid, groups) to do that rather than the calling process's
     credentials.
     This allows a process started by /sbin/request-key to find keys belonging
     to the authorising process.
 (4) A key can be read, even if the process executing KEYCTL_READ doesn't have
     direct read or search permission if that key is contained within the
     keyrings of a process specified by an authorisation key found within the
     calling process's session keyring, and is searchable using the
     credentials of the authorising process.
     This allows a process started by /sbin/request-key to read keys belonging
     to the authorising process.
 (5) The magic KEY_SPEC_*_KEYRING key IDs when passed to KEYCTL_INSTANTIATE or
     KEYCTL_NEGATE will specify a keyring of the authorising process, rather
     than the process doing the instantiation.
 (6) One of the process keyrings can be nominated as the default to which
     request_key() should attach new keys if not otherwise specified. This is
     done with KEYCTL_SET_REQKEY_KEYRING and one of the KEY_REQKEY_DEFL_*
     constants. The current setting can also be read using this call.
 (7) request_key() is partially interruptible. If it is waiting for another
     process to finish constructing a key, it can be interrupted. This permits
     a request-key cycle to be broken without recourse to rebooting.
Signed-Off-By: David Howells <dhowells@redhat.com>
Signed-Off-By: Benoit Boissinot <benoit.boissinot@ens-lyon.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
											
										 
											2005-06-23 22:00:56 -07:00
										 |  |  | 
 | 
					
						
							|  |  |  | 	/* find the appropriate keyring */ | 
					
						
							| 
									
										
											  
											
												KEYS: Alter use of key instantiation link-to-keyring argument
Alter the use of the key instantiation and negation functions' link-to-keyring
arguments.  Currently this specifies a keyring in the target process to link
the key into, creating the keyring if it doesn't exist.  This, however, can be
a problem for copy-on-write credentials as it means that the instantiating
process can alter the credentials of the requesting process.
This patch alters the behaviour such that:
 (1) If keyctl_instantiate_key() or keyctl_negate_key() are given a specific
     keyring by ID (ringid >= 0), then that keyring will be used.
 (2) If keyctl_instantiate_key() or keyctl_negate_key() are given one of the
     special constants that refer to the requesting process's keyrings
     (KEY_SPEC_*_KEYRING, all <= 0), then:
     (a) If sys_request_key() was given a keyring to use (destringid) then the
     	 key will be attached to that keyring.
     (b) If sys_request_key() was given a NULL keyring, then the key being
     	 instantiated will be attached to the default keyring as set by
     	 keyctl_set_reqkey_keyring().
 (3) No extra link will be made.
Decision point (1) follows current behaviour, and allows those instantiators
who've searched for a specifically named keyring in the requestor's keyring so
as to partition the keys by type to still have their named keyrings.
Decision point (2) allows the requestor to make sure that the key or keys that
get produced by request_key() go where they want, whilst allowing the
instantiator to request that the key is retained.  This is mainly useful for
situations where the instantiator makes a secondary request, the key for which
should be retained by the initial requestor:
	+-----------+        +--------------+        +--------------+
	|           |        |              |        |              |
	| Requestor |------->| Instantiator |------->| Instantiator |
	|           |        |              |        |              |
	+-----------+        +--------------+        +--------------+
	           request_key()           request_key()
This might be useful, for example, in Kerberos, where the requestor requests a
ticket, and then the ticket instantiator requests the TGT, which someone else
then has to go and fetch.  The TGT, however, should be retained in the
keyrings of the requestor, not the first instantiator.  To make this explict
an extra special keyring constant is also added.
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: James Morris <jmorris@namei.org>
Signed-off-by: James Morris <jmorris@namei.org>
											
										 
											2008-11-14 10:39:14 +11:00
										 |  |  | 	if (dest_keyring) { | 
					
						
							|  |  |  | 		/* the caller supplied one */ | 
					
						
							|  |  |  | 		key_get(dest_keyring); | 
					
						
							|  |  |  | 	} else { | 
					
						
							|  |  |  | 		/* use a default keyring; falling through the cases until we
 | 
					
						
							|  |  |  | 		 * find one that we actually have */ | 
					
						
							| 
									
										
										
										
											2008-11-14 10:39:20 +11:00
										 |  |  | 		switch (cred->jit_keyring) { | 
					
						
							| 
									
										
											  
											
												[PATCH] Keys: Make request-key create an authorisation key
The attached patch makes the following changes:
 (1) There's a new special key type called ".request_key_auth".
     This is an authorisation key for when one process requests a key and
     another process is started to construct it. This type of key cannot be
     created by the user; nor can it be requested by kernel services.
     Authorisation keys hold two references:
     (a) Each refers to a key being constructed. When the key being
     	 constructed is instantiated the authorisation key is revoked,
     	 rendering it of no further use.
     (b) The "authorising process". This is either:
     	 (i) the process that called request_key(), or:
     	 (ii) if the process that called request_key() itself had an
     	      authorisation key in its session keyring, then the authorising
     	      process referred to by that authorisation key will also be
     	      referred to by the new authorisation key.
	 This means that the process that initiated a chain of key requests
	 will authorise the lot of them, and will, by default, wind up with
	 the keys obtained from them in its keyrings.
 (2) request_key() creates an authorisation key which is then passed to
     /sbin/request-key in as part of a new session keyring.
 (3) When request_key() is searching for a key to hand back to the caller, if
     it comes across an authorisation key in the session keyring of the
     calling process, it will also search the keyrings of the process
     specified therein and it will use the specified process's credentials
     (fsuid, fsgid, groups) to do that rather than the calling process's
     credentials.
     This allows a process started by /sbin/request-key to find keys belonging
     to the authorising process.
 (4) A key can be read, even if the process executing KEYCTL_READ doesn't have
     direct read or search permission if that key is contained within the
     keyrings of a process specified by an authorisation key found within the
     calling process's session keyring, and is searchable using the
     credentials of the authorising process.
     This allows a process started by /sbin/request-key to read keys belonging
     to the authorising process.
 (5) The magic KEY_SPEC_*_KEYRING key IDs when passed to KEYCTL_INSTANTIATE or
     KEYCTL_NEGATE will specify a keyring of the authorising process, rather
     than the process doing the instantiation.
 (6) One of the process keyrings can be nominated as the default to which
     request_key() should attach new keys if not otherwise specified. This is
     done with KEYCTL_SET_REQKEY_KEYRING and one of the KEY_REQKEY_DEFL_*
     constants. The current setting can also be read using this call.
 (7) request_key() is partially interruptible. If it is waiting for another
     process to finish constructing a key, it can be interrupted. This permits
     a request-key cycle to be broken without recourse to rebooting.
Signed-Off-By: David Howells <dhowells@redhat.com>
Signed-Off-By: Benoit Boissinot <benoit.boissinot@ens-lyon.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
											
										 
											2005-06-23 22:00:56 -07:00
										 |  |  | 		case KEY_REQKEY_DEFL_DEFAULT: | 
					
						
							| 
									
										
											  
											
												KEYS: Alter use of key instantiation link-to-keyring argument
Alter the use of the key instantiation and negation functions' link-to-keyring
arguments.  Currently this specifies a keyring in the target process to link
the key into, creating the keyring if it doesn't exist.  This, however, can be
a problem for copy-on-write credentials as it means that the instantiating
process can alter the credentials of the requesting process.
This patch alters the behaviour such that:
 (1) If keyctl_instantiate_key() or keyctl_negate_key() are given a specific
     keyring by ID (ringid >= 0), then that keyring will be used.
 (2) If keyctl_instantiate_key() or keyctl_negate_key() are given one of the
     special constants that refer to the requesting process's keyrings
     (KEY_SPEC_*_KEYRING, all <= 0), then:
     (a) If sys_request_key() was given a keyring to use (destringid) then the
     	 key will be attached to that keyring.
     (b) If sys_request_key() was given a NULL keyring, then the key being
     	 instantiated will be attached to the default keyring as set by
     	 keyctl_set_reqkey_keyring().
 (3) No extra link will be made.
Decision point (1) follows current behaviour, and allows those instantiators
who've searched for a specifically named keyring in the requestor's keyring so
as to partition the keys by type to still have their named keyrings.
Decision point (2) allows the requestor to make sure that the key or keys that
get produced by request_key() go where they want, whilst allowing the
instantiator to request that the key is retained.  This is mainly useful for
situations where the instantiator makes a secondary request, the key for which
should be retained by the initial requestor:
	+-----------+        +--------------+        +--------------+
	|           |        |              |        |              |
	| Requestor |------->| Instantiator |------->| Instantiator |
	|           |        |              |        |              |
	+-----------+        +--------------+        +--------------+
	           request_key()           request_key()
This might be useful, for example, in Kerberos, where the requestor requests a
ticket, and then the ticket instantiator requests the TGT, which someone else
then has to go and fetch.  The TGT, however, should be retained in the
keyrings of the requestor, not the first instantiator.  To make this explict
an extra special keyring constant is also added.
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: James Morris <jmorris@namei.org>
Signed-off-by: James Morris <jmorris@namei.org>
											
										 
											2008-11-14 10:39:14 +11:00
										 |  |  | 		case KEY_REQKEY_DEFL_REQUESTOR_KEYRING: | 
					
						
							| 
									
										
										
										
											2008-11-14 10:39:20 +11:00
										 |  |  | 			if (cred->request_key_auth) { | 
					
						
							|  |  |  | 				authkey = cred->request_key_auth; | 
					
						
							| 
									
										
											  
											
												KEYS: Alter use of key instantiation link-to-keyring argument
Alter the use of the key instantiation and negation functions' link-to-keyring
arguments.  Currently this specifies a keyring in the target process to link
the key into, creating the keyring if it doesn't exist.  This, however, can be
a problem for copy-on-write credentials as it means that the instantiating
process can alter the credentials of the requesting process.
This patch alters the behaviour such that:
 (1) If keyctl_instantiate_key() or keyctl_negate_key() are given a specific
     keyring by ID (ringid >= 0), then that keyring will be used.
 (2) If keyctl_instantiate_key() or keyctl_negate_key() are given one of the
     special constants that refer to the requesting process's keyrings
     (KEY_SPEC_*_KEYRING, all <= 0), then:
     (a) If sys_request_key() was given a keyring to use (destringid) then the
     	 key will be attached to that keyring.
     (b) If sys_request_key() was given a NULL keyring, then the key being
     	 instantiated will be attached to the default keyring as set by
     	 keyctl_set_reqkey_keyring().
 (3) No extra link will be made.
Decision point (1) follows current behaviour, and allows those instantiators
who've searched for a specifically named keyring in the requestor's keyring so
as to partition the keys by type to still have their named keyrings.
Decision point (2) allows the requestor to make sure that the key or keys that
get produced by request_key() go where they want, whilst allowing the
instantiator to request that the key is retained.  This is mainly useful for
situations where the instantiator makes a secondary request, the key for which
should be retained by the initial requestor:
	+-----------+        +--------------+        +--------------+
	|           |        |              |        |              |
	| Requestor |------->| Instantiator |------->| Instantiator |
	|           |        |              |        |              |
	+-----------+        +--------------+        +--------------+
	           request_key()           request_key()
This might be useful, for example, in Kerberos, where the requestor requests a
ticket, and then the ticket instantiator requests the TGT, which someone else
then has to go and fetch.  The TGT, however, should be retained in the
keyrings of the requestor, not the first instantiator.  To make this explict
an extra special keyring constant is also added.
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: James Morris <jmorris@namei.org>
Signed-off-by: James Morris <jmorris@namei.org>
											
										 
											2008-11-14 10:39:14 +11:00
										 |  |  | 				down_read(&authkey->sem); | 
					
						
							|  |  |  | 				rka = authkey->payload.data; | 
					
						
							|  |  |  | 				if (!test_bit(KEY_FLAG_REVOKED, | 
					
						
							|  |  |  | 					      &authkey->flags)) | 
					
						
							|  |  |  | 					dest_keyring = | 
					
						
							|  |  |  | 						key_get(rka->dest_keyring); | 
					
						
							|  |  |  | 				up_read(&authkey->sem); | 
					
						
							|  |  |  | 				if (dest_keyring) | 
					
						
							|  |  |  | 					break; | 
					
						
							|  |  |  | 			} | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
											  
											
												[PATCH] Keys: Make request-key create an authorisation key
The attached patch makes the following changes:
 (1) There's a new special key type called ".request_key_auth".
     This is an authorisation key for when one process requests a key and
     another process is started to construct it. This type of key cannot be
     created by the user; nor can it be requested by kernel services.
     Authorisation keys hold two references:
     (a) Each refers to a key being constructed. When the key being
     	 constructed is instantiated the authorisation key is revoked,
     	 rendering it of no further use.
     (b) The "authorising process". This is either:
     	 (i) the process that called request_key(), or:
     	 (ii) if the process that called request_key() itself had an
     	      authorisation key in its session keyring, then the authorising
     	      process referred to by that authorisation key will also be
     	      referred to by the new authorisation key.
	 This means that the process that initiated a chain of key requests
	 will authorise the lot of them, and will, by default, wind up with
	 the keys obtained from them in its keyrings.
 (2) request_key() creates an authorisation key which is then passed to
     /sbin/request-key in as part of a new session keyring.
 (3) When request_key() is searching for a key to hand back to the caller, if
     it comes across an authorisation key in the session keyring of the
     calling process, it will also search the keyrings of the process
     specified therein and it will use the specified process's credentials
     (fsuid, fsgid, groups) to do that rather than the calling process's
     credentials.
     This allows a process started by /sbin/request-key to find keys belonging
     to the authorising process.
 (4) A key can be read, even if the process executing KEYCTL_READ doesn't have
     direct read or search permission if that key is contained within the
     keyrings of a process specified by an authorisation key found within the
     calling process's session keyring, and is searchable using the
     credentials of the authorising process.
     This allows a process started by /sbin/request-key to read keys belonging
     to the authorising process.
 (5) The magic KEY_SPEC_*_KEYRING key IDs when passed to KEYCTL_INSTANTIATE or
     KEYCTL_NEGATE will specify a keyring of the authorising process, rather
     than the process doing the instantiation.
 (6) One of the process keyrings can be nominated as the default to which
     request_key() should attach new keys if not otherwise specified. This is
     done with KEYCTL_SET_REQKEY_KEYRING and one of the KEY_REQKEY_DEFL_*
     constants. The current setting can also be read using this call.
 (7) request_key() is partially interruptible. If it is waiting for another
     process to finish constructing a key, it can be interrupted. This permits
     a request-key cycle to be broken without recourse to rebooting.
Signed-Off-By: David Howells <dhowells@redhat.com>
Signed-Off-By: Benoit Boissinot <benoit.boissinot@ens-lyon.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
											
										 
											2005-06-23 22:00:56 -07:00
										 |  |  | 		case KEY_REQKEY_DEFL_THREAD_KEYRING: | 
					
						
							| 
									
										
										
										
											2008-11-14 10:39:20 +11:00
										 |  |  | 			dest_keyring = key_get(cred->thread_keyring); | 
					
						
							| 
									
										
											  
											
												[PATCH] Keys: Make request-key create an authorisation key
The attached patch makes the following changes:
 (1) There's a new special key type called ".request_key_auth".
     This is an authorisation key for when one process requests a key and
     another process is started to construct it. This type of key cannot be
     created by the user; nor can it be requested by kernel services.
     Authorisation keys hold two references:
     (a) Each refers to a key being constructed. When the key being
     	 constructed is instantiated the authorisation key is revoked,
     	 rendering it of no further use.
     (b) The "authorising process". This is either:
     	 (i) the process that called request_key(), or:
     	 (ii) if the process that called request_key() itself had an
     	      authorisation key in its session keyring, then the authorising
     	      process referred to by that authorisation key will also be
     	      referred to by the new authorisation key.
	 This means that the process that initiated a chain of key requests
	 will authorise the lot of them, and will, by default, wind up with
	 the keys obtained from them in its keyrings.
 (2) request_key() creates an authorisation key which is then passed to
     /sbin/request-key in as part of a new session keyring.
 (3) When request_key() is searching for a key to hand back to the caller, if
     it comes across an authorisation key in the session keyring of the
     calling process, it will also search the keyrings of the process
     specified therein and it will use the specified process's credentials
     (fsuid, fsgid, groups) to do that rather than the calling process's
     credentials.
     This allows a process started by /sbin/request-key to find keys belonging
     to the authorising process.
 (4) A key can be read, even if the process executing KEYCTL_READ doesn't have
     direct read or search permission if that key is contained within the
     keyrings of a process specified by an authorisation key found within the
     calling process's session keyring, and is searchable using the
     credentials of the authorising process.
     This allows a process started by /sbin/request-key to read keys belonging
     to the authorising process.
 (5) The magic KEY_SPEC_*_KEYRING key IDs when passed to KEYCTL_INSTANTIATE or
     KEYCTL_NEGATE will specify a keyring of the authorising process, rather
     than the process doing the instantiation.
 (6) One of the process keyrings can be nominated as the default to which
     request_key() should attach new keys if not otherwise specified. This is
     done with KEYCTL_SET_REQKEY_KEYRING and one of the KEY_REQKEY_DEFL_*
     constants. The current setting can also be read using this call.
 (7) request_key() is partially interruptible. If it is waiting for another
     process to finish constructing a key, it can be interrupted. This permits
     a request-key cycle to be broken without recourse to rebooting.
Signed-Off-By: David Howells <dhowells@redhat.com>
Signed-Off-By: Benoit Boissinot <benoit.boissinot@ens-lyon.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
											
										 
											2005-06-23 22:00:56 -07:00
										 |  |  | 			if (dest_keyring) | 
					
						
							|  |  |  | 				break; | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | 		case KEY_REQKEY_DEFL_PROCESS_KEYRING: | 
					
						
							| 
									
										
										
										
											2008-11-14 10:39:20 +11:00
										 |  |  | 			dest_keyring = key_get(cred->tgcred->process_keyring); | 
					
						
							| 
									
										
											  
											
												[PATCH] Keys: Make request-key create an authorisation key
The attached patch makes the following changes:
 (1) There's a new special key type called ".request_key_auth".
     This is an authorisation key for when one process requests a key and
     another process is started to construct it. This type of key cannot be
     created by the user; nor can it be requested by kernel services.
     Authorisation keys hold two references:
     (a) Each refers to a key being constructed. When the key being
     	 constructed is instantiated the authorisation key is revoked,
     	 rendering it of no further use.
     (b) The "authorising process". This is either:
     	 (i) the process that called request_key(), or:
     	 (ii) if the process that called request_key() itself had an
     	      authorisation key in its session keyring, then the authorising
     	      process referred to by that authorisation key will also be
     	      referred to by the new authorisation key.
	 This means that the process that initiated a chain of key requests
	 will authorise the lot of them, and will, by default, wind up with
	 the keys obtained from them in its keyrings.
 (2) request_key() creates an authorisation key which is then passed to
     /sbin/request-key in as part of a new session keyring.
 (3) When request_key() is searching for a key to hand back to the caller, if
     it comes across an authorisation key in the session keyring of the
     calling process, it will also search the keyrings of the process
     specified therein and it will use the specified process's credentials
     (fsuid, fsgid, groups) to do that rather than the calling process's
     credentials.
     This allows a process started by /sbin/request-key to find keys belonging
     to the authorising process.
 (4) A key can be read, even if the process executing KEYCTL_READ doesn't have
     direct read or search permission if that key is contained within the
     keyrings of a process specified by an authorisation key found within the
     calling process's session keyring, and is searchable using the
     credentials of the authorising process.
     This allows a process started by /sbin/request-key to read keys belonging
     to the authorising process.
 (5) The magic KEY_SPEC_*_KEYRING key IDs when passed to KEYCTL_INSTANTIATE or
     KEYCTL_NEGATE will specify a keyring of the authorising process, rather
     than the process doing the instantiation.
 (6) One of the process keyrings can be nominated as the default to which
     request_key() should attach new keys if not otherwise specified. This is
     done with KEYCTL_SET_REQKEY_KEYRING and one of the KEY_REQKEY_DEFL_*
     constants. The current setting can also be read using this call.
 (7) request_key() is partially interruptible. If it is waiting for another
     process to finish constructing a key, it can be interrupted. This permits
     a request-key cycle to be broken without recourse to rebooting.
Signed-Off-By: David Howells <dhowells@redhat.com>
Signed-Off-By: Benoit Boissinot <benoit.boissinot@ens-lyon.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
											
										 
											2005-06-23 22:00:56 -07:00
										 |  |  | 			if (dest_keyring) | 
					
						
							|  |  |  | 				break; | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | 		case KEY_REQKEY_DEFL_SESSION_KEYRING: | 
					
						
							|  |  |  | 			rcu_read_lock(); | 
					
						
							|  |  |  | 			dest_keyring = key_get( | 
					
						
							| 
									
										
										
										
											2008-11-14 10:39:20 +11:00
										 |  |  | 				rcu_dereference(cred->tgcred->session_keyring)); | 
					
						
							| 
									
										
											  
											
												[PATCH] Keys: Make request-key create an authorisation key
The attached patch makes the following changes:
 (1) There's a new special key type called ".request_key_auth".
     This is an authorisation key for when one process requests a key and
     another process is started to construct it. This type of key cannot be
     created by the user; nor can it be requested by kernel services.
     Authorisation keys hold two references:
     (a) Each refers to a key being constructed. When the key being
     	 constructed is instantiated the authorisation key is revoked,
     	 rendering it of no further use.
     (b) The "authorising process". This is either:
     	 (i) the process that called request_key(), or:
     	 (ii) if the process that called request_key() itself had an
     	      authorisation key in its session keyring, then the authorising
     	      process referred to by that authorisation key will also be
     	      referred to by the new authorisation key.
	 This means that the process that initiated a chain of key requests
	 will authorise the lot of them, and will, by default, wind up with
	 the keys obtained from them in its keyrings.
 (2) request_key() creates an authorisation key which is then passed to
     /sbin/request-key in as part of a new session keyring.
 (3) When request_key() is searching for a key to hand back to the caller, if
     it comes across an authorisation key in the session keyring of the
     calling process, it will also search the keyrings of the process
     specified therein and it will use the specified process's credentials
     (fsuid, fsgid, groups) to do that rather than the calling process's
     credentials.
     This allows a process started by /sbin/request-key to find keys belonging
     to the authorising process.
 (4) A key can be read, even if the process executing KEYCTL_READ doesn't have
     direct read or search permission if that key is contained within the
     keyrings of a process specified by an authorisation key found within the
     calling process's session keyring, and is searchable using the
     credentials of the authorising process.
     This allows a process started by /sbin/request-key to read keys belonging
     to the authorising process.
 (5) The magic KEY_SPEC_*_KEYRING key IDs when passed to KEYCTL_INSTANTIATE or
     KEYCTL_NEGATE will specify a keyring of the authorising process, rather
     than the process doing the instantiation.
 (6) One of the process keyrings can be nominated as the default to which
     request_key() should attach new keys if not otherwise specified. This is
     done with KEYCTL_SET_REQKEY_KEYRING and one of the KEY_REQKEY_DEFL_*
     constants. The current setting can also be read using this call.
 (7) request_key() is partially interruptible. If it is waiting for another
     process to finish constructing a key, it can be interrupted. This permits
     a request-key cycle to be broken without recourse to rebooting.
Signed-Off-By: David Howells <dhowells@redhat.com>
Signed-Off-By: Benoit Boissinot <benoit.boissinot@ens-lyon.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
											
										 
											2005-06-23 22:00:56 -07:00
										 |  |  | 			rcu_read_unlock(); | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | 			if (dest_keyring) | 
					
						
							|  |  |  | 				break; | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | 		case KEY_REQKEY_DEFL_USER_SESSION_KEYRING: | 
					
						
							| 
									
										
										
										
											2008-11-14 10:39:16 +11:00
										 |  |  | 			dest_keyring = | 
					
						
							| 
									
										
										
										
											2008-11-14 10:39:20 +11:00
										 |  |  | 				key_get(cred->user->session_keyring); | 
					
						
							| 
									
										
											  
											
												[PATCH] Keys: Make request-key create an authorisation key
The attached patch makes the following changes:
 (1) There's a new special key type called ".request_key_auth".
     This is an authorisation key for when one process requests a key and
     another process is started to construct it. This type of key cannot be
     created by the user; nor can it be requested by kernel services.
     Authorisation keys hold two references:
     (a) Each refers to a key being constructed. When the key being
     	 constructed is instantiated the authorisation key is revoked,
     	 rendering it of no further use.
     (b) The "authorising process". This is either:
     	 (i) the process that called request_key(), or:
     	 (ii) if the process that called request_key() itself had an
     	      authorisation key in its session keyring, then the authorising
     	      process referred to by that authorisation key will also be
     	      referred to by the new authorisation key.
	 This means that the process that initiated a chain of key requests
	 will authorise the lot of them, and will, by default, wind up with
	 the keys obtained from them in its keyrings.
 (2) request_key() creates an authorisation key which is then passed to
     /sbin/request-key in as part of a new session keyring.
 (3) When request_key() is searching for a key to hand back to the caller, if
     it comes across an authorisation key in the session keyring of the
     calling process, it will also search the keyrings of the process
     specified therein and it will use the specified process's credentials
     (fsuid, fsgid, groups) to do that rather than the calling process's
     credentials.
     This allows a process started by /sbin/request-key to find keys belonging
     to the authorising process.
 (4) A key can be read, even if the process executing KEYCTL_READ doesn't have
     direct read or search permission if that key is contained within the
     keyrings of a process specified by an authorisation key found within the
     calling process's session keyring, and is searchable using the
     credentials of the authorising process.
     This allows a process started by /sbin/request-key to read keys belonging
     to the authorising process.
 (5) The magic KEY_SPEC_*_KEYRING key IDs when passed to KEYCTL_INSTANTIATE or
     KEYCTL_NEGATE will specify a keyring of the authorising process, rather
     than the process doing the instantiation.
 (6) One of the process keyrings can be nominated as the default to which
     request_key() should attach new keys if not otherwise specified. This is
     done with KEYCTL_SET_REQKEY_KEYRING and one of the KEY_REQKEY_DEFL_*
     constants. The current setting can also be read using this call.
 (7) request_key() is partially interruptible. If it is waiting for another
     process to finish constructing a key, it can be interrupted. This permits
     a request-key cycle to be broken without recourse to rebooting.
Signed-Off-By: David Howells <dhowells@redhat.com>
Signed-Off-By: Benoit Boissinot <benoit.boissinot@ens-lyon.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
											
										 
											2005-06-23 22:00:56 -07:00
										 |  |  | 			break; | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | 		case KEY_REQKEY_DEFL_USER_KEYRING: | 
					
						
							| 
									
										
										
										
											2008-11-14 10:39:20 +11:00
										 |  |  | 			dest_keyring = key_get(cred->user->uid_keyring); | 
					
						
							| 
									
										
											  
											
												[PATCH] Keys: Make request-key create an authorisation key
The attached patch makes the following changes:
 (1) There's a new special key type called ".request_key_auth".
     This is an authorisation key for when one process requests a key and
     another process is started to construct it. This type of key cannot be
     created by the user; nor can it be requested by kernel services.
     Authorisation keys hold two references:
     (a) Each refers to a key being constructed. When the key being
     	 constructed is instantiated the authorisation key is revoked,
     	 rendering it of no further use.
     (b) The "authorising process". This is either:
     	 (i) the process that called request_key(), or:
     	 (ii) if the process that called request_key() itself had an
     	      authorisation key in its session keyring, then the authorising
     	      process referred to by that authorisation key will also be
     	      referred to by the new authorisation key.
	 This means that the process that initiated a chain of key requests
	 will authorise the lot of them, and will, by default, wind up with
	 the keys obtained from them in its keyrings.
 (2) request_key() creates an authorisation key which is then passed to
     /sbin/request-key in as part of a new session keyring.
 (3) When request_key() is searching for a key to hand back to the caller, if
     it comes across an authorisation key in the session keyring of the
     calling process, it will also search the keyrings of the process
     specified therein and it will use the specified process's credentials
     (fsuid, fsgid, groups) to do that rather than the calling process's
     credentials.
     This allows a process started by /sbin/request-key to find keys belonging
     to the authorising process.
 (4) A key can be read, even if the process executing KEYCTL_READ doesn't have
     direct read or search permission if that key is contained within the
     keyrings of a process specified by an authorisation key found within the
     calling process's session keyring, and is searchable using the
     credentials of the authorising process.
     This allows a process started by /sbin/request-key to read keys belonging
     to the authorising process.
 (5) The magic KEY_SPEC_*_KEYRING key IDs when passed to KEYCTL_INSTANTIATE or
     KEYCTL_NEGATE will specify a keyring of the authorising process, rather
     than the process doing the instantiation.
 (6) One of the process keyrings can be nominated as the default to which
     request_key() should attach new keys if not otherwise specified. This is
     done with KEYCTL_SET_REQKEY_KEYRING and one of the KEY_REQKEY_DEFL_*
     constants. The current setting can also be read using this call.
 (7) request_key() is partially interruptible. If it is waiting for another
     process to finish constructing a key, it can be interrupted. This permits
     a request-key cycle to be broken without recourse to rebooting.
Signed-Off-By: David Howells <dhowells@redhat.com>
Signed-Off-By: Benoit Boissinot <benoit.boissinot@ens-lyon.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
											
										 
											2005-06-23 22:00:56 -07:00
										 |  |  | 			break; | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | 		case KEY_REQKEY_DEFL_GROUP_KEYRING: | 
					
						
							|  |  |  | 		default: | 
					
						
							|  |  |  | 			BUG(); | 
					
						
							|  |  |  | 		} | 
					
						
							|  |  |  | 	} | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
											  
											
												KEYS: Alter use of key instantiation link-to-keyring argument
Alter the use of the key instantiation and negation functions' link-to-keyring
arguments.  Currently this specifies a keyring in the target process to link
the key into, creating the keyring if it doesn't exist.  This, however, can be
a problem for copy-on-write credentials as it means that the instantiating
process can alter the credentials of the requesting process.
This patch alters the behaviour such that:
 (1) If keyctl_instantiate_key() or keyctl_negate_key() are given a specific
     keyring by ID (ringid >= 0), then that keyring will be used.
 (2) If keyctl_instantiate_key() or keyctl_negate_key() are given one of the
     special constants that refer to the requesting process's keyrings
     (KEY_SPEC_*_KEYRING, all <= 0), then:
     (a) If sys_request_key() was given a keyring to use (destringid) then the
     	 key will be attached to that keyring.
     (b) If sys_request_key() was given a NULL keyring, then the key being
     	 instantiated will be attached to the default keyring as set by
     	 keyctl_set_reqkey_keyring().
 (3) No extra link will be made.
Decision point (1) follows current behaviour, and allows those instantiators
who've searched for a specifically named keyring in the requestor's keyring so
as to partition the keys by type to still have their named keyrings.
Decision point (2) allows the requestor to make sure that the key or keys that
get produced by request_key() go where they want, whilst allowing the
instantiator to request that the key is retained.  This is mainly useful for
situations where the instantiator makes a secondary request, the key for which
should be retained by the initial requestor:
	+-----------+        +--------------+        +--------------+
	|           |        |              |        |              |
	| Requestor |------->| Instantiator |------->| Instantiator |
	|           |        |              |        |              |
	+-----------+        +--------------+        +--------------+
	           request_key()           request_key()
This might be useful, for example, in Kerberos, where the requestor requests a
ticket, and then the ticket instantiator requests the TGT, which someone else
then has to go and fetch.  The TGT, however, should be retained in the
keyrings of the requestor, not the first instantiator.  To make this explict
an extra special keyring constant is also added.
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: James Morris <jmorris@namei.org>
Signed-off-by: James Morris <jmorris@namei.org>
											
										 
											2008-11-14 10:39:14 +11:00
										 |  |  | 	*_dest_keyring = dest_keyring; | 
					
						
							|  |  |  | 	kleave(" [dk %d]", key_serial(dest_keyring)); | 
					
						
							|  |  |  | 	return; | 
					
						
							| 
									
										
										
										
											2007-10-16 23:29:46 -07:00
										 |  |  | } | 
					
						
							| 
									
										
											  
											
												[PATCH] Keys: Make request-key create an authorisation key
The attached patch makes the following changes:
 (1) There's a new special key type called ".request_key_auth".
     This is an authorisation key for when one process requests a key and
     another process is started to construct it. This type of key cannot be
     created by the user; nor can it be requested by kernel services.
     Authorisation keys hold two references:
     (a) Each refers to a key being constructed. When the key being
     	 constructed is instantiated the authorisation key is revoked,
     	 rendering it of no further use.
     (b) The "authorising process". This is either:
     	 (i) the process that called request_key(), or:
     	 (ii) if the process that called request_key() itself had an
     	      authorisation key in its session keyring, then the authorising
     	      process referred to by that authorisation key will also be
     	      referred to by the new authorisation key.
	 This means that the process that initiated a chain of key requests
	 will authorise the lot of them, and will, by default, wind up with
	 the keys obtained from them in its keyrings.
 (2) request_key() creates an authorisation key which is then passed to
     /sbin/request-key in as part of a new session keyring.
 (3) When request_key() is searching for a key to hand back to the caller, if
     it comes across an authorisation key in the session keyring of the
     calling process, it will also search the keyrings of the process
     specified therein and it will use the specified process's credentials
     (fsuid, fsgid, groups) to do that rather than the calling process's
     credentials.
     This allows a process started by /sbin/request-key to find keys belonging
     to the authorising process.
 (4) A key can be read, even if the process executing KEYCTL_READ doesn't have
     direct read or search permission if that key is contained within the
     keyrings of a process specified by an authorisation key found within the
     calling process's session keyring, and is searchable using the
     credentials of the authorising process.
     This allows a process started by /sbin/request-key to read keys belonging
     to the authorising process.
 (5) The magic KEY_SPEC_*_KEYRING key IDs when passed to KEYCTL_INSTANTIATE or
     KEYCTL_NEGATE will specify a keyring of the authorising process, rather
     than the process doing the instantiation.
 (6) One of the process keyrings can be nominated as the default to which
     request_key() should attach new keys if not otherwise specified. This is
     done with KEYCTL_SET_REQKEY_KEYRING and one of the KEY_REQKEY_DEFL_*
     constants. The current setting can also be read using this call.
 (7) request_key() is partially interruptible. If it is waiting for another
     process to finish constructing a key, it can be interrupted. This permits
     a request-key cycle to be broken without recourse to rebooting.
Signed-Off-By: David Howells <dhowells@redhat.com>
Signed-Off-By: Benoit Boissinot <benoit.boissinot@ens-lyon.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
											
										 
											2005-06-23 22:00:56 -07:00
										 |  |  | 
 | 
					
						
							| 
									
										
										
										
											2007-10-16 23:29:46 -07:00
										 |  |  | /*
 | 
					
						
							|  |  |  |  * allocate a new key in under-construction state and attempt to link it in to | 
					
						
							|  |  |  |  * the requested place | 
					
						
							|  |  |  |  * - may return a key that's already under construction instead | 
					
						
							|  |  |  |  */ | 
					
						
							|  |  |  | static int construct_alloc_key(struct key_type *type, | 
					
						
							|  |  |  | 			       const char *description, | 
					
						
							|  |  |  | 			       struct key *dest_keyring, | 
					
						
							|  |  |  | 			       unsigned long flags, | 
					
						
							|  |  |  | 			       struct key_user *user, | 
					
						
							|  |  |  | 			       struct key **_key) | 
					
						
							|  |  |  | { | 
					
						
							| 
									
										
											  
											
												CRED: Inaugurate COW credentials
Inaugurate copy-on-write credentials management.  This uses RCU to manage the
credentials pointer in the task_struct with respect to accesses by other tasks.
A process may only modify its own credentials, and so does not need locking to
access or modify its own credentials.
A mutex (cred_replace_mutex) is added to the task_struct to control the effect
of PTRACE_ATTACHED on credential calculations, particularly with respect to
execve().
With this patch, the contents of an active credentials struct may not be
changed directly; rather a new set of credentials must be prepared, modified
and committed using something like the following sequence of events:
	struct cred *new = prepare_creds();
	int ret = blah(new);
	if (ret < 0) {
		abort_creds(new);
		return ret;
	}
	return commit_creds(new);
There are some exceptions to this rule: the keyrings pointed to by the active
credentials may be instantiated - keyrings violate the COW rule as managing
COW keyrings is tricky, given that it is possible for a task to directly alter
the keys in a keyring in use by another task.
To help enforce this, various pointers to sets of credentials, such as those in
the task_struct, are declared const.  The purpose of this is compile-time
discouragement of altering credentials through those pointers.  Once a set of
credentials has been made public through one of these pointers, it may not be
modified, except under special circumstances:
  (1) Its reference count may incremented and decremented.
  (2) The keyrings to which it points may be modified, but not replaced.
The only safe way to modify anything else is to create a replacement and commit
using the functions described in Documentation/credentials.txt (which will be
added by a later patch).
This patch and the preceding patches have been tested with the LTP SELinux
testsuite.
This patch makes several logical sets of alteration:
 (1) execve().
     This now prepares and commits credentials in various places in the
     security code rather than altering the current creds directly.
 (2) Temporary credential overrides.
     do_coredump() and sys_faccessat() now prepare their own credentials and
     temporarily override the ones currently on the acting thread, whilst
     preventing interference from other threads by holding cred_replace_mutex
     on the thread being dumped.
     This will be replaced in a future patch by something that hands down the
     credentials directly to the functions being called, rather than altering
     the task's objective credentials.
 (3) LSM interface.
     A number of functions have been changed, added or removed:
     (*) security_capset_check(), ->capset_check()
     (*) security_capset_set(), ->capset_set()
     	 Removed in favour of security_capset().
     (*) security_capset(), ->capset()
     	 New.  This is passed a pointer to the new creds, a pointer to the old
     	 creds and the proposed capability sets.  It should fill in the new
     	 creds or return an error.  All pointers, barring the pointer to the
     	 new creds, are now const.
     (*) security_bprm_apply_creds(), ->bprm_apply_creds()
     	 Changed; now returns a value, which will cause the process to be
     	 killed if it's an error.
     (*) security_task_alloc(), ->task_alloc_security()
     	 Removed in favour of security_prepare_creds().
     (*) security_cred_free(), ->cred_free()
     	 New.  Free security data attached to cred->security.
     (*) security_prepare_creds(), ->cred_prepare()
     	 New. Duplicate any security data attached to cred->security.
     (*) security_commit_creds(), ->cred_commit()
     	 New. Apply any security effects for the upcoming installation of new
     	 security by commit_creds().
     (*) security_task_post_setuid(), ->task_post_setuid()
     	 Removed in favour of security_task_fix_setuid().
     (*) security_task_fix_setuid(), ->task_fix_setuid()
     	 Fix up the proposed new credentials for setuid().  This is used by
     	 cap_set_fix_setuid() to implicitly adjust capabilities in line with
     	 setuid() changes.  Changes are made to the new credentials, rather
     	 than the task itself as in security_task_post_setuid().
     (*) security_task_reparent_to_init(), ->task_reparent_to_init()
     	 Removed.  Instead the task being reparented to init is referred
     	 directly to init's credentials.
	 NOTE!  This results in the loss of some state: SELinux's osid no
	 longer records the sid of the thread that forked it.
     (*) security_key_alloc(), ->key_alloc()
     (*) security_key_permission(), ->key_permission()
     	 Changed.  These now take cred pointers rather than task pointers to
     	 refer to the security context.
 (4) sys_capset().
     This has been simplified and uses less locking.  The LSM functions it
     calls have been merged.
 (5) reparent_to_kthreadd().
     This gives the current thread the same credentials as init by simply using
     commit_thread() to point that way.
 (6) __sigqueue_alloc() and switch_uid()
     __sigqueue_alloc() can't stop the target task from changing its creds
     beneath it, so this function gets a reference to the currently applicable
     user_struct which it then passes into the sigqueue struct it returns if
     successful.
     switch_uid() is now called from commit_creds(), and possibly should be
     folded into that.  commit_creds() should take care of protecting
     __sigqueue_alloc().
 (7) [sg]et[ug]id() and co and [sg]et_current_groups.
     The set functions now all use prepare_creds(), commit_creds() and
     abort_creds() to build and check a new set of credentials before applying
     it.
     security_task_set[ug]id() is called inside the prepared section.  This
     guarantees that nothing else will affect the creds until we've finished.
     The calling of set_dumpable() has been moved into commit_creds().
     Much of the functionality of set_user() has been moved into
     commit_creds().
     The get functions all simply access the data directly.
 (8) security_task_prctl() and cap_task_prctl().
     security_task_prctl() has been modified to return -ENOSYS if it doesn't
     want to handle a function, or otherwise return the return value directly
     rather than through an argument.
     Additionally, cap_task_prctl() now prepares a new set of credentials, even
     if it doesn't end up using it.
 (9) Keyrings.
     A number of changes have been made to the keyrings code:
     (a) switch_uid_keyring(), copy_keys(), exit_keys() and suid_keys() have
     	 all been dropped and built in to the credentials functions directly.
     	 They may want separating out again later.
     (b) key_alloc() and search_process_keyrings() now take a cred pointer
     	 rather than a task pointer to specify the security context.
     (c) copy_creds() gives a new thread within the same thread group a new
     	 thread keyring if its parent had one, otherwise it discards the thread
     	 keyring.
     (d) The authorisation key now points directly to the credentials to extend
     	 the search into rather pointing to the task that carries them.
     (e) Installing thread, process or session keyrings causes a new set of
     	 credentials to be created, even though it's not strictly necessary for
     	 process or session keyrings (they're shared).
(10) Usermode helper.
     The usermode helper code now carries a cred struct pointer in its
     subprocess_info struct instead of a new session keyring pointer.  This set
     of credentials is derived from init_cred and installed on the new process
     after it has been cloned.
     call_usermodehelper_setup() allocates the new credentials and
     call_usermodehelper_freeinfo() discards them if they haven't been used.  A
     special cred function (prepare_usermodeinfo_creds()) is provided
     specifically for call_usermodehelper_setup() to call.
     call_usermodehelper_setkeys() adjusts the credentials to sport the
     supplied keyring as the new session keyring.
(11) SELinux.
     SELinux has a number of changes, in addition to those to support the LSM
     interface changes mentioned above:
     (a) selinux_setprocattr() no longer does its check for whether the
     	 current ptracer can access processes with the new SID inside the lock
     	 that covers getting the ptracer's SID.  Whilst this lock ensures that
     	 the check is done with the ptracer pinned, the result is only valid
     	 until the lock is released, so there's no point doing it inside the
     	 lock.
(12) is_single_threaded().
     This function has been extracted from selinux_setprocattr() and put into
     a file of its own in the lib/ directory as join_session_keyring() now
     wants to use it too.
     The code in SELinux just checked to see whether a task shared mm_structs
     with other tasks (CLONE_VM), but that isn't good enough.  We really want
     to know if they're part of the same thread group (CLONE_THREAD).
(13) nfsd.
     The NFS server daemon now has to use the COW credentials to set the
     credentials it is going to use.  It really needs to pass the credentials
     down to the functions it calls, but it can't do that until other patches
     in this series have been applied.
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: James Morris <jmorris@namei.org>
Signed-off-by: James Morris <jmorris@namei.org>
											
										 
											2008-11-14 10:39:23 +11:00
										 |  |  | 	const struct cred *cred = current_cred(); | 
					
						
							| 
									
										
										
										
											2007-10-16 23:29:46 -07:00
										 |  |  | 	struct key *key; | 
					
						
							|  |  |  | 	key_ref_t key_ref; | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | 	kenter("%s,%s,,,", type->name, description); | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | 	mutex_lock(&user->cons_lock); | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
											  
											
												CRED: Inaugurate COW credentials
Inaugurate copy-on-write credentials management.  This uses RCU to manage the
credentials pointer in the task_struct with respect to accesses by other tasks.
A process may only modify its own credentials, and so does not need locking to
access or modify its own credentials.
A mutex (cred_replace_mutex) is added to the task_struct to control the effect
of PTRACE_ATTACHED on credential calculations, particularly with respect to
execve().
With this patch, the contents of an active credentials struct may not be
changed directly; rather a new set of credentials must be prepared, modified
and committed using something like the following sequence of events:
	struct cred *new = prepare_creds();
	int ret = blah(new);
	if (ret < 0) {
		abort_creds(new);
		return ret;
	}
	return commit_creds(new);
There are some exceptions to this rule: the keyrings pointed to by the active
credentials may be instantiated - keyrings violate the COW rule as managing
COW keyrings is tricky, given that it is possible for a task to directly alter
the keys in a keyring in use by another task.
To help enforce this, various pointers to sets of credentials, such as those in
the task_struct, are declared const.  The purpose of this is compile-time
discouragement of altering credentials through those pointers.  Once a set of
credentials has been made public through one of these pointers, it may not be
modified, except under special circumstances:
  (1) Its reference count may incremented and decremented.
  (2) The keyrings to which it points may be modified, but not replaced.
The only safe way to modify anything else is to create a replacement and commit
using the functions described in Documentation/credentials.txt (which will be
added by a later patch).
This patch and the preceding patches have been tested with the LTP SELinux
testsuite.
This patch makes several logical sets of alteration:
 (1) execve().
     This now prepares and commits credentials in various places in the
     security code rather than altering the current creds directly.
 (2) Temporary credential overrides.
     do_coredump() and sys_faccessat() now prepare their own credentials and
     temporarily override the ones currently on the acting thread, whilst
     preventing interference from other threads by holding cred_replace_mutex
     on the thread being dumped.
     This will be replaced in a future patch by something that hands down the
     credentials directly to the functions being called, rather than altering
     the task's objective credentials.
 (3) LSM interface.
     A number of functions have been changed, added or removed:
     (*) security_capset_check(), ->capset_check()
     (*) security_capset_set(), ->capset_set()
     	 Removed in favour of security_capset().
     (*) security_capset(), ->capset()
     	 New.  This is passed a pointer to the new creds, a pointer to the old
     	 creds and the proposed capability sets.  It should fill in the new
     	 creds or return an error.  All pointers, barring the pointer to the
     	 new creds, are now const.
     (*) security_bprm_apply_creds(), ->bprm_apply_creds()
     	 Changed; now returns a value, which will cause the process to be
     	 killed if it's an error.
     (*) security_task_alloc(), ->task_alloc_security()
     	 Removed in favour of security_prepare_creds().
     (*) security_cred_free(), ->cred_free()
     	 New.  Free security data attached to cred->security.
     (*) security_prepare_creds(), ->cred_prepare()
     	 New. Duplicate any security data attached to cred->security.
     (*) security_commit_creds(), ->cred_commit()
     	 New. Apply any security effects for the upcoming installation of new
     	 security by commit_creds().
     (*) security_task_post_setuid(), ->task_post_setuid()
     	 Removed in favour of security_task_fix_setuid().
     (*) security_task_fix_setuid(), ->task_fix_setuid()
     	 Fix up the proposed new credentials for setuid().  This is used by
     	 cap_set_fix_setuid() to implicitly adjust capabilities in line with
     	 setuid() changes.  Changes are made to the new credentials, rather
     	 than the task itself as in security_task_post_setuid().
     (*) security_task_reparent_to_init(), ->task_reparent_to_init()
     	 Removed.  Instead the task being reparented to init is referred
     	 directly to init's credentials.
	 NOTE!  This results in the loss of some state: SELinux's osid no
	 longer records the sid of the thread that forked it.
     (*) security_key_alloc(), ->key_alloc()
     (*) security_key_permission(), ->key_permission()
     	 Changed.  These now take cred pointers rather than task pointers to
     	 refer to the security context.
 (4) sys_capset().
     This has been simplified and uses less locking.  The LSM functions it
     calls have been merged.
 (5) reparent_to_kthreadd().
     This gives the current thread the same credentials as init by simply using
     commit_thread() to point that way.
 (6) __sigqueue_alloc() and switch_uid()
     __sigqueue_alloc() can't stop the target task from changing its creds
     beneath it, so this function gets a reference to the currently applicable
     user_struct which it then passes into the sigqueue struct it returns if
     successful.
     switch_uid() is now called from commit_creds(), and possibly should be
     folded into that.  commit_creds() should take care of protecting
     __sigqueue_alloc().
 (7) [sg]et[ug]id() and co and [sg]et_current_groups.
     The set functions now all use prepare_creds(), commit_creds() and
     abort_creds() to build and check a new set of credentials before applying
     it.
     security_task_set[ug]id() is called inside the prepared section.  This
     guarantees that nothing else will affect the creds until we've finished.
     The calling of set_dumpable() has been moved into commit_creds().
     Much of the functionality of set_user() has been moved into
     commit_creds().
     The get functions all simply access the data directly.
 (8) security_task_prctl() and cap_task_prctl().
     security_task_prctl() has been modified to return -ENOSYS if it doesn't
     want to handle a function, or otherwise return the return value directly
     rather than through an argument.
     Additionally, cap_task_prctl() now prepares a new set of credentials, even
     if it doesn't end up using it.
 (9) Keyrings.
     A number of changes have been made to the keyrings code:
     (a) switch_uid_keyring(), copy_keys(), exit_keys() and suid_keys() have
     	 all been dropped and built in to the credentials functions directly.
     	 They may want separating out again later.
     (b) key_alloc() and search_process_keyrings() now take a cred pointer
     	 rather than a task pointer to specify the security context.
     (c) copy_creds() gives a new thread within the same thread group a new
     	 thread keyring if its parent had one, otherwise it discards the thread
     	 keyring.
     (d) The authorisation key now points directly to the credentials to extend
     	 the search into rather pointing to the task that carries them.
     (e) Installing thread, process or session keyrings causes a new set of
     	 credentials to be created, even though it's not strictly necessary for
     	 process or session keyrings (they're shared).
(10) Usermode helper.
     The usermode helper code now carries a cred struct pointer in its
     subprocess_info struct instead of a new session keyring pointer.  This set
     of credentials is derived from init_cred and installed on the new process
     after it has been cloned.
     call_usermodehelper_setup() allocates the new credentials and
     call_usermodehelper_freeinfo() discards them if they haven't been used.  A
     special cred function (prepare_usermodeinfo_creds()) is provided
     specifically for call_usermodehelper_setup() to call.
     call_usermodehelper_setkeys() adjusts the credentials to sport the
     supplied keyring as the new session keyring.
(11) SELinux.
     SELinux has a number of changes, in addition to those to support the LSM
     interface changes mentioned above:
     (a) selinux_setprocattr() no longer does its check for whether the
     	 current ptracer can access processes with the new SID inside the lock
     	 that covers getting the ptracer's SID.  Whilst this lock ensures that
     	 the check is done with the ptracer pinned, the result is only valid
     	 until the lock is released, so there's no point doing it inside the
     	 lock.
(12) is_single_threaded().
     This function has been extracted from selinux_setprocattr() and put into
     a file of its own in the lib/ directory as join_session_keyring() now
     wants to use it too.
     The code in SELinux just checked to see whether a task shared mm_structs
     with other tasks (CLONE_VM), but that isn't good enough.  We really want
     to know if they're part of the same thread group (CLONE_THREAD).
(13) nfsd.
     The NFS server daemon now has to use the COW credentials to set the
     credentials it is going to use.  It really needs to pass the credentials
     down to the functions it calls, but it can't do that until other patches
     in this series have been applied.
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: James Morris <jmorris@namei.org>
Signed-off-by: James Morris <jmorris@namei.org>
											
										 
											2008-11-14 10:39:23 +11:00
										 |  |  | 	key = key_alloc(type, description, cred->fsuid, cred->fsgid, cred, | 
					
						
							|  |  |  | 			KEY_POS_ALL, flags); | 
					
						
							| 
									
										
										
										
											2007-10-16 23:29:46 -07:00
										 |  |  | 	if (IS_ERR(key)) | 
					
						
							|  |  |  | 		goto alloc_failed; | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | 	set_bit(KEY_FLAG_USER_CONSTRUCT, &key->flags); | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2009-04-09 17:14:05 +01:00
										 |  |  | 	if (dest_keyring) | 
					
						
							|  |  |  | 		down_write(&dest_keyring->sem); | 
					
						
							| 
									
										
										
										
											2007-10-16 23:29:46 -07:00
										 |  |  | 
 | 
					
						
							|  |  |  | 	/* attach the key to the destination keyring under lock, but we do need
 | 
					
						
							|  |  |  | 	 * to do another check just in case someone beat us to it whilst we | 
					
						
							|  |  |  | 	 * waited for locks */ | 
					
						
							|  |  |  | 	mutex_lock(&key_construction_mutex); | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
											  
											
												CRED: Inaugurate COW credentials
Inaugurate copy-on-write credentials management.  This uses RCU to manage the
credentials pointer in the task_struct with respect to accesses by other tasks.
A process may only modify its own credentials, and so does not need locking to
access or modify its own credentials.
A mutex (cred_replace_mutex) is added to the task_struct to control the effect
of PTRACE_ATTACHED on credential calculations, particularly with respect to
execve().
With this patch, the contents of an active credentials struct may not be
changed directly; rather a new set of credentials must be prepared, modified
and committed using something like the following sequence of events:
	struct cred *new = prepare_creds();
	int ret = blah(new);
	if (ret < 0) {
		abort_creds(new);
		return ret;
	}
	return commit_creds(new);
There are some exceptions to this rule: the keyrings pointed to by the active
credentials may be instantiated - keyrings violate the COW rule as managing
COW keyrings is tricky, given that it is possible for a task to directly alter
the keys in a keyring in use by another task.
To help enforce this, various pointers to sets of credentials, such as those in
the task_struct, are declared const.  The purpose of this is compile-time
discouragement of altering credentials through those pointers.  Once a set of
credentials has been made public through one of these pointers, it may not be
modified, except under special circumstances:
  (1) Its reference count may incremented and decremented.
  (2) The keyrings to which it points may be modified, but not replaced.
The only safe way to modify anything else is to create a replacement and commit
using the functions described in Documentation/credentials.txt (which will be
added by a later patch).
This patch and the preceding patches have been tested with the LTP SELinux
testsuite.
This patch makes several logical sets of alteration:
 (1) execve().
     This now prepares and commits credentials in various places in the
     security code rather than altering the current creds directly.
 (2) Temporary credential overrides.
     do_coredump() and sys_faccessat() now prepare their own credentials and
     temporarily override the ones currently on the acting thread, whilst
     preventing interference from other threads by holding cred_replace_mutex
     on the thread being dumped.
     This will be replaced in a future patch by something that hands down the
     credentials directly to the functions being called, rather than altering
     the task's objective credentials.
 (3) LSM interface.
     A number of functions have been changed, added or removed:
     (*) security_capset_check(), ->capset_check()
     (*) security_capset_set(), ->capset_set()
     	 Removed in favour of security_capset().
     (*) security_capset(), ->capset()
     	 New.  This is passed a pointer to the new creds, a pointer to the old
     	 creds and the proposed capability sets.  It should fill in the new
     	 creds or return an error.  All pointers, barring the pointer to the
     	 new creds, are now const.
     (*) security_bprm_apply_creds(), ->bprm_apply_creds()
     	 Changed; now returns a value, which will cause the process to be
     	 killed if it's an error.
     (*) security_task_alloc(), ->task_alloc_security()
     	 Removed in favour of security_prepare_creds().
     (*) security_cred_free(), ->cred_free()
     	 New.  Free security data attached to cred->security.
     (*) security_prepare_creds(), ->cred_prepare()
     	 New. Duplicate any security data attached to cred->security.
     (*) security_commit_creds(), ->cred_commit()
     	 New. Apply any security effects for the upcoming installation of new
     	 security by commit_creds().
     (*) security_task_post_setuid(), ->task_post_setuid()
     	 Removed in favour of security_task_fix_setuid().
     (*) security_task_fix_setuid(), ->task_fix_setuid()
     	 Fix up the proposed new credentials for setuid().  This is used by
     	 cap_set_fix_setuid() to implicitly adjust capabilities in line with
     	 setuid() changes.  Changes are made to the new credentials, rather
     	 than the task itself as in security_task_post_setuid().
     (*) security_task_reparent_to_init(), ->task_reparent_to_init()
     	 Removed.  Instead the task being reparented to init is referred
     	 directly to init's credentials.
	 NOTE!  This results in the loss of some state: SELinux's osid no
	 longer records the sid of the thread that forked it.
     (*) security_key_alloc(), ->key_alloc()
     (*) security_key_permission(), ->key_permission()
     	 Changed.  These now take cred pointers rather than task pointers to
     	 refer to the security context.
 (4) sys_capset().
     This has been simplified and uses less locking.  The LSM functions it
     calls have been merged.
 (5) reparent_to_kthreadd().
     This gives the current thread the same credentials as init by simply using
     commit_thread() to point that way.
 (6) __sigqueue_alloc() and switch_uid()
     __sigqueue_alloc() can't stop the target task from changing its creds
     beneath it, so this function gets a reference to the currently applicable
     user_struct which it then passes into the sigqueue struct it returns if
     successful.
     switch_uid() is now called from commit_creds(), and possibly should be
     folded into that.  commit_creds() should take care of protecting
     __sigqueue_alloc().
 (7) [sg]et[ug]id() and co and [sg]et_current_groups.
     The set functions now all use prepare_creds(), commit_creds() and
     abort_creds() to build and check a new set of credentials before applying
     it.
     security_task_set[ug]id() is called inside the prepared section.  This
     guarantees that nothing else will affect the creds until we've finished.
     The calling of set_dumpable() has been moved into commit_creds().
     Much of the functionality of set_user() has been moved into
     commit_creds().
     The get functions all simply access the data directly.
 (8) security_task_prctl() and cap_task_prctl().
     security_task_prctl() has been modified to return -ENOSYS if it doesn't
     want to handle a function, or otherwise return the return value directly
     rather than through an argument.
     Additionally, cap_task_prctl() now prepares a new set of credentials, even
     if it doesn't end up using it.
 (9) Keyrings.
     A number of changes have been made to the keyrings code:
     (a) switch_uid_keyring(), copy_keys(), exit_keys() and suid_keys() have
     	 all been dropped and built in to the credentials functions directly.
     	 They may want separating out again later.
     (b) key_alloc() and search_process_keyrings() now take a cred pointer
     	 rather than a task pointer to specify the security context.
     (c) copy_creds() gives a new thread within the same thread group a new
     	 thread keyring if its parent had one, otherwise it discards the thread
     	 keyring.
     (d) The authorisation key now points directly to the credentials to extend
     	 the search into rather pointing to the task that carries them.
     (e) Installing thread, process or session keyrings causes a new set of
     	 credentials to be created, even though it's not strictly necessary for
     	 process or session keyrings (they're shared).
(10) Usermode helper.
     The usermode helper code now carries a cred struct pointer in its
     subprocess_info struct instead of a new session keyring pointer.  This set
     of credentials is derived from init_cred and installed on the new process
     after it has been cloned.
     call_usermodehelper_setup() allocates the new credentials and
     call_usermodehelper_freeinfo() discards them if they haven't been used.  A
     special cred function (prepare_usermodeinfo_creds()) is provided
     specifically for call_usermodehelper_setup() to call.
     call_usermodehelper_setkeys() adjusts the credentials to sport the
     supplied keyring as the new session keyring.
(11) SELinux.
     SELinux has a number of changes, in addition to those to support the LSM
     interface changes mentioned above:
     (a) selinux_setprocattr() no longer does its check for whether the
     	 current ptracer can access processes with the new SID inside the lock
     	 that covers getting the ptracer's SID.  Whilst this lock ensures that
     	 the check is done with the ptracer pinned, the result is only valid
     	 until the lock is released, so there's no point doing it inside the
     	 lock.
(12) is_single_threaded().
     This function has been extracted from selinux_setprocattr() and put into
     a file of its own in the lib/ directory as join_session_keyring() now
     wants to use it too.
     The code in SELinux just checked to see whether a task shared mm_structs
     with other tasks (CLONE_VM), but that isn't good enough.  We really want
     to know if they're part of the same thread group (CLONE_THREAD).
(13) nfsd.
     The NFS server daemon now has to use the COW credentials to set the
     credentials it is going to use.  It really needs to pass the credentials
     down to the functions it calls, but it can't do that until other patches
     in this series have been applied.
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: James Morris <jmorris@namei.org>
Signed-off-by: James Morris <jmorris@namei.org>
											
										 
											2008-11-14 10:39:23 +11:00
										 |  |  | 	key_ref = search_process_keyrings(type, description, type->match, cred); | 
					
						
							| 
									
										
										
										
											2007-10-16 23:29:46 -07:00
										 |  |  | 	if (!IS_ERR(key_ref)) | 
					
						
							|  |  |  | 		goto key_already_present; | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2009-04-09 17:14:05 +01:00
										 |  |  | 	if (dest_keyring) | 
					
						
							|  |  |  | 		__key_link(dest_keyring, key); | 
					
						
							| 
									
										
										
										
											2007-10-16 23:29:46 -07:00
										 |  |  | 
 | 
					
						
							|  |  |  | 	mutex_unlock(&key_construction_mutex); | 
					
						
							| 
									
										
										
										
											2009-04-09 17:14:05 +01:00
										 |  |  | 	if (dest_keyring) | 
					
						
							|  |  |  | 		up_write(&dest_keyring->sem); | 
					
						
							| 
									
										
										
										
											2007-10-16 23:29:46 -07:00
										 |  |  | 	mutex_unlock(&user->cons_lock); | 
					
						
							|  |  |  | 	*_key = key; | 
					
						
							|  |  |  | 	kleave(" = 0 [%d]", key_serial(key)); | 
					
						
							|  |  |  | 	return 0; | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | key_already_present: | 
					
						
							|  |  |  | 	mutex_unlock(&key_construction_mutex); | 
					
						
							| 
									
										
											  
											
												keys: the request_key() syscall should link an existing key to the dest keyring
The request_key() system call and request_key_and_link() should make a
link from an existing key to the destination keyring (if supplied), not
just from a new key to the destination keyring.
This can be tested by:
	ring=`keyctl newring fred @s`
	keyctl request2 user debug:a a
	keyctl request user debug:a $ring
	keyctl list $ring
If it says:
	keyring is empty
then it didn't work.  If it shows something like:
	1 key in keyring:
	1070462727: --alswrv     0     0 user: debug:a
then it did.
request_key() system call is meant to recursively search all your keyrings for
the key you desire, and, optionally, if it doesn't exist, call out to userspace
to create one for you.
If request_key() finds or creates a key, it should, optionally, create a link
to that key from the destination keyring specified.
Therefore, if, after a successful call to request_key() with a desination
keyring specified, you see the destination keyring empty, the code didn't work
correctly.
If you see the found key in the keyring, then it did - which is what the patch
is required for.
Signed-off-by: David Howells <dhowells@redhat.com>
Cc: James Morris <jmorris@namei.org>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
											
										 
											2010-04-27 13:13:08 -07:00
										 |  |  | 	if (dest_keyring) { | 
					
						
							|  |  |  | 		__key_link(dest_keyring, key_ref_to_ptr(key_ref)); | 
					
						
							| 
									
										
										
										
											2007-10-16 23:29:46 -07:00
										 |  |  | 		up_write(&dest_keyring->sem); | 
					
						
							| 
									
										
											  
											
												keys: the request_key() syscall should link an existing key to the dest keyring
The request_key() system call and request_key_and_link() should make a
link from an existing key to the destination keyring (if supplied), not
just from a new key to the destination keyring.
This can be tested by:
	ring=`keyctl newring fred @s`
	keyctl request2 user debug:a a
	keyctl request user debug:a $ring
	keyctl list $ring
If it says:
	keyring is empty
then it didn't work.  If it shows something like:
	1 key in keyring:
	1070462727: --alswrv     0     0 user: debug:a
then it did.
request_key() system call is meant to recursively search all your keyrings for
the key you desire, and, optionally, if it doesn't exist, call out to userspace
to create one for you.
If request_key() finds or creates a key, it should, optionally, create a link
to that key from the destination keyring specified.
Therefore, if, after a successful call to request_key() with a desination
keyring specified, you see the destination keyring empty, the code didn't work
correctly.
If you see the found key in the keyring, then it did - which is what the patch
is required for.
Signed-off-by: David Howells <dhowells@redhat.com>
Cc: James Morris <jmorris@namei.org>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
											
										 
											2010-04-27 13:13:08 -07:00
										 |  |  | 	} | 
					
						
							| 
									
										
										
										
											2007-10-16 23:29:46 -07:00
										 |  |  | 	mutex_unlock(&user->cons_lock); | 
					
						
							|  |  |  | 	key_put(key); | 
					
						
							|  |  |  | 	*_key = key = key_ref_to_ptr(key_ref); | 
					
						
							|  |  |  | 	kleave(" = -EINPROGRESS [%d]", key_serial(key)); | 
					
						
							|  |  |  | 	return -EINPROGRESS; | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | alloc_failed: | 
					
						
							|  |  |  | 	mutex_unlock(&user->cons_lock); | 
					
						
							|  |  |  | 	*_key = NULL; | 
					
						
							|  |  |  | 	kleave(" = %ld", PTR_ERR(key)); | 
					
						
							|  |  |  | 	return PTR_ERR(key); | 
					
						
							|  |  |  | } | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | /*
 | 
					
						
							|  |  |  |  * commence key construction | 
					
						
							|  |  |  |  */ | 
					
						
							|  |  |  | static struct key *construct_key_and_link(struct key_type *type, | 
					
						
							|  |  |  | 					  const char *description, | 
					
						
							|  |  |  | 					  const char *callout_info, | 
					
						
							| 
									
										
										
										
											2008-04-29 01:01:24 -07:00
										 |  |  | 					  size_t callout_len, | 
					
						
							| 
									
										
										
										
											2007-10-16 23:29:46 -07:00
										 |  |  | 					  void *aux, | 
					
						
							|  |  |  | 					  struct key *dest_keyring, | 
					
						
							|  |  |  | 					  unsigned long flags) | 
					
						
							|  |  |  | { | 
					
						
							|  |  |  | 	struct key_user *user; | 
					
						
							|  |  |  | 	struct key *key; | 
					
						
							|  |  |  | 	int ret; | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
											  
											
												CRED: Inaugurate COW credentials
Inaugurate copy-on-write credentials management.  This uses RCU to manage the
credentials pointer in the task_struct with respect to accesses by other tasks.
A process may only modify its own credentials, and so does not need locking to
access or modify its own credentials.
A mutex (cred_replace_mutex) is added to the task_struct to control the effect
of PTRACE_ATTACHED on credential calculations, particularly with respect to
execve().
With this patch, the contents of an active credentials struct may not be
changed directly; rather a new set of credentials must be prepared, modified
and committed using something like the following sequence of events:
	struct cred *new = prepare_creds();
	int ret = blah(new);
	if (ret < 0) {
		abort_creds(new);
		return ret;
	}
	return commit_creds(new);
There are some exceptions to this rule: the keyrings pointed to by the active
credentials may be instantiated - keyrings violate the COW rule as managing
COW keyrings is tricky, given that it is possible for a task to directly alter
the keys in a keyring in use by another task.
To help enforce this, various pointers to sets of credentials, such as those in
the task_struct, are declared const.  The purpose of this is compile-time
discouragement of altering credentials through those pointers.  Once a set of
credentials has been made public through one of these pointers, it may not be
modified, except under special circumstances:
  (1) Its reference count may incremented and decremented.
  (2) The keyrings to which it points may be modified, but not replaced.
The only safe way to modify anything else is to create a replacement and commit
using the functions described in Documentation/credentials.txt (which will be
added by a later patch).
This patch and the preceding patches have been tested with the LTP SELinux
testsuite.
This patch makes several logical sets of alteration:
 (1) execve().
     This now prepares and commits credentials in various places in the
     security code rather than altering the current creds directly.
 (2) Temporary credential overrides.
     do_coredump() and sys_faccessat() now prepare their own credentials and
     temporarily override the ones currently on the acting thread, whilst
     preventing interference from other threads by holding cred_replace_mutex
     on the thread being dumped.
     This will be replaced in a future patch by something that hands down the
     credentials directly to the functions being called, rather than altering
     the task's objective credentials.
 (3) LSM interface.
     A number of functions have been changed, added or removed:
     (*) security_capset_check(), ->capset_check()
     (*) security_capset_set(), ->capset_set()
     	 Removed in favour of security_capset().
     (*) security_capset(), ->capset()
     	 New.  This is passed a pointer to the new creds, a pointer to the old
     	 creds and the proposed capability sets.  It should fill in the new
     	 creds or return an error.  All pointers, barring the pointer to the
     	 new creds, are now const.
     (*) security_bprm_apply_creds(), ->bprm_apply_creds()
     	 Changed; now returns a value, which will cause the process to be
     	 killed if it's an error.
     (*) security_task_alloc(), ->task_alloc_security()
     	 Removed in favour of security_prepare_creds().
     (*) security_cred_free(), ->cred_free()
     	 New.  Free security data attached to cred->security.
     (*) security_prepare_creds(), ->cred_prepare()
     	 New. Duplicate any security data attached to cred->security.
     (*) security_commit_creds(), ->cred_commit()
     	 New. Apply any security effects for the upcoming installation of new
     	 security by commit_creds().
     (*) security_task_post_setuid(), ->task_post_setuid()
     	 Removed in favour of security_task_fix_setuid().
     (*) security_task_fix_setuid(), ->task_fix_setuid()
     	 Fix up the proposed new credentials for setuid().  This is used by
     	 cap_set_fix_setuid() to implicitly adjust capabilities in line with
     	 setuid() changes.  Changes are made to the new credentials, rather
     	 than the task itself as in security_task_post_setuid().
     (*) security_task_reparent_to_init(), ->task_reparent_to_init()
     	 Removed.  Instead the task being reparented to init is referred
     	 directly to init's credentials.
	 NOTE!  This results in the loss of some state: SELinux's osid no
	 longer records the sid of the thread that forked it.
     (*) security_key_alloc(), ->key_alloc()
     (*) security_key_permission(), ->key_permission()
     	 Changed.  These now take cred pointers rather than task pointers to
     	 refer to the security context.
 (4) sys_capset().
     This has been simplified and uses less locking.  The LSM functions it
     calls have been merged.
 (5) reparent_to_kthreadd().
     This gives the current thread the same credentials as init by simply using
     commit_thread() to point that way.
 (6) __sigqueue_alloc() and switch_uid()
     __sigqueue_alloc() can't stop the target task from changing its creds
     beneath it, so this function gets a reference to the currently applicable
     user_struct which it then passes into the sigqueue struct it returns if
     successful.
     switch_uid() is now called from commit_creds(), and possibly should be
     folded into that.  commit_creds() should take care of protecting
     __sigqueue_alloc().
 (7) [sg]et[ug]id() and co and [sg]et_current_groups.
     The set functions now all use prepare_creds(), commit_creds() and
     abort_creds() to build and check a new set of credentials before applying
     it.
     security_task_set[ug]id() is called inside the prepared section.  This
     guarantees that nothing else will affect the creds until we've finished.
     The calling of set_dumpable() has been moved into commit_creds().
     Much of the functionality of set_user() has been moved into
     commit_creds().
     The get functions all simply access the data directly.
 (8) security_task_prctl() and cap_task_prctl().
     security_task_prctl() has been modified to return -ENOSYS if it doesn't
     want to handle a function, or otherwise return the return value directly
     rather than through an argument.
     Additionally, cap_task_prctl() now prepares a new set of credentials, even
     if it doesn't end up using it.
 (9) Keyrings.
     A number of changes have been made to the keyrings code:
     (a) switch_uid_keyring(), copy_keys(), exit_keys() and suid_keys() have
     	 all been dropped and built in to the credentials functions directly.
     	 They may want separating out again later.
     (b) key_alloc() and search_process_keyrings() now take a cred pointer
     	 rather than a task pointer to specify the security context.
     (c) copy_creds() gives a new thread within the same thread group a new
     	 thread keyring if its parent had one, otherwise it discards the thread
     	 keyring.
     (d) The authorisation key now points directly to the credentials to extend
     	 the search into rather pointing to the task that carries them.
     (e) Installing thread, process or session keyrings causes a new set of
     	 credentials to be created, even though it's not strictly necessary for
     	 process or session keyrings (they're shared).
(10) Usermode helper.
     The usermode helper code now carries a cred struct pointer in its
     subprocess_info struct instead of a new session keyring pointer.  This set
     of credentials is derived from init_cred and installed on the new process
     after it has been cloned.
     call_usermodehelper_setup() allocates the new credentials and
     call_usermodehelper_freeinfo() discards them if they haven't been used.  A
     special cred function (prepare_usermodeinfo_creds()) is provided
     specifically for call_usermodehelper_setup() to call.
     call_usermodehelper_setkeys() adjusts the credentials to sport the
     supplied keyring as the new session keyring.
(11) SELinux.
     SELinux has a number of changes, in addition to those to support the LSM
     interface changes mentioned above:
     (a) selinux_setprocattr() no longer does its check for whether the
     	 current ptracer can access processes with the new SID inside the lock
     	 that covers getting the ptracer's SID.  Whilst this lock ensures that
     	 the check is done with the ptracer pinned, the result is only valid
     	 until the lock is released, so there's no point doing it inside the
     	 lock.
(12) is_single_threaded().
     This function has been extracted from selinux_setprocattr() and put into
     a file of its own in the lib/ directory as join_session_keyring() now
     wants to use it too.
     The code in SELinux just checked to see whether a task shared mm_structs
     with other tasks (CLONE_VM), but that isn't good enough.  We really want
     to know if they're part of the same thread group (CLONE_THREAD).
(13) nfsd.
     The NFS server daemon now has to use the COW credentials to set the
     credentials it is going to use.  It really needs to pass the credentials
     down to the functions it calls, but it can't do that until other patches
     in this series have been applied.
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: James Morris <jmorris@namei.org>
Signed-off-by: James Morris <jmorris@namei.org>
											
										 
											2008-11-14 10:39:23 +11:00
										 |  |  | 	kenter(""); | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2009-02-26 18:27:38 -06:00
										 |  |  | 	user = key_user_lookup(current_fsuid(), current_user_ns()); | 
					
						
							| 
									
										
										
										
											2007-10-16 23:29:46 -07:00
										 |  |  | 	if (!user) | 
					
						
							|  |  |  | 		return ERR_PTR(-ENOMEM); | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
											  
											
												KEYS: Alter use of key instantiation link-to-keyring argument
Alter the use of the key instantiation and negation functions' link-to-keyring
arguments.  Currently this specifies a keyring in the target process to link
the key into, creating the keyring if it doesn't exist.  This, however, can be
a problem for copy-on-write credentials as it means that the instantiating
process can alter the credentials of the requesting process.
This patch alters the behaviour such that:
 (1) If keyctl_instantiate_key() or keyctl_negate_key() are given a specific
     keyring by ID (ringid >= 0), then that keyring will be used.
 (2) If keyctl_instantiate_key() or keyctl_negate_key() are given one of the
     special constants that refer to the requesting process's keyrings
     (KEY_SPEC_*_KEYRING, all <= 0), then:
     (a) If sys_request_key() was given a keyring to use (destringid) then the
     	 key will be attached to that keyring.
     (b) If sys_request_key() was given a NULL keyring, then the key being
     	 instantiated will be attached to the default keyring as set by
     	 keyctl_set_reqkey_keyring().
 (3) No extra link will be made.
Decision point (1) follows current behaviour, and allows those instantiators
who've searched for a specifically named keyring in the requestor's keyring so
as to partition the keys by type to still have their named keyrings.
Decision point (2) allows the requestor to make sure that the key or keys that
get produced by request_key() go where they want, whilst allowing the
instantiator to request that the key is retained.  This is mainly useful for
situations where the instantiator makes a secondary request, the key for which
should be retained by the initial requestor:
	+-----------+        +--------------+        +--------------+
	|           |        |              |        |              |
	| Requestor |------->| Instantiator |------->| Instantiator |
	|           |        |              |        |              |
	+-----------+        +--------------+        +--------------+
	           request_key()           request_key()
This might be useful, for example, in Kerberos, where the requestor requests a
ticket, and then the ticket instantiator requests the TGT, which someone else
then has to go and fetch.  The TGT, however, should be retained in the
keyrings of the requestor, not the first instantiator.  To make this explict
an extra special keyring constant is also added.
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: James Morris <jmorris@namei.org>
Signed-off-by: James Morris <jmorris@namei.org>
											
										 
											2008-11-14 10:39:14 +11:00
										 |  |  | 	construct_get_dest_keyring(&dest_keyring); | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2007-10-16 23:29:46 -07:00
										 |  |  | 	ret = construct_alloc_key(type, description, dest_keyring, flags, user, | 
					
						
							|  |  |  | 				  &key); | 
					
						
							|  |  |  | 	key_user_put(user); | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | 	if (ret == 0) { | 
					
						
							| 
									
										
											  
											
												KEYS: Alter use of key instantiation link-to-keyring argument
Alter the use of the key instantiation and negation functions' link-to-keyring
arguments.  Currently this specifies a keyring in the target process to link
the key into, creating the keyring if it doesn't exist.  This, however, can be
a problem for copy-on-write credentials as it means that the instantiating
process can alter the credentials of the requesting process.
This patch alters the behaviour such that:
 (1) If keyctl_instantiate_key() or keyctl_negate_key() are given a specific
     keyring by ID (ringid >= 0), then that keyring will be used.
 (2) If keyctl_instantiate_key() or keyctl_negate_key() are given one of the
     special constants that refer to the requesting process's keyrings
     (KEY_SPEC_*_KEYRING, all <= 0), then:
     (a) If sys_request_key() was given a keyring to use (destringid) then the
     	 key will be attached to that keyring.
     (b) If sys_request_key() was given a NULL keyring, then the key being
     	 instantiated will be attached to the default keyring as set by
     	 keyctl_set_reqkey_keyring().
 (3) No extra link will be made.
Decision point (1) follows current behaviour, and allows those instantiators
who've searched for a specifically named keyring in the requestor's keyring so
as to partition the keys by type to still have their named keyrings.
Decision point (2) allows the requestor to make sure that the key or keys that
get produced by request_key() go where they want, whilst allowing the
instantiator to request that the key is retained.  This is mainly useful for
situations where the instantiator makes a secondary request, the key for which
should be retained by the initial requestor:
	+-----------+        +--------------+        +--------------+
	|           |        |              |        |              |
	| Requestor |------->| Instantiator |------->| Instantiator |
	|           |        |              |        |              |
	+-----------+        +--------------+        +--------------+
	           request_key()           request_key()
This might be useful, for example, in Kerberos, where the requestor requests a
ticket, and then the ticket instantiator requests the TGT, which someone else
then has to go and fetch.  The TGT, however, should be retained in the
keyrings of the requestor, not the first instantiator.  To make this explict
an extra special keyring constant is also added.
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: James Morris <jmorris@namei.org>
Signed-off-by: James Morris <jmorris@namei.org>
											
										 
											2008-11-14 10:39:14 +11:00
										 |  |  | 		ret = construct_key(key, callout_info, callout_len, aux, | 
					
						
							|  |  |  | 				    dest_keyring); | 
					
						
							| 
									
										
											  
											
												CRED: Inaugurate COW credentials
Inaugurate copy-on-write credentials management.  This uses RCU to manage the
credentials pointer in the task_struct with respect to accesses by other tasks.
A process may only modify its own credentials, and so does not need locking to
access or modify its own credentials.
A mutex (cred_replace_mutex) is added to the task_struct to control the effect
of PTRACE_ATTACHED on credential calculations, particularly with respect to
execve().
With this patch, the contents of an active credentials struct may not be
changed directly; rather a new set of credentials must be prepared, modified
and committed using something like the following sequence of events:
	struct cred *new = prepare_creds();
	int ret = blah(new);
	if (ret < 0) {
		abort_creds(new);
		return ret;
	}
	return commit_creds(new);
There are some exceptions to this rule: the keyrings pointed to by the active
credentials may be instantiated - keyrings violate the COW rule as managing
COW keyrings is tricky, given that it is possible for a task to directly alter
the keys in a keyring in use by another task.
To help enforce this, various pointers to sets of credentials, such as those in
the task_struct, are declared const.  The purpose of this is compile-time
discouragement of altering credentials through those pointers.  Once a set of
credentials has been made public through one of these pointers, it may not be
modified, except under special circumstances:
  (1) Its reference count may incremented and decremented.
  (2) The keyrings to which it points may be modified, but not replaced.
The only safe way to modify anything else is to create a replacement and commit
using the functions described in Documentation/credentials.txt (which will be
added by a later patch).
This patch and the preceding patches have been tested with the LTP SELinux
testsuite.
This patch makes several logical sets of alteration:
 (1) execve().
     This now prepares and commits credentials in various places in the
     security code rather than altering the current creds directly.
 (2) Temporary credential overrides.
     do_coredump() and sys_faccessat() now prepare their own credentials and
     temporarily override the ones currently on the acting thread, whilst
     preventing interference from other threads by holding cred_replace_mutex
     on the thread being dumped.
     This will be replaced in a future patch by something that hands down the
     credentials directly to the functions being called, rather than altering
     the task's objective credentials.
 (3) LSM interface.
     A number of functions have been changed, added or removed:
     (*) security_capset_check(), ->capset_check()
     (*) security_capset_set(), ->capset_set()
     	 Removed in favour of security_capset().
     (*) security_capset(), ->capset()
     	 New.  This is passed a pointer to the new creds, a pointer to the old
     	 creds and the proposed capability sets.  It should fill in the new
     	 creds or return an error.  All pointers, barring the pointer to the
     	 new creds, are now const.
     (*) security_bprm_apply_creds(), ->bprm_apply_creds()
     	 Changed; now returns a value, which will cause the process to be
     	 killed if it's an error.
     (*) security_task_alloc(), ->task_alloc_security()
     	 Removed in favour of security_prepare_creds().
     (*) security_cred_free(), ->cred_free()
     	 New.  Free security data attached to cred->security.
     (*) security_prepare_creds(), ->cred_prepare()
     	 New. Duplicate any security data attached to cred->security.
     (*) security_commit_creds(), ->cred_commit()
     	 New. Apply any security effects for the upcoming installation of new
     	 security by commit_creds().
     (*) security_task_post_setuid(), ->task_post_setuid()
     	 Removed in favour of security_task_fix_setuid().
     (*) security_task_fix_setuid(), ->task_fix_setuid()
     	 Fix up the proposed new credentials for setuid().  This is used by
     	 cap_set_fix_setuid() to implicitly adjust capabilities in line with
     	 setuid() changes.  Changes are made to the new credentials, rather
     	 than the task itself as in security_task_post_setuid().
     (*) security_task_reparent_to_init(), ->task_reparent_to_init()
     	 Removed.  Instead the task being reparented to init is referred
     	 directly to init's credentials.
	 NOTE!  This results in the loss of some state: SELinux's osid no
	 longer records the sid of the thread that forked it.
     (*) security_key_alloc(), ->key_alloc()
     (*) security_key_permission(), ->key_permission()
     	 Changed.  These now take cred pointers rather than task pointers to
     	 refer to the security context.
 (4) sys_capset().
     This has been simplified and uses less locking.  The LSM functions it
     calls have been merged.
 (5) reparent_to_kthreadd().
     This gives the current thread the same credentials as init by simply using
     commit_thread() to point that way.
 (6) __sigqueue_alloc() and switch_uid()
     __sigqueue_alloc() can't stop the target task from changing its creds
     beneath it, so this function gets a reference to the currently applicable
     user_struct which it then passes into the sigqueue struct it returns if
     successful.
     switch_uid() is now called from commit_creds(), and possibly should be
     folded into that.  commit_creds() should take care of protecting
     __sigqueue_alloc().
 (7) [sg]et[ug]id() and co and [sg]et_current_groups.
     The set functions now all use prepare_creds(), commit_creds() and
     abort_creds() to build and check a new set of credentials before applying
     it.
     security_task_set[ug]id() is called inside the prepared section.  This
     guarantees that nothing else will affect the creds until we've finished.
     The calling of set_dumpable() has been moved into commit_creds().
     Much of the functionality of set_user() has been moved into
     commit_creds().
     The get functions all simply access the data directly.
 (8) security_task_prctl() and cap_task_prctl().
     security_task_prctl() has been modified to return -ENOSYS if it doesn't
     want to handle a function, or otherwise return the return value directly
     rather than through an argument.
     Additionally, cap_task_prctl() now prepares a new set of credentials, even
     if it doesn't end up using it.
 (9) Keyrings.
     A number of changes have been made to the keyrings code:
     (a) switch_uid_keyring(), copy_keys(), exit_keys() and suid_keys() have
     	 all been dropped and built in to the credentials functions directly.
     	 They may want separating out again later.
     (b) key_alloc() and search_process_keyrings() now take a cred pointer
     	 rather than a task pointer to specify the security context.
     (c) copy_creds() gives a new thread within the same thread group a new
     	 thread keyring if its parent had one, otherwise it discards the thread
     	 keyring.
     (d) The authorisation key now points directly to the credentials to extend
     	 the search into rather pointing to the task that carries them.
     (e) Installing thread, process or session keyrings causes a new set of
     	 credentials to be created, even though it's not strictly necessary for
     	 process or session keyrings (they're shared).
(10) Usermode helper.
     The usermode helper code now carries a cred struct pointer in its
     subprocess_info struct instead of a new session keyring pointer.  This set
     of credentials is derived from init_cred and installed on the new process
     after it has been cloned.
     call_usermodehelper_setup() allocates the new credentials and
     call_usermodehelper_freeinfo() discards them if they haven't been used.  A
     special cred function (prepare_usermodeinfo_creds()) is provided
     specifically for call_usermodehelper_setup() to call.
     call_usermodehelper_setkeys() adjusts the credentials to sport the
     supplied keyring as the new session keyring.
(11) SELinux.
     SELinux has a number of changes, in addition to those to support the LSM
     interface changes mentioned above:
     (a) selinux_setprocattr() no longer does its check for whether the
     	 current ptracer can access processes with the new SID inside the lock
     	 that covers getting the ptracer's SID.  Whilst this lock ensures that
     	 the check is done with the ptracer pinned, the result is only valid
     	 until the lock is released, so there's no point doing it inside the
     	 lock.
(12) is_single_threaded().
     This function has been extracted from selinux_setprocattr() and put into
     a file of its own in the lib/ directory as join_session_keyring() now
     wants to use it too.
     The code in SELinux just checked to see whether a task shared mm_structs
     with other tasks (CLONE_VM), but that isn't good enough.  We really want
     to know if they're part of the same thread group (CLONE_THREAD).
(13) nfsd.
     The NFS server daemon now has to use the COW credentials to set the
     credentials it is going to use.  It really needs to pass the credentials
     down to the functions it calls, but it can't do that until other patches
     in this series have been applied.
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: James Morris <jmorris@namei.org>
Signed-off-by: James Morris <jmorris@namei.org>
											
										 
											2008-11-14 10:39:23 +11:00
										 |  |  | 		if (ret < 0) { | 
					
						
							|  |  |  | 			kdebug("cons failed"); | 
					
						
							| 
									
										
										
										
											2007-10-16 23:29:46 -07:00
										 |  |  | 			goto construction_failed; | 
					
						
							| 
									
										
											  
											
												CRED: Inaugurate COW credentials
Inaugurate copy-on-write credentials management.  This uses RCU to manage the
credentials pointer in the task_struct with respect to accesses by other tasks.
A process may only modify its own credentials, and so does not need locking to
access or modify its own credentials.
A mutex (cred_replace_mutex) is added to the task_struct to control the effect
of PTRACE_ATTACHED on credential calculations, particularly with respect to
execve().
With this patch, the contents of an active credentials struct may not be
changed directly; rather a new set of credentials must be prepared, modified
and committed using something like the following sequence of events:
	struct cred *new = prepare_creds();
	int ret = blah(new);
	if (ret < 0) {
		abort_creds(new);
		return ret;
	}
	return commit_creds(new);
There are some exceptions to this rule: the keyrings pointed to by the active
credentials may be instantiated - keyrings violate the COW rule as managing
COW keyrings is tricky, given that it is possible for a task to directly alter
the keys in a keyring in use by another task.
To help enforce this, various pointers to sets of credentials, such as those in
the task_struct, are declared const.  The purpose of this is compile-time
discouragement of altering credentials through those pointers.  Once a set of
credentials has been made public through one of these pointers, it may not be
modified, except under special circumstances:
  (1) Its reference count may incremented and decremented.
  (2) The keyrings to which it points may be modified, but not replaced.
The only safe way to modify anything else is to create a replacement and commit
using the functions described in Documentation/credentials.txt (which will be
added by a later patch).
This patch and the preceding patches have been tested with the LTP SELinux
testsuite.
This patch makes several logical sets of alteration:
 (1) execve().
     This now prepares and commits credentials in various places in the
     security code rather than altering the current creds directly.
 (2) Temporary credential overrides.
     do_coredump() and sys_faccessat() now prepare their own credentials and
     temporarily override the ones currently on the acting thread, whilst
     preventing interference from other threads by holding cred_replace_mutex
     on the thread being dumped.
     This will be replaced in a future patch by something that hands down the
     credentials directly to the functions being called, rather than altering
     the task's objective credentials.
 (3) LSM interface.
     A number of functions have been changed, added or removed:
     (*) security_capset_check(), ->capset_check()
     (*) security_capset_set(), ->capset_set()
     	 Removed in favour of security_capset().
     (*) security_capset(), ->capset()
     	 New.  This is passed a pointer to the new creds, a pointer to the old
     	 creds and the proposed capability sets.  It should fill in the new
     	 creds or return an error.  All pointers, barring the pointer to the
     	 new creds, are now const.
     (*) security_bprm_apply_creds(), ->bprm_apply_creds()
     	 Changed; now returns a value, which will cause the process to be
     	 killed if it's an error.
     (*) security_task_alloc(), ->task_alloc_security()
     	 Removed in favour of security_prepare_creds().
     (*) security_cred_free(), ->cred_free()
     	 New.  Free security data attached to cred->security.
     (*) security_prepare_creds(), ->cred_prepare()
     	 New. Duplicate any security data attached to cred->security.
     (*) security_commit_creds(), ->cred_commit()
     	 New. Apply any security effects for the upcoming installation of new
     	 security by commit_creds().
     (*) security_task_post_setuid(), ->task_post_setuid()
     	 Removed in favour of security_task_fix_setuid().
     (*) security_task_fix_setuid(), ->task_fix_setuid()
     	 Fix up the proposed new credentials for setuid().  This is used by
     	 cap_set_fix_setuid() to implicitly adjust capabilities in line with
     	 setuid() changes.  Changes are made to the new credentials, rather
     	 than the task itself as in security_task_post_setuid().
     (*) security_task_reparent_to_init(), ->task_reparent_to_init()
     	 Removed.  Instead the task being reparented to init is referred
     	 directly to init's credentials.
	 NOTE!  This results in the loss of some state: SELinux's osid no
	 longer records the sid of the thread that forked it.
     (*) security_key_alloc(), ->key_alloc()
     (*) security_key_permission(), ->key_permission()
     	 Changed.  These now take cred pointers rather than task pointers to
     	 refer to the security context.
 (4) sys_capset().
     This has been simplified and uses less locking.  The LSM functions it
     calls have been merged.
 (5) reparent_to_kthreadd().
     This gives the current thread the same credentials as init by simply using
     commit_thread() to point that way.
 (6) __sigqueue_alloc() and switch_uid()
     __sigqueue_alloc() can't stop the target task from changing its creds
     beneath it, so this function gets a reference to the currently applicable
     user_struct which it then passes into the sigqueue struct it returns if
     successful.
     switch_uid() is now called from commit_creds(), and possibly should be
     folded into that.  commit_creds() should take care of protecting
     __sigqueue_alloc().
 (7) [sg]et[ug]id() and co and [sg]et_current_groups.
     The set functions now all use prepare_creds(), commit_creds() and
     abort_creds() to build and check a new set of credentials before applying
     it.
     security_task_set[ug]id() is called inside the prepared section.  This
     guarantees that nothing else will affect the creds until we've finished.
     The calling of set_dumpable() has been moved into commit_creds().
     Much of the functionality of set_user() has been moved into
     commit_creds().
     The get functions all simply access the data directly.
 (8) security_task_prctl() and cap_task_prctl().
     security_task_prctl() has been modified to return -ENOSYS if it doesn't
     want to handle a function, or otherwise return the return value directly
     rather than through an argument.
     Additionally, cap_task_prctl() now prepares a new set of credentials, even
     if it doesn't end up using it.
 (9) Keyrings.
     A number of changes have been made to the keyrings code:
     (a) switch_uid_keyring(), copy_keys(), exit_keys() and suid_keys() have
     	 all been dropped and built in to the credentials functions directly.
     	 They may want separating out again later.
     (b) key_alloc() and search_process_keyrings() now take a cred pointer
     	 rather than a task pointer to specify the security context.
     (c) copy_creds() gives a new thread within the same thread group a new
     	 thread keyring if its parent had one, otherwise it discards the thread
     	 keyring.
     (d) The authorisation key now points directly to the credentials to extend
     	 the search into rather pointing to the task that carries them.
     (e) Installing thread, process or session keyrings causes a new set of
     	 credentials to be created, even though it's not strictly necessary for
     	 process or session keyrings (they're shared).
(10) Usermode helper.
     The usermode helper code now carries a cred struct pointer in its
     subprocess_info struct instead of a new session keyring pointer.  This set
     of credentials is derived from init_cred and installed on the new process
     after it has been cloned.
     call_usermodehelper_setup() allocates the new credentials and
     call_usermodehelper_freeinfo() discards them if they haven't been used.  A
     special cred function (prepare_usermodeinfo_creds()) is provided
     specifically for call_usermodehelper_setup() to call.
     call_usermodehelper_setkeys() adjusts the credentials to sport the
     supplied keyring as the new session keyring.
(11) SELinux.
     SELinux has a number of changes, in addition to those to support the LSM
     interface changes mentioned above:
     (a) selinux_setprocattr() no longer does its check for whether the
     	 current ptracer can access processes with the new SID inside the lock
     	 that covers getting the ptracer's SID.  Whilst this lock ensures that
     	 the check is done with the ptracer pinned, the result is only valid
     	 until the lock is released, so there's no point doing it inside the
     	 lock.
(12) is_single_threaded().
     This function has been extracted from selinux_setprocattr() and put into
     a file of its own in the lib/ directory as join_session_keyring() now
     wants to use it too.
     The code in SELinux just checked to see whether a task shared mm_structs
     with other tasks (CLONE_VM), but that isn't good enough.  We really want
     to know if they're part of the same thread group (CLONE_THREAD).
(13) nfsd.
     The NFS server daemon now has to use the COW credentials to set the
     credentials it is going to use.  It really needs to pass the credentials
     down to the functions it calls, but it can't do that until other patches
     in this series have been applied.
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: James Morris <jmorris@namei.org>
Signed-off-by: James Morris <jmorris@namei.org>
											
										 
											2008-11-14 10:39:23 +11:00
										 |  |  | 		} | 
					
						
							| 
									
										
										
										
											2007-10-16 23:29:46 -07:00
										 |  |  | 	} | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
											  
											
												KEYS: Alter use of key instantiation link-to-keyring argument
Alter the use of the key instantiation and negation functions' link-to-keyring
arguments.  Currently this specifies a keyring in the target process to link
the key into, creating the keyring if it doesn't exist.  This, however, can be
a problem for copy-on-write credentials as it means that the instantiating
process can alter the credentials of the requesting process.
This patch alters the behaviour such that:
 (1) If keyctl_instantiate_key() or keyctl_negate_key() are given a specific
     keyring by ID (ringid >= 0), then that keyring will be used.
 (2) If keyctl_instantiate_key() or keyctl_negate_key() are given one of the
     special constants that refer to the requesting process's keyrings
     (KEY_SPEC_*_KEYRING, all <= 0), then:
     (a) If sys_request_key() was given a keyring to use (destringid) then the
     	 key will be attached to that keyring.
     (b) If sys_request_key() was given a NULL keyring, then the key being
     	 instantiated will be attached to the default keyring as set by
     	 keyctl_set_reqkey_keyring().
 (3) No extra link will be made.
Decision point (1) follows current behaviour, and allows those instantiators
who've searched for a specifically named keyring in the requestor's keyring so
as to partition the keys by type to still have their named keyrings.
Decision point (2) allows the requestor to make sure that the key or keys that
get produced by request_key() go where they want, whilst allowing the
instantiator to request that the key is retained.  This is mainly useful for
situations where the instantiator makes a secondary request, the key for which
should be retained by the initial requestor:
	+-----------+        +--------------+        +--------------+
	|           |        |              |        |              |
	| Requestor |------->| Instantiator |------->| Instantiator |
	|           |        |              |        |              |
	+-----------+        +--------------+        +--------------+
	           request_key()           request_key()
This might be useful, for example, in Kerberos, where the requestor requests a
ticket, and then the ticket instantiator requests the TGT, which someone else
then has to go and fetch.  The TGT, however, should be retained in the
keyrings of the requestor, not the first instantiator.  To make this explict
an extra special keyring constant is also added.
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: James Morris <jmorris@namei.org>
Signed-off-by: James Morris <jmorris@namei.org>
											
										 
											2008-11-14 10:39:14 +11:00
										 |  |  | 	key_put(dest_keyring); | 
					
						
							| 
									
										
											  
											
												CRED: Inaugurate COW credentials
Inaugurate copy-on-write credentials management.  This uses RCU to manage the
credentials pointer in the task_struct with respect to accesses by other tasks.
A process may only modify its own credentials, and so does not need locking to
access or modify its own credentials.
A mutex (cred_replace_mutex) is added to the task_struct to control the effect
of PTRACE_ATTACHED on credential calculations, particularly with respect to
execve().
With this patch, the contents of an active credentials struct may not be
changed directly; rather a new set of credentials must be prepared, modified
and committed using something like the following sequence of events:
	struct cred *new = prepare_creds();
	int ret = blah(new);
	if (ret < 0) {
		abort_creds(new);
		return ret;
	}
	return commit_creds(new);
There are some exceptions to this rule: the keyrings pointed to by the active
credentials may be instantiated - keyrings violate the COW rule as managing
COW keyrings is tricky, given that it is possible for a task to directly alter
the keys in a keyring in use by another task.
To help enforce this, various pointers to sets of credentials, such as those in
the task_struct, are declared const.  The purpose of this is compile-time
discouragement of altering credentials through those pointers.  Once a set of
credentials has been made public through one of these pointers, it may not be
modified, except under special circumstances:
  (1) Its reference count may incremented and decremented.
  (2) The keyrings to which it points may be modified, but not replaced.
The only safe way to modify anything else is to create a replacement and commit
using the functions described in Documentation/credentials.txt (which will be
added by a later patch).
This patch and the preceding patches have been tested with the LTP SELinux
testsuite.
This patch makes several logical sets of alteration:
 (1) execve().
     This now prepares and commits credentials in various places in the
     security code rather than altering the current creds directly.
 (2) Temporary credential overrides.
     do_coredump() and sys_faccessat() now prepare their own credentials and
     temporarily override the ones currently on the acting thread, whilst
     preventing interference from other threads by holding cred_replace_mutex
     on the thread being dumped.
     This will be replaced in a future patch by something that hands down the
     credentials directly to the functions being called, rather than altering
     the task's objective credentials.
 (3) LSM interface.
     A number of functions have been changed, added or removed:
     (*) security_capset_check(), ->capset_check()
     (*) security_capset_set(), ->capset_set()
     	 Removed in favour of security_capset().
     (*) security_capset(), ->capset()
     	 New.  This is passed a pointer to the new creds, a pointer to the old
     	 creds and the proposed capability sets.  It should fill in the new
     	 creds or return an error.  All pointers, barring the pointer to the
     	 new creds, are now const.
     (*) security_bprm_apply_creds(), ->bprm_apply_creds()
     	 Changed; now returns a value, which will cause the process to be
     	 killed if it's an error.
     (*) security_task_alloc(), ->task_alloc_security()
     	 Removed in favour of security_prepare_creds().
     (*) security_cred_free(), ->cred_free()
     	 New.  Free security data attached to cred->security.
     (*) security_prepare_creds(), ->cred_prepare()
     	 New. Duplicate any security data attached to cred->security.
     (*) security_commit_creds(), ->cred_commit()
     	 New. Apply any security effects for the upcoming installation of new
     	 security by commit_creds().
     (*) security_task_post_setuid(), ->task_post_setuid()
     	 Removed in favour of security_task_fix_setuid().
     (*) security_task_fix_setuid(), ->task_fix_setuid()
     	 Fix up the proposed new credentials for setuid().  This is used by
     	 cap_set_fix_setuid() to implicitly adjust capabilities in line with
     	 setuid() changes.  Changes are made to the new credentials, rather
     	 than the task itself as in security_task_post_setuid().
     (*) security_task_reparent_to_init(), ->task_reparent_to_init()
     	 Removed.  Instead the task being reparented to init is referred
     	 directly to init's credentials.
	 NOTE!  This results in the loss of some state: SELinux's osid no
	 longer records the sid of the thread that forked it.
     (*) security_key_alloc(), ->key_alloc()
     (*) security_key_permission(), ->key_permission()
     	 Changed.  These now take cred pointers rather than task pointers to
     	 refer to the security context.
 (4) sys_capset().
     This has been simplified and uses less locking.  The LSM functions it
     calls have been merged.
 (5) reparent_to_kthreadd().
     This gives the current thread the same credentials as init by simply using
     commit_thread() to point that way.
 (6) __sigqueue_alloc() and switch_uid()
     __sigqueue_alloc() can't stop the target task from changing its creds
     beneath it, so this function gets a reference to the currently applicable
     user_struct which it then passes into the sigqueue struct it returns if
     successful.
     switch_uid() is now called from commit_creds(), and possibly should be
     folded into that.  commit_creds() should take care of protecting
     __sigqueue_alloc().
 (7) [sg]et[ug]id() and co and [sg]et_current_groups.
     The set functions now all use prepare_creds(), commit_creds() and
     abort_creds() to build and check a new set of credentials before applying
     it.
     security_task_set[ug]id() is called inside the prepared section.  This
     guarantees that nothing else will affect the creds until we've finished.
     The calling of set_dumpable() has been moved into commit_creds().
     Much of the functionality of set_user() has been moved into
     commit_creds().
     The get functions all simply access the data directly.
 (8) security_task_prctl() and cap_task_prctl().
     security_task_prctl() has been modified to return -ENOSYS if it doesn't
     want to handle a function, or otherwise return the return value directly
     rather than through an argument.
     Additionally, cap_task_prctl() now prepares a new set of credentials, even
     if it doesn't end up using it.
 (9) Keyrings.
     A number of changes have been made to the keyrings code:
     (a) switch_uid_keyring(), copy_keys(), exit_keys() and suid_keys() have
     	 all been dropped and built in to the credentials functions directly.
     	 They may want separating out again later.
     (b) key_alloc() and search_process_keyrings() now take a cred pointer
     	 rather than a task pointer to specify the security context.
     (c) copy_creds() gives a new thread within the same thread group a new
     	 thread keyring if its parent had one, otherwise it discards the thread
     	 keyring.
     (d) The authorisation key now points directly to the credentials to extend
     	 the search into rather pointing to the task that carries them.
     (e) Installing thread, process or session keyrings causes a new set of
     	 credentials to be created, even though it's not strictly necessary for
     	 process or session keyrings (they're shared).
(10) Usermode helper.
     The usermode helper code now carries a cred struct pointer in its
     subprocess_info struct instead of a new session keyring pointer.  This set
     of credentials is derived from init_cred and installed on the new process
     after it has been cloned.
     call_usermodehelper_setup() allocates the new credentials and
     call_usermodehelper_freeinfo() discards them if they haven't been used.  A
     special cred function (prepare_usermodeinfo_creds()) is provided
     specifically for call_usermodehelper_setup() to call.
     call_usermodehelper_setkeys() adjusts the credentials to sport the
     supplied keyring as the new session keyring.
(11) SELinux.
     SELinux has a number of changes, in addition to those to support the LSM
     interface changes mentioned above:
     (a) selinux_setprocattr() no longer does its check for whether the
     	 current ptracer can access processes with the new SID inside the lock
     	 that covers getting the ptracer's SID.  Whilst this lock ensures that
     	 the check is done with the ptracer pinned, the result is only valid
     	 until the lock is released, so there's no point doing it inside the
     	 lock.
(12) is_single_threaded().
     This function has been extracted from selinux_setprocattr() and put into
     a file of its own in the lib/ directory as join_session_keyring() now
     wants to use it too.
     The code in SELinux just checked to see whether a task shared mm_structs
     with other tasks (CLONE_VM), but that isn't good enough.  We really want
     to know if they're part of the same thread group (CLONE_THREAD).
(13) nfsd.
     The NFS server daemon now has to use the COW credentials to set the
     credentials it is going to use.  It really needs to pass the credentials
     down to the functions it calls, but it can't do that until other patches
     in this series have been applied.
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: James Morris <jmorris@namei.org>
Signed-off-by: James Morris <jmorris@namei.org>
											
										 
											2008-11-14 10:39:23 +11:00
										 |  |  | 	kleave(" = key %d", key_serial(key)); | 
					
						
							| 
									
										
										
										
											2007-10-16 23:29:46 -07:00
										 |  |  | 	return key; | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | construction_failed: | 
					
						
							|  |  |  | 	key_negate_and_link(key, key_negative_timeout, NULL, NULL); | 
					
						
							|  |  |  | 	key_put(key); | 
					
						
							| 
									
										
											  
											
												KEYS: Alter use of key instantiation link-to-keyring argument
Alter the use of the key instantiation and negation functions' link-to-keyring
arguments.  Currently this specifies a keyring in the target process to link
the key into, creating the keyring if it doesn't exist.  This, however, can be
a problem for copy-on-write credentials as it means that the instantiating
process can alter the credentials of the requesting process.
This patch alters the behaviour such that:
 (1) If keyctl_instantiate_key() or keyctl_negate_key() are given a specific
     keyring by ID (ringid >= 0), then that keyring will be used.
 (2) If keyctl_instantiate_key() or keyctl_negate_key() are given one of the
     special constants that refer to the requesting process's keyrings
     (KEY_SPEC_*_KEYRING, all <= 0), then:
     (a) If sys_request_key() was given a keyring to use (destringid) then the
     	 key will be attached to that keyring.
     (b) If sys_request_key() was given a NULL keyring, then the key being
     	 instantiated will be attached to the default keyring as set by
     	 keyctl_set_reqkey_keyring().
 (3) No extra link will be made.
Decision point (1) follows current behaviour, and allows those instantiators
who've searched for a specifically named keyring in the requestor's keyring so
as to partition the keys by type to still have their named keyrings.
Decision point (2) allows the requestor to make sure that the key or keys that
get produced by request_key() go where they want, whilst allowing the
instantiator to request that the key is retained.  This is mainly useful for
situations where the instantiator makes a secondary request, the key for which
should be retained by the initial requestor:
	+-----------+        +--------------+        +--------------+
	|           |        |              |        |              |
	| Requestor |------->| Instantiator |------->| Instantiator |
	|           |        |              |        |              |
	+-----------+        +--------------+        +--------------+
	           request_key()           request_key()
This might be useful, for example, in Kerberos, where the requestor requests a
ticket, and then the ticket instantiator requests the TGT, which someone else
then has to go and fetch.  The TGT, however, should be retained in the
keyrings of the requestor, not the first instantiator.  To make this explict
an extra special keyring constant is also added.
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: James Morris <jmorris@namei.org>
Signed-off-by: James Morris <jmorris@namei.org>
											
										 
											2008-11-14 10:39:14 +11:00
										 |  |  | 	key_put(dest_keyring); | 
					
						
							| 
									
										
											  
											
												CRED: Inaugurate COW credentials
Inaugurate copy-on-write credentials management.  This uses RCU to manage the
credentials pointer in the task_struct with respect to accesses by other tasks.
A process may only modify its own credentials, and so does not need locking to
access or modify its own credentials.
A mutex (cred_replace_mutex) is added to the task_struct to control the effect
of PTRACE_ATTACHED on credential calculations, particularly with respect to
execve().
With this patch, the contents of an active credentials struct may not be
changed directly; rather a new set of credentials must be prepared, modified
and committed using something like the following sequence of events:
	struct cred *new = prepare_creds();
	int ret = blah(new);
	if (ret < 0) {
		abort_creds(new);
		return ret;
	}
	return commit_creds(new);
There are some exceptions to this rule: the keyrings pointed to by the active
credentials may be instantiated - keyrings violate the COW rule as managing
COW keyrings is tricky, given that it is possible for a task to directly alter
the keys in a keyring in use by another task.
To help enforce this, various pointers to sets of credentials, such as those in
the task_struct, are declared const.  The purpose of this is compile-time
discouragement of altering credentials through those pointers.  Once a set of
credentials has been made public through one of these pointers, it may not be
modified, except under special circumstances:
  (1) Its reference count may incremented and decremented.
  (2) The keyrings to which it points may be modified, but not replaced.
The only safe way to modify anything else is to create a replacement and commit
using the functions described in Documentation/credentials.txt (which will be
added by a later patch).
This patch and the preceding patches have been tested with the LTP SELinux
testsuite.
This patch makes several logical sets of alteration:
 (1) execve().
     This now prepares and commits credentials in various places in the
     security code rather than altering the current creds directly.
 (2) Temporary credential overrides.
     do_coredump() and sys_faccessat() now prepare their own credentials and
     temporarily override the ones currently on the acting thread, whilst
     preventing interference from other threads by holding cred_replace_mutex
     on the thread being dumped.
     This will be replaced in a future patch by something that hands down the
     credentials directly to the functions being called, rather than altering
     the task's objective credentials.
 (3) LSM interface.
     A number of functions have been changed, added or removed:
     (*) security_capset_check(), ->capset_check()
     (*) security_capset_set(), ->capset_set()
     	 Removed in favour of security_capset().
     (*) security_capset(), ->capset()
     	 New.  This is passed a pointer to the new creds, a pointer to the old
     	 creds and the proposed capability sets.  It should fill in the new
     	 creds or return an error.  All pointers, barring the pointer to the
     	 new creds, are now const.
     (*) security_bprm_apply_creds(), ->bprm_apply_creds()
     	 Changed; now returns a value, which will cause the process to be
     	 killed if it's an error.
     (*) security_task_alloc(), ->task_alloc_security()
     	 Removed in favour of security_prepare_creds().
     (*) security_cred_free(), ->cred_free()
     	 New.  Free security data attached to cred->security.
     (*) security_prepare_creds(), ->cred_prepare()
     	 New. Duplicate any security data attached to cred->security.
     (*) security_commit_creds(), ->cred_commit()
     	 New. Apply any security effects for the upcoming installation of new
     	 security by commit_creds().
     (*) security_task_post_setuid(), ->task_post_setuid()
     	 Removed in favour of security_task_fix_setuid().
     (*) security_task_fix_setuid(), ->task_fix_setuid()
     	 Fix up the proposed new credentials for setuid().  This is used by
     	 cap_set_fix_setuid() to implicitly adjust capabilities in line with
     	 setuid() changes.  Changes are made to the new credentials, rather
     	 than the task itself as in security_task_post_setuid().
     (*) security_task_reparent_to_init(), ->task_reparent_to_init()
     	 Removed.  Instead the task being reparented to init is referred
     	 directly to init's credentials.
	 NOTE!  This results in the loss of some state: SELinux's osid no
	 longer records the sid of the thread that forked it.
     (*) security_key_alloc(), ->key_alloc()
     (*) security_key_permission(), ->key_permission()
     	 Changed.  These now take cred pointers rather than task pointers to
     	 refer to the security context.
 (4) sys_capset().
     This has been simplified and uses less locking.  The LSM functions it
     calls have been merged.
 (5) reparent_to_kthreadd().
     This gives the current thread the same credentials as init by simply using
     commit_thread() to point that way.
 (6) __sigqueue_alloc() and switch_uid()
     __sigqueue_alloc() can't stop the target task from changing its creds
     beneath it, so this function gets a reference to the currently applicable
     user_struct which it then passes into the sigqueue struct it returns if
     successful.
     switch_uid() is now called from commit_creds(), and possibly should be
     folded into that.  commit_creds() should take care of protecting
     __sigqueue_alloc().
 (7) [sg]et[ug]id() and co and [sg]et_current_groups.
     The set functions now all use prepare_creds(), commit_creds() and
     abort_creds() to build and check a new set of credentials before applying
     it.
     security_task_set[ug]id() is called inside the prepared section.  This
     guarantees that nothing else will affect the creds until we've finished.
     The calling of set_dumpable() has been moved into commit_creds().
     Much of the functionality of set_user() has been moved into
     commit_creds().
     The get functions all simply access the data directly.
 (8) security_task_prctl() and cap_task_prctl().
     security_task_prctl() has been modified to return -ENOSYS if it doesn't
     want to handle a function, or otherwise return the return value directly
     rather than through an argument.
     Additionally, cap_task_prctl() now prepares a new set of credentials, even
     if it doesn't end up using it.
 (9) Keyrings.
     A number of changes have been made to the keyrings code:
     (a) switch_uid_keyring(), copy_keys(), exit_keys() and suid_keys() have
     	 all been dropped and built in to the credentials functions directly.
     	 They may want separating out again later.
     (b) key_alloc() and search_process_keyrings() now take a cred pointer
     	 rather than a task pointer to specify the security context.
     (c) copy_creds() gives a new thread within the same thread group a new
     	 thread keyring if its parent had one, otherwise it discards the thread
     	 keyring.
     (d) The authorisation key now points directly to the credentials to extend
     	 the search into rather pointing to the task that carries them.
     (e) Installing thread, process or session keyrings causes a new set of
     	 credentials to be created, even though it's not strictly necessary for
     	 process or session keyrings (they're shared).
(10) Usermode helper.
     The usermode helper code now carries a cred struct pointer in its
     subprocess_info struct instead of a new session keyring pointer.  This set
     of credentials is derived from init_cred and installed on the new process
     after it has been cloned.
     call_usermodehelper_setup() allocates the new credentials and
     call_usermodehelper_freeinfo() discards them if they haven't been used.  A
     special cred function (prepare_usermodeinfo_creds()) is provided
     specifically for call_usermodehelper_setup() to call.
     call_usermodehelper_setkeys() adjusts the credentials to sport the
     supplied keyring as the new session keyring.
(11) SELinux.
     SELinux has a number of changes, in addition to those to support the LSM
     interface changes mentioned above:
     (a) selinux_setprocattr() no longer does its check for whether the
     	 current ptracer can access processes with the new SID inside the lock
     	 that covers getting the ptracer's SID.  Whilst this lock ensures that
     	 the check is done with the ptracer pinned, the result is only valid
     	 until the lock is released, so there's no point doing it inside the
     	 lock.
(12) is_single_threaded().
     This function has been extracted from selinux_setprocattr() and put into
     a file of its own in the lib/ directory as join_session_keyring() now
     wants to use it too.
     The code in SELinux just checked to see whether a task shared mm_structs
     with other tasks (CLONE_VM), but that isn't good enough.  We really want
     to know if they're part of the same thread group (CLONE_THREAD).
(13) nfsd.
     The NFS server daemon now has to use the COW credentials to set the
     credentials it is going to use.  It really needs to pass the credentials
     down to the functions it calls, but it can't do that until other patches
     in this series have been applied.
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: James Morris <jmorris@namei.org>
Signed-off-by: James Morris <jmorris@namei.org>
											
										 
											2008-11-14 10:39:23 +11:00
										 |  |  | 	kleave(" = %d", ret); | 
					
						
							| 
									
										
										
										
											2007-10-16 23:29:46 -07:00
										 |  |  | 	return ERR_PTR(ret); | 
					
						
							|  |  |  | } | 
					
						
							| 
									
										
											  
											
												[PATCH] Keys: Make request-key create an authorisation key
The attached patch makes the following changes:
 (1) There's a new special key type called ".request_key_auth".
     This is an authorisation key for when one process requests a key and
     another process is started to construct it. This type of key cannot be
     created by the user; nor can it be requested by kernel services.
     Authorisation keys hold two references:
     (a) Each refers to a key being constructed. When the key being
     	 constructed is instantiated the authorisation key is revoked,
     	 rendering it of no further use.
     (b) The "authorising process". This is either:
     	 (i) the process that called request_key(), or:
     	 (ii) if the process that called request_key() itself had an
     	      authorisation key in its session keyring, then the authorising
     	      process referred to by that authorisation key will also be
     	      referred to by the new authorisation key.
	 This means that the process that initiated a chain of key requests
	 will authorise the lot of them, and will, by default, wind up with
	 the keys obtained from them in its keyrings.
 (2) request_key() creates an authorisation key which is then passed to
     /sbin/request-key in as part of a new session keyring.
 (3) When request_key() is searching for a key to hand back to the caller, if
     it comes across an authorisation key in the session keyring of the
     calling process, it will also search the keyrings of the process
     specified therein and it will use the specified process's credentials
     (fsuid, fsgid, groups) to do that rather than the calling process's
     credentials.
     This allows a process started by /sbin/request-key to find keys belonging
     to the authorising process.
 (4) A key can be read, even if the process executing KEYCTL_READ doesn't have
     direct read or search permission if that key is contained within the
     keyrings of a process specified by an authorisation key found within the
     calling process's session keyring, and is searchable using the
     credentials of the authorising process.
     This allows a process started by /sbin/request-key to read keys belonging
     to the authorising process.
 (5) The magic KEY_SPEC_*_KEYRING key IDs when passed to KEYCTL_INSTANTIATE or
     KEYCTL_NEGATE will specify a keyring of the authorising process, rather
     than the process doing the instantiation.
 (6) One of the process keyrings can be nominated as the default to which
     request_key() should attach new keys if not otherwise specified. This is
     done with KEYCTL_SET_REQKEY_KEYRING and one of the KEY_REQKEY_DEFL_*
     constants. The current setting can also be read using this call.
 (7) request_key() is partially interruptible. If it is waiting for another
     process to finish constructing a key, it can be interrupted. This permits
     a request-key cycle to be broken without recourse to rebooting.
Signed-Off-By: David Howells <dhowells@redhat.com>
Signed-Off-By: Benoit Boissinot <benoit.boissinot@ens-lyon.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
											
										 
											2005-06-23 22:00:56 -07:00
										 |  |  | 
 | 
					
						
							| 
									
										
										
										
											2005-04-16 15:20:36 -07:00
										 |  |  | /*
 | 
					
						
							|  |  |  |  * request a key | 
					
						
							|  |  |  |  * - search the process's keyrings | 
					
						
							|  |  |  |  * - check the list of keys being created or updated | 
					
						
							| 
									
										
											  
											
												[PATCH] Keys: Make request-key create an authorisation key
The attached patch makes the following changes:
 (1) There's a new special key type called ".request_key_auth".
     This is an authorisation key for when one process requests a key and
     another process is started to construct it. This type of key cannot be
     created by the user; nor can it be requested by kernel services.
     Authorisation keys hold two references:
     (a) Each refers to a key being constructed. When the key being
     	 constructed is instantiated the authorisation key is revoked,
     	 rendering it of no further use.
     (b) The "authorising process". This is either:
     	 (i) the process that called request_key(), or:
     	 (ii) if the process that called request_key() itself had an
     	      authorisation key in its session keyring, then the authorising
     	      process referred to by that authorisation key will also be
     	      referred to by the new authorisation key.
	 This means that the process that initiated a chain of key requests
	 will authorise the lot of them, and will, by default, wind up with
	 the keys obtained from them in its keyrings.
 (2) request_key() creates an authorisation key which is then passed to
     /sbin/request-key in as part of a new session keyring.
 (3) When request_key() is searching for a key to hand back to the caller, if
     it comes across an authorisation key in the session keyring of the
     calling process, it will also search the keyrings of the process
     specified therein and it will use the specified process's credentials
     (fsuid, fsgid, groups) to do that rather than the calling process's
     credentials.
     This allows a process started by /sbin/request-key to find keys belonging
     to the authorising process.
 (4) A key can be read, even if the process executing KEYCTL_READ doesn't have
     direct read or search permission if that key is contained within the
     keyrings of a process specified by an authorisation key found within the
     calling process's session keyring, and is searchable using the
     credentials of the authorising process.
     This allows a process started by /sbin/request-key to read keys belonging
     to the authorising process.
 (5) The magic KEY_SPEC_*_KEYRING key IDs when passed to KEYCTL_INSTANTIATE or
     KEYCTL_NEGATE will specify a keyring of the authorising process, rather
     than the process doing the instantiation.
 (6) One of the process keyrings can be nominated as the default to which
     request_key() should attach new keys if not otherwise specified. This is
     done with KEYCTL_SET_REQKEY_KEYRING and one of the KEY_REQKEY_DEFL_*
     constants. The current setting can also be read using this call.
 (7) request_key() is partially interruptible. If it is waiting for another
     process to finish constructing a key, it can be interrupted. This permits
     a request-key cycle to be broken without recourse to rebooting.
Signed-Off-By: David Howells <dhowells@redhat.com>
Signed-Off-By: Benoit Boissinot <benoit.boissinot@ens-lyon.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
											
										 
											2005-06-23 22:00:56 -07:00
										 |  |  |  * - call out to userspace for a key if supplementary info was provided | 
					
						
							|  |  |  |  * - cache the key in an appropriate keyring | 
					
						
							| 
									
										
										
										
											2005-04-16 15:20:36 -07:00
										 |  |  |  */ | 
					
						
							| 
									
										
											  
											
												[PATCH] Keys: Make request-key create an authorisation key
The attached patch makes the following changes:
 (1) There's a new special key type called ".request_key_auth".
     This is an authorisation key for when one process requests a key and
     another process is started to construct it. This type of key cannot be
     created by the user; nor can it be requested by kernel services.
     Authorisation keys hold two references:
     (a) Each refers to a key being constructed. When the key being
     	 constructed is instantiated the authorisation key is revoked,
     	 rendering it of no further use.
     (b) The "authorising process". This is either:
     	 (i) the process that called request_key(), or:
     	 (ii) if the process that called request_key() itself had an
     	      authorisation key in its session keyring, then the authorising
     	      process referred to by that authorisation key will also be
     	      referred to by the new authorisation key.
	 This means that the process that initiated a chain of key requests
	 will authorise the lot of them, and will, by default, wind up with
	 the keys obtained from them in its keyrings.
 (2) request_key() creates an authorisation key which is then passed to
     /sbin/request-key in as part of a new session keyring.
 (3) When request_key() is searching for a key to hand back to the caller, if
     it comes across an authorisation key in the session keyring of the
     calling process, it will also search the keyrings of the process
     specified therein and it will use the specified process's credentials
     (fsuid, fsgid, groups) to do that rather than the calling process's
     credentials.
     This allows a process started by /sbin/request-key to find keys belonging
     to the authorising process.
 (4) A key can be read, even if the process executing KEYCTL_READ doesn't have
     direct read or search permission if that key is contained within the
     keyrings of a process specified by an authorisation key found within the
     calling process's session keyring, and is searchable using the
     credentials of the authorising process.
     This allows a process started by /sbin/request-key to read keys belonging
     to the authorising process.
 (5) The magic KEY_SPEC_*_KEYRING key IDs when passed to KEYCTL_INSTANTIATE or
     KEYCTL_NEGATE will specify a keyring of the authorising process, rather
     than the process doing the instantiation.
 (6) One of the process keyrings can be nominated as the default to which
     request_key() should attach new keys if not otherwise specified. This is
     done with KEYCTL_SET_REQKEY_KEYRING and one of the KEY_REQKEY_DEFL_*
     constants. The current setting can also be read using this call.
 (7) request_key() is partially interruptible. If it is waiting for another
     process to finish constructing a key, it can be interrupted. This permits
     a request-key cycle to be broken without recourse to rebooting.
Signed-Off-By: David Howells <dhowells@redhat.com>
Signed-Off-By: Benoit Boissinot <benoit.boissinot@ens-lyon.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
											
										 
											2005-06-23 22:00:56 -07:00
										 |  |  | struct key *request_key_and_link(struct key_type *type, | 
					
						
							|  |  |  | 				 const char *description, | 
					
						
							| 
									
										
										
										
											2008-04-29 01:01:24 -07:00
										 |  |  | 				 const void *callout_info, | 
					
						
							|  |  |  | 				 size_t callout_len, | 
					
						
							| 
									
										
										
										
											2006-06-29 02:24:28 -07:00
										 |  |  | 				 void *aux, | 
					
						
							| 
									
										
										
										
											2006-06-26 00:24:50 -07:00
										 |  |  | 				 struct key *dest_keyring, | 
					
						
							|  |  |  | 				 unsigned long flags) | 
					
						
							| 
									
										
										
										
											2005-04-16 15:20:36 -07:00
										 |  |  | { | 
					
						
							| 
									
										
											  
											
												CRED: Inaugurate COW credentials
Inaugurate copy-on-write credentials management.  This uses RCU to manage the
credentials pointer in the task_struct with respect to accesses by other tasks.
A process may only modify its own credentials, and so does not need locking to
access or modify its own credentials.
A mutex (cred_replace_mutex) is added to the task_struct to control the effect
of PTRACE_ATTACHED on credential calculations, particularly with respect to
execve().
With this patch, the contents of an active credentials struct may not be
changed directly; rather a new set of credentials must be prepared, modified
and committed using something like the following sequence of events:
	struct cred *new = prepare_creds();
	int ret = blah(new);
	if (ret < 0) {
		abort_creds(new);
		return ret;
	}
	return commit_creds(new);
There are some exceptions to this rule: the keyrings pointed to by the active
credentials may be instantiated - keyrings violate the COW rule as managing
COW keyrings is tricky, given that it is possible for a task to directly alter
the keys in a keyring in use by another task.
To help enforce this, various pointers to sets of credentials, such as those in
the task_struct, are declared const.  The purpose of this is compile-time
discouragement of altering credentials through those pointers.  Once a set of
credentials has been made public through one of these pointers, it may not be
modified, except under special circumstances:
  (1) Its reference count may incremented and decremented.
  (2) The keyrings to which it points may be modified, but not replaced.
The only safe way to modify anything else is to create a replacement and commit
using the functions described in Documentation/credentials.txt (which will be
added by a later patch).
This patch and the preceding patches have been tested with the LTP SELinux
testsuite.
This patch makes several logical sets of alteration:
 (1) execve().
     This now prepares and commits credentials in various places in the
     security code rather than altering the current creds directly.
 (2) Temporary credential overrides.
     do_coredump() and sys_faccessat() now prepare their own credentials and
     temporarily override the ones currently on the acting thread, whilst
     preventing interference from other threads by holding cred_replace_mutex
     on the thread being dumped.
     This will be replaced in a future patch by something that hands down the
     credentials directly to the functions being called, rather than altering
     the task's objective credentials.
 (3) LSM interface.
     A number of functions have been changed, added or removed:
     (*) security_capset_check(), ->capset_check()
     (*) security_capset_set(), ->capset_set()
     	 Removed in favour of security_capset().
     (*) security_capset(), ->capset()
     	 New.  This is passed a pointer to the new creds, a pointer to the old
     	 creds and the proposed capability sets.  It should fill in the new
     	 creds or return an error.  All pointers, barring the pointer to the
     	 new creds, are now const.
     (*) security_bprm_apply_creds(), ->bprm_apply_creds()
     	 Changed; now returns a value, which will cause the process to be
     	 killed if it's an error.
     (*) security_task_alloc(), ->task_alloc_security()
     	 Removed in favour of security_prepare_creds().
     (*) security_cred_free(), ->cred_free()
     	 New.  Free security data attached to cred->security.
     (*) security_prepare_creds(), ->cred_prepare()
     	 New. Duplicate any security data attached to cred->security.
     (*) security_commit_creds(), ->cred_commit()
     	 New. Apply any security effects for the upcoming installation of new
     	 security by commit_creds().
     (*) security_task_post_setuid(), ->task_post_setuid()
     	 Removed in favour of security_task_fix_setuid().
     (*) security_task_fix_setuid(), ->task_fix_setuid()
     	 Fix up the proposed new credentials for setuid().  This is used by
     	 cap_set_fix_setuid() to implicitly adjust capabilities in line with
     	 setuid() changes.  Changes are made to the new credentials, rather
     	 than the task itself as in security_task_post_setuid().
     (*) security_task_reparent_to_init(), ->task_reparent_to_init()
     	 Removed.  Instead the task being reparented to init is referred
     	 directly to init's credentials.
	 NOTE!  This results in the loss of some state: SELinux's osid no
	 longer records the sid of the thread that forked it.
     (*) security_key_alloc(), ->key_alloc()
     (*) security_key_permission(), ->key_permission()
     	 Changed.  These now take cred pointers rather than task pointers to
     	 refer to the security context.
 (4) sys_capset().
     This has been simplified and uses less locking.  The LSM functions it
     calls have been merged.
 (5) reparent_to_kthreadd().
     This gives the current thread the same credentials as init by simply using
     commit_thread() to point that way.
 (6) __sigqueue_alloc() and switch_uid()
     __sigqueue_alloc() can't stop the target task from changing its creds
     beneath it, so this function gets a reference to the currently applicable
     user_struct which it then passes into the sigqueue struct it returns if
     successful.
     switch_uid() is now called from commit_creds(), and possibly should be
     folded into that.  commit_creds() should take care of protecting
     __sigqueue_alloc().
 (7) [sg]et[ug]id() and co and [sg]et_current_groups.
     The set functions now all use prepare_creds(), commit_creds() and
     abort_creds() to build and check a new set of credentials before applying
     it.
     security_task_set[ug]id() is called inside the prepared section.  This
     guarantees that nothing else will affect the creds until we've finished.
     The calling of set_dumpable() has been moved into commit_creds().
     Much of the functionality of set_user() has been moved into
     commit_creds().
     The get functions all simply access the data directly.
 (8) security_task_prctl() and cap_task_prctl().
     security_task_prctl() has been modified to return -ENOSYS if it doesn't
     want to handle a function, or otherwise return the return value directly
     rather than through an argument.
     Additionally, cap_task_prctl() now prepares a new set of credentials, even
     if it doesn't end up using it.
 (9) Keyrings.
     A number of changes have been made to the keyrings code:
     (a) switch_uid_keyring(), copy_keys(), exit_keys() and suid_keys() have
     	 all been dropped and built in to the credentials functions directly.
     	 They may want separating out again later.
     (b) key_alloc() and search_process_keyrings() now take a cred pointer
     	 rather than a task pointer to specify the security context.
     (c) copy_creds() gives a new thread within the same thread group a new
     	 thread keyring if its parent had one, otherwise it discards the thread
     	 keyring.
     (d) The authorisation key now points directly to the credentials to extend
     	 the search into rather pointing to the task that carries them.
     (e) Installing thread, process or session keyrings causes a new set of
     	 credentials to be created, even though it's not strictly necessary for
     	 process or session keyrings (they're shared).
(10) Usermode helper.
     The usermode helper code now carries a cred struct pointer in its
     subprocess_info struct instead of a new session keyring pointer.  This set
     of credentials is derived from init_cred and installed on the new process
     after it has been cloned.
     call_usermodehelper_setup() allocates the new credentials and
     call_usermodehelper_freeinfo() discards them if they haven't been used.  A
     special cred function (prepare_usermodeinfo_creds()) is provided
     specifically for call_usermodehelper_setup() to call.
     call_usermodehelper_setkeys() adjusts the credentials to sport the
     supplied keyring as the new session keyring.
(11) SELinux.
     SELinux has a number of changes, in addition to those to support the LSM
     interface changes mentioned above:
     (a) selinux_setprocattr() no longer does its check for whether the
     	 current ptracer can access processes with the new SID inside the lock
     	 that covers getting the ptracer's SID.  Whilst this lock ensures that
     	 the check is done with the ptracer pinned, the result is only valid
     	 until the lock is released, so there's no point doing it inside the
     	 lock.
(12) is_single_threaded().
     This function has been extracted from selinux_setprocattr() and put into
     a file of its own in the lib/ directory as join_session_keyring() now
     wants to use it too.
     The code in SELinux just checked to see whether a task shared mm_structs
     with other tasks (CLONE_VM), but that isn't good enough.  We really want
     to know if they're part of the same thread group (CLONE_THREAD).
(13) nfsd.
     The NFS server daemon now has to use the COW credentials to set the
     credentials it is going to use.  It really needs to pass the credentials
     down to the functions it calls, but it can't do that until other patches
     in this series have been applied.
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: James Morris <jmorris@namei.org>
Signed-off-by: James Morris <jmorris@namei.org>
											
										 
											2008-11-14 10:39:23 +11:00
										 |  |  | 	const struct cred *cred = current_cred(); | 
					
						
							| 
									
										
										
										
											2005-04-16 15:20:36 -07:00
										 |  |  | 	struct key *key; | 
					
						
							| 
									
										
										
										
											2005-09-28 17:03:15 +01:00
										 |  |  | 	key_ref_t key_ref; | 
					
						
							| 
									
										
										
										
											2005-04-16 15:20:36 -07:00
										 |  |  | 
 | 
					
						
							| 
									
										
										
										
											2008-04-29 01:01:24 -07:00
										 |  |  | 	kenter("%s,%s,%p,%zu,%p,%p,%lx", | 
					
						
							|  |  |  | 	       type->name, description, callout_info, callout_len, aux, | 
					
						
							| 
									
										
										
										
											2006-06-29 02:24:28 -07:00
										 |  |  | 	       dest_keyring, flags); | 
					
						
							| 
									
										
											  
											
												[PATCH] Keys: Make request-key create an authorisation key
The attached patch makes the following changes:
 (1) There's a new special key type called ".request_key_auth".
     This is an authorisation key for when one process requests a key and
     another process is started to construct it. This type of key cannot be
     created by the user; nor can it be requested by kernel services.
     Authorisation keys hold two references:
     (a) Each refers to a key being constructed. When the key being
     	 constructed is instantiated the authorisation key is revoked,
     	 rendering it of no further use.
     (b) The "authorising process". This is either:
     	 (i) the process that called request_key(), or:
     	 (ii) if the process that called request_key() itself had an
     	      authorisation key in its session keyring, then the authorising
     	      process referred to by that authorisation key will also be
     	      referred to by the new authorisation key.
	 This means that the process that initiated a chain of key requests
	 will authorise the lot of them, and will, by default, wind up with
	 the keys obtained from them in its keyrings.
 (2) request_key() creates an authorisation key which is then passed to
     /sbin/request-key in as part of a new session keyring.
 (3) When request_key() is searching for a key to hand back to the caller, if
     it comes across an authorisation key in the session keyring of the
     calling process, it will also search the keyrings of the process
     specified therein and it will use the specified process's credentials
     (fsuid, fsgid, groups) to do that rather than the calling process's
     credentials.
     This allows a process started by /sbin/request-key to find keys belonging
     to the authorising process.
 (4) A key can be read, even if the process executing KEYCTL_READ doesn't have
     direct read or search permission if that key is contained within the
     keyrings of a process specified by an authorisation key found within the
     calling process's session keyring, and is searchable using the
     credentials of the authorising process.
     This allows a process started by /sbin/request-key to read keys belonging
     to the authorising process.
 (5) The magic KEY_SPEC_*_KEYRING key IDs when passed to KEYCTL_INSTANTIATE or
     KEYCTL_NEGATE will specify a keyring of the authorising process, rather
     than the process doing the instantiation.
 (6) One of the process keyrings can be nominated as the default to which
     request_key() should attach new keys if not otherwise specified. This is
     done with KEYCTL_SET_REQKEY_KEYRING and one of the KEY_REQKEY_DEFL_*
     constants. The current setting can also be read using this call.
 (7) request_key() is partially interruptible. If it is waiting for another
     process to finish constructing a key, it can be interrupted. This permits
     a request-key cycle to be broken without recourse to rebooting.
Signed-Off-By: David Howells <dhowells@redhat.com>
Signed-Off-By: Benoit Boissinot <benoit.boissinot@ens-lyon.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
											
										 
											2005-06-23 22:00:56 -07:00
										 |  |  | 
 | 
					
						
							| 
									
										
										
										
											2005-04-16 15:20:36 -07:00
										 |  |  | 	/* search all the process keyrings for a key */ | 
					
						
							| 
									
										
										
										
											2005-09-28 17:03:15 +01:00
										 |  |  | 	key_ref = search_process_keyrings(type, description, type->match, | 
					
						
							| 
									
										
											  
											
												CRED: Inaugurate COW credentials
Inaugurate copy-on-write credentials management.  This uses RCU to manage the
credentials pointer in the task_struct with respect to accesses by other tasks.
A process may only modify its own credentials, and so does not need locking to
access or modify its own credentials.
A mutex (cred_replace_mutex) is added to the task_struct to control the effect
of PTRACE_ATTACHED on credential calculations, particularly with respect to
execve().
With this patch, the contents of an active credentials struct may not be
changed directly; rather a new set of credentials must be prepared, modified
and committed using something like the following sequence of events:
	struct cred *new = prepare_creds();
	int ret = blah(new);
	if (ret < 0) {
		abort_creds(new);
		return ret;
	}
	return commit_creds(new);
There are some exceptions to this rule: the keyrings pointed to by the active
credentials may be instantiated - keyrings violate the COW rule as managing
COW keyrings is tricky, given that it is possible for a task to directly alter
the keys in a keyring in use by another task.
To help enforce this, various pointers to sets of credentials, such as those in
the task_struct, are declared const.  The purpose of this is compile-time
discouragement of altering credentials through those pointers.  Once a set of
credentials has been made public through one of these pointers, it may not be
modified, except under special circumstances:
  (1) Its reference count may incremented and decremented.
  (2) The keyrings to which it points may be modified, but not replaced.
The only safe way to modify anything else is to create a replacement and commit
using the functions described in Documentation/credentials.txt (which will be
added by a later patch).
This patch and the preceding patches have been tested with the LTP SELinux
testsuite.
This patch makes several logical sets of alteration:
 (1) execve().
     This now prepares and commits credentials in various places in the
     security code rather than altering the current creds directly.
 (2) Temporary credential overrides.
     do_coredump() and sys_faccessat() now prepare their own credentials and
     temporarily override the ones currently on the acting thread, whilst
     preventing interference from other threads by holding cred_replace_mutex
     on the thread being dumped.
     This will be replaced in a future patch by something that hands down the
     credentials directly to the functions being called, rather than altering
     the task's objective credentials.
 (3) LSM interface.
     A number of functions have been changed, added or removed:
     (*) security_capset_check(), ->capset_check()
     (*) security_capset_set(), ->capset_set()
     	 Removed in favour of security_capset().
     (*) security_capset(), ->capset()
     	 New.  This is passed a pointer to the new creds, a pointer to the old
     	 creds and the proposed capability sets.  It should fill in the new
     	 creds or return an error.  All pointers, barring the pointer to the
     	 new creds, are now const.
     (*) security_bprm_apply_creds(), ->bprm_apply_creds()
     	 Changed; now returns a value, which will cause the process to be
     	 killed if it's an error.
     (*) security_task_alloc(), ->task_alloc_security()
     	 Removed in favour of security_prepare_creds().
     (*) security_cred_free(), ->cred_free()
     	 New.  Free security data attached to cred->security.
     (*) security_prepare_creds(), ->cred_prepare()
     	 New. Duplicate any security data attached to cred->security.
     (*) security_commit_creds(), ->cred_commit()
     	 New. Apply any security effects for the upcoming installation of new
     	 security by commit_creds().
     (*) security_task_post_setuid(), ->task_post_setuid()
     	 Removed in favour of security_task_fix_setuid().
     (*) security_task_fix_setuid(), ->task_fix_setuid()
     	 Fix up the proposed new credentials for setuid().  This is used by
     	 cap_set_fix_setuid() to implicitly adjust capabilities in line with
     	 setuid() changes.  Changes are made to the new credentials, rather
     	 than the task itself as in security_task_post_setuid().
     (*) security_task_reparent_to_init(), ->task_reparent_to_init()
     	 Removed.  Instead the task being reparented to init is referred
     	 directly to init's credentials.
	 NOTE!  This results in the loss of some state: SELinux's osid no
	 longer records the sid of the thread that forked it.
     (*) security_key_alloc(), ->key_alloc()
     (*) security_key_permission(), ->key_permission()
     	 Changed.  These now take cred pointers rather than task pointers to
     	 refer to the security context.
 (4) sys_capset().
     This has been simplified and uses less locking.  The LSM functions it
     calls have been merged.
 (5) reparent_to_kthreadd().
     This gives the current thread the same credentials as init by simply using
     commit_thread() to point that way.
 (6) __sigqueue_alloc() and switch_uid()
     __sigqueue_alloc() can't stop the target task from changing its creds
     beneath it, so this function gets a reference to the currently applicable
     user_struct which it then passes into the sigqueue struct it returns if
     successful.
     switch_uid() is now called from commit_creds(), and possibly should be
     folded into that.  commit_creds() should take care of protecting
     __sigqueue_alloc().
 (7) [sg]et[ug]id() and co and [sg]et_current_groups.
     The set functions now all use prepare_creds(), commit_creds() and
     abort_creds() to build and check a new set of credentials before applying
     it.
     security_task_set[ug]id() is called inside the prepared section.  This
     guarantees that nothing else will affect the creds until we've finished.
     The calling of set_dumpable() has been moved into commit_creds().
     Much of the functionality of set_user() has been moved into
     commit_creds().
     The get functions all simply access the data directly.
 (8) security_task_prctl() and cap_task_prctl().
     security_task_prctl() has been modified to return -ENOSYS if it doesn't
     want to handle a function, or otherwise return the return value directly
     rather than through an argument.
     Additionally, cap_task_prctl() now prepares a new set of credentials, even
     if it doesn't end up using it.
 (9) Keyrings.
     A number of changes have been made to the keyrings code:
     (a) switch_uid_keyring(), copy_keys(), exit_keys() and suid_keys() have
     	 all been dropped and built in to the credentials functions directly.
     	 They may want separating out again later.
     (b) key_alloc() and search_process_keyrings() now take a cred pointer
     	 rather than a task pointer to specify the security context.
     (c) copy_creds() gives a new thread within the same thread group a new
     	 thread keyring if its parent had one, otherwise it discards the thread
     	 keyring.
     (d) The authorisation key now points directly to the credentials to extend
     	 the search into rather pointing to the task that carries them.
     (e) Installing thread, process or session keyrings causes a new set of
     	 credentials to be created, even though it's not strictly necessary for
     	 process or session keyrings (they're shared).
(10) Usermode helper.
     The usermode helper code now carries a cred struct pointer in its
     subprocess_info struct instead of a new session keyring pointer.  This set
     of credentials is derived from init_cred and installed on the new process
     after it has been cloned.
     call_usermodehelper_setup() allocates the new credentials and
     call_usermodehelper_freeinfo() discards them if they haven't been used.  A
     special cred function (prepare_usermodeinfo_creds()) is provided
     specifically for call_usermodehelper_setup() to call.
     call_usermodehelper_setkeys() adjusts the credentials to sport the
     supplied keyring as the new session keyring.
(11) SELinux.
     SELinux has a number of changes, in addition to those to support the LSM
     interface changes mentioned above:
     (a) selinux_setprocattr() no longer does its check for whether the
     	 current ptracer can access processes with the new SID inside the lock
     	 that covers getting the ptracer's SID.  Whilst this lock ensures that
     	 the check is done with the ptracer pinned, the result is only valid
     	 until the lock is released, so there's no point doing it inside the
     	 lock.
(12) is_single_threaded().
     This function has been extracted from selinux_setprocattr() and put into
     a file of its own in the lib/ directory as join_session_keyring() now
     wants to use it too.
     The code in SELinux just checked to see whether a task shared mm_structs
     with other tasks (CLONE_VM), but that isn't good enough.  We really want
     to know if they're part of the same thread group (CLONE_THREAD).
(13) nfsd.
     The NFS server daemon now has to use the COW credentials to set the
     credentials it is going to use.  It really needs to pass the credentials
     down to the functions it calls, but it can't do that until other patches
     in this series have been applied.
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: James Morris <jmorris@namei.org>
Signed-off-by: James Morris <jmorris@namei.org>
											
										 
											2008-11-14 10:39:23 +11:00
										 |  |  | 					  cred); | 
					
						
							| 
									
										
										
										
											2005-04-16 15:20:36 -07:00
										 |  |  | 
 | 
					
						
							| 
									
										
										
										
											2005-09-28 17:03:15 +01:00
										 |  |  | 	if (!IS_ERR(key_ref)) { | 
					
						
							|  |  |  | 		key = key_ref_to_ptr(key_ref); | 
					
						
							| 
									
										
											  
											
												keys: the request_key() syscall should link an existing key to the dest keyring
The request_key() system call and request_key_and_link() should make a
link from an existing key to the destination keyring (if supplied), not
just from a new key to the destination keyring.
This can be tested by:
	ring=`keyctl newring fred @s`
	keyctl request2 user debug:a a
	keyctl request user debug:a $ring
	keyctl list $ring
If it says:
	keyring is empty
then it didn't work.  If it shows something like:
	1 key in keyring:
	1070462727: --alswrv     0     0 user: debug:a
then it did.
request_key() system call is meant to recursively search all your keyrings for
the key you desire, and, optionally, if it doesn't exist, call out to userspace
to create one for you.
If request_key() finds or creates a key, it should, optionally, create a link
to that key from the destination keyring specified.
Therefore, if, after a successful call to request_key() with a desination
keyring specified, you see the destination keyring empty, the code didn't work
correctly.
If you see the found key in the keyring, then it did - which is what the patch
is required for.
Signed-off-by: David Howells <dhowells@redhat.com>
Cc: James Morris <jmorris@namei.org>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
											
										 
											2010-04-27 13:13:08 -07:00
										 |  |  | 		if (dest_keyring) { | 
					
						
							|  |  |  | 			construct_get_dest_keyring(&dest_keyring); | 
					
						
							|  |  |  | 			key_link(dest_keyring, key); | 
					
						
							|  |  |  | 			key_put(dest_keyring); | 
					
						
							|  |  |  | 		} | 
					
						
							| 
									
										
										
										
											2007-10-16 23:29:46 -07:00
										 |  |  | 	} else if (PTR_ERR(key_ref) != -EAGAIN) { | 
					
						
							| 
									
										
										
										
											2008-02-07 00:15:26 -08:00
										 |  |  | 		key = ERR_CAST(key_ref); | 
					
						
							| 
									
										
										
										
											2007-10-16 23:29:46 -07:00
										 |  |  | 	} else  { | 
					
						
							| 
									
										
										
										
											2005-04-16 15:20:36 -07:00
										 |  |  | 		/* the search failed, but the keyrings were searchable, so we
 | 
					
						
							|  |  |  | 		 * should consult userspace if we can */ | 
					
						
							|  |  |  | 		key = ERR_PTR(-ENOKEY); | 
					
						
							|  |  |  | 		if (!callout_info) | 
					
						
							|  |  |  | 			goto error; | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2007-10-16 23:29:46 -07:00
										 |  |  | 		key = construct_key_and_link(type, description, callout_info, | 
					
						
							| 
									
										
										
										
											2008-04-29 01:01:24 -07:00
										 |  |  | 					     callout_len, aux, dest_keyring, | 
					
						
							|  |  |  | 					     flags); | 
					
						
							| 
									
										
										
										
											2005-04-16 15:20:36 -07:00
										 |  |  | 	} | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
											  
											
												[PATCH] Keys: Make request-key create an authorisation key
The attached patch makes the following changes:
 (1) There's a new special key type called ".request_key_auth".
     This is an authorisation key for when one process requests a key and
     another process is started to construct it. This type of key cannot be
     created by the user; nor can it be requested by kernel services.
     Authorisation keys hold two references:
     (a) Each refers to a key being constructed. When the key being
     	 constructed is instantiated the authorisation key is revoked,
     	 rendering it of no further use.
     (b) The "authorising process". This is either:
     	 (i) the process that called request_key(), or:
     	 (ii) if the process that called request_key() itself had an
     	      authorisation key in its session keyring, then the authorising
     	      process referred to by that authorisation key will also be
     	      referred to by the new authorisation key.
	 This means that the process that initiated a chain of key requests
	 will authorise the lot of them, and will, by default, wind up with
	 the keys obtained from them in its keyrings.
 (2) request_key() creates an authorisation key which is then passed to
     /sbin/request-key in as part of a new session keyring.
 (3) When request_key() is searching for a key to hand back to the caller, if
     it comes across an authorisation key in the session keyring of the
     calling process, it will also search the keyrings of the process
     specified therein and it will use the specified process's credentials
     (fsuid, fsgid, groups) to do that rather than the calling process's
     credentials.
     This allows a process started by /sbin/request-key to find keys belonging
     to the authorising process.
 (4) A key can be read, even if the process executing KEYCTL_READ doesn't have
     direct read or search permission if that key is contained within the
     keyrings of a process specified by an authorisation key found within the
     calling process's session keyring, and is searchable using the
     credentials of the authorising process.
     This allows a process started by /sbin/request-key to read keys belonging
     to the authorising process.
 (5) The magic KEY_SPEC_*_KEYRING key IDs when passed to KEYCTL_INSTANTIATE or
     KEYCTL_NEGATE will specify a keyring of the authorising process, rather
     than the process doing the instantiation.
 (6) One of the process keyrings can be nominated as the default to which
     request_key() should attach new keys if not otherwise specified. This is
     done with KEYCTL_SET_REQKEY_KEYRING and one of the KEY_REQKEY_DEFL_*
     constants. The current setting can also be read using this call.
 (7) request_key() is partially interruptible. If it is waiting for another
     process to finish constructing a key, it can be interrupted. This permits
     a request-key cycle to be broken without recourse to rebooting.
Signed-Off-By: David Howells <dhowells@redhat.com>
Signed-Off-By: Benoit Boissinot <benoit.boissinot@ens-lyon.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
											
										 
											2005-06-23 22:00:56 -07:00
										 |  |  | error: | 
					
						
							|  |  |  | 	kleave(" = %p", key); | 
					
						
							| 
									
										
										
										
											2005-04-16 15:20:36 -07:00
										 |  |  | 	return key; | 
					
						
							| 
									
										
										
										
											2007-10-16 23:29:46 -07:00
										 |  |  | } | 
					
						
							| 
									
										
										
										
											2005-04-16 15:20:36 -07:00
										 |  |  | 
 | 
					
						
							| 
									
										
										
										
											2007-10-16 23:29:46 -07:00
										 |  |  | /*
 | 
					
						
							|  |  |  |  * wait for construction of a key to complete | 
					
						
							|  |  |  |  */ | 
					
						
							|  |  |  | int wait_for_key_construction(struct key *key, bool intr) | 
					
						
							|  |  |  | { | 
					
						
							|  |  |  | 	int ret; | 
					
						
							| 
									
										
											  
											
												[PATCH] Keys: Make request-key create an authorisation key
The attached patch makes the following changes:
 (1) There's a new special key type called ".request_key_auth".
     This is an authorisation key for when one process requests a key and
     another process is started to construct it. This type of key cannot be
     created by the user; nor can it be requested by kernel services.
     Authorisation keys hold two references:
     (a) Each refers to a key being constructed. When the key being
     	 constructed is instantiated the authorisation key is revoked,
     	 rendering it of no further use.
     (b) The "authorising process". This is either:
     	 (i) the process that called request_key(), or:
     	 (ii) if the process that called request_key() itself had an
     	      authorisation key in its session keyring, then the authorising
     	      process referred to by that authorisation key will also be
     	      referred to by the new authorisation key.
	 This means that the process that initiated a chain of key requests
	 will authorise the lot of them, and will, by default, wind up with
	 the keys obtained from them in its keyrings.
 (2) request_key() creates an authorisation key which is then passed to
     /sbin/request-key in as part of a new session keyring.
 (3) When request_key() is searching for a key to hand back to the caller, if
     it comes across an authorisation key in the session keyring of the
     calling process, it will also search the keyrings of the process
     specified therein and it will use the specified process's credentials
     (fsuid, fsgid, groups) to do that rather than the calling process's
     credentials.
     This allows a process started by /sbin/request-key to find keys belonging
     to the authorising process.
 (4) A key can be read, even if the process executing KEYCTL_READ doesn't have
     direct read or search permission if that key is contained within the
     keyrings of a process specified by an authorisation key found within the
     calling process's session keyring, and is searchable using the
     credentials of the authorising process.
     This allows a process started by /sbin/request-key to read keys belonging
     to the authorising process.
 (5) The magic KEY_SPEC_*_KEYRING key IDs when passed to KEYCTL_INSTANTIATE or
     KEYCTL_NEGATE will specify a keyring of the authorising process, rather
     than the process doing the instantiation.
 (6) One of the process keyrings can be nominated as the default to which
     request_key() should attach new keys if not otherwise specified. This is
     done with KEYCTL_SET_REQKEY_KEYRING and one of the KEY_REQKEY_DEFL_*
     constants. The current setting can also be read using this call.
 (7) request_key() is partially interruptible. If it is waiting for another
     process to finish constructing a key, it can be interrupted. This permits
     a request-key cycle to be broken without recourse to rebooting.
Signed-Off-By: David Howells <dhowells@redhat.com>
Signed-Off-By: Benoit Boissinot <benoit.boissinot@ens-lyon.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
											
										 
											2005-06-23 22:00:56 -07:00
										 |  |  | 
 | 
					
						
							| 
									
										
										
										
											2007-10-16 23:29:46 -07:00
										 |  |  | 	ret = wait_on_bit(&key->flags, KEY_FLAG_USER_CONSTRUCT, | 
					
						
							|  |  |  | 			  intr ? key_wait_bit_intr : key_wait_bit, | 
					
						
							|  |  |  | 			  intr ? TASK_INTERRUPTIBLE : TASK_UNINTERRUPTIBLE); | 
					
						
							|  |  |  | 	if (ret < 0) | 
					
						
							|  |  |  | 		return ret; | 
					
						
							|  |  |  | 	return key_validate(key); | 
					
						
							|  |  |  | } | 
					
						
							|  |  |  | EXPORT_SYMBOL(wait_for_key_construction); | 
					
						
							| 
									
										
											  
											
												[PATCH] Keys: Make request-key create an authorisation key
The attached patch makes the following changes:
 (1) There's a new special key type called ".request_key_auth".
     This is an authorisation key for when one process requests a key and
     another process is started to construct it. This type of key cannot be
     created by the user; nor can it be requested by kernel services.
     Authorisation keys hold two references:
     (a) Each refers to a key being constructed. When the key being
     	 constructed is instantiated the authorisation key is revoked,
     	 rendering it of no further use.
     (b) The "authorising process". This is either:
     	 (i) the process that called request_key(), or:
     	 (ii) if the process that called request_key() itself had an
     	      authorisation key in its session keyring, then the authorising
     	      process referred to by that authorisation key will also be
     	      referred to by the new authorisation key.
	 This means that the process that initiated a chain of key requests
	 will authorise the lot of them, and will, by default, wind up with
	 the keys obtained from them in its keyrings.
 (2) request_key() creates an authorisation key which is then passed to
     /sbin/request-key in as part of a new session keyring.
 (3) When request_key() is searching for a key to hand back to the caller, if
     it comes across an authorisation key in the session keyring of the
     calling process, it will also search the keyrings of the process
     specified therein and it will use the specified process's credentials
     (fsuid, fsgid, groups) to do that rather than the calling process's
     credentials.
     This allows a process started by /sbin/request-key to find keys belonging
     to the authorising process.
 (4) A key can be read, even if the process executing KEYCTL_READ doesn't have
     direct read or search permission if that key is contained within the
     keyrings of a process specified by an authorisation key found within the
     calling process's session keyring, and is searchable using the
     credentials of the authorising process.
     This allows a process started by /sbin/request-key to read keys belonging
     to the authorising process.
 (5) The magic KEY_SPEC_*_KEYRING key IDs when passed to KEYCTL_INSTANTIATE or
     KEYCTL_NEGATE will specify a keyring of the authorising process, rather
     than the process doing the instantiation.
 (6) One of the process keyrings can be nominated as the default to which
     request_key() should attach new keys if not otherwise specified. This is
     done with KEYCTL_SET_REQKEY_KEYRING and one of the KEY_REQKEY_DEFL_*
     constants. The current setting can also be read using this call.
 (7) request_key() is partially interruptible. If it is waiting for another
     process to finish constructing a key, it can be interrupted. This permits
     a request-key cycle to be broken without recourse to rebooting.
Signed-Off-By: David Howells <dhowells@redhat.com>
Signed-Off-By: Benoit Boissinot <benoit.boissinot@ens-lyon.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
											
										 
											2005-06-23 22:00:56 -07:00
										 |  |  | 
 | 
					
						
							|  |  |  | /*
 | 
					
						
							|  |  |  |  * request a key | 
					
						
							|  |  |  |  * - search the process's keyrings | 
					
						
							|  |  |  |  * - check the list of keys being created or updated | 
					
						
							|  |  |  |  * - call out to userspace for a key if supplementary info was provided | 
					
						
							| 
									
										
										
										
											2007-10-16 23:29:46 -07:00
										 |  |  |  * - waits uninterruptible for creation to complete | 
					
						
							| 
									
										
											  
											
												[PATCH] Keys: Make request-key create an authorisation key
The attached patch makes the following changes:
 (1) There's a new special key type called ".request_key_auth".
     This is an authorisation key for when one process requests a key and
     another process is started to construct it. This type of key cannot be
     created by the user; nor can it be requested by kernel services.
     Authorisation keys hold two references:
     (a) Each refers to a key being constructed. When the key being
     	 constructed is instantiated the authorisation key is revoked,
     	 rendering it of no further use.
     (b) The "authorising process". This is either:
     	 (i) the process that called request_key(), or:
     	 (ii) if the process that called request_key() itself had an
     	      authorisation key in its session keyring, then the authorising
     	      process referred to by that authorisation key will also be
     	      referred to by the new authorisation key.
	 This means that the process that initiated a chain of key requests
	 will authorise the lot of them, and will, by default, wind up with
	 the keys obtained from them in its keyrings.
 (2) request_key() creates an authorisation key which is then passed to
     /sbin/request-key in as part of a new session keyring.
 (3) When request_key() is searching for a key to hand back to the caller, if
     it comes across an authorisation key in the session keyring of the
     calling process, it will also search the keyrings of the process
     specified therein and it will use the specified process's credentials
     (fsuid, fsgid, groups) to do that rather than the calling process's
     credentials.
     This allows a process started by /sbin/request-key to find keys belonging
     to the authorising process.
 (4) A key can be read, even if the process executing KEYCTL_READ doesn't have
     direct read or search permission if that key is contained within the
     keyrings of a process specified by an authorisation key found within the
     calling process's session keyring, and is searchable using the
     credentials of the authorising process.
     This allows a process started by /sbin/request-key to read keys belonging
     to the authorising process.
 (5) The magic KEY_SPEC_*_KEYRING key IDs when passed to KEYCTL_INSTANTIATE or
     KEYCTL_NEGATE will specify a keyring of the authorising process, rather
     than the process doing the instantiation.
 (6) One of the process keyrings can be nominated as the default to which
     request_key() should attach new keys if not otherwise specified. This is
     done with KEYCTL_SET_REQKEY_KEYRING and one of the KEY_REQKEY_DEFL_*
     constants. The current setting can also be read using this call.
 (7) request_key() is partially interruptible. If it is waiting for another
     process to finish constructing a key, it can be interrupted. This permits
     a request-key cycle to be broken without recourse to rebooting.
Signed-Off-By: David Howells <dhowells@redhat.com>
Signed-Off-By: Benoit Boissinot <benoit.boissinot@ens-lyon.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
											
										 
											2005-06-23 22:00:56 -07:00
										 |  |  |  */ | 
					
						
							|  |  |  | struct key *request_key(struct key_type *type, | 
					
						
							|  |  |  | 			const char *description, | 
					
						
							|  |  |  | 			const char *callout_info) | 
					
						
							|  |  |  | { | 
					
						
							| 
									
										
										
										
											2007-10-16 23:29:46 -07:00
										 |  |  | 	struct key *key; | 
					
						
							| 
									
										
										
										
											2008-04-29 01:01:24 -07:00
										 |  |  | 	size_t callout_len = 0; | 
					
						
							| 
									
										
										
										
											2007-10-16 23:29:46 -07:00
										 |  |  | 	int ret; | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2008-04-29 01:01:24 -07:00
										 |  |  | 	if (callout_info) | 
					
						
							|  |  |  | 		callout_len = strlen(callout_info); | 
					
						
							|  |  |  | 	key = request_key_and_link(type, description, callout_info, callout_len, | 
					
						
							|  |  |  | 				   NULL, NULL, KEY_ALLOC_IN_QUOTA); | 
					
						
							| 
									
										
										
										
											2007-10-16 23:29:46 -07:00
										 |  |  | 	if (!IS_ERR(key)) { | 
					
						
							|  |  |  | 		ret = wait_for_key_construction(key, false); | 
					
						
							|  |  |  | 		if (ret < 0) { | 
					
						
							|  |  |  | 			key_put(key); | 
					
						
							|  |  |  | 			return ERR_PTR(ret); | 
					
						
							|  |  |  | 		} | 
					
						
							|  |  |  | 	} | 
					
						
							|  |  |  | 	return key; | 
					
						
							|  |  |  | } | 
					
						
							| 
									
										
										
										
											2005-04-16 15:20:36 -07:00
										 |  |  | EXPORT_SYMBOL(request_key); | 
					
						
							| 
									
										
										
										
											2006-06-29 02:24:28 -07:00
										 |  |  | 
 | 
					
						
							|  |  |  | /*
 | 
					
						
							|  |  |  |  * request a key with auxiliary data for the upcaller | 
					
						
							|  |  |  |  * - search the process's keyrings | 
					
						
							|  |  |  |  * - check the list of keys being created or updated | 
					
						
							|  |  |  |  * - call out to userspace for a key if supplementary info was provided | 
					
						
							| 
									
										
										
										
											2007-10-16 23:29:46 -07:00
										 |  |  |  * - waits uninterruptible for creation to complete | 
					
						
							| 
									
										
										
										
											2006-06-29 02:24:28 -07:00
										 |  |  |  */ | 
					
						
							|  |  |  | struct key *request_key_with_auxdata(struct key_type *type, | 
					
						
							|  |  |  | 				     const char *description, | 
					
						
							| 
									
										
										
										
											2008-04-29 01:01:24 -07:00
										 |  |  | 				     const void *callout_info, | 
					
						
							|  |  |  | 				     size_t callout_len, | 
					
						
							| 
									
										
										
										
											2006-06-29 02:24:28 -07:00
										 |  |  | 				     void *aux) | 
					
						
							|  |  |  | { | 
					
						
							| 
									
										
										
										
											2007-10-16 23:29:46 -07:00
										 |  |  | 	struct key *key; | 
					
						
							|  |  |  | 	int ret; | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2008-04-29 01:01:24 -07:00
										 |  |  | 	key = request_key_and_link(type, description, callout_info, callout_len, | 
					
						
							|  |  |  | 				   aux, NULL, KEY_ALLOC_IN_QUOTA); | 
					
						
							| 
									
										
										
										
											2007-10-16 23:29:46 -07:00
										 |  |  | 	if (!IS_ERR(key)) { | 
					
						
							|  |  |  | 		ret = wait_for_key_construction(key, false); | 
					
						
							|  |  |  | 		if (ret < 0) { | 
					
						
							|  |  |  | 			key_put(key); | 
					
						
							|  |  |  | 			return ERR_PTR(ret); | 
					
						
							|  |  |  | 		} | 
					
						
							|  |  |  | 	} | 
					
						
							|  |  |  | 	return key; | 
					
						
							|  |  |  | } | 
					
						
							|  |  |  | EXPORT_SYMBOL(request_key_with_auxdata); | 
					
						
							| 
									
										
										
										
											2006-06-29 02:24:28 -07:00
										 |  |  | 
 | 
					
						
							| 
									
										
										
										
											2007-10-16 23:29:46 -07:00
										 |  |  | /*
 | 
					
						
							|  |  |  |  * request a key (allow async construction) | 
					
						
							|  |  |  |  * - search the process's keyrings | 
					
						
							|  |  |  |  * - check the list of keys being created or updated | 
					
						
							|  |  |  |  * - call out to userspace for a key if supplementary info was provided | 
					
						
							|  |  |  |  */ | 
					
						
							|  |  |  | struct key *request_key_async(struct key_type *type, | 
					
						
							|  |  |  | 			      const char *description, | 
					
						
							| 
									
										
										
										
											2008-04-29 01:01:24 -07:00
										 |  |  | 			      const void *callout_info, | 
					
						
							|  |  |  | 			      size_t callout_len) | 
					
						
							| 
									
										
										
										
											2007-10-16 23:29:46 -07:00
										 |  |  | { | 
					
						
							| 
									
										
										
										
											2008-04-29 01:01:24 -07:00
										 |  |  | 	return request_key_and_link(type, description, callout_info, | 
					
						
							|  |  |  | 				    callout_len, NULL, NULL, | 
					
						
							|  |  |  | 				    KEY_ALLOC_IN_QUOTA); | 
					
						
							| 
									
										
										
										
											2007-10-16 23:29:46 -07:00
										 |  |  | } | 
					
						
							|  |  |  | EXPORT_SYMBOL(request_key_async); | 
					
						
							| 
									
										
										
										
											2006-06-29 02:24:28 -07:00
										 |  |  | 
 | 
					
						
							| 
									
										
										
										
											2007-10-16 23:29:46 -07:00
										 |  |  | /*
 | 
					
						
							|  |  |  |  * request a key with auxiliary data for the upcaller (allow async construction) | 
					
						
							|  |  |  |  * - search the process's keyrings | 
					
						
							|  |  |  |  * - check the list of keys being created or updated | 
					
						
							|  |  |  |  * - call out to userspace for a key if supplementary info was provided | 
					
						
							|  |  |  |  */ | 
					
						
							|  |  |  | struct key *request_key_async_with_auxdata(struct key_type *type, | 
					
						
							|  |  |  | 					   const char *description, | 
					
						
							| 
									
										
										
										
											2008-04-29 01:01:24 -07:00
										 |  |  | 					   const void *callout_info, | 
					
						
							|  |  |  | 					   size_t callout_len, | 
					
						
							| 
									
										
										
										
											2007-10-16 23:29:46 -07:00
										 |  |  | 					   void *aux) | 
					
						
							|  |  |  | { | 
					
						
							| 
									
										
										
										
											2008-04-29 01:01:24 -07:00
										 |  |  | 	return request_key_and_link(type, description, callout_info, | 
					
						
							|  |  |  | 				    callout_len, aux, NULL, KEY_ALLOC_IN_QUOTA); | 
					
						
							| 
									
										
										
										
											2007-10-16 23:29:46 -07:00
										 |  |  | } | 
					
						
							|  |  |  | EXPORT_SYMBOL(request_key_async_with_auxdata); |