lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ