2019-05-27 09:55:01 +03:00
// SPDX-License-Identifier: GPL-2.0-or-later
2008-04-29 12:01:31 +04:00
/* Keyring handling
2005-04-17 02:20:36 +04:00
*
2013-09-24 13:35:18 +04:00
* Copyright ( C ) 2004 - 2005 , 2008 , 2013 Red Hat , Inc . All Rights Reserved .
2005-04-17 02:20:36 +04:00
* Written by David Howells ( dhowells @ redhat . com )
*/
2018-12-09 23:36:29 +03:00
# include <linux/export.h>
2005-04-17 02:20:36 +04:00
# include <linux/init.h>
# include <linux/sched.h>
# include <linux/slab.h>
2005-10-31 02:02:44 +03:00
# include <linux/security.h>
2005-04-17 02:20:36 +04:00
# include <linux/seq_file.h>
# include <linux/err.h>
2019-06-26 23:02:32 +03:00
# include <linux/user_namespace.h>
2019-06-26 23:02:33 +03:00
# include <linux/nsproxy.h>
2008-11-14 02:39:13 +03:00
# include <keys/keyring-type.h>
2013-09-24 13:35:18 +04:00
# include <keys/user-type.h>
# include <linux/assoc_array_priv.h>
2010-03-09 02:11:34 +03:00
# include <linux/uaccess.h>
2019-06-26 23:02:33 +03:00
# include <net/net_namespace.h>
2005-04-17 02:20:36 +04:00
# include "internal.h"
/*
2011-01-20 19:38:33 +03:00
* When plumbing the depths of the key tree , this sets a hard limit
* set on how deep we ' re willing to go .
2005-04-17 02:20:36 +04:00
*/
# define KEYRING_SEARCH_MAX_DEPTH 6
2013-09-24 13:35:18 +04:00
/*
* We mark pointers we pass to the associative array with bit 1 set if
* they ' re keyrings and clear otherwise .
*/
# define KEYRING_PTR_SUBTYPE 0x2UL
static inline bool keyring_ptr_is_keyring ( const struct assoc_array_ptr * x )
{
return ( unsigned long ) x & KEYRING_PTR_SUBTYPE ;
}
static inline struct key * keyring_ptr_to_key ( const struct assoc_array_ptr * x )
{
void * object = assoc_array_ptr_to_leaf ( x ) ;
return ( struct key * ) ( ( unsigned long ) object & ~ KEYRING_PTR_SUBTYPE ) ;
}
static inline void * keyring_key_to_ptr ( struct key * key )
{
if ( key - > type = = & key_type_keyring )
return ( void * ) ( ( unsigned long ) key | KEYRING_PTR_SUBTYPE ) ;
return key ;
}
2005-04-17 02:20:36 +04:00
static DEFINE_RWLOCK ( keyring_name_lock ) ;
2019-06-26 23:02:32 +03:00
/*
* Clean up the bits of user_namespace that belong to us .
*/
void key_free_user_ns ( struct user_namespace * ns )
2005-04-17 02:20:36 +04:00
{
2019-06-26 23:02:32 +03:00
write_lock ( & keyring_name_lock ) ;
list_del_init ( & ns - > keyring_name_list ) ;
write_unlock ( & keyring_name_lock ) ;
2005-04-17 02:20:36 +04:00
2019-06-26 23:02:32 +03:00
key_put ( ns - > user_keyring_register ) ;
2019-06-26 23:02:32 +03:00
# ifdef CONFIG_PERSISTENT_KEYRINGS
key_put ( ns - > persistent_keyring_register ) ;
# endif
2005-04-17 02:20:36 +04:00
}
/*
2011-01-20 19:38:33 +03:00
* The keyring key type definition . Keyrings are simply keys of this type and
* can be treated as ordinary keys in addition to having their own special
* operations .
2005-04-17 02:20:36 +04:00
*/
2014-07-18 21:56:36 +04:00
static int keyring_preparse ( struct key_preparsed_payload * prep ) ;
static void keyring_free_preparse ( struct key_preparsed_payload * prep ) ;
2005-04-17 02:20:36 +04:00
static int keyring_instantiate ( struct key * keyring ,
2012-09-13 16:06:29 +04:00
struct key_preparsed_payload * prep ) ;
2006-06-26 11:24:51 +04:00
static void keyring_revoke ( struct key * keyring ) ;
2005-04-17 02:20:36 +04:00
static void keyring_destroy ( struct key * keyring ) ;
static void keyring_describe ( const struct key * keyring , struct seq_file * m ) ;
static long keyring_read ( const struct key * keyring ,
2022-09-07 15:12:30 +03:00
char * buffer , size_t buflen ) ;
2005-04-17 02:20:36 +04:00
struct key_type key_type_keyring = {
. name = " keyring " ,
2013-09-24 13:35:18 +04:00
. def_datalen = 0 ,
2014-07-18 21:56:36 +04:00
. preparse = keyring_preparse ,
. free_preparse = keyring_free_preparse ,
2005-04-17 02:20:36 +04:00
. instantiate = keyring_instantiate ,
2006-06-26 11:24:51 +04:00
. revoke = keyring_revoke ,
2005-04-17 02:20:36 +04:00
. destroy = keyring_destroy ,
. describe = keyring_describe ,
. read = keyring_read ,
} ;
2007-04-27 02:46:23 +04:00
EXPORT_SYMBOL ( key_type_keyring ) ;
2005-04-17 02:20:36 +04:00
/*
2011-01-20 19:38:33 +03:00
* Semaphore to serialise link / link calls to prevent two link calls in parallel
* introducing a cycle .
2005-04-17 02:20:36 +04:00
*/
2019-05-30 13:40:24 +03:00
static DEFINE_MUTEX ( keyring_serialise_link_lock ) ;
2005-04-17 02:20:36 +04:00
/*
2011-01-20 19:38:33 +03:00
* Publish the name of a keyring so that it can be found by name ( if it has
2019-06-26 23:02:32 +03:00
* one and it doesn ' t begin with a dot ) .
2005-04-17 02:20:36 +04:00
*/
2008-04-29 12:01:31 +04:00
static void keyring_publish_name ( struct key * keyring )
2005-04-17 02:20:36 +04:00
{
2019-06-26 23:02:32 +03:00
struct user_namespace * ns = current_user_ns ( ) ;
2005-04-17 02:20:36 +04:00
2019-06-26 23:02:32 +03:00
if ( keyring - > description & &
keyring - > description [ 0 ] & &
keyring - > description [ 0 ] ! = ' . ' ) {
2005-04-17 02:20:36 +04:00
write_lock ( & keyring_name_lock ) ;
2019-06-26 23:02:32 +03:00
list_add_tail ( & keyring - > name_link , & ns - > keyring_name_list ) ;
2005-04-17 02:20:36 +04:00
write_unlock ( & keyring_name_lock ) ;
}
2011-01-20 19:38:27 +03:00
}
2005-04-17 02:20:36 +04:00
2014-07-18 21:56:36 +04:00
/*
* Preparse a keyring payload
*/
static int keyring_preparse ( struct key_preparsed_payload * prep )
{
return prep - > datalen ! = 0 ? - EINVAL : 0 ;
}
/*
* Free a preparse of a user defined key payload
*/
static void keyring_free_preparse ( struct key_preparsed_payload * prep )
{
}
2005-04-17 02:20:36 +04:00
/*
2011-01-20 19:38:33 +03:00
* Initialise a keyring .
*
* Returns 0 on success , - EINVAL if given any data .
2005-04-17 02:20:36 +04:00
*/
static int keyring_instantiate ( struct key * keyring ,
2012-09-13 16:06:29 +04:00
struct key_preparsed_payload * prep )
2005-04-17 02:20:36 +04:00
{
2014-07-18 21:56:36 +04:00
assoc_array_init ( & keyring - > keys ) ;
/* make the keyring available by name if it has one */
keyring_publish_name ( keyring ) ;
return 0 ;
2011-01-20 19:38:27 +03:00
}
2005-04-17 02:20:36 +04:00
/*
2013-09-24 13:35:18 +04:00
* Multiply 64 - bits by 32 - bits to 96 - bits and fold back to 64 - bit . Ideally we ' d
* fold the carry back too , but that requires inline asm .
*/
static u64 mult_64x32_and_fold ( u64 x , u32 y )
{
u64 hi = ( u64 ) ( u32 ) ( x > > 32 ) * y ;
u64 lo = ( u64 ) ( u32 ) ( x ) * y ;
return lo + ( ( u64 ) ( u32 ) hi < < 32 ) + ( u32 ) ( hi > > 32 ) ;
}
/*
* Hash a key type and description .
*/
2019-06-26 23:02:32 +03:00
static void hash_key_type_and_desc ( struct keyring_index_key * index_key )
2013-09-24 13:35:18 +04:00
{
const unsigned level_shift = ASSOC_ARRAY_LEVEL_STEP ;
2013-12-02 15:24:18 +04:00
const unsigned long fan_mask = ASSOC_ARRAY_FAN_MASK ;
2013-09-24 13:35:18 +04:00
const char * description = index_key - > description ;
unsigned long hash , type ;
u32 piece ;
u64 acc ;
int n , desc_len = index_key - > desc_len ;
type = ( unsigned long ) index_key - > type ;
acc = mult_64x32_and_fold ( type , desc_len + 13 ) ;
acc = mult_64x32_and_fold ( acc , 9207 ) ;
2019-06-26 23:02:32 +03:00
piece = ( unsigned long ) index_key - > domain_tag ;
acc = mult_64x32_and_fold ( acc , piece ) ;
acc = mult_64x32_and_fold ( acc , 9207 ) ;
2019-06-26 23:02:31 +03:00
2013-09-24 13:35:18 +04:00
for ( ; ; ) {
n = desc_len ;
if ( n < = 0 )
break ;
if ( n > 4 )
n = 4 ;
piece = 0 ;
memcpy ( & piece , description , n ) ;
description + = n ;
desc_len - = n ;
acc = mult_64x32_and_fold ( acc , piece ) ;
acc = mult_64x32_and_fold ( acc , 9207 ) ;
}
/* Fold the hash down to 32 bits if need be. */
hash = acc ;
if ( ASSOC_ARRAY_KEY_CHUNK_SIZE = = 32 )
hash ^ = acc > > 32 ;
/* Squidge all the keyrings into a separate part of the tree to
* ordinary keys by making sure the lowest level segment in the hash is
* zero for keyrings and non - zero otherwise .
*/
2013-12-02 15:24:18 +04:00
if ( index_key - > type ! = & key_type_keyring & & ( hash & fan_mask ) = = 0 )
2019-06-26 23:02:32 +03:00
hash | = ( hash > > ( ASSOC_ARRAY_KEY_CHUNK_SIZE - level_shift ) ) | 1 ;
else if ( index_key - > type = = & key_type_keyring & & ( hash & fan_mask ) ! = 0 )
hash = ( hash + ( hash < < level_shift ) ) & ~ fan_mask ;
index_key - > hash = hash ;
2013-09-24 13:35:18 +04:00
}
/*
2019-06-26 23:02:32 +03:00
* Finalise an index key to include a part of the description actually in the
2019-06-26 23:02:32 +03:00
* index key , to set the domain tag and to calculate the hash .
2019-06-26 23:02:32 +03:00
*/
void key_set_index_key ( struct keyring_index_key * index_key )
{
2019-06-26 23:02:32 +03:00
static struct key_tag default_domain_tag = { . usage = REFCOUNT_INIT ( 1 ) , } ;
2019-06-26 23:02:32 +03:00
size_t n = min_t ( size_t , index_key - > desc_len , sizeof ( index_key - > desc ) ) ;
2019-06-26 23:02:32 +03:00
2019-06-26 23:02:32 +03:00
memcpy ( index_key - > desc , index_key - > description , n ) ;
2019-06-26 23:02:33 +03:00
if ( ! index_key - > domain_tag ) {
if ( index_key - > type - > flags & KEY_TYPE_NET_DOMAIN )
index_key - > domain_tag = current - > nsproxy - > net_ns - > key_domain ;
else
index_key - > domain_tag = & default_domain_tag ;
}
2019-06-26 23:02:32 +03:00
hash_key_type_and_desc ( index_key ) ;
2013-09-24 13:35:18 +04:00
}
2019-06-26 23:02:32 +03:00
/**
* key_put_tag - Release a ref on a tag .
* @ tag : The tag to release .
2013-09-24 13:35:18 +04:00
*
2019-06-26 23:02:32 +03:00
* This releases a reference the given tag and returns true if that ref was the
* last one .
*/
bool key_put_tag ( struct key_tag * tag )
{
if ( refcount_dec_and_test ( & tag - > usage ) ) {
kfree_rcu ( tag , rcu ) ;
return true ;
}
return false ;
}
2019-06-26 23:02:32 +03:00
/**
* key_remove_domain - Kill off a key domain and gc its keys
* @ domain_tag : The domain tag to release .
2013-09-24 13:35:18 +04:00
*
2019-06-26 23:02:32 +03:00
* This marks a domain tag as being dead and releases a ref on it . If that
* wasn ' t the last reference , the garbage collector is poked to try and delete
* all keys that were in the domain .
*/
void key_remove_domain ( struct key_tag * domain_tag )
{
domain_tag - > removed = true ;
if ( ! key_put_tag ( domain_tag ) )
key_schedule_gc_links ( ) ;
}
2013-09-24 13:35:18 +04:00
/*
* Build the next index key chunk .
*
* We return it one word - sized chunk at a time .
2005-04-17 02:20:36 +04:00
*/
2013-09-24 13:35:18 +04:00
static unsigned long keyring_get_key_chunk ( const void * data , int level )
{
const struct keyring_index_key * index_key = data ;
unsigned long chunk = 0 ;
2019-06-26 23:02:31 +03:00
const u8 * d ;
2013-09-24 13:35:18 +04:00
int desc_len = index_key - > desc_len , n = sizeof ( chunk ) ;
level / = ASSOC_ARRAY_KEY_CHUNK_SIZE ;
switch ( level ) {
case 0 :
2019-06-26 23:02:32 +03:00
return index_key - > hash ;
2013-09-24 13:35:18 +04:00
case 1 :
2019-06-26 23:02:31 +03:00
return index_key - > x ;
2013-09-24 13:35:18 +04:00
case 2 :
2019-06-26 23:02:31 +03:00
return ( unsigned long ) index_key - > type ;
2019-06-26 23:02:32 +03:00
case 3 :
return ( unsigned long ) index_key - > domain_tag ;
2013-09-24 13:35:18 +04:00
default :
2019-06-26 23:02:32 +03:00
level - = 4 ;
2019-06-26 23:02:31 +03:00
if ( desc_len < = sizeof ( index_key - > desc ) )
2013-09-24 13:35:18 +04:00
return 0 ;
2019-06-26 23:02:31 +03:00
d = index_key - > description + sizeof ( index_key - > desc ) ;
d + = level * sizeof ( long ) ;
desc_len - = sizeof ( index_key - > desc ) ;
2013-09-24 13:35:18 +04:00
if ( desc_len > n )
desc_len = n ;
do {
chunk < < = 8 ;
2019-06-26 23:02:31 +03:00
chunk | = * d + + ;
2013-09-24 13:35:18 +04:00
} while ( - - desc_len > 0 ) ;
return chunk ;
}
}
static unsigned long keyring_get_object_key_chunk ( const void * object , int level )
{
const struct key * key = keyring_ptr_to_key ( object ) ;
return keyring_get_key_chunk ( & key - > index_key , level ) ;
}
static bool keyring_compare_object ( const void * object , const void * data )
2005-04-17 02:20:36 +04:00
{
2013-09-24 13:35:18 +04:00
const struct keyring_index_key * index_key = data ;
const struct key * key = keyring_ptr_to_key ( object ) ;
return key - > index_key . type = = index_key - > type & &
2019-06-26 23:02:32 +03:00
key - > index_key . domain_tag = = index_key - > domain_tag & &
2013-09-24 13:35:18 +04:00
key - > index_key . desc_len = = index_key - > desc_len & &
memcmp ( key - > index_key . description , index_key - > description ,
index_key - > desc_len ) = = 0 ;
2011-01-20 19:38:27 +03:00
}
2005-04-17 02:20:36 +04:00
2013-09-24 13:35:18 +04:00
/*
* Compare the index keys of a pair of objects and determine the bit position
* at which they differ - if they differ .
*/
2013-12-02 15:24:18 +04:00
static int keyring_diff_objects ( const void * object , const void * data )
2013-09-24 13:35:18 +04:00
{
2013-12-02 15:24:18 +04:00
const struct key * key_a = keyring_ptr_to_key ( object ) ;
2013-09-24 13:35:18 +04:00
const struct keyring_index_key * a = & key_a - > index_key ;
2013-12-02 15:24:18 +04:00
const struct keyring_index_key * b = data ;
2013-09-24 13:35:18 +04:00
unsigned long seg_a , seg_b ;
int level , i ;
level = 0 ;
2019-06-26 23:02:32 +03:00
seg_a = a - > hash ;
seg_b = b - > hash ;
2013-09-24 13:35:18 +04:00
if ( ( seg_a ^ seg_b ) ! = 0 )
goto differ ;
2019-06-26 23:02:31 +03:00
level + = ASSOC_ARRAY_KEY_CHUNK_SIZE / 8 ;
2013-09-24 13:35:18 +04:00
/* The number of bits contributed by the hash is controlled by a
* constant in the assoc_array headers . Everything else thereafter we
* can deal with as being machine word - size dependent .
*/
2019-06-26 23:02:31 +03:00
seg_a = a - > x ;
seg_b = b - > x ;
2013-09-24 13:35:18 +04:00
if ( ( seg_a ^ seg_b ) ! = 0 )
goto differ ;
2019-06-26 23:02:31 +03:00
level + = sizeof ( unsigned long ) ;
2013-09-24 13:35:18 +04:00
/* The next bit may not work on big endian */
seg_a = ( unsigned long ) a - > type ;
seg_b = ( unsigned long ) b - > type ;
if ( ( seg_a ^ seg_b ) ! = 0 )
goto differ ;
level + = sizeof ( unsigned long ) ;
2019-06-26 23:02:32 +03:00
seg_a = ( unsigned long ) a - > domain_tag ;
seg_b = ( unsigned long ) b - > domain_tag ;
if ( ( seg_a ^ seg_b ) ! = 0 )
goto differ ;
2013-09-24 13:35:18 +04:00
level + = sizeof ( unsigned long ) ;
2019-06-26 23:02:31 +03:00
i = sizeof ( a - > desc ) ;
if ( a - > desc_len < = i )
goto same ;
2013-09-24 13:35:18 +04:00
for ( ; i < a - > desc_len ; i + + ) {
seg_a = * ( unsigned char * ) ( a - > description + i ) ;
seg_b = * ( unsigned char * ) ( b - > description + i ) ;
if ( ( seg_a ^ seg_b ) ! = 0 )
goto differ_plus_i ;
}
same :
return - 1 ;
differ_plus_i :
level + = i ;
differ :
i = level * 8 + __ffs ( seg_a ^ seg_b ) ;
return i ;
}
/*
* Free an object after stripping the keyring flag off of the pointer .
*/
static void keyring_free_object ( void * object )
{
key_put ( keyring_ptr_to_key ( object ) ) ;
}
/*
* Operations for keyring management by the index - tree routines .
*/
static const struct assoc_array_ops keyring_assoc_array_ops = {
. get_key_chunk = keyring_get_key_chunk ,
. get_object_key_chunk = keyring_get_object_key_chunk ,
. compare_object = keyring_compare_object ,
. diff_objects = keyring_diff_objects ,
. free_object = keyring_free_object ,
} ;
2005-04-17 02:20:36 +04:00
/*
2011-01-20 19:38:33 +03:00
* Clean up a keyring when it is destroyed . Unpublish its name if it had one
* and dispose of its data .
2012-05-11 13:56:56 +04:00
*
* The garbage collector detects the final key_put ( ) , removes the keyring from
* the serial number tree and then does RCU synchronisation before coming here ,
* so we shouldn ' t need to worry about code poking around here with the RCU
* readlock held by this time .
2005-04-17 02:20:36 +04:00
*/
static void keyring_destroy ( struct key * keyring )
{
if ( keyring - > description ) {
write_lock ( & keyring_name_lock ) ;
2005-08-05 00:07:07 +04:00
2015-10-21 16:04:48 +03:00
if ( keyring - > name_link . next ! = NULL & &
! list_empty ( & keyring - > name_link ) )
list_del ( & keyring - > name_link ) ;
2005-08-05 00:07:07 +04:00
2005-04-17 02:20:36 +04:00
write_unlock ( & keyring_name_lock ) ;
}
2016-09-01 02:05:43 +03:00
if ( keyring - > restrict_link ) {
struct key_restriction * keyres = keyring - > restrict_link ;
key_put ( keyres - > key ) ;
kfree ( keyres ) ;
}
2013-09-24 13:35:18 +04:00
assoc_array_destroy ( & keyring - > keys , & keyring_assoc_array_ops ) ;
2011-01-20 19:38:27 +03:00
}
2005-04-17 02:20:36 +04:00
/*
2011-01-20 19:38:33 +03:00
* Describe a keyring for / proc .
2005-04-17 02:20:36 +04:00
*/
static void keyring_describe ( const struct key * keyring , struct seq_file * m )
{
2010-03-04 16:26:23 +03:00
if ( keyring - > description )
2005-04-17 02:20:36 +04:00
seq_puts ( m , keyring - > description ) ;
2010-03-04 16:26:23 +03:00
else
2005-04-17 02:20:36 +04:00
seq_puts ( m , " [anon] " ) ;
2017-10-04 18:43:25 +03:00
if ( key_is_positive ( keyring ) ) {
2013-09-24 13:35:18 +04:00
if ( keyring - > keys . nr_leaves_on_tree ! = 0 )
seq_printf ( m , " : %lu " , keyring - > keys . nr_leaves_on_tree ) ;
2011-03-11 20:57:23 +03:00
else
seq_puts ( m , " : empty " ) ;
}
2011-01-20 19:38:27 +03:00
}
2005-04-17 02:20:36 +04:00
2013-09-24 13:35:18 +04:00
struct keyring_read_iterator_context {
2017-09-18 21:36:45 +03:00
size_t buflen ;
2013-09-24 13:35:18 +04:00
size_t count ;
2020-11-24 02:54:00 +03:00
key_serial_t * buffer ;
2013-09-24 13:35:18 +04:00
} ;
static int keyring_read_iterator ( const void * object , void * data )
{
struct keyring_read_iterator_context * ctx = data ;
const struct key * key = keyring_ptr_to_key ( object ) ;
kenter ( " {%s,%d},,{%zu/%zu} " ,
2017-09-18 21:36:45 +03:00
key - > type - > name , key - > serial , ctx - > count , ctx - > buflen ) ;
2013-09-24 13:35:18 +04:00
2017-09-18 21:36:45 +03:00
if ( ctx - > count > = ctx - > buflen )
2013-09-24 13:35:18 +04:00
return 1 ;
2020-03-22 04:11:24 +03:00
* ctx - > buffer + + = key - > serial ;
2013-09-24 13:35:18 +04:00
ctx - > count + = sizeof ( key - > serial ) ;
return 0 ;
}
2005-04-17 02:20:36 +04:00
/*
2011-01-20 19:38:33 +03:00
* Read a list of key IDs from the keyring ' s contents in binary form
*
2013-09-24 13:35:18 +04:00
* The keyring ' s semaphore is read - locked by the caller . This prevents someone
* from modifying it under us - which could cause us to read key IDs multiple
* times .
2005-04-17 02:20:36 +04:00
*/
static long keyring_read ( const struct key * keyring ,
2020-11-24 02:54:00 +03:00
char * buffer , size_t buflen )
2005-04-17 02:20:36 +04:00
{
2013-09-24 13:35:18 +04:00
struct keyring_read_iterator_context ctx ;
2017-11-02 03:47:03 +03:00
long ret ;
2005-04-17 02:20:36 +04:00
2013-09-24 13:35:18 +04:00
kenter ( " {%d},,%zu " , key_serial ( keyring ) , buflen ) ;
if ( buflen & ( sizeof ( key_serial_t ) - 1 ) )
return - EINVAL ;
2017-11-02 03:47:03 +03:00
/* Copy as many key IDs as fit into the buffer */
if ( buffer & & buflen ) {
2020-11-24 02:54:00 +03:00
ctx . buffer = ( key_serial_t * ) buffer ;
2017-11-02 03:47:03 +03:00
ctx . buflen = buflen ;
ctx . count = 0 ;
ret = assoc_array_iterate ( & keyring - > keys ,
keyring_read_iterator , & ctx ) ;
if ( ret < 0 ) {
kleave ( " = %ld [iterate] " , ret ) ;
return ret ;
}
2005-04-17 02:20:36 +04:00
}
2017-11-02 03:47:03 +03:00
/* Return the size of the buffer needed */
ret = keyring - > keys . nr_leaves_on_tree * sizeof ( key_serial_t ) ;
if ( ret < = buflen )
kleave ( " = %ld [ok] " , ret ) ;
else
kleave ( " = %ld [buffer too small] " , ret ) ;
return ret ;
2011-01-20 19:38:27 +03:00
}
2005-04-17 02:20:36 +04:00
2019-07-11 04:43:43 +03:00
/*
* Allocate a keyring and link into the destination keyring .
2005-04-17 02:20:36 +04:00
*/
2012-02-08 19:53:04 +04:00
struct key * keyring_alloc ( const char * description , kuid_t uid , kgid_t gid ,
2019-07-11 04:43:43 +03:00
const struct cred * cred , key_perm_t perm ,
KEYS: Add a facility to restrict new links into a keyring
Add a facility whereby proposed new links to be added to a keyring can be
vetted, permitting them to be rejected if necessary. This can be used to
block public keys from which the signature cannot be verified or for which
the signature verification fails. It could also be used to provide
blacklisting.
This affects operations like add_key(), KEYCTL_LINK and KEYCTL_INSTANTIATE.
To this end:
(1) A function pointer is added to the key struct that, if set, points to
the vetting function. This is called as:
int (*restrict_link)(struct key *keyring,
const struct key_type *key_type,
unsigned long key_flags,
const union key_payload *key_payload),
where 'keyring' will be the keyring being added to, key_type and
key_payload will describe the key being added and key_flags[*] can be
AND'ed with KEY_FLAG_TRUSTED.
[*] This parameter will be removed in a later patch when
KEY_FLAG_TRUSTED is removed.
The function should return 0 to allow the link to take place or an
error (typically -ENOKEY, -ENOPKG or -EKEYREJECTED) to reject the
link.
The pointer should not be set directly, but rather should be set
through keyring_alloc().
Note that if called during add_key(), preparse is called before this
method, but a key isn't actually allocated until after this function
is called.
(2) KEY_ALLOC_BYPASS_RESTRICTION is added. This can be passed to
key_create_or_update() or key_instantiate_and_link() to bypass the
restriction check.
(3) KEY_FLAG_TRUSTED_ONLY is removed. The entire contents of a keyring
with this restriction emplaced can be considered 'trustworthy' by
virtue of being in the keyring when that keyring is consulted.
(4) key_alloc() and keyring_alloc() take an extra argument that will be
used to set restrict_link in the new key. This ensures that the
pointer is set before the key is published, thus preventing a window
of unrestrictedness. Normally this argument will be NULL.
(5) As a temporary affair, keyring_restrict_trusted_only() is added. It
should be passed to keyring_alloc() as the extra argument instead of
setting KEY_FLAG_TRUSTED_ONLY on a keyring. This will be replaced in
a later patch with functions that look in the appropriate places for
authoritative keys.
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
2016-04-06 18:14:24 +03:00
unsigned long flags ,
2016-09-01 02:05:43 +03:00
struct key_restriction * restrict_link ,
KEYS: Add a facility to restrict new links into a keyring
Add a facility whereby proposed new links to be added to a keyring can be
vetted, permitting them to be rejected if necessary. This can be used to
block public keys from which the signature cannot be verified or for which
the signature verification fails. It could also be used to provide
blacklisting.
This affects operations like add_key(), KEYCTL_LINK and KEYCTL_INSTANTIATE.
To this end:
(1) A function pointer is added to the key struct that, if set, points to
the vetting function. This is called as:
int (*restrict_link)(struct key *keyring,
const struct key_type *key_type,
unsigned long key_flags,
const union key_payload *key_payload),
where 'keyring' will be the keyring being added to, key_type and
key_payload will describe the key being added and key_flags[*] can be
AND'ed with KEY_FLAG_TRUSTED.
[*] This parameter will be removed in a later patch when
KEY_FLAG_TRUSTED is removed.
The function should return 0 to allow the link to take place or an
error (typically -ENOKEY, -ENOPKG or -EKEYREJECTED) to reject the
link.
The pointer should not be set directly, but rather should be set
through keyring_alloc().
Note that if called during add_key(), preparse is called before this
method, but a key isn't actually allocated until after this function
is called.
(2) KEY_ALLOC_BYPASS_RESTRICTION is added. This can be passed to
key_create_or_update() or key_instantiate_and_link() to bypass the
restriction check.
(3) KEY_FLAG_TRUSTED_ONLY is removed. The entire contents of a keyring
with this restriction emplaced can be considered 'trustworthy' by
virtue of being in the keyring when that keyring is consulted.
(4) key_alloc() and keyring_alloc() take an extra argument that will be
used to set restrict_link in the new key. This ensures that the
pointer is set before the key is published, thus preventing a window
of unrestrictedness. Normally this argument will be NULL.
(5) As a temporary affair, keyring_restrict_trusted_only() is added. It
should be passed to keyring_alloc() as the extra argument instead of
setting KEY_FLAG_TRUSTED_ONLY on a keyring. This will be replaced in
a later patch with functions that look in the appropriate places for
authoritative keys.
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
2016-04-06 18:14:24 +03:00
struct key * dest )
2005-04-17 02:20:36 +04:00
{
struct key * keyring ;
int ret ;
keyring = key_alloc ( & key_type_keyring , description ,
2019-07-11 04:43:43 +03:00
uid , gid , cred , perm , flags , restrict_link ) ;
2005-04-17 02:20:36 +04:00
if ( ! IS_ERR ( 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-24 09:00:56 +04:00
ret = key_instantiate_and_link ( keyring , NULL , 0 , dest , NULL ) ;
2005-04-17 02:20:36 +04:00
if ( ret < 0 ) {
key_put ( keyring ) ;
keyring = ERR_PTR ( ret ) ;
}
}
return keyring ;
2011-01-20 19:38:27 +03:00
}
2012-10-02 22:24:56 +04:00
EXPORT_SYMBOL ( keyring_alloc ) ;
2005-04-17 02:20:36 +04:00
KEYS: Add a facility to restrict new links into a keyring
Add a facility whereby proposed new links to be added to a keyring can be
vetted, permitting them to be rejected if necessary. This can be used to
block public keys from which the signature cannot be verified or for which
the signature verification fails. It could also be used to provide
blacklisting.
This affects operations like add_key(), KEYCTL_LINK and KEYCTL_INSTANTIATE.
To this end:
(1) A function pointer is added to the key struct that, if set, points to
the vetting function. This is called as:
int (*restrict_link)(struct key *keyring,
const struct key_type *key_type,
unsigned long key_flags,
const union key_payload *key_payload),
where 'keyring' will be the keyring being added to, key_type and
key_payload will describe the key being added and key_flags[*] can be
AND'ed with KEY_FLAG_TRUSTED.
[*] This parameter will be removed in a later patch when
KEY_FLAG_TRUSTED is removed.
The function should return 0 to allow the link to take place or an
error (typically -ENOKEY, -ENOPKG or -EKEYREJECTED) to reject the
link.
The pointer should not be set directly, but rather should be set
through keyring_alloc().
Note that if called during add_key(), preparse is called before this
method, but a key isn't actually allocated until after this function
is called.
(2) KEY_ALLOC_BYPASS_RESTRICTION is added. This can be passed to
key_create_or_update() or key_instantiate_and_link() to bypass the
restriction check.
(3) KEY_FLAG_TRUSTED_ONLY is removed. The entire contents of a keyring
with this restriction emplaced can be considered 'trustworthy' by
virtue of being in the keyring when that keyring is consulted.
(4) key_alloc() and keyring_alloc() take an extra argument that will be
used to set restrict_link in the new key. This ensures that the
pointer is set before the key is published, thus preventing a window
of unrestrictedness. Normally this argument will be NULL.
(5) As a temporary affair, keyring_restrict_trusted_only() is added. It
should be passed to keyring_alloc() as the extra argument instead of
setting KEY_FLAG_TRUSTED_ONLY on a keyring. This will be replaced in
a later patch with functions that look in the appropriate places for
authoritative keys.
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
2016-04-06 18:14:24 +03:00
/**
* restrict_link_reject - Give - EPERM to restrict link
* @ keyring : The keyring being added to .
* @ type : The type of key being added .
* @ payload : The payload of the key intended to be added .
2019-05-22 15:30:56 +03:00
* @ restriction_key : Keys providing additional data for evaluating restriction .
KEYS: Add a facility to restrict new links into a keyring
Add a facility whereby proposed new links to be added to a keyring can be
vetted, permitting them to be rejected if necessary. This can be used to
block public keys from which the signature cannot be verified or for which
the signature verification fails. It could also be used to provide
blacklisting.
This affects operations like add_key(), KEYCTL_LINK and KEYCTL_INSTANTIATE.
To this end:
(1) A function pointer is added to the key struct that, if set, points to
the vetting function. This is called as:
int (*restrict_link)(struct key *keyring,
const struct key_type *key_type,
unsigned long key_flags,
const union key_payload *key_payload),
where 'keyring' will be the keyring being added to, key_type and
key_payload will describe the key being added and key_flags[*] can be
AND'ed with KEY_FLAG_TRUSTED.
[*] This parameter will be removed in a later patch when
KEY_FLAG_TRUSTED is removed.
The function should return 0 to allow the link to take place or an
error (typically -ENOKEY, -ENOPKG or -EKEYREJECTED) to reject the
link.
The pointer should not be set directly, but rather should be set
through keyring_alloc().
Note that if called during add_key(), preparse is called before this
method, but a key isn't actually allocated until after this function
is called.
(2) KEY_ALLOC_BYPASS_RESTRICTION is added. This can be passed to
key_create_or_update() or key_instantiate_and_link() to bypass the
restriction check.
(3) KEY_FLAG_TRUSTED_ONLY is removed. The entire contents of a keyring
with this restriction emplaced can be considered 'trustworthy' by
virtue of being in the keyring when that keyring is consulted.
(4) key_alloc() and keyring_alloc() take an extra argument that will be
used to set restrict_link in the new key. This ensures that the
pointer is set before the key is published, thus preventing a window
of unrestrictedness. Normally this argument will be NULL.
(5) As a temporary affair, keyring_restrict_trusted_only() is added. It
should be passed to keyring_alloc() as the extra argument instead of
setting KEY_FLAG_TRUSTED_ONLY on a keyring. This will be replaced in
a later patch with functions that look in the appropriate places for
authoritative keys.
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
2016-04-06 18:14:24 +03:00
*
* Reject the addition of any links to a keyring . It can be overridden by
* passing KEY_ALLOC_BYPASS_RESTRICTION to key_instantiate_and_link ( ) when
* adding a key to a keyring .
*
2016-09-01 02:05:43 +03:00
* This is meant to be stored in a key_restriction structure which is passed
* in the restrict_link parameter to keyring_alloc ( ) .
KEYS: Add a facility to restrict new links into a keyring
Add a facility whereby proposed new links to be added to a keyring can be
vetted, permitting them to be rejected if necessary. This can be used to
block public keys from which the signature cannot be verified or for which
the signature verification fails. It could also be used to provide
blacklisting.
This affects operations like add_key(), KEYCTL_LINK and KEYCTL_INSTANTIATE.
To this end:
(1) A function pointer is added to the key struct that, if set, points to
the vetting function. This is called as:
int (*restrict_link)(struct key *keyring,
const struct key_type *key_type,
unsigned long key_flags,
const union key_payload *key_payload),
where 'keyring' will be the keyring being added to, key_type and
key_payload will describe the key being added and key_flags[*] can be
AND'ed with KEY_FLAG_TRUSTED.
[*] This parameter will be removed in a later patch when
KEY_FLAG_TRUSTED is removed.
The function should return 0 to allow the link to take place or an
error (typically -ENOKEY, -ENOPKG or -EKEYREJECTED) to reject the
link.
The pointer should not be set directly, but rather should be set
through keyring_alloc().
Note that if called during add_key(), preparse is called before this
method, but a key isn't actually allocated until after this function
is called.
(2) KEY_ALLOC_BYPASS_RESTRICTION is added. This can be passed to
key_create_or_update() or key_instantiate_and_link() to bypass the
restriction check.
(3) KEY_FLAG_TRUSTED_ONLY is removed. The entire contents of a keyring
with this restriction emplaced can be considered 'trustworthy' by
virtue of being in the keyring when that keyring is consulted.
(4) key_alloc() and keyring_alloc() take an extra argument that will be
used to set restrict_link in the new key. This ensures that the
pointer is set before the key is published, thus preventing a window
of unrestrictedness. Normally this argument will be NULL.
(5) As a temporary affair, keyring_restrict_trusted_only() is added. It
should be passed to keyring_alloc() as the extra argument instead of
setting KEY_FLAG_TRUSTED_ONLY on a keyring. This will be replaced in
a later patch with functions that look in the appropriate places for
authoritative keys.
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
2016-04-06 18:14:24 +03:00
*/
int restrict_link_reject ( struct key * keyring ,
const struct key_type * type ,
2016-08-30 21:33:13 +03:00
const union key_payload * payload ,
struct key * restriction_key )
KEYS: Add a facility to restrict new links into a keyring
Add a facility whereby proposed new links to be added to a keyring can be
vetted, permitting them to be rejected if necessary. This can be used to
block public keys from which the signature cannot be verified or for which
the signature verification fails. It could also be used to provide
blacklisting.
This affects operations like add_key(), KEYCTL_LINK and KEYCTL_INSTANTIATE.
To this end:
(1) A function pointer is added to the key struct that, if set, points to
the vetting function. This is called as:
int (*restrict_link)(struct key *keyring,
const struct key_type *key_type,
unsigned long key_flags,
const union key_payload *key_payload),
where 'keyring' will be the keyring being added to, key_type and
key_payload will describe the key being added and key_flags[*] can be
AND'ed with KEY_FLAG_TRUSTED.
[*] This parameter will be removed in a later patch when
KEY_FLAG_TRUSTED is removed.
The function should return 0 to allow the link to take place or an
error (typically -ENOKEY, -ENOPKG or -EKEYREJECTED) to reject the
link.
The pointer should not be set directly, but rather should be set
through keyring_alloc().
Note that if called during add_key(), preparse is called before this
method, but a key isn't actually allocated until after this function
is called.
(2) KEY_ALLOC_BYPASS_RESTRICTION is added. This can be passed to
key_create_or_update() or key_instantiate_and_link() to bypass the
restriction check.
(3) KEY_FLAG_TRUSTED_ONLY is removed. The entire contents of a keyring
with this restriction emplaced can be considered 'trustworthy' by
virtue of being in the keyring when that keyring is consulted.
(4) key_alloc() and keyring_alloc() take an extra argument that will be
used to set restrict_link in the new key. This ensures that the
pointer is set before the key is published, thus preventing a window
of unrestrictedness. Normally this argument will be NULL.
(5) As a temporary affair, keyring_restrict_trusted_only() is added. It
should be passed to keyring_alloc() as the extra argument instead of
setting KEY_FLAG_TRUSTED_ONLY on a keyring. This will be replaced in
a later patch with functions that look in the appropriate places for
authoritative keys.
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
2016-04-06 18:14:24 +03:00
{
return - EPERM ;
}
2014-09-16 20:36:06 +04:00
/*
* By default , we keys found by getting an exact match on their descriptions .
*/
2014-09-16 20:36:08 +04:00
bool key_default_cmp ( const struct key * key ,
const struct key_match_data * match_data )
2014-09-16 20:36:06 +04:00
{
return strcmp ( key - > description , match_data - > raw_data ) = = 0 ;
}
2013-09-24 13:35:18 +04:00
/*
* Iteration function to consider each key found .
2005-04-17 02:20:36 +04:00
*/
2013-09-24 13:35:18 +04:00
static int keyring_search_iterator ( const void * object , void * iterator_data )
2005-04-17 02:20:36 +04:00
{
2013-09-24 13:35:18 +04:00
struct keyring_search_context * ctx = iterator_data ;
const struct key * key = keyring_ptr_to_key ( object ) ;
2017-10-04 18:43:25 +03:00
unsigned long kflags = READ_ONCE ( key - > flags ) ;
short state = READ_ONCE ( key - > state ) ;
2005-04-17 02:20:36 +04:00
2013-09-24 13:35:18 +04:00
kenter ( " {%d} " , key - > serial ) ;
2005-04-17 02:20:36 +04:00
2013-09-24 13:35:18 +04:00
/* ignore keys not of this type */
if ( key - > type ! = ctx - > index_key . type ) {
kleave ( " = 0 [!type] " ) ;
return 0 ;
2005-10-31 02:02:44 +03:00
}
2005-04-17 02:20:36 +04:00
2013-09-24 13:35:18 +04:00
/* skip invalidated, revoked and expired keys */
if ( ctx - > flags & KEYRING_SEARCH_DO_STATE_CHECK ) {
2017-11-15 19:38:45 +03:00
time64_t expiry = READ_ONCE ( key - > expiry ) ;
2017-09-27 22:50:45 +03:00
2013-09-24 13:35:18 +04:00
if ( kflags & ( ( 1 < < KEY_FLAG_INVALIDATED ) |
( 1 < < KEY_FLAG_REVOKED ) ) ) {
ctx - > result = ERR_PTR ( - EKEYREVOKED ) ;
kleave ( " = %d [invrev] " , ctx - > skipped_ret ) ;
goto skipped ;
}
2005-04-17 02:20:36 +04:00
2017-11-15 19:38:45 +03:00
if ( expiry & & ctx - > now > = expiry ) {
KEYS: request_key() should reget expired keys rather than give EKEYEXPIRED
Since the keyring facility can be viewed as a cache (at least in some
applications), the local expiration time on the key should probably be viewed
as a 'needs updating after this time' property rather than an absolute 'anyone
now wanting to use this object is out of luck' property.
Since request_key() is the main interface for the usage of keys, this should
update or replace an expired key rather than issuing EKEYEXPIRED if the local
expiration has been reached (ie. it should refresh the cache).
For absolute conditions where refreshing the cache probably doesn't help, the
key can be negatively instantiated using KEYCTL_REJECT_KEY with EKEYEXPIRED
given as the error to issue. This will still cause request_key() to return
EKEYEXPIRED as that was explicitly set.
In the future, if the key type has an update op available, we might want to
upcall with the expired key and allow the upcall to update it. We would pass
a different operation name (the first column in /etc/request-key.conf) to the
request-key program.
request_key() returning EKEYEXPIRED is causing an NFS problem which Chuck
Lever describes thusly:
After about 10 minutes, my NFSv4 functional tests fail because the
ownership of the test files goes to "-2". Looking at /proc/keys
shows that the id_resolv keys that map to my test user ID have
expired. The ownership problem persists until the expired keys are
purged from the keyring, and fresh keys are obtained.
I bisected the problem to 3.13 commit b2a4df200d57 ("KEYS: Expand
the capacity of a keyring"). This commit inadvertantly changes the
API contract of the internal function keyring_search_aux().
The root cause appears to be that b2a4df200d57 made "no state check"
the default behavior. "No state check" means the keyring search
iterator function skips checking the key's expiry timeout, and
returns expired keys. request_key_and_link() depends on getting
an -EAGAIN result code to know when to perform an upcall to refresh
an expired key.
This patch can be tested directly by:
keyctl request2 user debug:fred a @s
keyctl timeout %user:debug:fred 3
sleep 4
keyctl request2 user debug:fred a @s
Without the patch, the last command gives error EKEYEXPIRED, but with the
command it gives a new key.
Reported-by: Carl Hetherington <cth@carlh.net>
Reported-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Tested-by: Chuck Lever <chuck.lever@oracle.com>
2014-12-02 01:52:53 +03:00
if ( ! ( ctx - > flags & KEYRING_SEARCH_SKIP_EXPIRED ) )
ctx - > result = ERR_PTR ( - EKEYEXPIRED ) ;
2013-09-24 13:35:18 +04:00
kleave ( " = %d [expire] " , ctx - > skipped_ret ) ;
goto skipped ;
}
}
2005-09-28 20:03:15 +04:00
2013-09-24 13:35:18 +04:00
/* keys that don't match */
2014-09-16 20:36:02 +04:00
if ( ! ctx - > match_data . cmp ( key , & ctx - > match_data ) ) {
2013-09-24 13:35:18 +04:00
kleave ( " = 0 [!match] " ) ;
return 0 ;
}
2008-04-29 12:01:22 +04:00
2013-09-24 13:35:18 +04:00
/* key must have search permissions */
if ( ! ( ctx - > flags & KEYRING_SEARCH_NO_CHECK_PERM ) & &
key_task_permission ( make_key_ref ( key , ctx - > possessed ) ,
2014-03-14 21:44:49 +04:00
ctx - > cred , KEY_NEED_SEARCH ) < 0 ) {
2013-09-24 13:35:18 +04:00
ctx - > result = ERR_PTR ( - EACCES ) ;
kleave ( " = %d [!perm] " , ctx - > skipped_ret ) ;
goto skipped ;
2008-04-29 12:01:22 +04:00
}
2013-09-24 13:35:18 +04:00
if ( ctx - > flags & KEYRING_SEARCH_DO_STATE_CHECK ) {
/* we set a different error code if we pass a negative key */
2017-10-04 18:43:25 +03:00
if ( state < 0 ) {
ctx - > result = ERR_PTR ( state ) ;
2013-09-24 13:35:18 +04:00
kleave ( " = %d [neg] " , ctx - > skipped_ret ) ;
goto skipped ;
}
}
2005-04-17 02:20:36 +04:00
2013-09-24 13:35:18 +04:00
/* Found */
ctx - > result = make_key_ref ( key , ctx - > possessed ) ;
kleave ( " = 1 [found] " ) ;
return 1 ;
2005-04-17 02:20:36 +04:00
2013-09-24 13:35:18 +04:00
skipped :
return ctx - > skipped_ret ;
}
2005-04-17 02:20:36 +04:00
2013-09-24 13:35:18 +04:00
/*
* Search inside a keyring for a key . We can search by walking to it
* directly based on its index - key or we can iterate over the entire
* tree looking for it , based on the match function .
*/
static int search_keyring ( struct key * keyring , struct keyring_search_context * ctx )
{
2014-09-16 20:36:02 +04:00
if ( ctx - > match_data . lookup_type = = KEYRING_SEARCH_LOOKUP_DIRECT ) {
2013-09-24 13:35:18 +04:00
const void * object ;
object = assoc_array_find ( & keyring - > keys ,
& keyring_assoc_array_ops ,
& ctx - > index_key ) ;
return object ? ctx - > iterator ( object , ctx ) : 0 ;
}
return assoc_array_iterate ( & keyring - > keys , ctx - > iterator , ctx ) ;
}
2005-04-17 02:20:36 +04:00
2013-09-24 13:35:18 +04:00
/*
* Search a tree of keyrings that point to other keyrings up to the maximum
* depth .
*/
static bool search_nested_keyrings ( struct key * keyring ,
struct keyring_search_context * ctx )
{
struct {
struct key * keyring ;
struct assoc_array_node * node ;
int slot ;
} stack [ KEYRING_SEARCH_MAX_DEPTH ] ;
2005-04-17 02:20:36 +04:00
2013-09-24 13:35:18 +04:00
struct assoc_array_shortcut * shortcut ;
struct assoc_array_node * node ;
struct assoc_array_ptr * ptr ;
struct key * key ;
int sp = 0 , slot ;
2005-04-17 02:20:36 +04:00
2013-09-24 13:35:18 +04:00
kenter ( " {%d},{%s,%s} " ,
keyring - > serial ,
ctx - > index_key . type - > name ,
ctx - > index_key . description ) ;
2005-04-17 02:20:36 +04:00
KEYS: Simplify KEYRING_SEARCH_{NO,DO}_STATE_CHECK flags
Simplify KEYRING_SEARCH_{NO,DO}_STATE_CHECK flags to be two variations of the
same flag. They are effectively mutually exclusive and one or the other
should be provided, but not both.
Keyring cycle detection and key possession determination are the only things
that set NO_STATE_CHECK, except that neither flag really does anything there
because neither purpose makes use of the keyring_search_iterator() function,
but rather provides their own.
For cycle detection we definitely want to check inside of expired keyrings,
just so that we don't create a cycle we can't get rid of. Revoked keyrings
are cleared at revocation time and can't then be reused, so shouldn't be a
problem either way.
For possession determination, we *might* want to validate each keyring before
searching it: do you possess a key that's hidden behind an expired or just
plain inaccessible keyring? Currently, the answer is yes. Note that you
cannot, however, possess a key behind a revoked keyring because they are
cleared on revocation.
keyring_search() sets DO_STATE_CHECK, which is correct.
request_key_and_link() currently doesn't specify whether to check the key
state or not - but it should set DO_STATE_CHECK.
key_get_instantiation_authkey() also currently doesn't specify whether to
check the key state or not - but it probably should also set DO_STATE_CHECK.
Signed-off-by: David Howells <dhowells@redhat.com>
Tested-by: Chuck Lever <chuck.lever@oracle.com>
2014-12-02 01:52:50 +03:00
# define STATE_CHECKS (KEYRING_SEARCH_NO_STATE_CHECK | KEYRING_SEARCH_DO_STATE_CHECK)
BUG_ON ( ( ctx - > flags & STATE_CHECKS ) = = 0 | |
( ctx - > flags & STATE_CHECKS ) = = STATE_CHECKS ) ;
2019-06-26 23:02:31 +03:00
if ( ctx - > index_key . description )
key_set_index_key ( & ctx - > index_key ) ;
2013-09-24 13:35:18 +04:00
/* Check to see if this top-level keyring is what we are looking for
* and whether it is valid or not .
*/
2014-09-16 20:36:02 +04:00
if ( ctx - > match_data . lookup_type = = KEYRING_SEARCH_LOOKUP_ITERATE | |
2013-09-24 13:35:18 +04:00
keyring_compare_object ( keyring , & ctx - > index_key ) ) {
ctx - > skipped_ret = 2 ;
switch ( ctx - > iterator ( keyring_key_to_ptr ( keyring ) , ctx ) ) {
case 1 :
2011-03-11 20:57:23 +03:00
goto found ;
2013-09-24 13:35:18 +04:00
case 2 :
return false ;
default :
break ;
2005-04-17 02:20:36 +04:00
}
2013-09-24 13:35:18 +04:00
}
2005-04-17 02:20:36 +04:00
2013-09-24 13:35:18 +04:00
ctx - > skipped_ret = 0 ;
/* Start processing a new keyring */
descend_to_keyring :
kdebug ( " descend to %d " , keyring - > serial ) ;
if ( keyring - > flags & ( ( 1 < < KEY_FLAG_INVALIDATED ) |
( 1 < < KEY_FLAG_REVOKED ) ) )
goto not_this_keyring ;
/* Search through the keys in this keyring before its searching its
* subtrees .
*/
if ( search_keyring ( keyring , ctx ) )
2005-04-17 02:20:36 +04:00
goto found ;
2013-09-24 13:35:18 +04:00
/* Then manually iterate through the keyrings nested in this one.
*
* Start from the root node of the index tree . Because of the way the
* hash function has been set up , keyrings cluster on the leftmost
* branch of the root node ( root slot 0 ) or in the root node itself .
* Non - keyrings avoid the leftmost branch of the root entirely ( root
* slots 1 - 15 ) .
*/
2019-06-26 23:02:32 +03:00
if ( ! ( ctx - > flags & KEYRING_SEARCH_RECURSE ) )
goto not_this_keyring ;
2017-06-08 16:47:34 +03:00
ptr = READ_ONCE ( keyring - > keys . root ) ;
2013-09-24 13:35:18 +04:00
if ( ! ptr )
goto not_this_keyring ;
2005-04-17 02:20:36 +04:00
2013-09-24 13:35:18 +04:00
if ( assoc_array_ptr_is_shortcut ( ptr ) ) {
/* If the root is a shortcut, either the keyring only contains
* keyring pointers ( everything clusters behind root slot 0 ) or
* doesn ' t contain any keyring pointers .
2005-04-17 02:20:36 +04:00
*/
2013-09-24 13:35:18 +04:00
shortcut = assoc_array_ptr_to_shortcut ( ptr ) ;
if ( ( shortcut - > index_key [ 0 ] & ASSOC_ARRAY_FAN_MASK ) ! = 0 )
goto not_this_keyring ;
2017-06-08 16:47:34 +03:00
ptr = READ_ONCE ( shortcut - > next_node ) ;
2013-09-24 13:35:18 +04:00
node = assoc_array_ptr_to_node ( ptr ) ;
goto begin_node ;
}
node = assoc_array_ptr_to_node ( ptr ) ;
ptr = node - > slots [ 0 ] ;
if ( ! assoc_array_ptr_is_meta ( ptr ) )
goto begin_node ;
descend_to_node :
/* Descend to a more distal node in this keyring's content tree and go
* through that .
*/
kdebug ( " descend " ) ;
if ( assoc_array_ptr_is_shortcut ( ptr ) ) {
shortcut = assoc_array_ptr_to_shortcut ( ptr ) ;
2017-06-08 16:47:34 +03:00
ptr = READ_ONCE ( shortcut - > next_node ) ;
2013-09-24 13:35:18 +04:00
BUG_ON ( ! assoc_array_ptr_is_node ( ptr ) ) ;
}
2013-12-02 15:24:19 +04:00
node = assoc_array_ptr_to_node ( ptr ) ;
2013-09-24 13:35:18 +04:00
begin_node :
kdebug ( " begin_node " ) ;
slot = 0 ;
ascend_to_node :
/* Go through the slots in a node */
for ( ; slot < ASSOC_ARRAY_FAN_OUT ; slot + + ) {
2017-06-08 16:47:34 +03:00
ptr = READ_ONCE ( node - > slots [ slot ] ) ;
2013-09-24 13:35:18 +04:00
if ( assoc_array_ptr_is_meta ( ptr ) & & node - > back_pointer )
goto descend_to_node ;
if ( ! keyring_ptr_is_keyring ( ptr ) )
2005-06-24 09:00:49 +04:00
continue ;
2005-04-17 02:20:36 +04:00
2013-09-24 13:35:18 +04:00
key = keyring_ptr_to_key ( ptr ) ;
if ( sp > = KEYRING_SEARCH_MAX_DEPTH ) {
if ( ctx - > flags & KEYRING_SEARCH_DETECT_TOO_DEEP ) {
ctx - > result = ERR_PTR ( - ELOOP ) ;
return false ;
}
goto not_this_keyring ;
}
/* Search a nested keyring */
if ( ! ( ctx - > flags & KEYRING_SEARCH_NO_CHECK_PERM ) & &
key_task_permission ( make_key_ref ( key , ctx - > possessed ) ,
2014-03-14 21:44:49 +04:00
ctx - > cred , KEY_NEED_SEARCH ) < 0 )
2005-06-24 09:00:49 +04:00
continue ;
2005-04-17 02:20:36 +04:00
/* stack the current position */
2012-05-11 13:56:56 +04:00
stack [ sp ] . keyring = keyring ;
2013-09-24 13:35:18 +04:00
stack [ sp ] . node = node ;
stack [ sp ] . slot = slot ;
2005-04-17 02:20:36 +04:00
sp + + ;
/* begin again with the new keyring */
keyring = key ;
2013-09-24 13:35:18 +04:00
goto descend_to_keyring ;
}
/* We've dealt with all the slots in the current node, so now we need
* to ascend to the parent and continue processing there .
*/
2017-06-08 16:47:34 +03:00
ptr = READ_ONCE ( node - > back_pointer ) ;
2013-09-24 13:35:18 +04:00
slot = node - > parent_slot ;
if ( ptr & & assoc_array_ptr_is_shortcut ( ptr ) ) {
shortcut = assoc_array_ptr_to_shortcut ( ptr ) ;
2017-06-08 16:47:34 +03:00
ptr = READ_ONCE ( shortcut - > back_pointer ) ;
2013-09-24 13:35:18 +04:00
slot = shortcut - > parent_slot ;
}
if ( ! ptr )
goto not_this_keyring ;
node = assoc_array_ptr_to_node ( ptr ) ;
slot + + ;
/* If we've ascended to the root (zero backpointer), we must have just
* finished processing the leftmost branch rather than the root slots -
* so there can ' t be any more keyrings for us to find .
*/
if ( node - > back_pointer ) {
kdebug ( " ascend %d " , slot ) ;
goto ascend_to_node ;
2005-04-17 02:20:36 +04:00
}
2013-09-24 13:35:18 +04:00
/* The keyring we're looking at was disqualified or didn't contain a
* matching key .
*/
2005-09-28 20:03:15 +04:00
not_this_keyring :
2013-09-24 13:35:18 +04:00
kdebug ( " not_this_keyring %d " , sp ) ;
if ( sp < = 0 ) {
kleave ( " = false " ) ;
return false ;
2005-04-17 02:20:36 +04:00
}
2013-09-24 13:35:18 +04:00
/* Resume the processing of a keyring higher up in the tree */
sp - - ;
keyring = stack [ sp ] . keyring ;
node = stack [ sp ] . node ;
slot = stack [ sp ] . slot + 1 ;
kdebug ( " ascend to %d [%d] " , keyring - > serial , slot ) ;
goto ascend_to_node ;
2005-04-17 02:20:36 +04:00
2013-09-24 13:35:18 +04:00
/* We found a viable match */
2005-09-28 20:03:15 +04:00
found :
2013-09-24 13:35:18 +04:00
key = key_ref_to_ptr ( ctx - > result ) ;
2005-04-17 02:20:36 +04:00
key_check ( key ) ;
2013-09-24 13:35:18 +04:00
if ( ! ( ctx - > flags & KEYRING_SEARCH_NO_UPDATE_TIME ) ) {
2017-11-15 19:38:45 +03:00
key - > last_used_at = ctx - > now ;
keyring - > last_used_at = ctx - > now ;
2013-09-24 13:35:18 +04:00
while ( sp > 0 )
2017-11-15 19:38:45 +03:00
stack [ - - sp ] . keyring - > last_used_at = ctx - > now ;
2013-09-24 13:35:18 +04:00
}
kleave ( " = true " ) ;
return true ;
}
/**
2019-06-19 18:10:15 +03:00
* keyring_search_rcu - Search a keyring tree for a matching key under RCU
2013-09-24 13:35:18 +04:00
* @ keyring_ref : A pointer to the keyring with possession indicator .
* @ ctx : The keyring search context .
*
* Search the supplied keyring tree for a key that matches the criteria given .
* The root keyring and any linked keyrings must grant Search permission to the
* caller to be searchable and keys can only be found if they too grant Search
* to the caller . The possession flag on the root keyring pointer controls use
* of the possessor bits in permissions checking of the entire tree . In
* addition , the LSM gets to forbid keyring searches and key matches .
*
* The search is performed as a breadth - then - depth search up to the prescribed
2019-06-19 18:10:15 +03:00
* limit ( KEYRING_SEARCH_MAX_DEPTH ) . The caller must hold the RCU read lock to
* prevent keyrings from being destroyed or rearranged whilst they are being
* searched .
2013-09-24 13:35:18 +04:00
*
* Keys are matched to the type provided and are then filtered by the match
* function , which is given the description to use in any way it sees fit . The
2020-08-07 19:51:23 +03:00
* match function may use any attributes of a key that it wishes to
2013-09-24 13:35:18 +04:00
* determine the match . Normally the match function from the key type would be
* used .
*
* RCU can be used to prevent the keyring key lists from disappearing without
* the need to take lots of locks .
*
* Returns a pointer to the found key and increments the key usage count if
* successful ; - EAGAIN if no matching keys were found , or if expired or revoked
* keys were found ; - ENOKEY if only negative keys were found ; - ENOTDIR if the
* specified keyring wasn ' t a keyring .
*
* In the case of a successful return , the possession attribute from
* @ keyring_ref is propagated to the returned key reference .
*/
2019-06-19 18:10:15 +03:00
key_ref_t keyring_search_rcu ( key_ref_t keyring_ref ,
2013-09-24 13:35:18 +04:00
struct keyring_search_context * ctx )
{
struct key * keyring ;
long err ;
ctx - > iterator = keyring_search_iterator ;
ctx - > possessed = is_key_possessed ( keyring_ref ) ;
ctx - > result = ERR_PTR ( - EAGAIN ) ;
keyring = key_ref_to_ptr ( keyring_ref ) ;
key_check ( keyring ) ;
if ( keyring - > type ! = & key_type_keyring )
return ERR_PTR ( - ENOTDIR ) ;
if ( ! ( ctx - > flags & KEYRING_SEARCH_NO_CHECK_PERM ) ) {
2014-03-14 21:44:49 +04:00
err = key_task_permission ( keyring_ref , ctx - > cred , KEY_NEED_SEARCH ) ;
2013-09-24 13:35:18 +04:00
if ( err < 0 )
return ERR_PTR ( err ) ;
}
2017-11-15 19:38:45 +03:00
ctx - > now = ktime_get_real_seconds ( ) ;
2013-09-24 13:35:18 +04:00
if ( search_nested_keyrings ( keyring , ctx ) )
__key_get ( key_ref_to_ptr ( ctx - > result ) ) ;
return ctx - > result ;
2011-01-20 19:38:27 +03:00
}
2005-04-17 02:20:36 +04:00
2011-01-20 19:38:33 +03:00
/**
* keyring_search - Search the supplied keyring tree for a matching key
* @ keyring : The root of the keyring tree to be searched .
* @ type : The type of keyring we want to find .
* @ description : The name of the keyring we want to find .
2019-06-26 23:02:32 +03:00
* @ recurse : True to search the children of @ keyring also
2011-01-20 19:38:33 +03:00
*
2019-06-19 18:10:15 +03:00
* As keyring_search_rcu ( ) above , but using the current task ' s credentials and
2013-09-24 13:35:18 +04:00
* type ' s default matching function and preferred search method .
2005-04-17 02:20:36 +04:00
*/
2005-09-28 20:03:15 +04:00
key_ref_t keyring_search ( key_ref_t keyring ,
struct key_type * type ,
2019-06-26 23:02:32 +03:00
const char * description ,
bool recurse )
2005-04-17 02:20:36 +04:00
{
2013-09-24 13:35:15 +04:00
struct keyring_search_context ctx = {
. index_key . type = type ,
. index_key . description = description ,
KEYS: always initialize keyring_index_key::desc_len
syzbot hit the 'BUG_ON(index_key->desc_len == 0);' in __key_link_begin()
called from construct_alloc_key() during sys_request_key(), because the
length of the key description was never calculated.
The problem is that we rely on ->desc_len being initialized by
search_process_keyrings(), specifically by search_nested_keyrings().
But, if the process isn't subscribed to any keyrings that never happens.
Fix it by always initializing keyring_index_key::desc_len as soon as the
description is set, like we already do in some places.
The following program reproduces the BUG_ON() when it's run as root and
no session keyring has been installed. If it doesn't work, try removing
pam_keyinit.so from /etc/pam.d/login and rebooting.
#include <stdlib.h>
#include <unistd.h>
#include <keyutils.h>
int main(void)
{
int id = add_key("keyring", "syz", NULL, 0, KEY_SPEC_USER_KEYRING);
keyctl_setperm(id, KEY_OTH_WRITE);
setreuid(5000, 5000);
request_key("user", "desc", "", id);
}
Reported-by: syzbot+ec24e95ea483de0a24da@syzkaller.appspotmail.com
Fixes: b2a4df200d57 ("KEYS: Expand the capacity of a keyring")
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: James Morris <james.morris@microsoft.com>
2019-02-22 18:36:18 +03:00
. index_key . desc_len = strlen ( description ) ,
2013-09-24 13:35:15 +04:00
. cred = current_cred ( ) ,
2014-09-16 20:36:06 +04:00
. match_data . cmp = key_default_cmp ,
2014-09-16 20:36:02 +04:00
. match_data . raw_data = description ,
. match_data . lookup_type = KEYRING_SEARCH_LOOKUP_DIRECT ,
. flags = KEYRING_SEARCH_DO_STATE_CHECK ,
2013-09-24 13:35:15 +04:00
} ;
2014-09-16 20:36:02 +04:00
key_ref_t key ;
int ret ;
2013-09-24 13:35:15 +04:00
2019-06-26 23:02:32 +03:00
if ( recurse )
ctx . flags | = KEYRING_SEARCH_RECURSE ;
2014-09-16 20:36:02 +04:00
if ( type - > match_preparse ) {
ret = type - > match_preparse ( & ctx . match_data ) ;
if ( ret < 0 )
return ERR_PTR ( ret ) ;
}
2019-06-19 18:10:15 +03:00
rcu_read_lock ( ) ;
key = keyring_search_rcu ( keyring , & ctx ) ;
rcu_read_unlock ( ) ;
2014-09-16 20:36:02 +04:00
if ( type - > match_free )
type - > match_free ( & ctx . match_data ) ;
return key ;
2011-01-20 19:38:27 +03:00
}
2005-04-17 02:20:36 +04:00
EXPORT_SYMBOL ( keyring_search ) ;
2017-03-02 03:44:09 +03:00
static struct key_restriction * keyring_restriction_alloc (
key_restrict_link_func_t check )
{
struct key_restriction * keyres =
kzalloc ( sizeof ( struct key_restriction ) , GFP_KERNEL ) ;
if ( ! keyres )
return ERR_PTR ( - ENOMEM ) ;
keyres - > check = check ;
return keyres ;
}
/*
* Semaphore to serialise restriction setup to prevent reference count
* cycles through restriction key pointers .
*/
static DECLARE_RWSEM ( keyring_serialise_restrict_sem ) ;
/*
* Check for restriction cycles that would prevent keyring garbage collection .
* keyring_serialise_restrict_sem must be held .
*/
static bool keyring_detect_restriction_cycle ( const struct key * dest_keyring ,
struct key_restriction * keyres )
{
while ( keyres & & keyres - > key & &
keyres - > key - > type = = & key_type_keyring ) {
if ( keyres - > key = = dest_keyring )
return true ;
keyres = keyres - > key - > restrict_link ;
}
return false ;
}
/**
* keyring_restrict - Look up and apply a restriction to a keyring
2019-05-22 15:30:56 +03:00
* @ keyring_ref : The keyring to be restricted
* @ type : The key type that will provide the restriction checker .
2017-03-02 03:44:09 +03:00
* @ restriction : The restriction options to apply to the keyring
2019-05-22 15:30:56 +03:00
*
* Look up a keyring and apply a restriction to it . The restriction is managed
* by the specific key type , but can be configured by the options specified in
* the restriction string .
2017-03-02 03:44:09 +03:00
*/
int keyring_restrict ( key_ref_t keyring_ref , const char * type ,
const char * restriction )
{
struct key * keyring ;
struct key_type * restrict_type = NULL ;
struct key_restriction * restrict_link ;
int ret = 0 ;
keyring = key_ref_to_ptr ( keyring_ref ) ;
key_check ( keyring ) ;
if ( keyring - > type ! = & key_type_keyring )
return - ENOTDIR ;
if ( ! type ) {
restrict_link = keyring_restriction_alloc ( restrict_link_reject ) ;
} else {
restrict_type = key_type_lookup ( type ) ;
if ( IS_ERR ( restrict_type ) )
return PTR_ERR ( restrict_type ) ;
if ( ! restrict_type - > lookup_restriction ) {
ret = - ENOENT ;
goto error ;
}
restrict_link = restrict_type - > lookup_restriction ( restriction ) ;
}
if ( IS_ERR ( restrict_link ) ) {
ret = PTR_ERR ( restrict_link ) ;
goto error ;
}
down_write ( & keyring - > sem ) ;
down_write ( & keyring_serialise_restrict_sem ) ;
watch_queue: Add a key/keyring notification facility
Add a key/keyring change notification facility whereby notifications about
changes in key and keyring content and attributes can be received.
Firstly, an event queue needs to be created:
pipe2(fds, O_NOTIFICATION_PIPE);
ioctl(fds[1], IOC_WATCH_QUEUE_SET_SIZE, 256);
then a notification can be set up to report notifications via that queue:
struct watch_notification_filter filter = {
.nr_filters = 1,
.filters = {
[0] = {
.type = WATCH_TYPE_KEY_NOTIFY,
.subtype_filter[0] = UINT_MAX,
},
},
};
ioctl(fds[1], IOC_WATCH_QUEUE_SET_FILTER, &filter);
keyctl_watch_key(KEY_SPEC_SESSION_KEYRING, fds[1], 0x01);
After that, records will be placed into the queue when events occur in
which keys are changed in some way. Records are of the following format:
struct key_notification {
struct watch_notification watch;
__u32 key_id;
__u32 aux;
} *n;
Where:
n->watch.type will be WATCH_TYPE_KEY_NOTIFY.
n->watch.subtype will indicate the type of event, such as
NOTIFY_KEY_REVOKED.
n->watch.info & WATCH_INFO_LENGTH will indicate the length of the
record.
n->watch.info & WATCH_INFO_ID will be the second argument to
keyctl_watch_key(), shifted.
n->key will be the ID of the affected key.
n->aux will hold subtype-dependent information, such as the key
being linked into the keyring specified by n->key in the case of
NOTIFY_KEY_LINKED.
Note that it is permissible for event records to be of variable length -
or, at least, the length may be dependent on the subtype. Note also that
the queue can be shared between multiple notifications of various types.
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: James Morris <jamorris@linux.microsoft.com>
2020-01-14 20:07:11 +03:00
if ( keyring - > restrict_link ) {
2017-03-02 03:44:09 +03:00
ret = - EEXIST ;
watch_queue: Add a key/keyring notification facility
Add a key/keyring change notification facility whereby notifications about
changes in key and keyring content and attributes can be received.
Firstly, an event queue needs to be created:
pipe2(fds, O_NOTIFICATION_PIPE);
ioctl(fds[1], IOC_WATCH_QUEUE_SET_SIZE, 256);
then a notification can be set up to report notifications via that queue:
struct watch_notification_filter filter = {
.nr_filters = 1,
.filters = {
[0] = {
.type = WATCH_TYPE_KEY_NOTIFY,
.subtype_filter[0] = UINT_MAX,
},
},
};
ioctl(fds[1], IOC_WATCH_QUEUE_SET_FILTER, &filter);
keyctl_watch_key(KEY_SPEC_SESSION_KEYRING, fds[1], 0x01);
After that, records will be placed into the queue when events occur in
which keys are changed in some way. Records are of the following format:
struct key_notification {
struct watch_notification watch;
__u32 key_id;
__u32 aux;
} *n;
Where:
n->watch.type will be WATCH_TYPE_KEY_NOTIFY.
n->watch.subtype will indicate the type of event, such as
NOTIFY_KEY_REVOKED.
n->watch.info & WATCH_INFO_LENGTH will indicate the length of the
record.
n->watch.info & WATCH_INFO_ID will be the second argument to
keyctl_watch_key(), shifted.
n->key will be the ID of the affected key.
n->aux will hold subtype-dependent information, such as the key
being linked into the keyring specified by n->key in the case of
NOTIFY_KEY_LINKED.
Note that it is permissible for event records to be of variable length -
or, at least, the length may be dependent on the subtype. Note also that
the queue can be shared between multiple notifications of various types.
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: James Morris <jamorris@linux.microsoft.com>
2020-01-14 20:07:11 +03:00
} else if ( keyring_detect_restriction_cycle ( keyring , restrict_link ) ) {
2017-03-02 03:44:09 +03:00
ret = - EDEADLK ;
watch_queue: Add a key/keyring notification facility
Add a key/keyring change notification facility whereby notifications about
changes in key and keyring content and attributes can be received.
Firstly, an event queue needs to be created:
pipe2(fds, O_NOTIFICATION_PIPE);
ioctl(fds[1], IOC_WATCH_QUEUE_SET_SIZE, 256);
then a notification can be set up to report notifications via that queue:
struct watch_notification_filter filter = {
.nr_filters = 1,
.filters = {
[0] = {
.type = WATCH_TYPE_KEY_NOTIFY,
.subtype_filter[0] = UINT_MAX,
},
},
};
ioctl(fds[1], IOC_WATCH_QUEUE_SET_FILTER, &filter);
keyctl_watch_key(KEY_SPEC_SESSION_KEYRING, fds[1], 0x01);
After that, records will be placed into the queue when events occur in
which keys are changed in some way. Records are of the following format:
struct key_notification {
struct watch_notification watch;
__u32 key_id;
__u32 aux;
} *n;
Where:
n->watch.type will be WATCH_TYPE_KEY_NOTIFY.
n->watch.subtype will indicate the type of event, such as
NOTIFY_KEY_REVOKED.
n->watch.info & WATCH_INFO_LENGTH will indicate the length of the
record.
n->watch.info & WATCH_INFO_ID will be the second argument to
keyctl_watch_key(), shifted.
n->key will be the ID of the affected key.
n->aux will hold subtype-dependent information, such as the key
being linked into the keyring specified by n->key in the case of
NOTIFY_KEY_LINKED.
Note that it is permissible for event records to be of variable length -
or, at least, the length may be dependent on the subtype. Note also that
the queue can be shared between multiple notifications of various types.
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: James Morris <jamorris@linux.microsoft.com>
2020-01-14 20:07:11 +03:00
} else {
2017-03-02 03:44:09 +03:00
keyring - > restrict_link = restrict_link ;
watch_queue: Add a key/keyring notification facility
Add a key/keyring change notification facility whereby notifications about
changes in key and keyring content and attributes can be received.
Firstly, an event queue needs to be created:
pipe2(fds, O_NOTIFICATION_PIPE);
ioctl(fds[1], IOC_WATCH_QUEUE_SET_SIZE, 256);
then a notification can be set up to report notifications via that queue:
struct watch_notification_filter filter = {
.nr_filters = 1,
.filters = {
[0] = {
.type = WATCH_TYPE_KEY_NOTIFY,
.subtype_filter[0] = UINT_MAX,
},
},
};
ioctl(fds[1], IOC_WATCH_QUEUE_SET_FILTER, &filter);
keyctl_watch_key(KEY_SPEC_SESSION_KEYRING, fds[1], 0x01);
After that, records will be placed into the queue when events occur in
which keys are changed in some way. Records are of the following format:
struct key_notification {
struct watch_notification watch;
__u32 key_id;
__u32 aux;
} *n;
Where:
n->watch.type will be WATCH_TYPE_KEY_NOTIFY.
n->watch.subtype will indicate the type of event, such as
NOTIFY_KEY_REVOKED.
n->watch.info & WATCH_INFO_LENGTH will indicate the length of the
record.
n->watch.info & WATCH_INFO_ID will be the second argument to
keyctl_watch_key(), shifted.
n->key will be the ID of the affected key.
n->aux will hold subtype-dependent information, such as the key
being linked into the keyring specified by n->key in the case of
NOTIFY_KEY_LINKED.
Note that it is permissible for event records to be of variable length -
or, at least, the length may be dependent on the subtype. Note also that
the queue can be shared between multiple notifications of various types.
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: James Morris <jamorris@linux.microsoft.com>
2020-01-14 20:07:11 +03:00
notify_key ( keyring , NOTIFY_KEY_SETATTR , 0 ) ;
}
2017-03-02 03:44:09 +03:00
up_write ( & keyring_serialise_restrict_sem ) ;
up_write ( & keyring - > sem ) ;
if ( ret < 0 ) {
key_put ( restrict_link - > key ) ;
kfree ( restrict_link ) ;
}
error :
if ( restrict_type )
key_type_put ( restrict_type ) ;
return ret ;
}
EXPORT_SYMBOL ( keyring_restrict ) ;
2005-04-17 02:20:36 +04:00
/*
2013-09-24 13:35:18 +04:00
* Search the given keyring for a key that might be updated .
2011-01-20 19:38:33 +03:00
*
* The caller must guarantee that the keyring is a keyring and that the
2013-09-24 13:35:18 +04:00
* permission is granted to modify the keyring as no check is made here . The
* caller must also hold a lock on the keyring semaphore .
2011-01-20 19:38:33 +03:00
*
* Returns a pointer to the found key with usage count incremented if
2013-09-24 13:35:18 +04:00
* successful and returns NULL if not found . Revoked and invalidated keys are
* skipped over .
2011-01-20 19:38:33 +03:00
*
* If successful , the possession indicator is propagated from the keyring ref
* to the returned key reference .
2005-04-17 02:20:36 +04:00
*/
2013-09-24 13:35:18 +04:00
key_ref_t find_key_to_update ( key_ref_t keyring_ref ,
const struct keyring_index_key * index_key )
2005-04-17 02:20:36 +04:00
{
2005-09-28 20:03:15 +04:00
struct key * keyring , * key ;
2013-09-24 13:35:18 +04:00
const void * object ;
2005-04-17 02:20:36 +04:00
2005-09-28 20:03:15 +04:00
keyring = key_ref_to_ptr ( keyring_ref ) ;
2013-09-24 13:35:18 +04:00
kenter ( " {%d},{%s,%s} " ,
keyring - > serial , index_key - > type - > name , index_key - > description ) ;
2005-06-24 09:00:49 +04:00
2013-09-24 13:35:18 +04:00
object = assoc_array_find ( & keyring - > keys , & keyring_assoc_array_ops ,
index_key ) ;
2005-04-17 02:20:36 +04:00
2013-09-24 13:35:18 +04:00
if ( object )
goto found ;
kleave ( " = NULL " ) ;
return NULL ;
2005-04-17 02:20:36 +04:00
2010-04-21 11:02:11 +04:00
found :
2013-09-24 13:35:18 +04:00
key = keyring_ptr_to_key ( object ) ;
if ( key - > flags & ( ( 1 < < KEY_FLAG_INVALIDATED ) |
( 1 < < KEY_FLAG_REVOKED ) ) ) {
kleave ( " = NULL [x] " ) ;
return NULL ;
}
2013-09-24 13:35:16 +04:00
__key_get ( key ) ;
2013-09-24 13:35:18 +04:00
kleave ( " = {%d} " , key - > serial ) ;
return make_key_ref ( key , is_key_possessed ( keyring_ref ) ) ;
2011-01-20 19:38:27 +03:00
}
2005-04-17 02:20:36 +04:00
/*
2011-01-20 19:38:33 +03:00
* Find a keyring with the specified name .
*
2019-07-11 04:43:43 +03:00
* Only keyrings that have nonzero refcount , are not revoked , and are owned by a
* user in the current user namespace are considered . If @ uid_keyring is % true ,
* the keyring additionally must have been allocated as a user or user session
* keyring ; otherwise , it must grant Search permission directly to the caller .
2011-01-20 19:38:33 +03:00
*
* Returns a pointer to the keyring with the keyring ' s refcount having being
* incremented on success . - ENOKEY is returned if a key could not be found .
2005-04-17 02:20:36 +04:00
*/
2017-09-18 21:37:03 +03:00
struct key * find_keyring_by_name ( const char * name , bool uid_keyring )
2005-04-17 02:20:36 +04:00
{
2019-06-26 23:02:32 +03:00
struct user_namespace * ns = current_user_ns ( ) ;
2005-04-17 02:20:36 +04:00
struct key * keyring ;
if ( ! name )
KEYS: find_keyring_by_name() can gain access to a freed keyring
find_keyring_by_name() can gain access to a keyring that has had its reference
count reduced to zero, and is thus ready to be freed. This then allows the
dead keyring to be brought back into use whilst it is being destroyed.
The following timeline illustrates the process:
|(cleaner) (user)
|
| free_user(user) sys_keyctl()
| | |
| key_put(user->session_keyring) keyctl_get_keyring_ID()
| || //=> keyring->usage = 0 |
| |schedule_work(&key_cleanup_task) lookup_user_key()
| || |
| kmem_cache_free(,user) |
| . |[KEY_SPEC_USER_KEYRING]
| . install_user_keyrings()
| . ||
| key_cleanup() [<= worker_thread()] ||
| | ||
| [spin_lock(&key_serial_lock)] |[mutex_lock(&key_user_keyr..mutex)]
| | ||
| atomic_read() == 0 ||
| |{ rb_ease(&key->serial_node,) } ||
| | ||
| [spin_unlock(&key_serial_lock)] |find_keyring_by_name()
| | |||
| keyring_destroy(keyring) ||[read_lock(&keyring_name_lock)]
| || |||
| |[write_lock(&keyring_name_lock)] ||atomic_inc(&keyring->usage)
| |. ||| *** GET freeing keyring ***
| |. ||[read_unlock(&keyring_name_lock)]
| || ||
| |list_del() |[mutex_unlock(&key_user_k..mutex)]
| || |
| |[write_unlock(&keyring_name_lock)] ** INVALID keyring is returned **
| | .
| kmem_cache_free(,keyring) .
| .
| atomic_dec(&keyring->usage)
v *** DESTROYED ***
TIME
If CONFIG_SLUB_DEBUG=y then we may see the following message generated:
=============================================================================
BUG key_jar: Poison overwritten
-----------------------------------------------------------------------------
INFO: 0xffff880197a7e200-0xffff880197a7e200. First byte 0x6a instead of 0x6b
INFO: Allocated in key_alloc+0x10b/0x35f age=25 cpu=1 pid=5086
INFO: Freed in key_cleanup+0xd0/0xd5 age=12 cpu=1 pid=10
INFO: Slab 0xffffea000592cb90 objects=16 used=2 fp=0xffff880197a7e200 flags=0x200000000000c3
INFO: Object 0xffff880197a7e200 @offset=512 fp=0xffff880197a7e300
Bytes b4 0xffff880197a7e1f0: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZZZZZ
Object 0xffff880197a7e200: 6a 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b jkkkkkkkkkkkkkkk
Alternatively, we may see a system panic happen, such as:
BUG: unable to handle kernel NULL pointer dereference at 0000000000000001
IP: [<ffffffff810e61a3>] kmem_cache_alloc+0x5b/0xe9
PGD 6b2b4067 PUD 6a80d067 PMD 0
Oops: 0000 [#1] SMP
last sysfs file: /sys/kernel/kexec_crash_loaded
CPU 1
...
Pid: 31245, comm: su Not tainted 2.6.34-rc5-nofixed-nodebug #2 D2089/PRIMERGY
RIP: 0010:[<ffffffff810e61a3>] [<ffffffff810e61a3>] kmem_cache_alloc+0x5b/0xe9
RSP: 0018:ffff88006af3bd98 EFLAGS: 00010002
RAX: 0000000000000000 RBX: 0000000000000001 RCX: ffff88007d19900b
RDX: 0000000100000000 RSI: 00000000000080d0 RDI: ffffffff81828430
RBP: ffffffff81828430 R08: ffff88000a293750 R09: 0000000000000000
R10: 0000000000000001 R11: 0000000000100000 R12: 00000000000080d0
R13: 00000000000080d0 R14: 0000000000000296 R15: ffffffff810f20ce
FS: 00007f97116bc700(0000) GS:ffff88000a280000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000001 CR3: 000000006a91c000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process su (pid: 31245, threadinfo ffff88006af3a000, task ffff8800374414c0)
Stack:
0000000512e0958e 0000000000008000 ffff880037f8d180 0000000000000001
0000000000000000 0000000000008001 ffff88007d199000 ffffffff810f20ce
0000000000008000 ffff88006af3be48 0000000000000024 ffffffff810face3
Call Trace:
[<ffffffff810f20ce>] ? get_empty_filp+0x70/0x12f
[<ffffffff810face3>] ? do_filp_open+0x145/0x590
[<ffffffff810ce208>] ? tlb_finish_mmu+0x2a/0x33
[<ffffffff810ce43c>] ? unmap_region+0xd3/0xe2
[<ffffffff810e4393>] ? virt_to_head_page+0x9/0x2d
[<ffffffff81103916>] ? alloc_fd+0x69/0x10e
[<ffffffff810ef4ed>] ? do_sys_open+0x56/0xfc
[<ffffffff81008a02>] ? system_call_fastpath+0x16/0x1b
Code: 0f 1f 44 00 00 49 89 c6 fa 66 0f 1f 44 00 00 65 4c 8b 04 25 60 e8 00 00 48 8b 45 00 49 01 c0 49 8b 18 48 85 db 74 0d 48 63 45 18 <48> 8b 04 03 49 89 00 eb 14 4c 89 f9 83 ca ff 44 89 e6 48 89 ef
RIP [<ffffffff810e61a3>] kmem_cache_alloc+0x5b/0xe9
This problem is that find_keyring_by_name does not confirm that the keyring is
valid before accepting it.
Skipping keyrings that have been reduced to a zero count seems the way to go.
To this end, use atomic_inc_not_zero() to increment the usage count and skip
the candidate keyring if that returns false.
The following script _may_ cause the bug to happen, but there's no guarantee
as the window of opportunity is small:
#!/bin/sh
LOOP=100000
USER=dummy_user
/bin/su -c "exit;" $USER || { /usr/sbin/adduser -m $USER; add=1; }
for ((i=0; i<LOOP; i++))
do
/bin/su -c "echo '$i' > /dev/null" $USER
done
(( add == 1 )) && /usr/sbin/userdel -r $USER
exit
Note that the nominated user must not be in use.
An alternative way of testing this may be:
for ((i=0; i<100000; i++))
do
keyctl session foo /bin/true || break
done >&/dev/null
as that uses a keyring named "foo" rather than relying on the user and
user-session named keyrings.
Reported-by: Toshiyuki Okajima <toshi.okajima@jp.fujitsu.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Tested-by: Toshiyuki Okajima <toshi.okajima@jp.fujitsu.com>
Acked-by: Serge Hallyn <serue@us.ibm.com>
Signed-off-by: James Morris <jmorris@namei.org>
2010-04-30 17:32:13 +04:00
return ERR_PTR ( - EINVAL ) ;
2005-04-17 02:20:36 +04:00
read_lock ( & keyring_name_lock ) ;
2019-06-26 23:02:32 +03:00
/* Search this hash bucket for a keyring with a matching name that
* grants Search permission and that hasn ' t been revoked
*/
list_for_each_entry ( keyring , & ns - > keyring_name_list , name_link ) {
if ( ! kuid_has_mapping ( ns , keyring - > user - > uid ) )
continue ;
2005-04-17 02:20:36 +04:00
2019-06-26 23:02:32 +03:00
if ( test_bit ( KEY_FLAG_REVOKED , & keyring - > flags ) )
continue ;
2005-04-17 02:20:36 +04:00
2019-06-26 23:02:32 +03:00
if ( strcmp ( keyring - > description , name ) ! = 0 )
continue ;
2005-04-17 02:20:36 +04:00
2019-06-26 23:02:32 +03:00
if ( uid_keyring ) {
if ( ! test_bit ( KEY_FLAG_UID_KEYRING ,
& keyring - > flags ) )
continue ;
} else {
if ( key_permission ( make_key_ref ( keyring , 0 ) ,
2019-07-11 04:43:43 +03:00
KEY_NEED_SEARCH ) < 0 )
KEYS: find_keyring_by_name() can gain access to a freed keyring
find_keyring_by_name() can gain access to a keyring that has had its reference
count reduced to zero, and is thus ready to be freed. This then allows the
dead keyring to be brought back into use whilst it is being destroyed.
The following timeline illustrates the process:
|(cleaner) (user)
|
| free_user(user) sys_keyctl()
| | |
| key_put(user->session_keyring) keyctl_get_keyring_ID()
| || //=> keyring->usage = 0 |
| |schedule_work(&key_cleanup_task) lookup_user_key()
| || |
| kmem_cache_free(,user) |
| . |[KEY_SPEC_USER_KEYRING]
| . install_user_keyrings()
| . ||
| key_cleanup() [<= worker_thread()] ||
| | ||
| [spin_lock(&key_serial_lock)] |[mutex_lock(&key_user_keyr..mutex)]
| | ||
| atomic_read() == 0 ||
| |{ rb_ease(&key->serial_node,) } ||
| | ||
| [spin_unlock(&key_serial_lock)] |find_keyring_by_name()
| | |||
| keyring_destroy(keyring) ||[read_lock(&keyring_name_lock)]
| || |||
| |[write_lock(&keyring_name_lock)] ||atomic_inc(&keyring->usage)
| |. ||| *** GET freeing keyring ***
| |. ||[read_unlock(&keyring_name_lock)]
| || ||
| |list_del() |[mutex_unlock(&key_user_k..mutex)]
| || |
| |[write_unlock(&keyring_name_lock)] ** INVALID keyring is returned **
| | .
| kmem_cache_free(,keyring) .
| .
| atomic_dec(&keyring->usage)
v *** DESTROYED ***
TIME
If CONFIG_SLUB_DEBUG=y then we may see the following message generated:
=============================================================================
BUG key_jar: Poison overwritten
-----------------------------------------------------------------------------
INFO: 0xffff880197a7e200-0xffff880197a7e200. First byte 0x6a instead of 0x6b
INFO: Allocated in key_alloc+0x10b/0x35f age=25 cpu=1 pid=5086
INFO: Freed in key_cleanup+0xd0/0xd5 age=12 cpu=1 pid=10
INFO: Slab 0xffffea000592cb90 objects=16 used=2 fp=0xffff880197a7e200 flags=0x200000000000c3
INFO: Object 0xffff880197a7e200 @offset=512 fp=0xffff880197a7e300
Bytes b4 0xffff880197a7e1f0: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZZZZZ
Object 0xffff880197a7e200: 6a 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b jkkkkkkkkkkkkkkk
Alternatively, we may see a system panic happen, such as:
BUG: unable to handle kernel NULL pointer dereference at 0000000000000001
IP: [<ffffffff810e61a3>] kmem_cache_alloc+0x5b/0xe9
PGD 6b2b4067 PUD 6a80d067 PMD 0
Oops: 0000 [#1] SMP
last sysfs file: /sys/kernel/kexec_crash_loaded
CPU 1
...
Pid: 31245, comm: su Not tainted 2.6.34-rc5-nofixed-nodebug #2 D2089/PRIMERGY
RIP: 0010:[<ffffffff810e61a3>] [<ffffffff810e61a3>] kmem_cache_alloc+0x5b/0xe9
RSP: 0018:ffff88006af3bd98 EFLAGS: 00010002
RAX: 0000000000000000 RBX: 0000000000000001 RCX: ffff88007d19900b
RDX: 0000000100000000 RSI: 00000000000080d0 RDI: ffffffff81828430
RBP: ffffffff81828430 R08: ffff88000a293750 R09: 0000000000000000
R10: 0000000000000001 R11: 0000000000100000 R12: 00000000000080d0
R13: 00000000000080d0 R14: 0000000000000296 R15: ffffffff810f20ce
FS: 00007f97116bc700(0000) GS:ffff88000a280000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000001 CR3: 000000006a91c000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process su (pid: 31245, threadinfo ffff88006af3a000, task ffff8800374414c0)
Stack:
0000000512e0958e 0000000000008000 ffff880037f8d180 0000000000000001
0000000000000000 0000000000008001 ffff88007d199000 ffffffff810f20ce
0000000000008000 ffff88006af3be48 0000000000000024 ffffffff810face3
Call Trace:
[<ffffffff810f20ce>] ? get_empty_filp+0x70/0x12f
[<ffffffff810face3>] ? do_filp_open+0x145/0x590
[<ffffffff810ce208>] ? tlb_finish_mmu+0x2a/0x33
[<ffffffff810ce43c>] ? unmap_region+0xd3/0xe2
[<ffffffff810e4393>] ? virt_to_head_page+0x9/0x2d
[<ffffffff81103916>] ? alloc_fd+0x69/0x10e
[<ffffffff810ef4ed>] ? do_sys_open+0x56/0xfc
[<ffffffff81008a02>] ? system_call_fastpath+0x16/0x1b
Code: 0f 1f 44 00 00 49 89 c6 fa 66 0f 1f 44 00 00 65 4c 8b 04 25 60 e8 00 00 48 8b 45 00 49 01 c0 49 8b 18 48 85 db 74 0d 48 63 45 18 <48> 8b 04 03 49 89 00 eb 14 4c 89 f9 83 ca ff 44 89 e6 48 89 ef
RIP [<ffffffff810e61a3>] kmem_cache_alloc+0x5b/0xe9
This problem is that find_keyring_by_name does not confirm that the keyring is
valid before accepting it.
Skipping keyrings that have been reduced to a zero count seems the way to go.
To this end, use atomic_inc_not_zero() to increment the usage count and skip
the candidate keyring if that returns false.
The following script _may_ cause the bug to happen, but there's no guarantee
as the window of opportunity is small:
#!/bin/sh
LOOP=100000
USER=dummy_user
/bin/su -c "exit;" $USER || { /usr/sbin/adduser -m $USER; add=1; }
for ((i=0; i<LOOP; i++))
do
/bin/su -c "echo '$i' > /dev/null" $USER
done
(( add == 1 )) && /usr/sbin/userdel -r $USER
exit
Note that the nominated user must not be in use.
An alternative way of testing this may be:
for ((i=0; i<100000; i++))
do
keyctl session foo /bin/true || break
done >&/dev/null
as that uses a keyring named "foo" rather than relying on the user and
user-session named keyrings.
Reported-by: Toshiyuki Okajima <toshi.okajima@jp.fujitsu.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Tested-by: Toshiyuki Okajima <toshi.okajima@jp.fujitsu.com>
Acked-by: Serge Hallyn <serue@us.ibm.com>
Signed-off-by: James Morris <jmorris@namei.org>
2010-04-30 17:32:13 +04:00
continue ;
2005-04-17 02:20:36 +04:00
}
2019-06-26 23:02:32 +03:00
/* we've got a match but we might end up racing with
* key_cleanup ( ) if the keyring is currently ' dead '
* ( ie . it has a zero usage count ) */
if ( ! refcount_inc_not_zero ( & keyring - > usage ) )
continue ;
keyring - > last_used_at = ktime_get_real_seconds ( ) ;
goto out ;
2005-04-17 02:20:36 +04:00
}
keyring = ERR_PTR ( - ENOKEY ) ;
KEYS: find_keyring_by_name() can gain access to a freed keyring
find_keyring_by_name() can gain access to a keyring that has had its reference
count reduced to zero, and is thus ready to be freed. This then allows the
dead keyring to be brought back into use whilst it is being destroyed.
The following timeline illustrates the process:
|(cleaner) (user)
|
| free_user(user) sys_keyctl()
| | |
| key_put(user->session_keyring) keyctl_get_keyring_ID()
| || //=> keyring->usage = 0 |
| |schedule_work(&key_cleanup_task) lookup_user_key()
| || |
| kmem_cache_free(,user) |
| . |[KEY_SPEC_USER_KEYRING]
| . install_user_keyrings()
| . ||
| key_cleanup() [<= worker_thread()] ||
| | ||
| [spin_lock(&key_serial_lock)] |[mutex_lock(&key_user_keyr..mutex)]
| | ||
| atomic_read() == 0 ||
| |{ rb_ease(&key->serial_node,) } ||
| | ||
| [spin_unlock(&key_serial_lock)] |find_keyring_by_name()
| | |||
| keyring_destroy(keyring) ||[read_lock(&keyring_name_lock)]
| || |||
| |[write_lock(&keyring_name_lock)] ||atomic_inc(&keyring->usage)
| |. ||| *** GET freeing keyring ***
| |. ||[read_unlock(&keyring_name_lock)]
| || ||
| |list_del() |[mutex_unlock(&key_user_k..mutex)]
| || |
| |[write_unlock(&keyring_name_lock)] ** INVALID keyring is returned **
| | .
| kmem_cache_free(,keyring) .
| .
| atomic_dec(&keyring->usage)
v *** DESTROYED ***
TIME
If CONFIG_SLUB_DEBUG=y then we may see the following message generated:
=============================================================================
BUG key_jar: Poison overwritten
-----------------------------------------------------------------------------
INFO: 0xffff880197a7e200-0xffff880197a7e200. First byte 0x6a instead of 0x6b
INFO: Allocated in key_alloc+0x10b/0x35f age=25 cpu=1 pid=5086
INFO: Freed in key_cleanup+0xd0/0xd5 age=12 cpu=1 pid=10
INFO: Slab 0xffffea000592cb90 objects=16 used=2 fp=0xffff880197a7e200 flags=0x200000000000c3
INFO: Object 0xffff880197a7e200 @offset=512 fp=0xffff880197a7e300
Bytes b4 0xffff880197a7e1f0: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZZZZZ
Object 0xffff880197a7e200: 6a 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b jkkkkkkkkkkkkkkk
Alternatively, we may see a system panic happen, such as:
BUG: unable to handle kernel NULL pointer dereference at 0000000000000001
IP: [<ffffffff810e61a3>] kmem_cache_alloc+0x5b/0xe9
PGD 6b2b4067 PUD 6a80d067 PMD 0
Oops: 0000 [#1] SMP
last sysfs file: /sys/kernel/kexec_crash_loaded
CPU 1
...
Pid: 31245, comm: su Not tainted 2.6.34-rc5-nofixed-nodebug #2 D2089/PRIMERGY
RIP: 0010:[<ffffffff810e61a3>] [<ffffffff810e61a3>] kmem_cache_alloc+0x5b/0xe9
RSP: 0018:ffff88006af3bd98 EFLAGS: 00010002
RAX: 0000000000000000 RBX: 0000000000000001 RCX: ffff88007d19900b
RDX: 0000000100000000 RSI: 00000000000080d0 RDI: ffffffff81828430
RBP: ffffffff81828430 R08: ffff88000a293750 R09: 0000000000000000
R10: 0000000000000001 R11: 0000000000100000 R12: 00000000000080d0
R13: 00000000000080d0 R14: 0000000000000296 R15: ffffffff810f20ce
FS: 00007f97116bc700(0000) GS:ffff88000a280000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000001 CR3: 000000006a91c000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process su (pid: 31245, threadinfo ffff88006af3a000, task ffff8800374414c0)
Stack:
0000000512e0958e 0000000000008000 ffff880037f8d180 0000000000000001
0000000000000000 0000000000008001 ffff88007d199000 ffffffff810f20ce
0000000000008000 ffff88006af3be48 0000000000000024 ffffffff810face3
Call Trace:
[<ffffffff810f20ce>] ? get_empty_filp+0x70/0x12f
[<ffffffff810face3>] ? do_filp_open+0x145/0x590
[<ffffffff810ce208>] ? tlb_finish_mmu+0x2a/0x33
[<ffffffff810ce43c>] ? unmap_region+0xd3/0xe2
[<ffffffff810e4393>] ? virt_to_head_page+0x9/0x2d
[<ffffffff81103916>] ? alloc_fd+0x69/0x10e
[<ffffffff810ef4ed>] ? do_sys_open+0x56/0xfc
[<ffffffff81008a02>] ? system_call_fastpath+0x16/0x1b
Code: 0f 1f 44 00 00 49 89 c6 fa 66 0f 1f 44 00 00 65 4c 8b 04 25 60 e8 00 00 48 8b 45 00 49 01 c0 49 8b 18 48 85 db 74 0d 48 63 45 18 <48> 8b 04 03 49 89 00 eb 14 4c 89 f9 83 ca ff 44 89 e6 48 89 ef
RIP [<ffffffff810e61a3>] kmem_cache_alloc+0x5b/0xe9
This problem is that find_keyring_by_name does not confirm that the keyring is
valid before accepting it.
Skipping keyrings that have been reduced to a zero count seems the way to go.
To this end, use atomic_inc_not_zero() to increment the usage count and skip
the candidate keyring if that returns false.
The following script _may_ cause the bug to happen, but there's no guarantee
as the window of opportunity is small:
#!/bin/sh
LOOP=100000
USER=dummy_user
/bin/su -c "exit;" $USER || { /usr/sbin/adduser -m $USER; add=1; }
for ((i=0; i<LOOP; i++))
do
/bin/su -c "echo '$i' > /dev/null" $USER
done
(( add == 1 )) && /usr/sbin/userdel -r $USER
exit
Note that the nominated user must not be in use.
An alternative way of testing this may be:
for ((i=0; i<100000; i++))
do
keyctl session foo /bin/true || break
done >&/dev/null
as that uses a keyring named "foo" rather than relying on the user and
user-session named keyrings.
Reported-by: Toshiyuki Okajima <toshi.okajima@jp.fujitsu.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Tested-by: Toshiyuki Okajima <toshi.okajima@jp.fujitsu.com>
Acked-by: Serge Hallyn <serue@us.ibm.com>
Signed-off-by: James Morris <jmorris@namei.org>
2010-04-30 17:32:13 +04:00
out :
read_unlock ( & keyring_name_lock ) ;
2005-04-17 02:20:36 +04:00
return keyring ;
2011-01-20 19:38:27 +03:00
}
2005-04-17 02:20:36 +04:00
2013-09-24 13:35:18 +04:00
static int keyring_detect_cycle_iterator ( const void * object ,
void * iterator_data )
{
struct keyring_search_context * ctx = iterator_data ;
const struct key * key = keyring_ptr_to_key ( object ) ;
kenter ( " {%d} " , key - > serial ) ;
2014-03-09 12:21:58 +04:00
/* We might get a keyring with matching index-key that is nonetheless a
* different keyring . */
2014-09-16 20:36:02 +04:00
if ( key ! = ctx - > match_data . raw_data )
2014-03-09 12:21:58 +04:00
return 0 ;
2013-09-24 13:35:18 +04:00
ctx - > result = ERR_PTR ( - EDEADLK ) ;
return 1 ;
}
2005-04-17 02:20:36 +04:00
/*
2020-08-07 19:51:23 +03:00
* See if a cycle will be created by inserting acyclic tree B in acyclic
2011-01-20 19:38:33 +03:00
* tree A at the topmost level ( ie : as a direct child of A ) .
*
* Since we are adding B to A at the top level , checking for cycles should just
* be a matter of seeing if node A is somewhere in tree B .
2005-04-17 02:20:36 +04:00
*/
static int keyring_detect_cycle ( struct key * A , struct key * B )
{
2013-09-24 13:35:18 +04:00
struct keyring_search_context ctx = {
2014-09-16 20:36:02 +04:00
. index_key = A - > index_key ,
. match_data . raw_data = A ,
. match_data . lookup_type = KEYRING_SEARCH_LOOKUP_DIRECT ,
. iterator = keyring_detect_cycle_iterator ,
. flags = ( KEYRING_SEARCH_NO_STATE_CHECK |
KEYRING_SEARCH_NO_UPDATE_TIME |
KEYRING_SEARCH_NO_CHECK_PERM |
2019-06-26 23:02:32 +03:00
KEYRING_SEARCH_DETECT_TOO_DEEP |
KEYRING_SEARCH_RECURSE ) ,
2013-09-24 13:35:18 +04:00
} ;
2005-04-17 02:20:36 +04:00
2005-06-24 09:00:49 +04:00
rcu_read_lock ( ) ;
2013-09-24 13:35:18 +04:00
search_nested_keyrings ( B , & ctx ) ;
2005-06-24 09:00:49 +04:00
rcu_read_unlock ( ) ;
2013-09-24 13:35:18 +04:00
return PTR_ERR ( ctx . result ) = = - EAGAIN ? 0 : PTR_ERR ( ctx . result ) ;
2010-04-30 17:32:39 +04:00
}
2006-01-08 12:02:45 +03:00
2019-05-30 13:37:39 +03:00
/*
* Lock keyring for link .
*/
int __key_link_lock ( struct key * keyring ,
const struct keyring_index_key * index_key )
__acquires ( & keyring - > sem )
__acquires ( & keyring_serialise_link_lock )
{
if ( keyring - > type ! = & key_type_keyring )
return - ENOTDIR ;
down_write ( & keyring - > sem ) ;
/* Serialise link/link calls to prevent parallel calls causing a cycle
* when linking two keyring in opposite orders .
*/
if ( index_key - > type = = & key_type_keyring )
mutex_lock ( & keyring_serialise_link_lock ) ;
return 0 ;
}
2019-05-20 23:51:50 +03:00
/*
* Lock keyrings for move ( link / unlink combination ) .
*/
int __key_move_lock ( struct key * l_keyring , struct key * u_keyring ,
const struct keyring_index_key * index_key )
__acquires ( & l_keyring - > sem )
__acquires ( & u_keyring - > sem )
__acquires ( & keyring_serialise_link_lock )
{
if ( l_keyring - > type ! = & key_type_keyring | |
u_keyring - > type ! = & key_type_keyring )
return - ENOTDIR ;
/* We have to be very careful here to take the keyring locks in the
* right order , lest we open ourselves to deadlocking against another
* move operation .
*/
if ( l_keyring < u_keyring ) {
down_write ( & l_keyring - > sem ) ;
down_write_nested ( & u_keyring - > sem , 1 ) ;
} else {
down_write ( & u_keyring - > sem ) ;
down_write_nested ( & l_keyring - > sem , 1 ) ;
}
/* Serialise link/link calls to prevent parallel calls causing a cycle
* when linking two keyring in opposite orders .
*/
if ( index_key - > type = = & key_type_keyring )
mutex_lock ( & keyring_serialise_link_lock ) ;
return 0 ;
}
2005-04-17 02:20:36 +04:00
/*
2011-01-20 19:38:33 +03:00
* Preallocate memory so that a key can be linked into to a keyring .
2005-04-17 02:20:36 +04:00
*/
2013-09-24 13:35:18 +04:00
int __key_link_begin ( struct key * keyring ,
const struct keyring_index_key * index_key ,
struct assoc_array_edit * * _edit )
2005-04-17 02:20:36 +04:00
{
2013-09-24 13:35:18 +04:00
struct assoc_array_edit * edit ;
int ret ;
2005-04-17 02:20:36 +04:00
2013-09-24 13:35:15 +04:00
kenter ( " %d,%s,%s, " ,
2013-09-24 13:35:18 +04:00
keyring - > serial , index_key - > type - > name , index_key - > description ) ;
BUG_ON ( index_key - > desc_len = = 0 ) ;
2019-05-30 13:37:39 +03:00
BUG_ON ( * _edit ! = NULL ) ;
2005-04-17 02:20:36 +04:00
2019-05-30 13:37:39 +03:00
* _edit = NULL ;
2010-04-30 17:32:39 +04:00
ret = - EKEYREVOKED ;
if ( test_bit ( KEY_FLAG_REVOKED , & keyring - > flags ) )
2019-05-30 13:37:39 +03:00
goto error ;
2010-04-30 17:32:28 +04:00
2013-09-24 13:35:18 +04:00
/* Create an edit script that will insert/replace the key in the
* keyring tree .
*/
edit = assoc_array_insert ( & keyring - > keys ,
& keyring_assoc_array_ops ,
index_key ,
NULL ) ;
if ( IS_ERR ( edit ) ) {
ret = PTR_ERR ( edit ) ;
2019-05-30 13:37:39 +03:00
goto error ;
2013-10-30 15:15:24 +04:00
}
/* If we're not replacing a link in-place then we're going to need some
* extra quota .
*/
if ( ! edit - > dead_leaf ) {
ret = key_payload_reserve ( keyring ,
keyring - > datalen + KEYQUOTA_LINK_BYTES ) ;
if ( ret < 0 )
goto error_cancel ;
2005-04-17 02:20:36 +04:00
}
2013-09-24 13:35:18 +04:00
* _edit = edit ;
2010-04-30 17:32:39 +04:00
kleave ( " = 0 " ) ;
return 0 ;
2005-04-17 02:20:36 +04:00
2013-10-30 15:15:24 +04:00
error_cancel :
assoc_array_cancel_edit ( edit ) ;
2019-05-30 13:37:39 +03:00
error :
2010-04-30 17:32:39 +04:00
kleave ( " = %d " , ret ) ;
return ret ;
}
2005-04-17 02:20:36 +04:00
2010-04-30 17:32:39 +04:00
/*
2011-01-20 19:38:33 +03:00
* Check already instantiated keys aren ' t going to be a problem .
*
* The caller must have called __key_link_begin ( ) . Don ' t need to call this for
* keys that were created since __key_link_begin ( ) was called .
2010-04-30 17:32:39 +04:00
*/
int __key_link_check_live_key ( struct key * keyring , struct key * key )
{
if ( key - > type = = & key_type_keyring )
/* check that we aren't going to create a cycle by linking one
* keyring to another */
return keyring_detect_cycle ( keyring , key ) ;
return 0 ;
}
/*
2011-01-20 19:38:33 +03:00
* Link a key into to a keyring .
*
* Must be called with __key_link_begin ( ) having being called . Discards any
* already extant link to matching key if there is one , so that each keyring
* holds at most one link to any given key of a particular type + description
* combination .
2010-04-30 17:32:39 +04:00
*/
watch_queue: Add a key/keyring notification facility
Add a key/keyring change notification facility whereby notifications about
changes in key and keyring content and attributes can be received.
Firstly, an event queue needs to be created:
pipe2(fds, O_NOTIFICATION_PIPE);
ioctl(fds[1], IOC_WATCH_QUEUE_SET_SIZE, 256);
then a notification can be set up to report notifications via that queue:
struct watch_notification_filter filter = {
.nr_filters = 1,
.filters = {
[0] = {
.type = WATCH_TYPE_KEY_NOTIFY,
.subtype_filter[0] = UINT_MAX,
},
},
};
ioctl(fds[1], IOC_WATCH_QUEUE_SET_FILTER, &filter);
keyctl_watch_key(KEY_SPEC_SESSION_KEYRING, fds[1], 0x01);
After that, records will be placed into the queue when events occur in
which keys are changed in some way. Records are of the following format:
struct key_notification {
struct watch_notification watch;
__u32 key_id;
__u32 aux;
} *n;
Where:
n->watch.type will be WATCH_TYPE_KEY_NOTIFY.
n->watch.subtype will indicate the type of event, such as
NOTIFY_KEY_REVOKED.
n->watch.info & WATCH_INFO_LENGTH will indicate the length of the
record.
n->watch.info & WATCH_INFO_ID will be the second argument to
keyctl_watch_key(), shifted.
n->key will be the ID of the affected key.
n->aux will hold subtype-dependent information, such as the key
being linked into the keyring specified by n->key in the case of
NOTIFY_KEY_LINKED.
Note that it is permissible for event records to be of variable length -
or, at least, the length may be dependent on the subtype. Note also that
the queue can be shared between multiple notifications of various types.
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: James Morris <jamorris@linux.microsoft.com>
2020-01-14 20:07:11 +03:00
void __key_link ( struct key * keyring , struct key * key ,
struct assoc_array_edit * * _edit )
2010-04-30 17:32:39 +04:00
{
2013-09-24 13:35:16 +04:00
__key_get ( key ) ;
2013-09-24 13:35:18 +04:00
assoc_array_insert_set_object ( * _edit , keyring_key_to_ptr ( key ) ) ;
assoc_array_apply_edit ( * _edit ) ;
* _edit = NULL ;
watch_queue: Add a key/keyring notification facility
Add a key/keyring change notification facility whereby notifications about
changes in key and keyring content and attributes can be received.
Firstly, an event queue needs to be created:
pipe2(fds, O_NOTIFICATION_PIPE);
ioctl(fds[1], IOC_WATCH_QUEUE_SET_SIZE, 256);
then a notification can be set up to report notifications via that queue:
struct watch_notification_filter filter = {
.nr_filters = 1,
.filters = {
[0] = {
.type = WATCH_TYPE_KEY_NOTIFY,
.subtype_filter[0] = UINT_MAX,
},
},
};
ioctl(fds[1], IOC_WATCH_QUEUE_SET_FILTER, &filter);
keyctl_watch_key(KEY_SPEC_SESSION_KEYRING, fds[1], 0x01);
After that, records will be placed into the queue when events occur in
which keys are changed in some way. Records are of the following format:
struct key_notification {
struct watch_notification watch;
__u32 key_id;
__u32 aux;
} *n;
Where:
n->watch.type will be WATCH_TYPE_KEY_NOTIFY.
n->watch.subtype will indicate the type of event, such as
NOTIFY_KEY_REVOKED.
n->watch.info & WATCH_INFO_LENGTH will indicate the length of the
record.
n->watch.info & WATCH_INFO_ID will be the second argument to
keyctl_watch_key(), shifted.
n->key will be the ID of the affected key.
n->aux will hold subtype-dependent information, such as the key
being linked into the keyring specified by n->key in the case of
NOTIFY_KEY_LINKED.
Note that it is permissible for event records to be of variable length -
or, at least, the length may be dependent on the subtype. Note also that
the queue can be shared between multiple notifications of various types.
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: James Morris <jamorris@linux.microsoft.com>
2020-01-14 20:07:11 +03:00
notify_key ( keyring , NOTIFY_KEY_LINKED , key_serial ( key ) ) ;
2010-04-30 17:32:39 +04:00
}
/*
2011-01-20 19:38:33 +03:00
* Finish linking a key into to a keyring .
*
* Must be called with __key_link_begin ( ) having being called .
2010-04-30 17:32:39 +04:00
*/
2013-09-24 13:35:15 +04:00
void __key_link_end ( struct key * keyring ,
const struct keyring_index_key * index_key ,
2013-09-24 13:35:18 +04:00
struct assoc_array_edit * edit )
2010-04-30 17:32:39 +04:00
__releases ( & keyring - > sem )
2019-05-30 13:40:24 +03:00
__releases ( & keyring_serialise_link_lock )
2010-04-30 17:32:39 +04:00
{
2013-09-24 13:35:15 +04:00
BUG_ON ( index_key - > type = = NULL ) ;
2013-09-24 13:35:18 +04:00
kenter ( " %d,%s, " , keyring - > serial , index_key - > type - > name ) ;
2010-04-30 17:32:39 +04:00
2015-07-27 17:23:43 +03:00
if ( edit ) {
if ( ! edit - > dead_leaf ) {
key_payload_reserve ( keyring ,
keyring - > datalen - KEYQUOTA_LINK_BYTES ) ;
}
2013-09-24 13:35:18 +04:00
assoc_array_cancel_edit ( edit ) ;
2010-04-30 17:32:39 +04:00
}
up_write ( & keyring - > sem ) ;
2019-05-30 13:37:39 +03:00
if ( index_key - > type = = & key_type_keyring )
mutex_unlock ( & keyring_serialise_link_lock ) ;
2010-04-30 17:32:39 +04:00
}
2005-04-17 02:20:36 +04:00
KEYS: Add a facility to restrict new links into a keyring
Add a facility whereby proposed new links to be added to a keyring can be
vetted, permitting them to be rejected if necessary. This can be used to
block public keys from which the signature cannot be verified or for which
the signature verification fails. It could also be used to provide
blacklisting.
This affects operations like add_key(), KEYCTL_LINK and KEYCTL_INSTANTIATE.
To this end:
(1) A function pointer is added to the key struct that, if set, points to
the vetting function. This is called as:
int (*restrict_link)(struct key *keyring,
const struct key_type *key_type,
unsigned long key_flags,
const union key_payload *key_payload),
where 'keyring' will be the keyring being added to, key_type and
key_payload will describe the key being added and key_flags[*] can be
AND'ed with KEY_FLAG_TRUSTED.
[*] This parameter will be removed in a later patch when
KEY_FLAG_TRUSTED is removed.
The function should return 0 to allow the link to take place or an
error (typically -ENOKEY, -ENOPKG or -EKEYREJECTED) to reject the
link.
The pointer should not be set directly, but rather should be set
through keyring_alloc().
Note that if called during add_key(), preparse is called before this
method, but a key isn't actually allocated until after this function
is called.
(2) KEY_ALLOC_BYPASS_RESTRICTION is added. This can be passed to
key_create_or_update() or key_instantiate_and_link() to bypass the
restriction check.
(3) KEY_FLAG_TRUSTED_ONLY is removed. The entire contents of a keyring
with this restriction emplaced can be considered 'trustworthy' by
virtue of being in the keyring when that keyring is consulted.
(4) key_alloc() and keyring_alloc() take an extra argument that will be
used to set restrict_link in the new key. This ensures that the
pointer is set before the key is published, thus preventing a window
of unrestrictedness. Normally this argument will be NULL.
(5) As a temporary affair, keyring_restrict_trusted_only() is added. It
should be passed to keyring_alloc() as the extra argument instead of
setting KEY_FLAG_TRUSTED_ONLY on a keyring. This will be replaced in
a later patch with functions that look in the appropriate places for
authoritative keys.
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
2016-04-06 18:14:24 +03:00
/*
* Check addition of keys to restricted keyrings .
*/
static int __key_link_check_restriction ( struct key * keyring , struct key * key )
{
2016-09-01 02:05:43 +03:00
if ( ! keyring - > restrict_link | | ! keyring - > restrict_link - > check )
KEYS: Add a facility to restrict new links into a keyring
Add a facility whereby proposed new links to be added to a keyring can be
vetted, permitting them to be rejected if necessary. This can be used to
block public keys from which the signature cannot be verified or for which
the signature verification fails. It could also be used to provide
blacklisting.
This affects operations like add_key(), KEYCTL_LINK and KEYCTL_INSTANTIATE.
To this end:
(1) A function pointer is added to the key struct that, if set, points to
the vetting function. This is called as:
int (*restrict_link)(struct key *keyring,
const struct key_type *key_type,
unsigned long key_flags,
const union key_payload *key_payload),
where 'keyring' will be the keyring being added to, key_type and
key_payload will describe the key being added and key_flags[*] can be
AND'ed with KEY_FLAG_TRUSTED.
[*] This parameter will be removed in a later patch when
KEY_FLAG_TRUSTED is removed.
The function should return 0 to allow the link to take place or an
error (typically -ENOKEY, -ENOPKG or -EKEYREJECTED) to reject the
link.
The pointer should not be set directly, but rather should be set
through keyring_alloc().
Note that if called during add_key(), preparse is called before this
method, but a key isn't actually allocated until after this function
is called.
(2) KEY_ALLOC_BYPASS_RESTRICTION is added. This can be passed to
key_create_or_update() or key_instantiate_and_link() to bypass the
restriction check.
(3) KEY_FLAG_TRUSTED_ONLY is removed. The entire contents of a keyring
with this restriction emplaced can be considered 'trustworthy' by
virtue of being in the keyring when that keyring is consulted.
(4) key_alloc() and keyring_alloc() take an extra argument that will be
used to set restrict_link in the new key. This ensures that the
pointer is set before the key is published, thus preventing a window
of unrestrictedness. Normally this argument will be NULL.
(5) As a temporary affair, keyring_restrict_trusted_only() is added. It
should be passed to keyring_alloc() as the extra argument instead of
setting KEY_FLAG_TRUSTED_ONLY on a keyring. This will be replaced in
a later patch with functions that look in the appropriate places for
authoritative keys.
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
2016-04-06 18:14:24 +03:00
return 0 ;
2016-09-01 02:05:43 +03:00
return keyring - > restrict_link - > check ( keyring , key - > type , & key - > payload ,
keyring - > restrict_link - > key ) ;
KEYS: Add a facility to restrict new links into a keyring
Add a facility whereby proposed new links to be added to a keyring can be
vetted, permitting them to be rejected if necessary. This can be used to
block public keys from which the signature cannot be verified or for which
the signature verification fails. It could also be used to provide
blacklisting.
This affects operations like add_key(), KEYCTL_LINK and KEYCTL_INSTANTIATE.
To this end:
(1) A function pointer is added to the key struct that, if set, points to
the vetting function. This is called as:
int (*restrict_link)(struct key *keyring,
const struct key_type *key_type,
unsigned long key_flags,
const union key_payload *key_payload),
where 'keyring' will be the keyring being added to, key_type and
key_payload will describe the key being added and key_flags[*] can be
AND'ed with KEY_FLAG_TRUSTED.
[*] This parameter will be removed in a later patch when
KEY_FLAG_TRUSTED is removed.
The function should return 0 to allow the link to take place or an
error (typically -ENOKEY, -ENOPKG or -EKEYREJECTED) to reject the
link.
The pointer should not be set directly, but rather should be set
through keyring_alloc().
Note that if called during add_key(), preparse is called before this
method, but a key isn't actually allocated until after this function
is called.
(2) KEY_ALLOC_BYPASS_RESTRICTION is added. This can be passed to
key_create_or_update() or key_instantiate_and_link() to bypass the
restriction check.
(3) KEY_FLAG_TRUSTED_ONLY is removed. The entire contents of a keyring
with this restriction emplaced can be considered 'trustworthy' by
virtue of being in the keyring when that keyring is consulted.
(4) key_alloc() and keyring_alloc() take an extra argument that will be
used to set restrict_link in the new key. This ensures that the
pointer is set before the key is published, thus preventing a window
of unrestrictedness. Normally this argument will be NULL.
(5) As a temporary affair, keyring_restrict_trusted_only() is added. It
should be passed to keyring_alloc() as the extra argument instead of
setting KEY_FLAG_TRUSTED_ONLY on a keyring. This will be replaced in
a later patch with functions that look in the appropriate places for
authoritative keys.
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
2016-04-06 18:14:24 +03:00
}
2011-01-20 19:38:33 +03:00
/**
* key_link - Link a key to a keyring
* @ keyring : The keyring to make the link in .
* @ key : The key to link to .
*
* Make a link in a keyring to a key , such that the keyring holds a reference
* on that key and the key can potentially be found by searching that keyring .
*
* This function will write - lock the keyring ' s semaphore and will consume some
* of the user ' s key data quota to hold the link .
*
* Returns 0 if successful , - ENOTDIR if the keyring isn ' t a keyring ,
* - EKEYREVOKED if the keyring has been revoked , - ENFILE if the keyring is
* full , - EDQUOT if there is insufficient key data quota remaining to add
* another link or - ENOMEM if there ' s insufficient memory .
*
* It is assumed that the caller has checked that it is permitted for a link to
* be made ( the keyring should have Write permission and the key Link
* permission ) .
2005-04-17 02:20:36 +04:00
*/
int key_link ( struct key * keyring , struct key * key )
{
2019-05-30 13:37:39 +03:00
struct assoc_array_edit * edit = NULL ;
2005-04-17 02:20:36 +04:00
int ret ;
2017-03-31 15:20:48 +03:00
kenter ( " {%d,%d} " , keyring - > serial , refcount_read ( & keyring - > usage ) ) ;
2013-09-24 13:35:18 +04:00
2005-04-17 02:20:36 +04:00
key_check ( keyring ) ;
key_check ( key ) ;
2019-05-30 13:37:39 +03:00
ret = __key_link_lock ( keyring , & key - > index_key ) ;
if ( ret < 0 )
goto error ;
2013-09-24 13:35:18 +04:00
ret = __key_link_begin ( keyring , & key - > index_key , & edit ) ;
2019-05-30 13:37:39 +03:00
if ( ret < 0 )
goto error_end ;
2005-04-17 02:20:36 +04:00
2019-05-30 13:37:39 +03:00
kdebug ( " begun {%d,%d} " , keyring - > serial , refcount_read ( & keyring - > usage ) ) ;
ret = __key_link_check_restriction ( keyring , key ) ;
if ( ret = = 0 )
ret = __key_link_check_live_key ( keyring , key ) ;
if ( ret = = 0 )
watch_queue: Add a key/keyring notification facility
Add a key/keyring change notification facility whereby notifications about
changes in key and keyring content and attributes can be received.
Firstly, an event queue needs to be created:
pipe2(fds, O_NOTIFICATION_PIPE);
ioctl(fds[1], IOC_WATCH_QUEUE_SET_SIZE, 256);
then a notification can be set up to report notifications via that queue:
struct watch_notification_filter filter = {
.nr_filters = 1,
.filters = {
[0] = {
.type = WATCH_TYPE_KEY_NOTIFY,
.subtype_filter[0] = UINT_MAX,
},
},
};
ioctl(fds[1], IOC_WATCH_QUEUE_SET_FILTER, &filter);
keyctl_watch_key(KEY_SPEC_SESSION_KEYRING, fds[1], 0x01);
After that, records will be placed into the queue when events occur in
which keys are changed in some way. Records are of the following format:
struct key_notification {
struct watch_notification watch;
__u32 key_id;
__u32 aux;
} *n;
Where:
n->watch.type will be WATCH_TYPE_KEY_NOTIFY.
n->watch.subtype will indicate the type of event, such as
NOTIFY_KEY_REVOKED.
n->watch.info & WATCH_INFO_LENGTH will indicate the length of the
record.
n->watch.info & WATCH_INFO_ID will be the second argument to
keyctl_watch_key(), shifted.
n->key will be the ID of the affected key.
n->aux will hold subtype-dependent information, such as the key
being linked into the keyring specified by n->key in the case of
NOTIFY_KEY_LINKED.
Note that it is permissible for event records to be of variable length -
or, at least, the length may be dependent on the subtype. Note also that
the queue can be shared between multiple notifications of various types.
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: James Morris <jamorris@linux.microsoft.com>
2020-01-14 20:07:11 +03:00
__key_link ( keyring , key , & edit ) ;
2005-04-17 02:20:36 +04:00
2019-05-30 13:37:39 +03:00
error_end :
__key_link_end ( keyring , & key - > index_key , edit ) ;
error :
2017-03-31 15:20:48 +03:00
kleave ( " = %d {%d,%d} " , ret , keyring - > serial , refcount_read ( & keyring - > usage ) ) ;
2005-04-17 02:20:36 +04:00
return ret ;
2010-04-30 17:32:39 +04:00
}
2005-04-17 02:20:36 +04:00
EXPORT_SYMBOL ( key_link ) ;
2019-05-30 16:19:20 +03:00
/*
* Lock a keyring for unlink .
*/
static int __key_unlink_lock ( struct key * keyring )
__acquires ( & keyring - > sem )
{
if ( keyring - > type ! = & key_type_keyring )
return - ENOTDIR ;
down_write ( & keyring - > sem ) ;
return 0 ;
}
/*
* Begin the process of unlinking a key from a keyring .
*/
static int __key_unlink_begin ( struct key * keyring , struct key * key ,
struct assoc_array_edit * * _edit )
{
struct assoc_array_edit * edit ;
BUG_ON ( * _edit ! = NULL ) ;
watch_queue: Add a key/keyring notification facility
Add a key/keyring change notification facility whereby notifications about
changes in key and keyring content and attributes can be received.
Firstly, an event queue needs to be created:
pipe2(fds, O_NOTIFICATION_PIPE);
ioctl(fds[1], IOC_WATCH_QUEUE_SET_SIZE, 256);
then a notification can be set up to report notifications via that queue:
struct watch_notification_filter filter = {
.nr_filters = 1,
.filters = {
[0] = {
.type = WATCH_TYPE_KEY_NOTIFY,
.subtype_filter[0] = UINT_MAX,
},
},
};
ioctl(fds[1], IOC_WATCH_QUEUE_SET_FILTER, &filter);
keyctl_watch_key(KEY_SPEC_SESSION_KEYRING, fds[1], 0x01);
After that, records will be placed into the queue when events occur in
which keys are changed in some way. Records are of the following format:
struct key_notification {
struct watch_notification watch;
__u32 key_id;
__u32 aux;
} *n;
Where:
n->watch.type will be WATCH_TYPE_KEY_NOTIFY.
n->watch.subtype will indicate the type of event, such as
NOTIFY_KEY_REVOKED.
n->watch.info & WATCH_INFO_LENGTH will indicate the length of the
record.
n->watch.info & WATCH_INFO_ID will be the second argument to
keyctl_watch_key(), shifted.
n->key will be the ID of the affected key.
n->aux will hold subtype-dependent information, such as the key
being linked into the keyring specified by n->key in the case of
NOTIFY_KEY_LINKED.
Note that it is permissible for event records to be of variable length -
or, at least, the length may be dependent on the subtype. Note also that
the queue can be shared between multiple notifications of various types.
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: James Morris <jamorris@linux.microsoft.com>
2020-01-14 20:07:11 +03:00
2019-05-30 16:19:20 +03:00
edit = assoc_array_delete ( & keyring - > keys , & keyring_assoc_array_ops ,
& key - > index_key ) ;
if ( IS_ERR ( edit ) )
return PTR_ERR ( edit ) ;
if ( ! edit )
return - ENOENT ;
* _edit = edit ;
return 0 ;
}
/*
* Apply an unlink change .
*/
static void __key_unlink ( struct key * keyring , struct key * key ,
struct assoc_array_edit * * _edit )
{
assoc_array_apply_edit ( * _edit ) ;
watch_queue: Add a key/keyring notification facility
Add a key/keyring change notification facility whereby notifications about
changes in key and keyring content and attributes can be received.
Firstly, an event queue needs to be created:
pipe2(fds, O_NOTIFICATION_PIPE);
ioctl(fds[1], IOC_WATCH_QUEUE_SET_SIZE, 256);
then a notification can be set up to report notifications via that queue:
struct watch_notification_filter filter = {
.nr_filters = 1,
.filters = {
[0] = {
.type = WATCH_TYPE_KEY_NOTIFY,
.subtype_filter[0] = UINT_MAX,
},
},
};
ioctl(fds[1], IOC_WATCH_QUEUE_SET_FILTER, &filter);
keyctl_watch_key(KEY_SPEC_SESSION_KEYRING, fds[1], 0x01);
After that, records will be placed into the queue when events occur in
which keys are changed in some way. Records are of the following format:
struct key_notification {
struct watch_notification watch;
__u32 key_id;
__u32 aux;
} *n;
Where:
n->watch.type will be WATCH_TYPE_KEY_NOTIFY.
n->watch.subtype will indicate the type of event, such as
NOTIFY_KEY_REVOKED.
n->watch.info & WATCH_INFO_LENGTH will indicate the length of the
record.
n->watch.info & WATCH_INFO_ID will be the second argument to
keyctl_watch_key(), shifted.
n->key will be the ID of the affected key.
n->aux will hold subtype-dependent information, such as the key
being linked into the keyring specified by n->key in the case of
NOTIFY_KEY_LINKED.
Note that it is permissible for event records to be of variable length -
or, at least, the length may be dependent on the subtype. Note also that
the queue can be shared between multiple notifications of various types.
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: James Morris <jamorris@linux.microsoft.com>
2020-01-14 20:07:11 +03:00
notify_key ( keyring , NOTIFY_KEY_UNLINKED , key_serial ( key ) ) ;
2019-05-30 16:19:20 +03:00
* _edit = NULL ;
key_payload_reserve ( keyring , keyring - > datalen - KEYQUOTA_LINK_BYTES ) ;
}
/*
* Finish unlinking a key from to a keyring .
*/
static void __key_unlink_end ( struct key * keyring ,
struct key * key ,
struct assoc_array_edit * edit )
__releases ( & keyring - > sem )
{
if ( edit )
assoc_array_cancel_edit ( edit ) ;
up_write ( & keyring - > sem ) ;
}
2011-01-20 19:38:33 +03:00
/**
* key_unlink - Unlink the first link to a key from a keyring .
* @ keyring : The keyring to remove the link from .
* @ key : The key the link is to .
*
* Remove a link from a keyring to a key .
*
* This function will write - lock the keyring ' s semaphore .
*
* Returns 0 if successful , - ENOTDIR if the keyring isn ' t a keyring , - ENOENT if
* the key isn ' t linked to by the keyring or - ENOMEM if there ' s insufficient
* memory .
*
* It is assumed that the caller has checked that it is permitted for a link to
* be removed ( the keyring should have Write permission ; no permissions are
* required on the key ) .
2005-04-17 02:20:36 +04:00
*/
int key_unlink ( struct key * keyring , struct key * key )
{
2019-05-30 16:19:20 +03:00
struct assoc_array_edit * edit = NULL ;
2013-09-24 13:35:18 +04:00
int ret ;
2005-04-17 02:20:36 +04:00
key_check ( keyring ) ;
key_check ( key ) ;
2019-05-30 16:19:20 +03:00
ret = __key_unlink_lock ( keyring ) ;
if ( ret < 0 )
return ret ;
2005-04-17 02:20:36 +04:00
2019-05-30 16:19:20 +03:00
ret = __key_unlink_begin ( keyring , key , & edit ) ;
if ( ret = = 0 )
__key_unlink ( keyring , key , & edit ) ;
__key_unlink_end ( keyring , key , edit ) ;
2013-09-24 13:35:18 +04:00
return ret ;
2011-01-20 19:38:27 +03:00
}
2005-04-17 02:20:36 +04:00
EXPORT_SYMBOL ( key_unlink ) ;
2019-05-20 23:51:50 +03:00
/**
* key_move - Move a key from one keyring to another
* @ key : The key to move
* @ from_keyring : The keyring to remove the link from .
* @ to_keyring : The keyring to make the link in .
* @ flags : Qualifying flags , such as KEYCTL_MOVE_EXCL .
*
* Make a link in @ to_keyring to a key , such that the keyring holds a reference
* on that key and the key can potentially be found by searching that keyring
* whilst simultaneously removing a link to the key from @ from_keyring .
*
* This function will write - lock both keyring ' s semaphores and will consume
* some of the user ' s key data quota to hold the link on @ to_keyring .
*
* Returns 0 if successful , - ENOTDIR if either keyring isn ' t a keyring ,
* - EKEYREVOKED if either keyring has been revoked , - ENFILE if the second
* keyring is full , - EDQUOT if there is insufficient key data quota remaining
* to add another link or - ENOMEM if there ' s insufficient memory . If
* KEYCTL_MOVE_EXCL is set , then - EEXIST will be returned if there ' s already a
* matching key in @ to_keyring .
*
* It is assumed that the caller has checked that it is permitted for a link to
* be made ( the keyring should have Write permission and the key Link
* permission ) .
*/
int key_move ( struct key * key ,
struct key * from_keyring ,
struct key * to_keyring ,
unsigned int flags )
{
struct assoc_array_edit * from_edit = NULL , * to_edit = NULL ;
int ret ;
kenter ( " %d,%d,%d " , key - > serial , from_keyring - > serial , to_keyring - > serial ) ;
if ( from_keyring = = to_keyring )
return 0 ;
key_check ( key ) ;
key_check ( from_keyring ) ;
key_check ( to_keyring ) ;
ret = __key_move_lock ( from_keyring , to_keyring , & key - > index_key ) ;
if ( ret < 0 )
goto out ;
ret = __key_unlink_begin ( from_keyring , key , & from_edit ) ;
if ( ret < 0 )
2013-09-24 13:35:18 +04:00
goto error ;
2019-05-20 23:51:50 +03:00
ret = __key_link_begin ( to_keyring , & key - > index_key , & to_edit ) ;
if ( ret < 0 )
2013-09-24 13:35:18 +04:00
goto error ;
2005-04-17 02:20:36 +04:00
2019-05-20 23:51:50 +03:00
ret = - EEXIST ;
if ( to_edit - > dead_leaf & & ( flags & KEYCTL_MOVE_EXCL ) )
goto error ;
2005-04-17 02:20:36 +04:00
2019-05-20 23:51:50 +03:00
ret = __key_link_check_restriction ( to_keyring , key ) ;
if ( ret < 0 )
goto error ;
ret = __key_link_check_live_key ( to_keyring , key ) ;
if ( ret < 0 )
goto error ;
__key_unlink ( from_keyring , key , & from_edit ) ;
watch_queue: Add a key/keyring notification facility
Add a key/keyring change notification facility whereby notifications about
changes in key and keyring content and attributes can be received.
Firstly, an event queue needs to be created:
pipe2(fds, O_NOTIFICATION_PIPE);
ioctl(fds[1], IOC_WATCH_QUEUE_SET_SIZE, 256);
then a notification can be set up to report notifications via that queue:
struct watch_notification_filter filter = {
.nr_filters = 1,
.filters = {
[0] = {
.type = WATCH_TYPE_KEY_NOTIFY,
.subtype_filter[0] = UINT_MAX,
},
},
};
ioctl(fds[1], IOC_WATCH_QUEUE_SET_FILTER, &filter);
keyctl_watch_key(KEY_SPEC_SESSION_KEYRING, fds[1], 0x01);
After that, records will be placed into the queue when events occur in
which keys are changed in some way. Records are of the following format:
struct key_notification {
struct watch_notification watch;
__u32 key_id;
__u32 aux;
} *n;
Where:
n->watch.type will be WATCH_TYPE_KEY_NOTIFY.
n->watch.subtype will indicate the type of event, such as
NOTIFY_KEY_REVOKED.
n->watch.info & WATCH_INFO_LENGTH will indicate the length of the
record.
n->watch.info & WATCH_INFO_ID will be the second argument to
keyctl_watch_key(), shifted.
n->key will be the ID of the affected key.
n->aux will hold subtype-dependent information, such as the key
being linked into the keyring specified by n->key in the case of
NOTIFY_KEY_LINKED.
Note that it is permissible for event records to be of variable length -
or, at least, the length may be dependent on the subtype. Note also that
the queue can be shared between multiple notifications of various types.
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: James Morris <jamorris@linux.microsoft.com>
2020-01-14 20:07:11 +03:00
__key_link ( to_keyring , key , & to_edit ) ;
2005-06-24 09:00:49 +04:00
error :
2019-05-20 23:51:50 +03:00
__key_link_end ( to_keyring , & key - > index_key , to_edit ) ;
__key_unlink_end ( from_keyring , key , from_edit ) ;
out :
kleave ( " = %d " , ret ) ;
2013-09-24 13:35:18 +04:00
return ret ;
2011-01-20 19:38:27 +03:00
}
2019-05-20 23:51:50 +03:00
EXPORT_SYMBOL ( key_move ) ;
2005-04-17 02:20:36 +04:00
2011-01-20 19:38:33 +03:00
/**
* keyring_clear - Clear a keyring
* @ keyring : The keyring to clear .
*
* Clear the contents of the specified keyring .
*
* Returns 0 if successful or - ENOTDIR if the keyring isn ' t a keyring .
2005-04-17 02:20:36 +04:00
*/
int keyring_clear ( struct key * keyring )
{
2013-09-24 13:35:18 +04:00
struct assoc_array_edit * edit ;
2005-06-24 09:00:49 +04:00
int ret ;
2005-04-17 02:20:36 +04:00
2013-09-24 13:35:18 +04:00
if ( keyring - > type ! = & key_type_keyring )
return - ENOTDIR ;
2005-04-17 02:20:36 +04:00
2013-09-24 13:35:18 +04:00
down_write ( & keyring - > sem ) ;
2005-04-17 02:20:36 +04:00
2013-09-24 13:35:18 +04:00
edit = assoc_array_clear ( & keyring - > keys , & keyring_assoc_array_ops ) ;
if ( IS_ERR ( edit ) ) {
ret = PTR_ERR ( edit ) ;
} else {
if ( edit )
assoc_array_apply_edit ( edit ) ;
watch_queue: Add a key/keyring notification facility
Add a key/keyring change notification facility whereby notifications about
changes in key and keyring content and attributes can be received.
Firstly, an event queue needs to be created:
pipe2(fds, O_NOTIFICATION_PIPE);
ioctl(fds[1], IOC_WATCH_QUEUE_SET_SIZE, 256);
then a notification can be set up to report notifications via that queue:
struct watch_notification_filter filter = {
.nr_filters = 1,
.filters = {
[0] = {
.type = WATCH_TYPE_KEY_NOTIFY,
.subtype_filter[0] = UINT_MAX,
},
},
};
ioctl(fds[1], IOC_WATCH_QUEUE_SET_FILTER, &filter);
keyctl_watch_key(KEY_SPEC_SESSION_KEYRING, fds[1], 0x01);
After that, records will be placed into the queue when events occur in
which keys are changed in some way. Records are of the following format:
struct key_notification {
struct watch_notification watch;
__u32 key_id;
__u32 aux;
} *n;
Where:
n->watch.type will be WATCH_TYPE_KEY_NOTIFY.
n->watch.subtype will indicate the type of event, such as
NOTIFY_KEY_REVOKED.
n->watch.info & WATCH_INFO_LENGTH will indicate the length of the
record.
n->watch.info & WATCH_INFO_ID will be the second argument to
keyctl_watch_key(), shifted.
n->key will be the ID of the affected key.
n->aux will hold subtype-dependent information, such as the key
being linked into the keyring specified by n->key in the case of
NOTIFY_KEY_LINKED.
Note that it is permissible for event records to be of variable length -
or, at least, the length may be dependent on the subtype. Note also that
the queue can be shared between multiple notifications of various types.
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: James Morris <jamorris@linux.microsoft.com>
2020-01-14 20:07:11 +03:00
notify_key ( keyring , NOTIFY_KEY_CLEARED , 0 ) ;
2013-09-24 13:35:18 +04:00
key_payload_reserve ( keyring , 0 ) ;
2005-04-17 02:20:36 +04:00
ret = 0 ;
}
2013-09-24 13:35:18 +04:00
up_write ( & keyring - > sem ) ;
2005-04-17 02:20:36 +04:00
return ret ;
2011-01-20 19:38:27 +03:00
}
2005-04-17 02:20:36 +04:00
EXPORT_SYMBOL ( keyring_clear ) ;
2006-06-26 11:24:51 +04:00
/*
2011-01-20 19:38:33 +03:00
* Dispose of the links from a revoked keyring .
*
* This is called with the key sem write - locked .
2006-06-26 11:24:51 +04:00
*/
static void keyring_revoke ( struct key * keyring )
{
2013-09-24 13:35:18 +04:00
struct assoc_array_edit * edit ;
2010-04-30 17:32:18 +04:00
2013-09-24 13:35:18 +04:00
edit = assoc_array_clear ( & keyring - > keys , & keyring_assoc_array_ops ) ;
if ( ! IS_ERR ( edit ) ) {
if ( edit )
assoc_array_apply_edit ( edit ) ;
key_payload_reserve ( keyring , 0 ) ;
}
}
2006-06-26 11:24:51 +04:00
2013-11-14 17:02:31 +04:00
static bool keyring_gc_select_iterator ( void * object , void * iterator_data )
2013-09-24 13:35:18 +04:00
{
struct key * key = keyring_ptr_to_key ( object ) ;
2017-11-15 19:38:45 +03:00
time64_t * limit = iterator_data ;
2006-06-26 11:24:51 +04:00
2013-09-24 13:35:18 +04:00
if ( key_is_dead ( key , * limit ) )
return false ;
key_get ( key ) ;
return true ;
2011-01-20 19:38:27 +03:00
}
2009-09-02 12:14:00 +04:00
2013-11-14 17:02:31 +04:00
static int keyring_gc_check_iterator ( const void * object , void * iterator_data )
{
const struct key * key = keyring_ptr_to_key ( object ) ;
2017-11-15 19:38:45 +03:00
time64_t * limit = iterator_data ;
2013-11-14 17:02:31 +04:00
key_check ( key ) ;
return key_is_dead ( key , * limit ) ;
}
2009-09-02 12:14:00 +04:00
/*
2013-11-14 17:02:31 +04:00
* Garbage collect pointers from a keyring .
2011-01-20 19:38:33 +03:00
*
2013-11-14 17:02:31 +04:00
* Not called with any locks held . The keyring ' s key struct will not be
* deallocated under us as only our caller may deallocate it .
2009-09-02 12:14:00 +04:00
*/
2017-11-15 19:38:45 +03:00
void keyring_gc ( struct key * keyring , time64_t limit )
2009-09-02 12:14:00 +04:00
{
2013-11-14 17:02:31 +04:00
int result ;
kenter ( " %x{%s} " , keyring - > serial , keyring - > description ? : " " ) ;
2009-09-02 12:14:00 +04:00
2013-11-14 17:02:31 +04:00
if ( keyring - > flags & ( ( 1 < < KEY_FLAG_INVALIDATED ) |
( 1 < < KEY_FLAG_REVOKED ) ) )
goto dont_gc ;
/* scan the keyring looking for dead keys */
rcu_read_lock ( ) ;
result = assoc_array_iterate ( & keyring - > keys ,
keyring_gc_check_iterator , & limit ) ;
rcu_read_unlock ( ) ;
if ( result = = true )
goto do_gc ;
dont_gc :
kleave ( " [no gc] " ) ;
return ;
do_gc :
2009-09-02 12:14:00 +04:00
down_write ( & keyring - > sem ) ;
2013-09-24 13:35:18 +04:00
assoc_array_gc ( & keyring - > keys , & keyring_assoc_array_ops ,
2013-11-14 17:02:31 +04:00
keyring_gc_select_iterator , & limit ) ;
2009-09-14 20:26:13 +04:00
up_write ( & keyring - > sem ) ;
2013-11-14 17:02:31 +04:00
kleave ( " [gc] " ) ;
2009-09-02 12:14:00 +04:00
}
2016-09-01 02:05:43 +03:00
/*
* Garbage collect restriction pointers from a keyring .
*
* Keyring restrictions are associated with a key type , and must be cleaned
* up if the key type is unregistered . The restriction is altered to always
* reject additional keys so a keyring cannot be opened up by unregistering
* a key type .
*
* Not called with any keyring locks held . The keyring ' s key struct will not
* be deallocated under us as only our caller may deallocate it .
*
* The caller is required to hold key_types_sem and dead_type - > sem . This is
* fulfilled by key_gc_keytype ( ) holding the locks on behalf of
* key_garbage_collector ( ) , which it invokes on a workqueue .
*/
void keyring_restriction_gc ( struct key * keyring , struct key_type * dead_type )
{
struct key_restriction * keyres ;
kenter ( " %x{%s} " , keyring - > serial , keyring - > description ? : " " ) ;
/*
* keyring - > restrict_link is only assigned at key allocation time
* or with the key type locked , so the only values that could be
* concurrently assigned to keyring - > restrict_link are for key
* types other than dead_type . Given this , it ' s ok to check
* the key type before acquiring keyring - > sem .
*/
if ( ! dead_type | | ! keyring - > restrict_link | |
keyring - > restrict_link - > keytype ! = dead_type ) {
kleave ( " [no restriction gc] " ) ;
return ;
}
/* Lock the keyring to ensure that a link is not in progress */
down_write ( & keyring - > sem ) ;
keyres = keyring - > restrict_link ;
keyres - > check = restrict_link_reject ;
key_put ( keyres - > key ) ;
keyres - > key = NULL ;
keyres - > keytype = NULL ;
up_write ( & keyring - > sem ) ;
kleave ( " [restriction gc] " ) ;
}