Adventures with the UEFI shim

[Paul Moore]

On Sun, Nov 15, 2020 at 9:53 PM James Bottomley
<James.Bottomley at hansenpartnership.com> wrote:
> On Sun, 2020-11-15 at 18:21 -0500, Paul Moore wrote:
> [...]
> > Do you see any reason why the PCR extensions I'm proposing as build
> > time options are a bad idea and not something that should be merged
> > into shim?
>
> Well I don't understand what you're actually trying to do.

My goal is to seal a TPM nvindex containing a secret (let's say a
storage encryption key for the sake of argument) such that it is only
accessible to authorized kernels.  In the case of UEFI Secure Boot,
the plan is that authorization would be determined by the key/cert
used to sign the kernel.  Updates to the firmware, including changes
to the db/dbx variables should be expected during the lifetime of the
system.  There is no safe and/or practical way to track the TPM
ownership credentials of the system outside the TPM itself, and in
some cases trusted physical access to the system will be difficult,
costly, or even impossible.

> What are
> you trying to seal that would be significantly disrupted by periodic
> updates to dbx (I really don't think db updates often enough to be a
> significant problem)?

I think I covered all of that above.

> Plus you seem to have a broken security chain:
> your PCR8 chain doesn't measure the key that signed shim although this
> might be explained if I understood what you were trying to seal ... but
> it does look odd that your variable chain is SecureBoot, PK, KEK, shim
> signing key.

As the KEK secures the db/dbx variables, and their updates, my
understanding is that measuring the SecureBoot, PK, and KEK variables
is sufficient to ensure that the system is running with secure boot
enabled and that the db/dbx variables have not been modified outside
of authorized updates.  Measuring the certificate which verifies the
kernel's signature allows us to determine if the kernel is authorized
to access the TPM based secrets.

Things such as BootGuard are outside the scope of shim, but are part
of the overall solution.

> > Do you see any reason why we need to keep the existing
> > ExitBootServices check as discussed above?  If yes, are you okay with
> > allowing the ExitBootServices check to be disabled via a build time
> > option?
>
> Well, it's not my code, but it does seem to provide additional belt and
> braces security against someone tricking grub into booting an unsigned
> kernel.  I suppose the real question is did we ever sell this to
> Microsoft as a security feature?  Because if so they're unlikely to
> sign a version of shim that has it turned off.

As has already been pointed out above, the ExitBootServices check is
trivially bypassed by a second (or third, or fourth, ...) stage
loader.  If shim's ExitBootServices check turns out to be on a
critical security enforcement path then there are likely serious
issues that need to be addressed independent of the discussion here.

-- 
paul moore
www.paul-moore.com