lkml.org 
[lkml]   [2016]   [Nov]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH 8/9] MODSIGN: Import certificates from UEFI Secure Boot
From
Date
On Mon, 2016-11-21 at 11:25 -0500, Josh Boyer wrote:
> On Mon, Nov 21, 2016 at 11:16 AM, Ard Biesheuvel
> <ard.biesheuvel@linaro.org> wrote:
> > On 16 November 2016 at 18:11, David Howells <dhowells@redhat.com>
> > wrote:
> > > From: Josh Boyer <jwboyer@fedoraproject.org>
> > >
> > > Secure Boot stores a list of allowed certificates in the 'db'
> > > variable. This imports those certificates into the system trusted
> > > keyring. This allows for a third party signing certificate to
> > > be used in conjunction with signed modules. By importing the
> > > public certificate into the 'db' variable, a user can allow a
> > > module signed with that certificate to load. The shim UEFI
> > > bootloader has a similar certificate list stored in the
> > > 'MokListRT' variable. We import those as well.
> > >
> >
> > This sounds like a bad idea to me. For the standard databases like
> > db and dbx, we can rely on the firmware to ensure that they are
> > what you expect. For MokListRt, not so much: anyone with sufficient
> > capabilities can generate such a variable from userland, and not
> > every arch/distro combo will be using shim and/or mokmanager. (The
> > debates are still ongoing, but my position is that there is no need
> > for shim at all on ARM given that the M$ problem only exists on
> > x86)
>
> In order for MokListRT to be modified, the user has to have physical
> access and boot into Mok and complete the enrollment. That is no
> different than simply enrolling in db or dbx. I don't see a
> difference in security under the thread model that Secure Boot is
> attempting to protect against.

Isn't a potential attack to write to MokListRT and then force a kexec?
That means shim doesn't validate the variable yet you treat it as
though it has been validated.

James


\
 
 \ /
  Last update: 2016-11-24 20:23    [W:0.064 / U:0.416 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site