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: <87fw0iswja.fsf@mid.deneb.enyo.de>
Date:	Tue, 26 Feb 2013 20:30:17 +0100
From:	Florian Weimer <fw@...eb.enyo.de>
To:	Matthew Garrett <mjg59@...f.ucam.org>
Cc:	Theodore Ts'o <tytso@....edu>,
	Greg KH <gregkh@...uxfoundation.org>,
	David Howells <dhowells@...hat.com>,
	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

* Matthew Garrett:

> On Mon, Feb 25, 2013 at 10:25:08PM -0500, Theodore Ts'o 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.
>> 
>> Microsoft would take a severe hit both from a PR perspective, as well
>> as incurring significant legal risks if they did that in certain
>> jourisdictions --- in particular, I suspect in Europe, if Microsoft
>> were to break the ability of Linux distributions from booting, it
>> would be significantly frowned upon.
>
> If a Linux vendor chose to knowingly breach the obligations they agreed 
> to, you don't think there'd be any PR hit?

I'm sure many folks have read <http://mjg59.dreamwidth.org/12368.html>
("Implementing UEFI Secure Boot in Fedora", 2012-30-05) and similar
analysis and came away with the impression of a rather open, automated
signing process, like we had/have for ActiveX controls and Java
Webstart applications.  This may have helped to increase acceptance of
Microsoft Secure Boot in the technical community.  But lately, in
direct contradiction to earlier descriptions of the process, a lot of
talk about "obligations" has appeared.  I understand that you cannot
go into specifics, but this situation is rather unfortunate for all of
us.

>> So Microsoft may have privately threatened this to certain Red Hat
>> attendees (threats are cheap, but it's not obvious that they would
>> necessarily follow through on this threat.
>
> You're happy advising Linux vendors that they don't need to worry about 
> module signing because it's "not obvious" that Microsoft would actually 
> enforce the security model they've spent significant money developing 
> and advertising?

What are the security objectives for UEFI Secure Boot and the
Microsoft implementation?  What are Microsoft's review critera for
signing and revoking drivers under the UEFI third-party market place
authority?  Is its existence even documented?
--
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/