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]

Message-ID: <CA+55aFx9HkRGfMx6pfR2xsTf0vof_yyrT4ks5TzMKoEpS7w=5g@mail.gmail.com>
Date:	Mon, 25 Feb 2013 20:43:59 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Matthew Garrett <mjg59@...f.ucam.org>
Cc:	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 8:23 PM, Matthew Garrett <mjg59@...f.ucam.org> wrote:
>
> If the user has explicitly enrolled a hash then they're stepping outside
> the trust model.

This is the kind of totally bogus crap that no sane person should ever
spout. Stop it.

If the user has explicitly enrolled a hash, then that should be the
*primary* trust model, dammit. That should be very much what you
should care about first and foremost, and that should be your goal in
life. That's when the user says "I'm in control of my own machine, and
I want to trust *this*".

It's not about "stepping outside of the trust model". Quite the
reverse. It's about actually being *part* of the trust model, and
taking control of your own machine. It's the *good* scenario. It's
what you should encourage users to do.

No, it likely can't be the default because we shouldn't expect users
to care enough, but on the other hand the default should definitely
*not* be "enable random third party modules signed indirectly by MS",
which is what your crazy world-view seems to be.

So the first order should be: "we provide modules to cover all normal
users". You use the RH key for that.

The *second* order should be: "we encourage and tell people how to add
their own keys and sign modules they trust".

The third order should probably be "we encourage people to use random
one-time keys - probably with UEFI key checking turned off entirely,
because let's face it, that doesn't really add any real security for
most people". It's what kernel developers and most servers would
probably want to use. They likely don't do the whole UEFI crap anyway,
and random one-time keys are actually better against things like
rootkits etc than *any* centrally administered chain of trust.

Only somewhere really really deep down should the "ok, what about a MS
signature" thing be. It could be part of the user-level application
(part of your distribution) that displays the "are you really sure you
want to load this module with an unrecognized signature? I can tell
that it has a MS signature on it". But by the time you get this far,
you've already failed the first few normal levels.

            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/