linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH RFC 00/12] Enroll kernel keys thru MOK
@ 2021-07-07  2:43 Eric Snowberg
  2021-07-07  2:43 ` [PATCH RFC 01/12] KEYS: Add KEY_ALLOC_BYPASS_RESTRICTION option to key_move Eric Snowberg
                   ` (13 more replies)
  0 siblings, 14 replies; 30+ messages in thread
From: Eric Snowberg @ 2021-07-07  2:43 UTC (permalink / raw)
  To: keyrings, linux-integrity, zohar, dhowells, dwmw2, herbert,
	davem, jarkko, jmorris, serge
  Cc: eric.snowberg, keescook, gregkh, torvalds, scott.branden,
	weiyongjun1, nayna, ebiggers, ardb, nramas, lszubowi,
	linux-kernel, linux-crypto, linux-security-module,
	James.Bottomley, pjones, glin, konrad.wilk

This is a follow up to the "Add additional MOK vars" [1] series I 
previously sent.  This series incorporates the feedback given 
both publicly on the mailing list and privately from Mimi. This 
series just focuses on getting end-user keys into the kernel trust 
boundary.

Currently, pre-boot keys are not trusted within the Linux boundary [2].
Pre-boot keys include UEFI Secure Boot DB keys and MOKList keys. These
keys are loaded into the platform keyring and can only be used for kexec.
If an end-user wants to use their own key within the Linux trust
boundary, they must either compile it into the kernel themselves or use
the insert-sys-cert script. Both options present a problem. Many
end-users do not want to compile their own kernels. With the
insert-sys-cert option, there are missing upstream changes [3].  Also,
with the insert-sys-cert option, the end-user must re-sign their kernel
again with their own key, and then insert that key into the MOK db.
Another problem with insert-sys-cert is that only a single key can be
inserted into a compressed kernel.

Having the ability to insert a key into the Linux trust boundary opens
up various possibilities.  The end-user can use a pre-built kernel and
sign their own kernel modules.  It also opens up the ability for an
end-user to more easily use digital signature based IMA-appraisal.  To
get a key into the ima keyring, it must be signed by a key within the
Linux trust boundary.

Downstream Linux distros try to have a single signed kernel for each
architecture.  Each end-user may use this kernel in entirely different
ways.  Some downstream kernels have chosen to always trust platform keys
within the Linux trust boundary for kernel module signing.  These
kernels have no way of using digital signature base IMA appraisal. 

This series adds a new MOK variable to shim.  This variable allows the
end-user to decide if they want to trust keys enrolled in the MOK within
the Linux trust boundary.  By default, nothing changes; MOK keys are
not trusted within the Linux kernel.  They are only trusted after the 
end-user makes the decision themselves.  The end-user would set this
through mokutil using a new --trust-mok option [4]. This would work
similar to how the kernel uses MOK variable to enable/disable signature
validation as well as use/ignore the db.

When shim boots, it mirrors the new MokTML Boot Services variable to a new
MokListTrustedRT Runtime Services variable and extends PCR14. 
MokListTrustedRT is written without EFI_VARIABLE_NON_VOLATILE set,
preventing an end-user from setting it after booting and doing a kexec.

When the kernel boots, if MokListTrustedRT is set and
EFI_VARIABLE_NON_VOLATILE is not set, the MokListRT is loaded into the
secondary trusted keyring instead of the platform keyring. Mimi has
suggested that only CA keys or keys that can be vouched for by other
kernel keys be loaded. All other certs will load into the platform
keyring instead.

This is done by introducing a new .mok keyring.  This keyring is only
used during boot.  After booting it is destroyed and not visible to the
end-user after booting completes.  This keyring contains a new keyring
permission that only allows CA keys to be loaded. If the permission
fails, the key is later loaded into the platform keyring.  After keys
are added into the .mok keyring, they are moved into the secondary
trusted keyring.

Secure Boot keys will never be trusted.  They will always be loaded
into the platform keyring.  If an end-user wanted to trust one, they
would need to enroll it into the MOK.

I have included links to both the mokutil [3] and shim [4] changes I
have made to support this new functionality.

Thank you and looking forward to hearing your reviews.

[1] https://lore.kernel.org/linux-integrity/20210517225714.498032-1-eric.snowberg@oracle.com/
[2] https://lore.kernel.org/lkml/1556221605.24945.3.camel@HansenPartnership.com/
[3] https://lore.kernel.org/patchwork/cover/902768/
[4] https://github.com/esnowberg/mokutil/tree/0.3.0-mokvars-v2
[5] https://github.com/esnowberg/shim/tree/mokvars-v2

Eric Snowberg (12):
  KEYS: Add KEY_ALLOC_BYPASS_RESTRICTION option to key_move
  KEYS: Allow unrestricted keys to be moved to the secondary keyring
  KEYS: CA link restriction
  integrity: add integrity_destroy_keyring
  integrity: Introduce mok keyring
  integrity: Trust mok keys if MokListTrustedRT found
  integrity: add add_to_mok_keyring
  integrity: restrict INTEGRITY_KEYRING_MOK to
    restrict_link_by_secondary_trusted_or_ca
  integrity: accessor function to get trust_moklist
  integrity: add new keyring handler
  integrity: move keys from the mok keyring into the secondary keyring
  integrity: Suppress error message for keys added to the mok keyring

 certs/system_keyring.c                        | 43 +++++++++
 crypto/asymmetric_keys/restrict.c             | 60 +++++++++++++
 include/crypto/public_key.h                   |  5 ++
 include/keys/system_keyring.h                 | 21 +++++
 security/integrity/Makefile                   |  3 +-
 security/integrity/digsig.c                   | 26 +++++-
 security/integrity/integrity.h                | 21 ++++-
 .../platform_certs/keyring_handler.c          | 17 +++-
 .../platform_certs/keyring_handler.h          |  5 ++
 security/integrity/platform_certs/load_uefi.c |  5 +-
 .../integrity/platform_certs/mok_keyring.c    | 90 +++++++++++++++++++
 security/keys/keyring.c                       | 10 ++-
 12 files changed, 294 insertions(+), 12 deletions(-)
 create mode 100644 security/integrity/platform_certs/mok_keyring.c


base-commit: 13311e74253fe64329390df80bed3f07314ddd61
-- 
2.18.4


^ permalink raw reply	[flat|nested] 30+ messages in thread

end of thread, other threads:[~2021-07-09 16:00 UTC | newest]

Thread overview: 30+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-07-07  2:43 [PATCH RFC 00/12] Enroll kernel keys thru MOK Eric Snowberg
2021-07-07  2:43 ` [PATCH RFC 01/12] KEYS: Add KEY_ALLOC_BYPASS_RESTRICTION option to key_move Eric Snowberg
2021-07-07  2:43 ` [PATCH RFC 02/12] KEYS: Allow unrestricted keys to be moved to the secondary keyring Eric Snowberg
2021-07-07  2:43 ` [PATCH RFC 03/12] KEYS: CA link restriction Eric Snowberg
2021-07-07  2:43 ` [PATCH RFC 04/12] integrity: add integrity_destroy_keyring Eric Snowberg
2021-07-07  2:43 ` [PATCH RFC 05/12] integrity: Introduce mok keyring Eric Snowberg
2021-07-07 19:31   ` Linus Torvalds
2021-07-07 21:26     ` Jarkko Sakkinen
2021-07-07 22:32       ` Eric Snowberg
2021-07-07  2:43 ` [PATCH RFC 06/12] integrity: Trust mok keys if MokListTrustedRT found Eric Snowberg
2021-07-07  2:43 ` [PATCH RFC 07/12] integrity: add add_to_mok_keyring Eric Snowberg
2021-07-07  2:43 ` [PATCH RFC 08/12] integrity: restrict INTEGRITY_KEYRING_MOK to restrict_link_by_secondary_trusted_or_ca Eric Snowberg
2021-07-07  2:44 ` [PATCH RFC 09/12] integrity: accessor function to get trust_moklist Eric Snowberg
2021-07-07  2:44 ` [PATCH RFC 10/12] integrity: add new keyring handler Eric Snowberg
2021-07-07  2:44 ` [PATCH RFC 11/12] integrity: move keys from the mok keyring into the secondary keyring Eric Snowberg
2021-07-07  2:44 ` [PATCH RFC 12/12] integrity: Suppress error message for keys added to the mok keyring Eric Snowberg
2021-07-07  6:46 ` [PATCH RFC 00/12] Enroll kernel keys thru MOK Christoph Hellwig
2021-07-07 16:23   ` Eric Snowberg
2021-07-07 16:28     ` Christoph Hellwig
2021-07-07 16:45       ` Eric Snowberg
2021-07-07 12:39 ` Mimi Zohar
2021-07-07 16:28   ` Eric Snowberg
2021-07-07 17:00     ` Mimi Zohar
2021-07-07 22:10       ` Eric Snowberg
2021-07-08 13:56         ` Mimi Zohar
2021-07-08 17:59           ` Eric Snowberg
2021-07-08 19:31             ` Mimi Zohar
2021-07-08 23:17               ` Eric Snowberg
2021-07-09  1:10                 ` Mimi Zohar
2021-07-09 15:59                   ` Nayna

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).