linux-kernel - Re: [PATCH 8/9] MODSIGN: Import certificates from UEFI Secure Boot

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1480015063.2444.9.camel@HansenPartnership.com>
Date:   Thu, 24 Nov 2016 11:17:43 -0800
From:   James Bottomley <James.Bottomley@...senPartnership.com>
To:     Ard Biesheuvel <ard.biesheuvel@...aro.org>,
        David Howells <dhowells@...hat.com>
Cc:     keyrings@...r.kernel.org,
        Matthew Garrett <matthew.garrett@...ula.com>,
        "linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        linux-security-module <linux-security-module@...r.kernel.org>,
        Josh Boyer <jwboyer@...oraproject.org>
Subject: Re: [PATCH 8/9] MODSIGN: Import certificates from UEFI Secure Boot

On Mon, 2016-11-21 at 16:16 +0000, Ard Biesheuvel wrote:
> On 16 November 2016 at 18:11, David Howells <dhowells@...hat.com>
> wrote:
> > From: Josh Boyer <jwboyer@...oraproject.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.

Actually, I think it's a bad idea for the opposite reason: Shim
explicitly pivots the root of trust away from the db keys to its own
Moklist keys.  We have no choice and are forced to trust db for the
secure boot part, but once we're in the kernel proper, I'd argue that
we would only want to trust the pivoted root, i.e. Moklist.

Trusting both could generate unwanted consequences, like pressure on
Microsoft to sign modules or worse, pressure on OEMs to include module
keys or hashes ... or worst of all OEMs signing external modules.

>  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)

OK, so on this point, I'm already not using Shim on my x86 box. 
 However, what you find if you're using grub is that because grub
doesn't do signature verification, you still have to use the shim
protocol callout, so you need something between UEFI and grub to load
at least this protocol.  I suppose this would go away once we can
persuade grub to verify signatures.

James