diff options
author | Michael LeMay <mdlemay@epoch.ncsc.mil> | 2006-06-26 00:24:54 -0700 |
---|---|---|
committer | Linus Torvalds <torvalds@g5.osdl.org> | 2006-06-26 09:58:18 -0700 |
commit | e51f6d343789a4f0a2a7587ad7ec7746969d5c1c (patch) | |
tree | 39ca4e05c0dda995f3eaaea1aaa2c8689003f1d0 /security/keys/key.c | |
parent | 5801649d8b83e7cb9b15839761bdee594653c294 (diff) | |
download | kernel_samsung_smdk4412-e51f6d343789a4f0a2a7587ad7ec7746969d5c1c.zip kernel_samsung_smdk4412-e51f6d343789a4f0a2a7587ad7ec7746969d5c1c.tar.gz kernel_samsung_smdk4412-e51f6d343789a4f0a2a7587ad7ec7746969d5c1c.tar.bz2 |
[PATCH] keys: allocate key serial numbers randomly
Cause key_alloc_serial() to generate key serial numbers randomly rather than
in linear sequence.
Using an linear sequence permits a covert communication channel to be
established, in which one process can communicate with another by creating or
not creating new keys within a certain timeframe. The second process can
probe for the expected next key serial number and judge its existence by the
error returned.
This is a problem as the serial number namespace is globally shared between
all tasks, regardless of their context.
For more information on this topic, this old TCSEC guide is recommended:
http://www.radium.ncsc.mil/tpep/library/rainbow/NCSC-TG-030.html
Signed-off-by: Michael LeMay <mdlemay@epoch.ncsc.mil>
Signed-off-by: James Morris <jmorris@namei.org>
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Diffstat (limited to 'security/keys/key.c')
-rw-r--r-- | security/keys/key.c | 28 |
1 files changed, 14 insertions, 14 deletions
diff --git a/security/keys/key.c b/security/keys/key.c index 3601fdd..43295ca 100644 --- a/security/keys/key.c +++ b/security/keys/key.c @@ -15,11 +15,11 @@ #include <linux/slab.h> #include <linux/security.h> #include <linux/workqueue.h> +#include <linux/random.h> #include <linux/err.h> #include "internal.h" static kmem_cache_t *key_jar; -static key_serial_t key_serial_next = 3; struct rb_root key_serial_tree; /* tree of keys indexed by serial */ DEFINE_SPINLOCK(key_serial_lock); @@ -169,22 +169,23 @@ static void __init __key_insert_serial(struct key *key) /*****************************************************************************/ /* * assign a key the next unique serial number - * - we work through all the serial numbers between 2 and 2^31-1 in turn and - * then wrap + * - these are assigned randomly to avoid security issues through covert + * channel problems */ static inline void key_alloc_serial(struct key *key) { struct rb_node *parent, **p; struct key *xkey; - spin_lock(&key_serial_lock); - - /* propose a likely serial number and look for a hole for it in the + /* propose a random serial number and look for a hole for it in the * serial number tree */ - key->serial = key_serial_next; - if (key->serial < 3) - key->serial = 3; - key_serial_next = key->serial + 1; + do { + get_random_bytes(&key->serial, sizeof(key->serial)); + + key->serial >>= 1; /* negative numbers are not permitted */ + } while (key->serial < 3); + + spin_lock(&key_serial_lock); parent = NULL; p = &key_serial_tree.rb_node; @@ -204,12 +205,11 @@ static inline void key_alloc_serial(struct key *key) /* we found a key with the proposed serial number - walk the tree from * that point looking for the next unused serial number */ - serial_exists: +serial_exists: for (;;) { - key->serial = key_serial_next; + key->serial++; if (key->serial < 2) key->serial = 2; - key_serial_next = key->serial + 1; if (!rb_parent(parent)) p = &key_serial_tree.rb_node; @@ -228,7 +228,7 @@ static inline void key_alloc_serial(struct key *key) } /* we've found a suitable hole - arrange for this key to occupy it */ - insert_here: +insert_here: rb_link_node(&key->serial_node, parent, p); rb_insert_color(&key->serial_node, &key_serial_tree); |