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:	Tue, 26 Feb 2013 10:30:45 -0500
From:	Vivek Goyal <vgoyal@...hat.com>
To:	Matthew Garrett <mjg59@...f.ucam.org>
Cc:	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

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

Thanks
Vivek
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ