[RFC PATCH 0/3] Add additional MOK vars

[Eric Snowberg]

This series is being sent as an RFC. I am looking for feedback; if
adding additional MOK variables would be an acceptable solution to help
downstream Linux distros solve some of the problems we are facing?

Currently, pre-boot keys are not trusted within the Linux boundary [1].
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 [2].  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.  In addition, most downstream kernels
do not have an easy way for an end-user to use digital signature based
IMA-appraisal.

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

The second MOK variable allows a downstream Linux distro to make
better use of the IMA architecture specific Secure Boot policy.  This
IMA policy is enabled whenever Secure Boot is enabled.  By default, this 
new MOK variable is not defined.  This causes the IMA architecture 
specific Secure Boot policy to be disabled.  Since this changes the 
current behavior, it is placed behind a new Kconfig option.  Kernels
built with IMA_UEFI_ARCH_POLICY enabled would  allow the end-user
to enable this through mokutil using a new --ima-sb-enable option [3].
This gives the downstream Linux distro the capability to offer the
IMA architecture specific Secure Boot policy option, while giving
the end-user the ability to decide if they want to use it.

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

Thank you and looking forward to hearing your reviews.

[1] https://lore.kernel.org/lkml/1556221605.24945.3.camel@xxxxxxxxxxxxxxxxxxxxx/
[2] https://lore.kernel.org/patchwork/cover/902768/
[3] https://github.com/esnowberg/mokutil/tree/0.3.0-mokvars
[4] https://github.com/esnowberg/shim/tree/mokvars

Eric Snowberg (3):
  keys: Add ability to trust the platform keyring
  keys: Trust platform keyring if MokTrustPlatform found
  ima: Enable IMA SB Policy if MokIMAPolicy found

 certs/system_keyring.c                        | 19 ++++++++-
 include/keys/system_keyring.h                 | 10 +++++
 security/integrity/ima/Kconfig                |  8 ++++
 security/integrity/ima/ima_efi.c              | 24 ++++++++++++
 .../platform_certs/platform_keyring.c         | 39 +++++++++++++++++++
 5 files changed, 99 insertions(+), 1 deletion(-)

-- 
2.18.4