Thread (40 messages) 40 messages, 10 authors, 2018-03-27

Re: [PATCH 9/9] MODSIGN: Allow the "db" UEFI variable to be suppressed

From: Peter Jones <pjones@redhat.com>
Date: 2016-11-21 19:18:46
Also in: lkml

On Mon, Nov 21, 2016 at 08:06:44PM +0100, Ard Biesheuvel wrote:
On 21 November 2016 at 20:05, Peter Jones [off-list ref] wrote:
quoted
On Mon, Nov 21, 2016 at 04:42:45PM +0000, Ard Biesheuvel wrote:
quoted
On 21 November 2016 at 16:26, Josh Boyer [off-list ref] wrote:
quoted
On Mon, Nov 21, 2016 at 11:18 AM, Ard Biesheuvel
[off-list ref] wrote:
quoted
On 16 November 2016 at 18:11, David Howells [off-list ref] wrote:
quoted
From: Josh Boyer <redacted>

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help