From: Jarkko Sakkinen <jarkko@kernel.org>
To: Eric Snowberg <eric.snowberg@oracle.com>
Cc: keyrings@vger.kernel.org, linux-integrity@vger.kernel.org,
dhowells@redhat.com, dwmw2@infradead.org,
dmitry.kasatkin@gmail.com, jmorris@namei.org,
linux-kernel@vger.kernel.org,
linux-security-module@vger.kernel.org, zohar@linux.ibm.com,
torvalds@linux-foundation.org, serge@hallyn.com,
James.Bottomley@hansenpartnership.com, pjones@redhat.com,
glin@suse.com
Subject: Re: [RFC PATCH 0/3] Add additional MOK vars
Date: Wed, 19 May 2021 10:55:33 +0300 [thread overview]
Message-ID: <YKTEdWgwy0R1qpOE@kernel.org> (raw)
In-Reply-To: <20210517225714.498032-1-eric.snowberg@oracle.com>
On Mon, May 17, 2021 at 06:57:11PM -0400, Eric Snowberg wrote:
> 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
Nit: would be nice to just say "what it is" instead "what it allows".
> 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@HansenPartnership.com/
> [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
>
>
/Jarkko
next prev parent reply other threads:[~2021-05-19 7:55 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-17 22:57 [RFC PATCH 0/3] Add additional MOK vars Eric Snowberg
2021-05-17 22:57 ` [RFC PATCH 1/3] keys: Add ability to trust the platform keyring Eric Snowberg
2021-05-20 15:59 ` Jarkko Sakkinen
2021-05-17 22:57 ` [RFC PATCH 2/3] keys: Trust platform keyring if MokTrustPlatform found Eric Snowberg
2021-05-17 22:57 ` [RFC PATCH 3/3] ima: Enable IMA SB Policy if MokIMAPolicy found Eric Snowberg
2021-05-19 7:55 ` Jarkko Sakkinen [this message]
2021-05-19 14:32 ` [RFC PATCH 0/3] Add additional MOK vars Mimi Zohar
2021-05-19 22:04 ` Eric Snowberg
2021-05-20 12:22 ` Mimi Zohar
2021-05-20 20:37 ` Eric Snowberg
2021-05-21 11:44 ` Mimi Zohar
2021-05-24 0:57 ` Eric Snowberg
2021-05-24 11:12 ` Mimi Zohar
2021-06-01 15:24 ` Eric Snowberg
2021-05-24 10:09 ` Dr. Greg
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=YKTEdWgwy0R1qpOE@kernel.org \
--to=jarkko@kernel.org \
--cc=James.Bottomley@hansenpartnership.com \
--cc=dhowells@redhat.com \
--cc=dmitry.kasatkin@gmail.com \
--cc=dwmw2@infradead.org \
--cc=eric.snowberg@oracle.com \
--cc=glin@suse.com \
--cc=jmorris@namei.org \
--cc=keyrings@vger.kernel.org \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=pjones@redhat.com \
--cc=serge@hallyn.com \
--cc=torvalds@linux-foundation.org \
--cc=zohar@linux.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.