linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers3@gmail.com>
To: keyrings@vger.kernel.org
Cc: linux-security-module@vger.kernel.org,
	David Howells <dhowells@redhat.com>,
	linux-kernel@vger.kernel.org, Eric Biggers <ebiggers@google.com>
Subject: [PATCH 5/5] KEYS: sanitize key structs before freeing
Date: Fri, 21 Apr 2017 01:30:37 -0700	[thread overview]
Message-ID: <20170421083037.12746-6-ebiggers3@gmail.com> (raw)
In-Reply-To: <20170421083037.12746-1-ebiggers3@gmail.com>

From: Eric Biggers <ebiggers@google.com>

While a 'struct key' itself normally does not contain sensitive
information, Documentation/security/keys.txt actually encourages this:

     "Having a payload is not required; and the payload can, in fact,
     just be a value stored in the struct key itself."

In case someone has taken this advice, or will take this advice in the
future, zero the key structure before freeing it.  We might as well, and
as a bonus this could make it a bit more difficult for an adversary to
determine which keys have recently been in use.

This is safe because the key_jar cache does not use a constructor.

Signed-off-by: Eric Biggers <ebiggers@google.com>
---
 include/linux/key.h | 1 -
 security/keys/gc.c  | 4 +---
 2 files changed, 1 insertion(+), 4 deletions(-)

diff --git a/include/linux/key.h b/include/linux/key.h
index 0c9b93b0d1f7..78e25aabedaf 100644
--- a/include/linux/key.h
+++ b/include/linux/key.h
@@ -173,7 +173,6 @@ struct key {
 #ifdef KEY_DEBUGGING
 	unsigned		magic;
 #define KEY_DEBUG_MAGIC		0x18273645u
-#define KEY_DEBUG_MAGIC_X	0xf8e9dacbu
 #endif
 
 	unsigned long		flags;		/* status flags (change with bitops) */
diff --git a/security/keys/gc.c b/security/keys/gc.c
index 15b9ddf510e4..5233c073d982 100644
--- a/security/keys/gc.c
+++ b/security/keys/gc.c
@@ -158,9 +158,7 @@ static noinline void key_gc_unused_keys(struct list_head *keys)
 
 		kfree(key->description);
 
-#ifdef KEY_DEBUGGING
-		key->magic = KEY_DEBUG_MAGIC_X;
-#endif
+		memzero_explicit(key, sizeof(*key));
 		kmem_cache_free(key_jar, key);
 	}
 }
-- 
2.12.2

  parent reply	other threads:[~2017-04-21  8:32 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-21  8:30 [PATCH 0/5] KEYS: sanitize key payloads Eric Biggers
2017-04-21  8:30 ` [PATCH 1/5] KEYS: sanitize add_key() and keyctl() " Eric Biggers
2017-04-28 17:57   ` Eric Biggers
2017-04-21  8:30 ` [PATCH 2/5] KEYS: user_defined: sanitize " Eric Biggers
2017-04-21  8:30 ` [PATCH 3/5] KEYS: encrypted: sanitize all key material Eric Biggers
2017-04-21  8:30 ` [PATCH 4/5] KEYS: trusted: " Eric Biggers
2017-04-21  8:30 ` Eric Biggers [this message]
2017-04-21 13:57 ` [PATCH 2/5] KEYS: user_defined: sanitize key payloads David Howells
2017-04-21 18:34   ` Eric Biggers
2017-04-24 14:14   ` David Howells
2017-04-21 14:31 ` [PATCH 3/5] KEYS: encrypted: sanitize all key material David Howells
2017-04-21 18:24   ` Eric Biggers
2017-04-24 14:14   ` David Howells
2017-04-27 15:09 ` [PATCH 0/5] KEYS: sanitize key payloads David Howells
2017-04-27 17:43   ` Eric Biggers
2017-06-02 15:34 ` [PATCH 1/5] KEYS: sanitize add_key() and keyctl() " David Howells
2017-06-02 17:24   ` Eric Biggers

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=20170421083037.12746-6-ebiggers3@gmail.com \
    --to=ebiggers3@gmail.com \
    --cc=dhowells@redhat.com \
    --cc=ebiggers@google.com \
    --cc=keyrings@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.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;
as well as URLs for NNTP newsgroup(s).