All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Kasatkin <d.kasatkin@samsung.com>
To: zohar@linux.vnet.ibm.com, dhowells@redhat.com,
	jwboyer@redhat.com, keyrings@linux-nfs.org,
	linux-security-module@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, dmitry.kasatkin@gmail.com,
	Dmitry Kasatkin <d.kasatkin@samsung.com>
Subject: [PATCH 0/4] KEYS: validate key trust with owner and builtin keys only
Date: Tue, 10 Jun 2014 11:48:14 +0300	[thread overview]
Message-ID: <cover.1402387862.git.d.kasatkin@samsung.com> (raw)
In-Reply-To: <1402331614.7064.60.camel@dhcp-9-2-203-236.watson.ibm.com>

Hi Mimi,

As you asked ofline , here is possible equivalent and simpler alternative
patches not requiring to have additional keyring.

First patch are irrelevant minor fixes.

Also I want to discuss here Fedora UEFI patches as they are the reason for
the these original patchset.

http://pkgs.fedoraproject.org/cgit/kernel.git/tree/modsign-uefi.patch

They provide functionality to specify MokIgnoreDb variable to limit loading of
UEFI keys only from MOK List, while ignoring DB. This is certainly a good
functionality. But once MODULE_SIG_UEFI is enabled, it looks there is no way
to prevent loading keys from UEFI at all. And this might not be a good default
functionality. Someone might want not allow loading of keys from UEFI unless
kernel parameter is specified to allow it without recompiling the kernel
and disabling MODULE_SIG_UEFI.

Josh, why such design decision was made?

Why not to provide kernel parameter to have more fine-tune control over the
functionality? Unconfigured machines will not have MokIgnoreDb and will
allow to load kernel modules signed with certain undesired keys. In fact,
I beleive, it should be default behavior of the kernel. Bootloader can
enable UEFI functionality by specifing it on the kernel command line.

Second patch allows to overcome keys coming from UEFI for key validation by
specifing owner key id and is an alternative for v5 4/4 patch.

It was also a good idea presented in Mimi's v4 4/4 patch to have possibility
to limit key trust valiation by only builtin keys. Third patch as an alternative.
It uses keys->flags to specify origin of the key, but any additional field could
be added as well.

Both key id and origin verification is done in x509_validate_trust().

Thanks,
Dmitry

Dmitry Kasatkin (3):
  KEYS: fix couple of things
  KEYS: validate key trust only with selected owner key
  KEYS: validate key trust only with builtin keys

Mimi Zohar (1):
  KEYS: define an owner trusted keyring

 Documentation/kernel-parameters.txt      |  5 +++++
 crypto/asymmetric_keys/x509_public_key.c | 35 +++++++++++++++++++++++++++++---
 include/linux/key.h                      |  1 +
 kernel/system_keyring.c                  |  1 +
 4 files changed, 39 insertions(+), 3 deletions(-)

-- 
1.9.1


  reply	other threads:[~2014-06-10  8:48 UTC|newest]

Thread overview: 70+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-03 17:58 [RFC PATCH v5 0/4] ima: extending secure boot certificate chain of trust Mimi Zohar
2014-06-03 17:58 ` [RFC PATCH v5 1/4] KEYS: special dot prefixed keyring name bug fix Mimi Zohar
2014-06-06 21:48   ` Dmitry Kasatkin
2014-06-06 22:00     ` Mimi Zohar
2014-06-09  7:56       ` Dmitry Kasatkin
2014-06-09  8:17         ` Dmitry Kasatkin
2014-06-03 17:58 ` [RFC PATCH v5 2/4] KEYS: verify a certificate is signed by a 'trusted' key Mimi Zohar
2014-06-06 21:50   ` Dmitry Kasatkin
2014-06-09 13:13     ` Dmitry Kasatkin
2014-06-09 13:48       ` Mimi Zohar
2014-06-09 14:57         ` Dmitry Kasatkin
2014-06-03 17:58 ` [RFC PATCH v5 3/4] ima: define '.ima' as a builtin 'trusted' keyring Mimi Zohar
2014-06-06 21:53   ` Dmitry Kasatkin
2014-06-06 23:27     ` Mimi Zohar
2014-06-09  8:45       ` Dmitry Kasatkin
2014-06-03 17:58 ` [RFC PATCH v5 4/4] KEYS: define an owner trusted keyring Mimi Zohar
2014-06-09 12:13   ` Dmitry Kasatkin
2014-06-09 12:51     ` Mimi Zohar
2014-06-09 13:05       ` Dmitry Kasatkin
2014-06-09 13:48         ` Mimi Zohar
2014-06-09 13:58           ` Dmitry Kasatkin
2014-06-09 14:06             ` Dmitry Kasatkin
2014-06-09 16:33               ` Mimi Zohar
2014-06-10  8:48                 ` Dmitry Kasatkin [this message]
2014-06-10  8:48                   ` [PATCH 1/4] " Dmitry Kasatkin
2014-06-10 12:24                     ` Josh Boyer
2014-06-10 12:41                       ` Dmitry Kasatkin
2014-06-10 13:07                       ` Mimi Zohar
2014-06-10  8:48                   ` [PATCH 2/4] KEYS: fix couple of things Dmitry Kasatkin
2014-06-10  8:48                   ` [PATCH 3/4] KEYS: validate key trust only with selected owner key Dmitry Kasatkin
2014-06-12 16:03                     ` Vivek Goyal
2014-06-12 16:55                       ` Mimi Zohar
2014-06-12 17:00                         ` Vivek Goyal
2014-06-12 17:17                           ` Mimi Zohar
2014-06-12 17:23                             ` Vivek Goyal
2014-06-12 17:23                       ` Dmitry Kasatkin
2014-06-12 17:32                         ` Vivek Goyal
2014-06-12 17:37                           ` Mimi Zohar
2014-06-12 18:36                           ` Dmitry Kasatkin
2014-06-12 19:01                             ` Vivek Goyal
2014-06-12 19:04                               ` Dmitry Kasatkin
2014-06-12 19:05                               ` Vivek Goyal
2014-06-12 19:15                                 ` Dmitry Kasatkin
2014-06-10  8:48                   ` [PATCH 4/4] KEYS: validate key trust only with builtin keys Dmitry Kasatkin
2014-06-10 12:20                   ` [PATCH 0/4] KEYS: validate key trust with owner and builtin keys only Josh Boyer
2014-06-10 12:52                     ` Mimi Zohar
2014-06-10 13:21                       ` Dmitry Kasatkin
2014-06-10 13:29                         ` Josh Boyer
2014-06-10 14:53                           ` Mimi Zohar
2014-06-10 12:58                     ` Dmitry Kasatkin
2014-06-10 15:08                       ` Matthew Garrett
2014-06-10 20:39                     ` Dmitry Kasatkin
     [not found]                     ` <CACE9dm9Ff6b3J=05QfcgBv-c_y=5qGNq1-ZSfo4smtj34i1e-A@mail.gmail.com>
2014-06-10 20:40                       ` Matthew Garrett
2014-06-10 21:00                         ` Dmitry Kasatkin
2014-06-10 21:17                           ` Dmitry Kasatkin
2014-06-10 21:25                             ` Matthew Garrett
2014-06-10 21:34                               ` Dmitry Kasatkin
2014-06-10 21:40                                 ` Matthew Garrett
2014-06-10 21:45                                   ` Dmitry Kasatkin
2014-06-11  1:24                                   ` Mimi Zohar
2014-06-11  2:22                                     ` Matthew Garrett
2014-06-11  3:08                                       ` Mimi Zohar
2014-06-11  3:23                                         ` Matthew Garrett
2014-06-11 12:30                                           ` Mimi Zohar
2014-06-11 15:20                                             ` Matthew Garrett
2014-06-27 14:16                                         ` David Howells
2014-06-10 21:40                                 ` Dmitry Kasatkin
2014-06-10 12:45                   ` Mimi Zohar
2014-06-10 12:49                     ` Dmitry Kasatkin
2014-06-11 20:49                       ` Mimi Zohar

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=cover.1402387862.git.d.kasatkin@samsung.com \
    --to=d.kasatkin@samsung.com \
    --cc=dhowells@redhat.com \
    --cc=dmitry.kasatkin@gmail.com \
    --cc=jwboyer@redhat.com \
    --cc=keyrings@linux-nfs.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --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.