mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: David Howells <dhowells@redhat.com>
To: d.kasatkin@samsung.com, zohar@us.ibm.com
Cc: keyrings@linux-nfs.org, linux-security-module@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: [RFC][PATCH 0/9] encrypted keys & key control op
Date: Mon, 04 Nov 2013 16:22:16 +0000	[thread overview]
Message-ID: <20131104162216.10177.98067.stgit@warthog.procyon.org.uk> (raw)


Hi Mimi, Dmitry,

Here's a series of patches, the last three of which attempt to fix up a
problem with encrypted keys update method.  The preceding patches are fixes or
are preparatory for other changes that I want to put underneath.

I really want to make all key types use ->preparse() to avoid a deadlock in
the garbage collector with quota recycling, but encrypted_update() requires
access to the old key - which you can't have in ->preparse() because the
keyring isn't locked (and this lock is the root of the gc deadlock anyway).

Further, the existence of encrypted_update() means that add_key() will
sometimes get things wrong with encrypted keys (add_key() will call ->update()
if a matching key already exists rather than creating a new key).  But you
can't pre-search for the existence of a key and mould the payload accordingly
because that means you can race against both add_key() and keyctl_unlink().

My solution is to add a new keyctl function that allows the caller to perform
a type-specific operation on a key:

	long keyctl_control(key_serial_t key_id,
			    const char *command,
			    char *reply_buffer,
			    size_t reply_size);

This would then take a NUL-terminated string indicating the command and
arguments and potentially return a reply up to the buffer length.

For instance:

	keyctl_control(1234, "encrypted change-master-key fred's key", NULL, 0);

or, from the shell:

	keyctl control 1234 "encrypted change-master-key fred's key"

(I think that requiring the command string to be prefixed with the expected
key type is probably a good idea).

The control op could also be used for other things like pushing a key into a
TPM.

What do you think?

David
---
David Howells (9):
      KEYS: The RSA public key algorithm needs to select MPILIB
      KEYS: Provide a generic instantiation function
      KEYS: struct key_preparsed_payload should have two payload pointers
      KEYS: Allow expiry time to be set when preparsing a key
      KEYS: Call ->free_preparse() even after ->preparse() returns an error
      KEYS: Trusted: Use key preparsing
      KEYS: Add a keyctl function to alter/control a key in type-dependent way
      KEYS: Implement keyctl control for encrypted keys
      KEYS: Fix encrypted key type update method


 Documentation/security/keys.txt          |   48 +++++++-
 crypto/asymmetric_keys/Kconfig           |    1 
 crypto/asymmetric_keys/asymmetric_type.c |   27 ----
 crypto/asymmetric_keys/x509_public_key.c |    2 
 include/linux/key-type.h                 |   11 ++
 include/uapi/linux/keyctl.h              |    1 
 security/keys/compat.c                   |    6 +
 security/keys/encrypted-keys/encrypted.c |  111 +++++++++++++-----
 security/keys/internal.h                 |    2 
 security/keys/key.c                      |   49 +++++++-
 security/keys/keyctl.c                   |  104 ++++++++++++++++
 security/keys/trusted.c                  |  190 ++++++++++++++----------------
 12 files changed, 385 insertions(+), 167 deletions(-)


             reply	other threads:[~2013-11-04 18:14 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-04 16:22 David Howells [this message]
2013-11-04 16:22 ` [PATCH 1/9] KEYS: The RSA public key algorithm needs to select MPILIB David Howells
2013-11-04 16:22 ` [PATCH 2/9] KEYS: Provide a generic instantiation function David Howells
2013-11-04 16:22 ` [PATCH 3/9] KEYS: struct key_preparsed_payload should have two payload pointers David Howells
2013-11-04 16:22 ` [PATCH 4/9] KEYS: Allow expiry time to be set when preparsing a key David Howells
2013-11-04 16:22 ` [PATCH 5/9] KEYS: Call ->free_preparse() even after ->preparse() returns an error David Howells
2013-11-04 16:23 ` [PATCH 6/9] KEYS: Trusted: Use key preparsing David Howells
2013-11-13 16:49   ` Mimi Zohar
2013-11-14 15:50   ` David Howells
2013-11-04 16:23 ` [PATCH 7/9] KEYS: Add a keyctl function to alter/control a key in type-dependent way David Howells
2013-11-04 16:23 ` [PATCH 8/9] KEYS: Implement keyctl control for encrypted keys David Howells
2013-11-04 16:23 ` [PATCH 9/9] KEYS: Fix encrypted key type update method David Howells
2013-11-13 18:45   ` Mimi Zohar
2013-11-14 17:59   ` David Howells
2013-11-17  3:51     ` Mimi Zohar
2013-11-17  9:17     ` David Howells
2013-11-17 13:43       ` Mimi Zohar
2013-11-06 17:20 ` [RFC][PATCH 0/9] encrypted keys & key control op Dmitry Kasatkin
2013-11-06 17:42 ` David Howells
2013-11-11 12:14 ` Mimi Zohar
2013-11-11 16:32 ` Mimi Zohar
2013-11-11 22:34 ` David Howells
2013-11-12  0:26   ` Mimi Zohar
2013-11-12 16:19   ` David Howells
2013-11-11 22:35 ` David Howells

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=20131104162216.10177.98067.stgit@warthog.procyon.org.uk \
    --to=dhowells@redhat.com \
    --cc=d.kasatkin@samsung.com \
    --cc=keyrings@linux-nfs.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=zohar@us.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®