From: David Safford <safford@watson.ibm.com>
To: Roberto Sassu <roberto.sassu@polito.it>
Cc: keyrings@linux-nfs.org, linux-security-module@vger.kernel.org,
linux-kernel@vger.kernel.org, zohar@us.ibm.com,
dhowells@redhat.com, jmorris@namei.org
Subject: Re: [PATCH 1/2] trusted-key: allow overwriting the migratable flag
Date: Wed, 02 Nov 2011 12:58:56 -0400 [thread overview]
Message-ID: <1320253136.3225.13.camel@localhost> (raw)
In-Reply-To: <1320237682-3857-1-git-send-email-roberto.sassu@polito.it>
On Wed, 2011-11-02 at 13:41 +0100, Roberto Sassu wrote:
> The migratable should be modifiable during the key update() method. This
> allows for example to update a migratable trusted key, wrapped by a TPM
> key, to a a non-migratable one sealed under the SRK with a PCR set.
>
> Signed-off-by: Roberto Sassu <roberto.sassu@polito.it>
I can see a use case for updating a migratable key to a non-migratable
one - such as keeping a migratable master on a flash drive, and keeping
only the non-migratable copy on-line. I certainly don't want the
ability to change a non-migratable to migratable, as that would defeat
the entire purpose of non-migratable.
I don't think this patch actually does either, though.
> ---
> security/keys/trusted.c | 1 -
> 1 files changed, 0 insertions(+), 1 deletions(-)
>
> diff --git a/security/keys/trusted.c b/security/keys/trusted.c
> index 0c33e2e..8777015 100644
> --- a/security/keys/trusted.c
> +++ b/security/keys/trusted.c
> @@ -1036,7 +1036,6 @@ static int trusted_update(struct key *key, const void *data, size_t datalen)
> goto out;
> }
> /* copy old key values, and reseal with new pcrs */
> - new_p->migratable = p->migratable;
Taking out this line appears only to remove a redundant assignment.
We can only get here if the old key is already migratable, and the
earlier trusted_payload_alloc() initializes the new copy to
migratable by default. I don't see how the flag can be changed
with this patch. Perhaps I'm missing something or this was just
the start, and there is more to come?
dave
> new_p->key_len = p->key_len;
> memcpy(new_p->key, p->key, p->key_len);
> dump_payload(p);
next prev parent reply other threads:[~2011-11-02 17:03 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-02 12:41 [PATCH 1/2] trusted-key: allow overwriting the migratable flag Roberto Sassu
2011-11-02 12:41 ` [PATCH 2/2] trusted-key: added support for loading a key blob in the TPM Roberto Sassu
2011-11-02 17:26 ` David Safford
2011-11-02 17:43 ` Roberto Sassu
2011-11-03 12:12 ` Roberto Sassu
2011-11-02 16:58 ` David Safford [this message]
2011-11-02 17:37 ` [PATCH 1/2] trusted-key: allow overwriting the migratable flag Roberto Sassu
2011-11-02 17:46 ` David Safford
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=1320253136.3225.13.camel@localhost \
--to=safford@watson.ibm.com \
--cc=dhowells@redhat.com \
--cc=jmorris@namei.org \
--cc=keyrings@linux-nfs.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=roberto.sassu@polito.it \
--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.