linux-kernel - Re: [GIT PULL] Load keys from signed PE binaries

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: <20130226033803.GA30285@srcf.ucam.org>
Date:	Tue, 26 Feb 2013 03:38:04 +0000
From:	Matthew Garrett <mjg59@...f.ucam.org>
To:	Greg KH <gregkh@...uxfoundation.org>
Cc:	David Howells <dhowells@...hat.com>,
	Florian Weimer <fw@...eb.enyo.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Josh Boyer <jwboyer@...hat.com>,
	Peter Jones <pjones@...hat.com>,
	Vivek Goyal <vgoyal@...hat.com>,
	Kees Cook <keescook@...omium.org>, keyrings@...ux-nfs.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] Load keys from signed PE binaries

On Mon, Feb 25, 2013 at 07:31:56PM -0800, Greg KH wrote:
> On Tue, Feb 26, 2013 at 03:13:38AM +0000, Matthew Garrett wrote:
> > Because Microsoft have indicated that they'd be taking a reactive 
> > approach to blacklisting and because, so far, nobody has decided to 
> > write the trivial proof of concept that demonstrates the problem.
> 
> So, once that proof is written, suddenly all of the working Linux
> distros's keys will be revoked?  That will be fun to watch happen, and
> odds are, it will not.  Imagine the PR fun that will cause :)

No. Why would they be?

> > "In addition, in the case of Microsoft’s digital signatures of UEFI 
> > Code, Microsoft may remove a Compatible Product from the Microsoft 
> > Compatibility Lists and/or revoke the digital signature upon 30 days’ 
> > notice to Company in the event Microsoft determines in its sole judgment 
> > that the security of the UEFI Code is compromised."
> > 
> > The ability to use the signed code to boot an untrusted copy of the 
> > Windows kernel is a clear breach of the trust model.
> 
> I don't buy it.  Yes, I understand this is your position, and has been
> all along, and _maybe_ you can extend it to "we should sign our kernel
> modules", but to take it farther than that, like the list David has
> described, is not required by anyone here.

Failing to take it to that extent is dangerously naive. If you can do it 
with kernel modules, you can do it with kexec. If you can do it with 
kexec, you can do it with arbitrary mmio access to PCI devices.

> Yes, they are all "nice" things to have, but I fail to see how Microsoft
> should be dictating how Linux, or any other operating system, works,
> especially when they aren't even signing the kernel, they are merely
> signing a bootloader shim and saying "do your best for keeping the rest
> of the system secure please."

Microsoft aren't dictating anything here. We're free not to use their 
signatures. However, if we do use their signatures, we agree to play by 
their rules. Nobody seems to have come up with a viable alternative, so 
here we are.

-- 
Matthew Garrett | mjg59@...f.ucam.org
--
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/