linux-kernel - Re: RFC: sign the modules at install time

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+55aFzEH1jguw8NB90si2uxvyO63FuKPOc8wiEPRCYwruSzRg@mail.gmail.com>
Date:	Wed, 17 Oct 2012 15:44:28 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	David Howells <dhowells@...hat.com>
Cc:	David Miller <davem@...emloft.net>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	jwboyer@...hat.com, pjones@...hat.com
Subject: Re: RFC: sign the modules at install time

On Wed, Oct 17, 2012 at 3:19 PM, David Howells <dhowells@...hat.com> wrote:
>
> It's probably even better to just get rid of all the automatic module signing
> stuff completely and leave the sign-file script for the builder to use
> manually.  The module verification code will still be present.

That's just disgusting crazy talk.

Christ, David, get a grip on yourself. You seem to dismiss the "people
want to build their own kernel" people entirely.

One of the main sane use-cases for module signing is:

 - CONFIG_CHECK_SIGNATURE=y
 - randomly generated one-time key
 - "make modules_install; make install"
 - "make clean" to get rid of the keys.
 - reboot.

and now you have a custom kernel that has the convenience of modules,
yet is basically as safe as a non-modular build. The above makes it
much harder for any kind of root-kit module to be loaded, and
basically entirely avoids one fundamental security scare of modules.

Everything else is garbage and should largely be ignored. Distro
people who want to use magic distro keys can do whatever the hell they
want with their modules, they'll have a separate packaging phase
anyway for their secret keys - and they'll have to do it separately
anyway just to keep their private key safe.

And the UEFI "we only boot kernels signed by microsoft keys" case is
just BS, and while it might be useful for some people, it's more
likely to be a pain.

In contrast, the case I outlined above is about true *security*, not
some "vendor control" bullshit. And THAT is the case that kernel
developers should encourage: using cryptography to secure individual
users, instead of controlling things for others.

Quite frankly, your "get rid of all the automatic module signing stuff
completely" answer makes me think that your agenda is fundamentally
flawed. Module signing is *not* about some magic redhat or microsoft
key, and anybody who thinks it *should* be about that should seriously
rethink their position.

In fact, if I believed this was about redhat or microsoft keys, I
would never have merged the code at all.

              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/