[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-id: <cover.1402387862.git.d.kasatkin@samsung.com>
Date: Tue, 10 Jun 2014 11:48:14 +0300
From: Dmitry Kasatkin <d.kasatkin@...sung.com>
To: zohar@...ux.vnet.ibm.com, dhowells@...hat.com, jwboyer@...hat.com,
keyrings@...ux-nfs.org, linux-security-module@...r.kernel.org
Cc: linux-kernel@...r.kernel.org, dmitry.kasatkin@...il.com,
Dmitry Kasatkin <d.kasatkin@...sung.com>
Subject: [PATCH 0/4] KEYS: validate key trust with owner and builtin keys only
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists