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: <CALCETrXGv-bi9GKWxm9n71wx6sYotpL4rm9OUB5d2Hh2h9FdJg@mail.gmail.com>
Date:	Tue, 19 May 2015 11:12:17 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	David Woodhouse <dwmw2@...radead.org>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andy Lutomirski <luto@...nel.org>,
	David Howells <dhowells@...hat.com>,
	Michal Marek <mmarek@...e.cz>,
	Abelardo Ricart III <aricart@...nix.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Sedat Dilek <sedat.dilek@...il.com>, keyrings@...ux-nfs.org,
	Rusty Russell <rusty@...tcorp.com.au>,
	LSM List <linux-security-module@...r.kernel.org>,
	Borislav Petkov <bp@...en8.de>, Jiri Kosina <jkosina@...e.cz>
Subject: Re: Should we automatically generate a module signing key at all?

On Tue, May 19, 2015 at 11:08 AM, David Woodhouse <dwmw2@...radead.org> wrote:
> On Tue, 2015-05-19 at 10:58 -0700, Andy Lutomirski wrote:
>>
>> Throwing away the key is outright impossible in some contexts.
>>
>> https://wiki.debian.org/ReproducibleBuilds
>
> Are any of the benefits described at
> https://wiki.debian.org/ReproducibleBuilds/About *not* just as
> achievable with the method I suggested — where you throw away the key
> and just validate that your builds are identical *except* for the
> signatures... which you can reuse, since your builds were identical.

Yes, blatantly.  Quoting that link:

Should reproducible uploads become mandatory, then the incentive of an
attacker to compromise the system of a developer with upload rights is
lowered because it is not anymore possible for the developer to upload
a binary that does not match the uploaded sources.

In the context of a kernel, this means that I shouldn't have to trust
the machine that actually generated the binary.  In principle, I
shouldn't even need to trust the person who generated the package,
since the package should be easily comparable to kernel.org sources.

With your proposal, I need to trust that whoever built the actual
running kernel image really did throw away the key.  If they didn't,
then under whatever threat model requires that I enable module
verification, I'm screwed -- the bad guy has the private key.

The actual runtime code needed to implement a hash tree solution is
maybe twenty lines.  The bzImage will be smaller, and the modules will
be smaller (although the latter is only true because the current
scheme is bloated).  The only tricky part is getting the build process
to work.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ