[PATCH v6 00/13] Enroll kernel keys thru MOK

[Peter Jones]

On Thu, Sep 16, 2021 at 06:15:50PM +0300, Jarkko Sakkinen wrote:
> On Wed, 2021-09-15 at 15:28 -0600, Eric Snowberg wrote:
> > > On Sep 15, 2021, at 11:57 AM, Jarkko Sakkinen <jarkko at kernel.org> wrote:
> > > 
> > > On Tue, 2021-09-14 at 17:14 -0400, Eric Snowberg wrote:
> > > > Back in 2013 Linus requested a feature to allow end-users to have the 
> > > > ability "to add their own keys and sign modules they trust". This was
> > > > his *second* order outlined here [1]. There have been many attempts 
> > > > over the years to solve this problem, all have been rejected.  Many 
> > > > of the failed attempts loaded all preboot firmware keys into the kernel,
> > > > including the Secure Boot keys. Many distributions carry one of these 
> > > > rejected attempts [2], [3], [4]. This series tries to solve this problem 
> > > > with a solution that takes into account all the problems brought up in 
> > > > the previous attempts.
> > > > 
> > > > On UEFI based systems, this series introduces a new Linux kernel keyring 
> > > > containing the Machine Owner Keys (MOK) called machine. It also defines
> > > > a new MOK variable in shim. This variable allows the end-user to decide 
> > > > if they want to load MOK keys into the machine keyring. Mimi has suggested 
> > > > that only CA keys contained within the MOK be loaded into the machine 
> > > > keyring. All other certs will load into the platform keyring instead.
> > > > 
> > > > By default, nothing changes; MOK keys are not loaded into the machine
> > > > keyring.  They are only loaded after the end-user makes the decision 
> > > > themselves.  The end-user would set this through mokutil using a new 
> > > > --trust-mok option [5]. This would work similar to how the kernel uses 
> > > > MOK variables to enable/disable signature validation as well as use/ignore 
> > > > the db. Any kernel operation that uses either the builtin or secondary 
> > > > trusted keys as a trust source shall also reference the new machine 
> > > > keyring as a trust source.
> > > > 
> > > > Secure Boot keys will never be loaded into the machine keyring.  They
> > > > will always be loaded into the platform keyring.  If an end-user wanted 
> > > > to load one, they would need to enroll it into the MOK.
> > > > 
> > > > Steps required by the end user:
> > > > 
> > > > Sign kernel module with user created key:
> > > > $ /usr/src/kernels/$(uname -r)/scripts/sign-file sha512 \
> > > >   machine_signing_key.priv machine_signing_key.x509 my_module.ko
> > > > 
> > > > Import the key into the MOK
> > > > $ mokutil --import machine_signing_key.x509
> > > > 
> > > > Setup the kernel to load MOK keys into the .machine keyring
> > > > $ mokutil --trust-mok
> > > > 
> > > > Then reboot, the MokManager will load and ask if you want to trust the
> > > > MOK key and enroll the MOK into the MOKList.  Afterwards the signed kernel
> > > > module will load.
> > > > 
> > > > I have included links to both the mokutil [5] and shim [6] changes I
> > > > have made to support this new functionality.
> > > 
> > > How hard it is to self-compile shim and boot it with QEMU (I
> > > do not know even the GIT location of Shim)?
> > 
> > It is not hard, that is the setup I use for my testing.  Upstream shim 
> > is located here [1].  Or you can use my repo which contains the necessary
> > changes [2].
> > 
> > [1] https://github.com/rhboot/shim
> > [2] https://github.com/esnowberg/shim/tree/mokvars-v2
> > 
> 
> So, my 2nd Q would be: which order these should be upstreamed?
> 
> Linux patch set cannot depend on "yet to be upstreamed" things.
> 
> Code changes look good enough to me.

We can carry this support in shim before it's in kernel.  Eric's current
patch for shim and mokutil looks mostly reasonable, though I see a few
minor nits we'll have to sort out.

-- 
        Peter