linux-kernel - Re: [PATCH 0/4] KEYS: validate key trust with owner and builtin keys only

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: <20140610132918.GD31944@hansolo.jdub.homelinux.org>
Date:	Tue, 10 Jun 2014 09:29:18 -0400
From:	Josh Boyer <jwboyer@...hat.com>
To:	Dmitry Kasatkin <d.kasatkin@...sung.com>
Cc:	Mimi Zohar <zohar@...ux.vnet.ibm.com>, dhowells@...hat.com,
	keyrings@...ux-nfs.org, linux-security-module@...r.kernel.org,
	linux-kernel@...r.kernel.org, dmitry.kasatkin@...il.com,
	mjg59@...f.ucam.org
Subject: Re: [PATCH 0/4] KEYS: validate key trust with owner and builtin keys
 only

On Tue, Jun 10, 2014 at 04:21:36PM +0300, Dmitry Kasatkin wrote:
> On 10/06/14 15:52, Mimi Zohar wrote:
> > On Tue, 2014-06-10 at 08:20 -0400, Josh Boyer wrote: 
> >> On Tue, Jun 10, 2014 at 11:48:14AM +0300, Dmitry Kasatkin wrote:
> >>> Also I want to discuss here Fedora UEFI patches as they are the reason for
> >>> the these original patchset.
> >>>
> >>> http://pkgs.fedoraproject.org/cgit/kernel.git/tree/modsign-uefi.patch
> >>>
> >>> They provide functionality to specify MokIgnoreDb variable to limit loading of
> >>> UEFI keys only from MOK List, while ignoring DB. This is certainly a good
> >>> functionality. But once MODULE_SIG_UEFI is enabled, it looks there is no way
> >>> to prevent loading keys from UEFI at all. And this might not be a good default
> >>> functionality. Someone might want not allow loading of keys from UEFI unless
> >>> kernel parameter is specified to allow it without recompiling the kernel
> >>> and disabling MODULE_SIG_UEFI.
> >>>
> >>> Josh, why such design decision was made?
> >> IIRC, it's because kernel parameters can be added programmatically from a
> >> remote user if they gain root access.  Having a kernel parameter to
> >> disable a key piece of secure boot isn't all that great.  We disable
> >> other kernel parameters like acpi_rspd as well.
> > In this case, there shouldn't be a problem as the kernel parameters
> > would further limit the keys usage.
> >
> > Mimi
> 
> Josh probably means that it can be removed and restriction is lifted..
> And after reboot, all keys come to the keyring..

Right.  Or if we went with your suggestion of the default being "do not
load UEFI keys", then they could conversely add the parameter instead.
This might not be an immediate threat to the SB attack vector itself
(thought it could be if I thought about it harder), but it's certainly
a change in system behavior that would catch a user unaware.

At any rate, I'm likely not the best person to weigh in on this aspect.
Matthew has certainly done more thinking about these kinds of problems.

josh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/