From: Dmitry Kasatkin <d.kasatkin@samsung.com>
To: David Howells <dhowells@redhat.com>, zohar@us.ibm.com
Cc: keyrings@linux-nfs.org, linux-security-module@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [RFC][PATCH 0/9] encrypted keys & key control op
Date: Wed, 06 Nov 2013 19:20:14 +0200 [thread overview]
Message-ID: <527A7A4E.4020702@samsung.com> (raw)
In-Reply-To: <20131104162216.10177.98067.stgit@warthog.procyon.org.uk>
Hello David,
I will be looking to patches today...
- Dmitry
On 04/11/13 18:22, David Howells wrote:
> 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 prev parent reply other threads:[~2013-11-06 17:20 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-04 16:22 [RFC][PATCH 0/9] encrypted keys & key control op David Howells
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 ` Dmitry Kasatkin [this message]
2013-11-06 17:42 ` [RFC][PATCH 0/9] encrypted keys & key control op 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=527A7A4E.4020702@samsung.com \
--to=d.kasatkin@samsung.com \
--cc=dhowells@redhat.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;
as well as URLs for NNTP newsgroup(s).