linux-kernel - Re: Should we automatically generate a module signing key at all?

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: <20150522141358.2581.qmail@ns.horizon.com>
Date:	22 May 2015 10:13:58 -0400
From:	"George Spelvin" <linux@...izon.com>
To:	linux@...izon.com, torvalds@...ux-foundation.org
Cc:	dhowells@...hat.com, dwmw2@...radead.org,
	linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org, luto@...capital.net,
	petkan@...-labs.com, tytso@....edu, zohar@...ux.vnet.ibm.com
Subject: Re: Should we automatically generate a module signing key at all?

Linus Torvalds wrote:
> It's also very annoying because the whole build gets much nastier,
> particularly if you want to have modules in external trees.
> 
> In short, I don't see any actual *advantages* over just using signed
> modules. Signing is much more flexible, and thanks to that extra
> indirection (the signing key), there are no ordering constraints on
> generating modules vs the kernel.

That's why I originally wrote:
>> To address other use cases, it's possible to allow multiple authentication
>> systems.  You can generate one big tree for in-tree modules, then either
>> additional trees or the existing public-key signatures for additions.

Reproducible builds are an attractive security feature; they enable
things like distributed double compilation.  But as you point out,
his proposed mechanism is annoyingly less flexible.

It would have to be an optional alternative to the existing public key,
not a replacement.

It seems that there are two basic ways to satisfy the distributions:

1) Create a tool to canonicalize the kernel and modules,
   stripping out the signatures before comparing them.  This has
   precedent in the way the prelink tool can un-prelink binaries
   so that hashes can be verified.

2) Provide something like Andy's hash tree that covers the in-tree case,
   in addition to the existing public-key signatures.  A reproducible
   build would just not use the public key, but it would still be available.

   One note: if the module hash database were kept separately from the
   modules, then it would only need to store the 2n-1 distinct hashes,
   not n log n.  Or, if you don't mind doing a bit more hashing, you
   could just store the n module hashes and linearly hash that list.
   That's reasonable as long as the master list of modules (32 bytes
   per module) is no larger than the modules being verified.

In both cases, the additional code is part of the attack surface.
The issue is which is less effort, less bugs, and more secure?

While option 1 avoids complcating the kernel by throwing the entire
problem over the fence to the distributions, Andy has a point that adding
option 2 to the kernel might be a lot simpler overall.

I'm also trying to think if the same issues might arise for other
code that loads modules, but the signatures are only an issue when
the "main" binary is loaded from a more trustworthy source than the
modules, a situation that is rare outside the kernel.
--
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/