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(-)
next 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.