mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: David Howells <dhowells@redhat.com>
To: jmorris@namei.org
Cc: linux-kernel@vger.kernel.org, stable@vger.kernel.org,
	dhowells@redhat.com, linux-security-module@vger.kernel.org,
	keyrings@vger.kernel.org, sgallagh@redhat.com,
	Mimi Zohar <zohar@linux.vnet.ibm.com>
Subject: [PATCH] KEYS: Only apply KEY_FLAG_KEEP to a key if a parent keyring has it set
Date: Wed, 27 Jan 2016 01:02:03 +0000	[thread overview]
Message-ID: <20160127010203.27333.90518.stgit@warthog.procyon.org.uk> (raw)

KEY_FLAG_KEEP should only be applied to a key if the keyring it is being
linked into has KEY_FLAG_KEEP set.

To this end, partially revert the following patch:

	commit 1d6d167c2efcfe9539d9cffb1a1be9c92e39c2c0
	Author: Mimi Zohar <zohar@linux.vnet.ibm.com>
	Date:   Thu Jan 7 07:46:36 2016 -0500
	KEYS: refcount bug fix

to undo the change that made it unconditional (Mimi got it right the first
time).

Without undoing this change, it becomes impossible to delete, revoke or
invalidate keys added to keyrings through __key_instantiate_and_link()
where the keyring has itself been linked to.  To test this, run the
following command sequence:

    keyctl newring foo @s
    keyctl add user a a %:foo
    keyctl unlink %user:a %:foo
    keyctl clear %:foo

With the commit mentioned above the third and fourth commands fail with
EPERM when they should succeed.

Reported-by: Stephen Gallager <sgallagh@redhat.com>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Mimi Zohar <zohar@linux.vnet.ibm.com>
cc: keyrings@vger.kernel.org
cc: stable@vger.kernel.org
---

 security/keys/key.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/security/keys/key.c b/security/keys/key.c
index 07a87311055c..09ef276c4bdc 100644
--- a/security/keys/key.c
+++ b/security/keys/key.c
@@ -430,7 +430,8 @@ static int __key_instantiate_and_link(struct key *key,
 
 			/* and link it into the destination keyring */
 			if (keyring) {
-				set_bit(KEY_FLAG_KEEP, &key->flags);
+				if (test_bit(KEY_FLAG_KEEP, &keyring->flags))
+					set_bit(KEY_FLAG_KEEP, &key->flags);
 
 				__key_link(key, _edit);
 			}

             reply	other threads:[~2016-01-27  1:02 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-27  1:02 David Howells [this message]
2016-01-27  1:05 ` David Howells
2016-01-27  5:18   ` James Morris
2016-01-27 13:09     ` Mimi Zohar
2016-01-28 13:46       ` Stephen Gallagher

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=20160127010203.27333.90518.stgit@warthog.procyon.org.uk \
    --to=dhowells@redhat.com \
    --cc=jmorris@namei.org \
    --cc=keyrings@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=sgallagh@redhat.com \
    --cc=stable@vger.kernel.org \
    --cc=zohar@linux.vnet.ibm.com \
    /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®