From: David Howells <dhowells@redhat.com>
To: torvalds@osdl.org, akpm@osdl.org
Cc: linux-kernel@vger.kernel.org, keyrings@linux-nfs.org
Subject: [PATCH 4/6] Keys: Allocate key serial numbers randomly [try #3]
Date: Tue, 20 Jun 2006 18:37:44 +0100 [thread overview]
Message-ID: <20060620173744.5034.50837.stgit@warthog.cambridge.redhat.com> (raw)
In-Reply-To: <20060620173735.5034.11436.stgit@warthog.cambridge.redhat.com>
From: Michael LeMay <mdlemay@epoch.ncsc.mil>
The attached patch causes 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>
---
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 a9b6ca7..10fea8c 100644
--- a/security/keys/key.c
+++ b/security/keys/key.c
@@ -15,11 +15,11 @@ #include <linux/sched.h>
#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(s
/*****************************************************************************/
/*
* 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(stru
/* 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 (!parent->rb_parent)
p = &key_serial_tree.rb_node;
@@ -228,7 +228,7 @@ static inline void key_alloc_serial(stru
}
/* 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);
next prev parent reply other threads:[~2006-06-20 17:38 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-20 17:37 [PATCH 0/6] Keys: Key management updates " David Howells
2006-06-20 17:37 ` [PATCH 1/6] Keys: Sort out key quota system " David Howells
2006-06-20 17:37 ` [PATCH 2/6] Keys: Discard the contents of a key on revocation " David Howells
2006-06-20 17:37 ` [PATCH 3/6] Keys: Let keyctl_chown() change a key's owner " David Howells
2006-06-20 17:37 ` David Howells [this message]
2006-06-20 17:37 ` [PATCH 5/6] Keys: Restrict contents of /proc/keys to Viewable keys " David Howells
2006-06-20 17:37 ` [PATCH 6/6] Keys: Add a way to store the appropriate context for newly-created " David Howells
2006-06-20 20:44 ` [Keyrings] [PATCH 0/6] Keys: Key management updates " James Morris
2006-06-20 21:03 ` Andrew Morton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060620173744.5034.50837.stgit@warthog.cambridge.redhat.com \
--to=dhowells@redhat.com \
--cc=akpm@osdl.org \
--cc=keyrings@linux-nfs.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@osdl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®