linux-kernel - Re: [GIT PULL] Load keys from signed PE binaries

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 for Android: free password hash cracker in your pocket

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

Date:	Wed, 27 Feb 2013 09:23:08 -0800
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Vivek Goyal <vgoyal@...hat.com>
Cc:	Matthew Garrett <mjg59@...f.ucam.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	"Theodore Ts'o" <tytso@....edu>,
	Greg KH <gregkh@...uxfoundation.org>,
	David Howells <dhowells@...hat.com>,
	Florian Weimer <fw@...eb.enyo.de>,
	Josh Boyer <jwboyer@...hat.com>,
	Peter Jones <pjones@...hat.com>,
	Kees Cook <keescook@...omium.org>, keyrings@...ux-nfs.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] Load keys from signed PE binaries

Vivek Goyal <vgoyal@...hat.com> writes:

> On Tue, Feb 26, 2013 at 10:30:45AM -0500, Vivek Goyal wrote:
>> On Tue, Feb 26, 2013 at 04:57:47AM +0000, Matthew Garrett wrote:
>> 
>> [..]
>> > >  - encourage things like per-host random keys - with the stupid UEFI
>> > > checks disabled entirely if required. They are almost certainly going
>> > > to be *more* secure than depending on some crazy root of trust based
>> > > on a big company, with key signing authorities that trust anybody with
>> > > a credit card. Try to teach people about things like that instead.
>> > > Encourage people to do their own (random) keys, and adding those to
>> > > their UEFI setups (or not: the whole UEFI thing is more about control
>> > > than security), and strive to do things like one-time signing with the
>> > > private key thrown out entirely. IOW try to encourage *that* kind of
>> > > "we made sure to ask the user very explicitly with big warnings and
>> > > create his own key for that particular module" security. Real
>> > > security, not "we control the user" security.
>> > 
>> > Yes, ideally people will engage in self-signing and distributions will 
>> > have mechanisms for dealing with that.
>> 
>> So even if a user installs its own keys in UEFI to boot self signed
>> shim, kernel and modules, I am assuming that we will still need to
>> make sure kexec does not load and run an unsigned kernel? (Otherwise
>> there is no point in installing user keys in UEFI and there is an
>> easy way to bypass it). 
>
> As I am kind of lost in the long mail thread, so I will ask. If a user
> installs its own keys in UEFI database and boots self signed linux
> kernel, will we still make sure that no unsigned code can be run at
> ring 0 (without explicitly asking user on console).

The short version is what I said at the start.

Whatever kexec does should make sense outside of the context of UEFI and
secure boot.

The point of installing user keys in UEFI is so that the user has
control of when other keys are trusted.  So that the user is not
required to trust Microsoft, or anything signed by Microsoft.  So that
the user has control of the start of the boot process.

One way or another the bad-guys will figure out how to get into
ring0. UEFI secure boot at best means you can wrest back control of your
machine from the bad-guys after that happens.

What kexec checking signatures fundamentally does is make it hard for a
bad guy to pull a fast one and get you to boot a compromised kernel.
That is an interesting problem regardless of secure boot.

Eric
--
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/