Message-ID: <20130226045747.GA31181@srcf.ucam.org>
Date:	Tue, 26 Feb 2013 04:57:47 +0000
From:	Matthew Garrett <mjg59@...f.ucam.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	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>,
	Vivek Goyal <vgoyal@...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 Mon, Feb 25, 2013 at 08:31:08PM -0800, Linus Torvalds wrote:
> On Mon, Feb 25, 2013 at 7:48 PM, Matthew Garrett <mjg59@...f.ucam.org> wrote:
> >
> > Our users want to be able to boot Linux. If Microsoft blacklist a
> > distribution's bootloader, that user isn't going to be able to boot
> > Linux any more. How does that benefit our users?
> 
> How does bringing up an unlikely and bogus scenario - and when people
> call you on it, just double down on it - help users?

What's unlikely or bogus about it? There's incentive to breach the 
Secure Boot trust model, and to do that you need signed code that'll run 
unsigned code in ring 0. Why would the black hats bother finding more 
subtle exploits if they can just write a new kexec loader?

>  - a distro should sign its own modules AND NOTHING ELSE by default.
> And it damn well shouldn't allow any other modules to be loaded at all
> by default, because why the f*ck should it? And what the hell should a
> microsoft signature have to do with *anything*?

So far? Nothing.

>  - before loading any third-party module, you'd better make sure you
> ask the user for permission. On the console. Not using keys. Nothing
> like that. Keys will be compromised. Try to limit the damage, but more
> importantly, let the user be in control.

So some sort of blocking insmod that waits for a sysrq input? I spent 
some time thinking about that, but then there's people who want 
automated installs on systems with bizarre storage hardware that depends 
on out of tree drivers. Like I said, *I'm* absolutely fine with not 
supporting out of tree drivers at all.

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

> Sure, users will screw that up too. They'll want to load crazy nvidia
> binary modules etc crap. But make it *their* decision, and under
> *their* control, instead of trying to tell the world about how this
> should be blessed by Microsoft.

We can block third party modules by default, but they'll still be 
trusting Microsoft by default.

-- 
Matthew Garrett | mjg59@...f.ucam.org
--
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