| 
									
										
											  
											
												[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_key_auth.c: request key authorisation controlling key def
 | 
					
						
							|  |  |  |  * | 
					
						
							|  |  |  |  * Copyright (C) 2005 Red Hat, Inc. All Rights Reserved. | 
					
						
							|  |  |  |  * 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 | 
					
						
							| 
									
										
											  
											
												[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/module.h>
 | 
					
						
							|  |  |  | #include <linux/sched.h>
 | 
					
						
							|  |  |  | #include <linux/err.h>
 | 
					
						
							|  |  |  | #include <linux/seq_file.h>
 | 
					
						
							| 
									
										
										
										
											2008-04-29 01:01:32 -07:00
										 |  |  | #include <linux/slab.h>
 | 
					
						
							| 
									
										
										
										
											2006-01-08 01:02:47 -08:00
										 |  |  | #include <asm/uaccess.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 "internal.h"
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | static int request_key_auth_instantiate(struct key *, const void *, size_t); | 
					
						
							|  |  |  | static void request_key_auth_describe(const struct key *, struct seq_file *); | 
					
						
							| 
									
										
										
										
											2006-06-22 14:47:18 -07:00
										 |  |  | static void request_key_auth_revoke(struct key *); | 
					
						
							| 
									
										
											  
											
												[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
										 |  |  | static void request_key_auth_destroy(struct key *); | 
					
						
							| 
									
										
										
										
											2006-01-08 01:02:47 -08:00
										 |  |  | static long request_key_auth_read(const struct key *, char __user *, size_t); | 
					
						
							| 
									
										
											  
											
												[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
										 |  |  | 
 | 
					
						
							|  |  |  | /*
 | 
					
						
							|  |  |  |  * the request-key authorisation key type definition | 
					
						
							|  |  |  |  */ | 
					
						
							|  |  |  | struct key_type key_type_request_key_auth = { | 
					
						
							|  |  |  | 	.name		= ".request_key_auth", | 
					
						
							|  |  |  | 	.def_datalen	= sizeof(struct request_key_auth), | 
					
						
							|  |  |  | 	.instantiate	= request_key_auth_instantiate, | 
					
						
							|  |  |  | 	.describe	= request_key_auth_describe, | 
					
						
							| 
									
										
										
										
											2006-06-22 14:47:18 -07:00
										 |  |  | 	.revoke		= request_key_auth_revoke, | 
					
						
							| 
									
										
											  
											
												[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
										 |  |  | 	.destroy	= request_key_auth_destroy, | 
					
						
							| 
									
										
										
										
											2006-01-08 01:02:47 -08:00
										 |  |  | 	.read		= request_key_auth_read, | 
					
						
							| 
									
										
											  
											
												[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
										 |  |  |  * instantiate a request-key authorisation key | 
					
						
							| 
									
										
											  
											
												[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
										 |  |  |  */ | 
					
						
							|  |  |  | static int request_key_auth_instantiate(struct key *key, | 
					
						
							|  |  |  | 					const void *data, | 
					
						
							|  |  |  | 					size_t datalen) | 
					
						
							|  |  |  | { | 
					
						
							| 
									
										
										
										
											2006-01-08 01:02:47 -08:00
										 |  |  | 	key->payload.data = (struct request_key_auth *) data; | 
					
						
							|  |  |  | 	return 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
										 |  |  | 
 | 
					
						
							|  |  |  | } /* end request_key_auth_instantiate() */ | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | /*****************************************************************************/ | 
					
						
							|  |  |  | /*
 | 
					
						
							| 
									
										
										
										
											2006-01-08 01:02:47 -08:00
										 |  |  |  * reading a request-key authorisation key retrieves the callout information | 
					
						
							| 
									
										
											  
											
												[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
										 |  |  |  */ | 
					
						
							|  |  |  | static void request_key_auth_describe(const struct key *key, | 
					
						
							|  |  |  | 				      struct seq_file *m) | 
					
						
							|  |  |  | { | 
					
						
							|  |  |  | 	struct request_key_auth *rka = key->payload.data; | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | 	seq_puts(m, "key:"); | 
					
						
							|  |  |  | 	seq_puts(m, key->description); | 
					
						
							| 
									
										
										
										
											2008-04-29 01:01:24 -07:00
										 |  |  | 	seq_printf(m, " pid:%d ci:%zu", rka->pid, rka->callout_len); | 
					
						
							| 
									
										
											  
											
												[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
										 |  |  | 
 | 
					
						
							|  |  |  | } /* end request_key_auth_describe() */ | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2006-01-08 01:02:47 -08:00
										 |  |  | /*****************************************************************************/ | 
					
						
							|  |  |  | /*
 | 
					
						
							|  |  |  |  * read the callout_info data | 
					
						
							|  |  |  |  * - the key's semaphore is read-locked | 
					
						
							|  |  |  |  */ | 
					
						
							|  |  |  | static long request_key_auth_read(const struct key *key, | 
					
						
							|  |  |  | 				  char __user *buffer, size_t buflen) | 
					
						
							|  |  |  | { | 
					
						
							|  |  |  | 	struct request_key_auth *rka = key->payload.data; | 
					
						
							|  |  |  | 	size_t datalen; | 
					
						
							|  |  |  | 	long ret; | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2008-04-29 01:01:24 -07:00
										 |  |  | 	datalen = rka->callout_len; | 
					
						
							| 
									
										
										
										
											2006-01-08 01:02:47 -08:00
										 |  |  | 	ret = datalen; | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | 	/* we can return the data as is */ | 
					
						
							|  |  |  | 	if (buffer && buflen > 0) { | 
					
						
							|  |  |  | 		if (buflen > datalen) | 
					
						
							|  |  |  | 			buflen = datalen; | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | 		if (copy_to_user(buffer, rka->callout_info, buflen) != 0) | 
					
						
							|  |  |  | 			ret = -EFAULT; | 
					
						
							|  |  |  | 	} | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | 	return ret; | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | } /* end request_key_auth_read() */ | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2006-06-22 14:47:18 -07:00
										 |  |  | /*****************************************************************************/ | 
					
						
							|  |  |  | /*
 | 
					
						
							|  |  |  |  * handle revocation of an authorisation token key | 
					
						
							|  |  |  |  * - called with the key sem write-locked | 
					
						
							|  |  |  |  */ | 
					
						
							|  |  |  | static void request_key_auth_revoke(struct key *key) | 
					
						
							|  |  |  | { | 
					
						
							|  |  |  | 	struct request_key_auth *rka = key->payload.data; | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | 	kenter("{%d}", 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
										 |  |  | 	if (rka->cred) { | 
					
						
							|  |  |  | 		put_cred(rka->cred); | 
					
						
							|  |  |  | 		rka->cred = NULL; | 
					
						
							| 
									
										
										
										
											2006-06-22 14:47:18 -07:00
										 |  |  | 	} | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | } /* end request_key_auth_revoke() */ | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
											  
											
												[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
										 |  |  | /*****************************************************************************/ | 
					
						
							|  |  |  | /*
 | 
					
						
							|  |  |  |  * destroy an instantiation authorisation token key | 
					
						
							|  |  |  |  */ | 
					
						
							|  |  |  | static void request_key_auth_destroy(struct key *key) | 
					
						
							|  |  |  | { | 
					
						
							|  |  |  | 	struct request_key_auth *rka = key->payload.data; | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | 	kenter("{%d}", 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
										 |  |  | 	if (rka->cred) { | 
					
						
							|  |  |  | 		put_cred(rka->cred); | 
					
						
							|  |  |  | 		rka->cred = NULL; | 
					
						
							| 
									
										
										
										
											2006-06-22 14:47:18 -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
										 |  |  | 	key_put(rka->target_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(rka->dest_keyring); | 
					
						
							| 
									
										
										
										
											2007-10-16 23:29:46 -07:00
										 |  |  | 	kfree(rka->callout_info); | 
					
						
							| 
									
										
										
										
											2005-10-07 15:01:09 +01:00
										 |  |  | 	kfree(rka); | 
					
						
							| 
									
										
											  
											
												[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
										 |  |  | 
 | 
					
						
							|  |  |  | } /* end request_key_auth_destroy() */ | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | /*****************************************************************************/ | 
					
						
							|  |  |  | /*
 | 
					
						
							| 
									
										
										
										
											2006-01-08 01:02:47 -08:00
										 |  |  |  * create an authorisation token for /sbin/request-key or whoever to gain | 
					
						
							|  |  |  |  * access to the caller's security data | 
					
						
							| 
									
										
											  
											
												[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
										 |  |  |  */ | 
					
						
							| 
									
										
										
										
											2008-04-29 01:01:24 -07:00
										 |  |  | struct key *request_key_auth_new(struct key *target, 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, 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
										 |  |  | { | 
					
						
							| 
									
										
										
										
											2006-01-08 01:02:47 -08:00
										 |  |  | 	struct request_key_auth *rka, *irka; | 
					
						
							| 
									
										
											  
											
												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; | 
					
						
							| 
									
										
										
										
											2006-01-08 01:02:47 -08:00
										 |  |  | 	struct key *authkey = NULL; | 
					
						
							| 
									
										
											  
											
												[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
										 |  |  | 	char desc[20]; | 
					
						
							|  |  |  | 	int ret; | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | 	kenter("%d,", target->serial); | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2006-01-08 01:02:47 -08:00
										 |  |  | 	/* allocate a auth record */ | 
					
						
							|  |  |  | 	rka = kmalloc(sizeof(*rka), GFP_KERNEL); | 
					
						
							|  |  |  | 	if (!rka) { | 
					
						
							|  |  |  | 		kleave(" = -ENOMEM"); | 
					
						
							|  |  |  | 		return ERR_PTR(-ENOMEM); | 
					
						
							|  |  |  | 	} | 
					
						
							| 
									
										
										
										
											2008-04-29 01:01:24 -07:00
										 |  |  | 	rka->callout_info = kmalloc(callout_len, GFP_KERNEL); | 
					
						
							| 
									
										
										
										
											2007-10-16 23:29:46 -07:00
										 |  |  | 	if (!rka->callout_info) { | 
					
						
							|  |  |  | 		kleave(" = -ENOMEM"); | 
					
						
							|  |  |  | 		kfree(rka); | 
					
						
							|  |  |  | 		return ERR_PTR(-ENOMEM); | 
					
						
							|  |  |  | 	} | 
					
						
							| 
									
										
											  
											
												[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
										 |  |  | 	/* see if the calling process is already servicing the key request of
 | 
					
						
							|  |  |  | 	 * another process */ | 
					
						
							| 
									
										
											  
											
												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 (cred->request_key_auth) { | 
					
						
							| 
									
										
										
										
											2006-01-08 01:02:47 -08:00
										 |  |  | 		/* it is - use that instantiation context here too */ | 
					
						
							| 
									
										
											  
											
												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
										 |  |  | 		down_read(&cred->request_key_auth->sem); | 
					
						
							| 
									
										
										
										
											2006-06-22 14:47:18 -07:00
										 |  |  | 
 | 
					
						
							|  |  |  | 		/* if the auth key has been revoked, then the key we're
 | 
					
						
							|  |  |  | 		 * servicing is already instantiated */ | 
					
						
							| 
									
										
											  
											
												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 (test_bit(KEY_FLAG_REVOKED, &cred->request_key_auth->flags)) | 
					
						
							| 
									
										
										
										
											2006-06-22 14:47:18 -07:00
										 |  |  | 			goto auth_key_revoked; | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
											  
											
												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
										 |  |  | 		irka = cred->request_key_auth->payload.data; | 
					
						
							|  |  |  | 		rka->cred = get_cred(irka->cred); | 
					
						
							| 
									
										
										
										
											2006-01-08 01:02:47 -08:00
										 |  |  | 		rka->pid = irka->pid; | 
					
						
							| 
									
										
										
										
											2006-06-22 14:47:18 -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
										 |  |  | 		up_read(&cred->request_key_auth->sem); | 
					
						
							| 
									
										
											  
											
												[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
										 |  |  | 	else { | 
					
						
							|  |  |  | 		/* it isn't - use this process as the context */ | 
					
						
							| 
									
										
											  
											
												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
										 |  |  | 		rka->cred = get_cred(cred); | 
					
						
							| 
									
										
										
										
											2006-01-08 01:02:47 -08:00
										 |  |  | 		rka->pid = current->pid; | 
					
						
							|  |  |  | 	} | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | 	rka->target_key = key_get(target); | 
					
						
							| 
									
										
											  
											
												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
										 |  |  | 	rka->dest_keyring = key_get(dest_keyring); | 
					
						
							| 
									
										
										
										
											2008-04-29 01:01:24 -07:00
										 |  |  | 	memcpy(rka->callout_info, callout_info, callout_len); | 
					
						
							|  |  |  | 	rka->callout_len = callout_len; | 
					
						
							| 
									
										
											  
											
												[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
										 |  |  | 
 | 
					
						
							|  |  |  | 	/* allocate the auth key */ | 
					
						
							|  |  |  | 	sprintf(desc, "%x", target->serial); | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2006-01-08 01:02:47 -08:00
										 |  |  | 	authkey = key_alloc(&key_type_request_key_auth, desc, | 
					
						
							| 
									
										
											  
											
												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->fsuid, cred->fsgid, cred, | 
					
						
							| 
									
										
										
										
											2006-01-08 01:02:47 -08:00
										 |  |  | 			    KEY_POS_VIEW | KEY_POS_READ | KEY_POS_SEARCH | | 
					
						
							| 
									
										
										
										
											2006-06-26 00:24:50 -07:00
										 |  |  | 			    KEY_USR_VIEW, KEY_ALLOC_NOT_IN_QUOTA); | 
					
						
							| 
									
										
										
										
											2006-01-08 01:02:47 -08:00
										 |  |  | 	if (IS_ERR(authkey)) { | 
					
						
							|  |  |  | 		ret = PTR_ERR(authkey); | 
					
						
							|  |  |  | 		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
										 |  |  | 	} | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
											  
											
												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
										 |  |  | 	/* construct the auth key */ | 
					
						
							| 
									
										
										
										
											2006-01-08 01:02:47 -08:00
										 |  |  | 	ret = key_instantiate_and_link(authkey, rka, 0, NULL, NULL); | 
					
						
							|  |  |  | 	if (ret < 0) | 
					
						
							|  |  |  | 		goto error_inst; | 
					
						
							| 
									
										
											  
											
												[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
										 |  |  | 
 | 
					
						
							| 
									
										
											  
											
												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,%d}", authkey->serial, atomic_read(&authkey->usage)); | 
					
						
							| 
									
										
										
										
											2006-01-08 01:02:47 -08:00
										 |  |  | 	return authkey; | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2006-06-22 14:47:18 -07:00
										 |  |  | auth_key_revoked: | 
					
						
							| 
									
										
											  
											
												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
										 |  |  | 	up_read(&cred->request_key_auth->sem); | 
					
						
							| 
									
										
										
										
											2007-10-16 23:29:46 -07:00
										 |  |  | 	kfree(rka->callout_info); | 
					
						
							| 
									
										
										
										
											2006-06-22 14:47:18 -07:00
										 |  |  | 	kfree(rka); | 
					
						
							|  |  |  | 	kleave("= -EKEYREVOKED"); | 
					
						
							|  |  |  | 	return ERR_PTR(-EKEYREVOKED); | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2006-01-08 01:02:47 -08:00
										 |  |  | error_inst: | 
					
						
							|  |  |  | 	key_revoke(authkey); | 
					
						
							|  |  |  | 	key_put(authkey); | 
					
						
							|  |  |  | error_alloc: | 
					
						
							|  |  |  | 	key_put(rka->target_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(rka->dest_keyring); | 
					
						
							| 
									
										
										
										
											2007-10-16 23:29:46 -07:00
										 |  |  | 	kfree(rka->callout_info); | 
					
						
							| 
									
										
										
										
											2006-01-08 01:02:47 -08:00
										 |  |  | 	kfree(rka); | 
					
						
							|  |  |  | 	kleave("= %d", ret); | 
					
						
							|  |  |  | 	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
										 |  |  | 
 | 
					
						
							|  |  |  | } /* end request_key_auth_new() */ | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2006-01-08 01:02:47 -08:00
										 |  |  | /*****************************************************************************/ | 
					
						
							|  |  |  | /*
 | 
					
						
							|  |  |  |  * see if an authorisation key is associated with a particular key | 
					
						
							|  |  |  |  */ | 
					
						
							|  |  |  | static int key_get_instantiation_authkey_match(const struct key *key, | 
					
						
							|  |  |  | 					       const void *_id) | 
					
						
							|  |  |  | { | 
					
						
							|  |  |  | 	struct request_key_auth *rka = key->payload.data; | 
					
						
							|  |  |  | 	key_serial_t id = (key_serial_t)(unsigned long) _id; | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | 	return rka->target_key->serial == id; | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | } /* end key_get_instantiation_authkey_match() */ | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
											  
											
												[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
										 |  |  | /*****************************************************************************/ | 
					
						
							|  |  |  | /*
 | 
					
						
							|  |  |  |  * get the authorisation key for instantiation of a specific key if attached to | 
					
						
							|  |  |  |  * the current process's keyrings | 
					
						
							|  |  |  |  * - this key is inserted into a keyring and that is set as /sbin/request-key's | 
					
						
							|  |  |  |  *   session keyring | 
					
						
							|  |  |  |  * - a target_id of zero specifies any valid token | 
					
						
							|  |  |  |  */ | 
					
						
							|  |  |  | struct key *key_get_instantiation_authkey(key_serial_t target_id) | 
					
						
							|  |  |  | { | 
					
						
							| 
									
										
											  
											
												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(); | 
					
						
							| 
									
										
										
										
											2006-01-08 01:02:47 -08:00
										 |  |  | 	struct key *authkey; | 
					
						
							|  |  |  | 	key_ref_t authkey_ref; | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | 	authkey_ref = search_process_keyrings( | 
					
						
							|  |  |  | 		&key_type_request_key_auth, | 
					
						
							|  |  |  | 		(void *) (unsigned long) target_id, | 
					
						
							|  |  |  | 		key_get_instantiation_authkey_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); | 
					
						
							| 
									
										
										
										
											2006-01-08 01:02:47 -08:00
										 |  |  | 
 | 
					
						
							|  |  |  | 	if (IS_ERR(authkey_ref)) { | 
					
						
							| 
									
										
										
										
											2008-02-07 00:15:26 -08:00
										 |  |  | 		authkey = ERR_CAST(authkey_ref); | 
					
						
							| 
									
										
										
										
											2006-01-08 01:02:47 -08:00
										 |  |  | 		goto error; | 
					
						
							|  |  |  | 	} | 
					
						
							| 
									
										
											  
											
												[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
										 |  |  | 	authkey = key_ref_to_ptr(authkey_ref); | 
					
						
							|  |  |  | 	if (test_bit(KEY_FLAG_REVOKED, &authkey->flags)) { | 
					
						
							|  |  |  | 		key_put(authkey); | 
					
						
							|  |  |  | 		authkey = ERR_PTR(-EKEYREVOKED); | 
					
						
							|  |  |  | 	} | 
					
						
							| 
									
										
											  
											
												[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: | 
					
						
							|  |  |  | 	return 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
										 |  |  | 
 | 
					
						
							|  |  |  | } /* end key_get_instantiation_authkey() */ |