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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Mon, 25 Feb 2013 20:31:08 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Matthew Garrett <mjg59@...f.ucam.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 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?

Stop the fear mongering already.

So here's what I would suggest, and it is based on REAL SECURITY and
on PUTTING THE USER FIRST instead of your continual "let's please
microsoft by doing idiotic crap" approach.

So instead of pleasing microsoft, try to see how we can add real security:

 - 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*?

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

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

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.

Because it really shouldn't be about MS blessings, it should be about
the *user* blessing kernel modules.

Quite frankly, *you* are what he key-hating crazies were afraid of.
You peddle the "control, not security" crap-ware. The whole "MS owns
your machine" is *exactly* the wrong way to use keys.

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