Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754768AbcKUTSq (ORCPT ); Mon, 21 Nov 2016 14:18:46 -0500 Received: from mx1.redhat.com ([209.132.183.28]:34062 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754104AbcKUTSo (ORCPT ); Mon, 21 Nov 2016 14:18:44 -0500 Date: Mon, 21 Nov 2016 14:18:15 -0500 From: Peter Jones To: Ard Biesheuvel Cc: Josh Boyer , David Howells , keyrings@vger.kernel.org, Matthew Garrett , "linux-efi@vger.kernel.org" , "linux-kernel@vger.kernel.org" , linux-security-module Subject: Re: [PATCH 9/9] MODSIGN: Allow the "db" UEFI variable to be suppressed Message-ID: <20161121191814.fmjzn7c62jgfrtqw@redhat.com> References: <147931984418.16460.6639993676886095760.stgit@warthog.procyon.org.uk> <147931990959.16460.3038875071067540418.stgit@warthog.procyon.org.uk> <20161121190531.dcha3soohybzaqr6@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20161104 (1.7.1) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Mon, 21 Nov 2016 19:18:18 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2561 Lines: 55 On Mon, Nov 21, 2016 at 08:06:44PM +0100, Ard Biesheuvel wrote: > On 21 November 2016 at 20:05, Peter Jones wrote: > > On Mon, Nov 21, 2016 at 04:42:45PM +0000, Ard Biesheuvel wrote: > >> On 21 November 2016 at 16:26, Josh Boyer wrote: > >> > On Mon, Nov 21, 2016 at 11:18 AM, Ard Biesheuvel > >> > wrote: > >> >> On 16 November 2016 at 18:11, David Howells wrote: > >> >>> From: Josh Boyer > >> >>> > >> >>> If a user tells shim to not use the certs/hashes in the UEFI db variable > >> >>> for verification purposes, shim will set a UEFI variable called > >> >>> MokIgnoreDB. Have the uefi import code look for this and ignore the db > >> >>> variable if it is found. > >> >>> > >> >> > >> >> Similar concern as in the previous patch: it appears to me that you > >> >> can DoS a machine by setting MokIgnoreDB if, e.g., its modules are > >> >> signed against a cert that resides in db, and shim/mokmanager are not > >> >> being used. > >> > > >> > If shim/mokmanager aren't used, then you can't actually modify > >> > MokIgnoreDB. Again, it requires physical access and a reboot into > >> > mokmanager to actually take effect. > >> > > >> > >> This does the trick as well > >> > >> printf "\x07\x00\x00\x00\x01" > > >> /sys/firmware/efi/efivars/MokIgnoreDB-605dab50-e046-4300-abb6-3dd810dd8b23 > > > > So that really means two things. First, kernel should only honor any of > > the Mok* variables if they're Boot Services-only variables. Second, to > > avoid the DoS, shim should create them all as Boot Services-only the > > first time it boots. That'll prevent them from being created post-boot. > > > > All of that assumes you are using shim and mokmanager in the first place. No, it doesn't. If you're not using shim, there's no DoS problem, because what would you be DoSing? And likewise, if you're not using Secure Boot at all, you have no guarantee of anything about your boot environment, starting with the idea that the boot loader isn't hostile. If you're not using Secure Boot, a hostile pre-boot driver could easily add DB entries just as easily as MokList entries, or any other variables. The fact that keys can be injected is true with or without this patch, though it does make it easier. But making a boot loader that injects keys into the kernel's built-in keyring isn't actually very difficult. If you're not using firmware enforced SB and shim, you do not have security against this. -- Peter