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]

Date:	Thu, 21 May 2015 09:50:46 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	David Howells <dhowells@...hat.com>
Cc:	David Woodhouse <dwmw2@...radead.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andy Lutomirski <luto@...nel.org>,
	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 Thu, May 21, 2015 at 9:10 AM, David Howells <dhowells@...hat.com> wrote:
> Andy Lutomirski <luto@...capital.net> wrote:
>
>> Suppose you have a depth-k tree (i.e. up to 2^k modules).  We'll
>> compute a 32-byte value Tree(d, i) for each d from 0 to k and each i
>> from 0 to 2^d-1.  First you assign each module an index starting at
>> zero (with the maximum index less than 2^k).  Then you hash each
>> module.
>
> Now you've got a different problem.  Unless you want to load the entire tree
> in one go (in which case you're back to the kernel space issue), the kernel
> now has to be able to pull it piecemeal from storage and the initramfs builder
> either has to pull in the entire tree or select a subset.  Further, if the
> initfamfs only contains a subtree, then the kernel has to be able to switch to
> the full tree as some point.

Each module would just package its proof as part of the module file.
After the kernel build is done, no one ever needs to see the whole
tree at once.

>
>> > And that doesn't include the issue of hashing the firmware blobs you might
>> > need.
>>
>> As before, that's true.  To verify firmware, either you need to hash
>> it, use a termporary signing key, or use a long-term signing key.
>> Choose your poison.  I still prefer a hash over a temporary signing
>> key.
>
> From a distribution point of view, a hash list of all known firmware is icky
> as all the kernels maintained by the distribution would have to be updated
> each time a new firmware blob needs listing.  Further, all past known firmware
> would have to be kept in the list and could never be discarded lest you
> prevent someone's machine from booting.
>

Sorry, I mis-spoke.  I don't think we should use a hash for firmware,
except possibly for Atomic-like systems, in which case we should
really just turn off firmware signature verification entirely in favor
of using IMA, dm-verity or similar to verify the entire root fs.

--Andy


> David



-- 
Andy Lutomirski
AMA Capital Management, LLC
--
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/