All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Howells <dhowells@redhat.com>
To: Mimi Zohar <zohar@linux.vnet.ibm.com>, James Morris <jmorris@namei.org>
Cc: dhowells@redhat.com, Marcel Holtmann <marcel@holtmann.org>,
	petkan@mip-labs.com, linux-security-module@vger.kernel.org,
	keyrings@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] X.509: Partially revert patch to add validation against IMA MOK keyring
Date: Sun, 10 Jan 2016 20:33:38 +0000	[thread overview]
Message-ID: <3384.1452458018@warthog.procyon.org.uk> (raw)
In-Reply-To: <2033.1452447990@warthog.procyon.org.uk>

David Howells <dhowells@redhat.com> wrote:

> Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:
> 
> > > Is this a NAK on the patch?
> > 
> > Yes
> 
> I would like to counter Mimi's NAK:
> 
>  (1) Commit 41c89b64d7184a780f12f2cccdabe65cb2408893 doesn't do what it
>      says.  Given the change I want to revert, this bit of the description:
> 
> 	To successfully import a key into .ima_mok it must be signed by a
> 	key which CA is in .system keyring.
> 
>      is *not* true.  A key in the .ima_mok keyring will *also* allow a key
>      into the .ima_mok keyring.  Thus the .ima_mok keyring is redundant and
>      should be merged into the .system keyring.
> 
>  (2) You can use KEYCTL_LINK to link trusted keys between trusted keyrings
>      if the key being linked grants permission.  Add a new key to one open
>      keyring and you can then link it across to another.
> 
>      Keyrings need to guard against *link* as per my recently posted
>      patches.
> 
>  (3) In the current model, the trusted-only keyring and trusted-key concept
>      ought really to apply only to the .system keyring as the concept of
>      'trust' is boolean in this implementation.
> 
>      Again, I want to change this as per my recently posted patches.

 (4) Marcel asked to have user-based 'trusted' keyrings - where userspace
     can load a keyring up and then mark it as 'trusted' thereby limiting
     further additions - for the use with kernel-based TLS.

     These would *not* depend on the .system keyring.  Unless we're willing
     to store the root CA certificate for the world in the kernel, we can't
     really do that.

David

  reply	other threads:[~2016-01-10 20:33 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-06 13:45 [PATCH] X.509: Partially revert patch to add validation against IMA MOK keyring David Howells
2016-01-07  0:04 ` James Morris
2016-01-07  0:34 ` David Howells
2016-01-07  2:13   ` Mimi Zohar
2016-01-07  3:28     ` Mimi Zohar
2016-01-07 15:31   ` Mimi Zohar
2016-01-10 10:36     ` James Morris
2016-01-10 13:26       ` Mimi Zohar
2016-01-10 17:46         ` David Howells
2016-01-10 20:33           ` David Howells [this message]
2016-01-10 23:55             ` Mimi Zohar
2016-01-12  0:44               ` David Howells
2016-01-12  1:28                 ` Mark D. Baushke
2016-01-12  2:03                   ` David Howells
2016-01-12  2:25                     ` Mark D. Baushke
2016-01-12  3:35                     ` Mimi Zohar
2016-01-12 10:08                       ` David Howells
2016-01-12 13:21                         ` Mimi Zohar
2016-01-12 13:55                           ` David Howells
2016-01-12 15:17                             ` Mimi Zohar
2016-01-12 15:56                               ` David Howells
2016-01-12 16:02                                 ` Mimi Zohar
2016-01-12 14:11                         ` Petko Manolov
2016-01-10 20:33           ` Petko Manolov
2016-01-12  1:38             ` David Howells
2016-01-12 16:14               ` Petko Manolov
2016-01-12 17:08                 ` David Howells
2016-01-13 16:31                   ` Petko Manolov
2016-01-13 17:51                     ` Mimi Zohar
2016-01-13 18:01                       ` Petko Manolov
2016-01-13 18:19                       ` David Howells
2016-01-13 18:35                         ` Petko Manolov
2016-01-13 18:56                           ` Mimi Zohar
2016-01-13 19:19                             ` Petko Manolov

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=3384.1452458018@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=marcel@holtmann.org \
    --cc=petkan@mip-labs.com \
    --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 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.