linux-kernel - Re: [PATCH] MODSIGN: Change default key details [ver #2]

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]

Message-ID: <1430714551.5800.93.camel@memnix.com>
Date:	Mon, 04 May 2015 00:42:31 -0400
From:	Abelardo Ricart III <aricart@...nix.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Michal Marek <mmarek@...e.cz>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Sedat Dilek <sedat.dilek@...il.com>,
	David Howells <dhowells@...hat.com>, keyrings@...ux-nfs.org,
	Rusty Russell <rusty@...tcorp.com.au>,
	LSM List <linux-security-module@...r.kernel.org>,
	James Morris <james.l.morris@...cle.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [PATCH] MODSIGN: Change default key details [ver #2]

On Sun, 2015-05-03 at 18:45 -0700, Linus Torvalds wrote:
> On Sat, May 2, 2015 at 2:46 AM, Abelardo Ricart III <aricart@...nix.com>
> wrote:
> >  endif
> > 
> > -signing_key.priv signing_key.x509: x509.genkey
> > +signing_key.priv signing_key.x509: | x509.genkey
> 
> Hmm. Thinking some more about this, I'm not entirely convinced.
> 
> With this change, if we change kernel/Makefile to have a different
> keysigning authority etc, it won't re-generate the keys, because the
> old keys still exist. No? That would be wrong.
> 

That's correct. I was under the impression that having the Makefile generate
the signing keys was something that was done just to prevent a build failure
with CONFIG_MODULE_SIG but no keys. The comment above the key generation target
seems to say that.

David Howells' patch to make the key details "more obviously unspecified" seems
to be along those lines as well; that those generated keys are simply a generic
way to have signed modules without managing your own keys. In that case, the
actual contents of x509.genkey would be of little significance because those
keys are entirely generic and transient. 

> I'd much rather see "x509.genkey" be generated with a move-if-changed
> pattern, so that it only changes if (a) it didn't exist before or (b)
> it actually has new content.
> 

And this would indeed trigger key regeneration by make. But what if I do manage
my own keys? As I said, I wouldn't want the Makefile to touch them at all, even
if the x509.genkey config is missing or was changed. 

So we have two use cases here: people who use auto-generated keys and people
who use their own keys. Sounds like this could be a good case for having a
config option that tells make which group you fall under? Something like
"CONFIG_MODULE_SIG_GEN_KEY"?

If CONFIG_MODULE_SIG_GEN_KEY=y, keys are (re)generated based on the internal
x509.genkey.

If CONFIG_MODULE_SIG_GEN_KEY is not set, keys are only (re)generated if they
don't already exist, which is what my patch would do (and what the
documentation implies should be happening now).

> On a tangentially related issue: I figured out why I get those (very
> annoying) "X.509 certificate list changed" messages. I made it print
> out *what* changed:
> 
>     X.509 certificate list changed from ./signing_key.x509 to signing_key.x509
> 
> Note the "./" difference.
> 
>                     Linus

That Makefile could use a makeover. Pun intended.
--
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/