User: Password:
|
|
Subscribe / Log in / New account

SUSE and Secure Boot: The Details (SUSE Blog)

SUSE and Secure Boot: The Details (SUSE Blog)

Posted Aug 12, 2012 4:54 UTC (Sun) by theophrastus (guest, #80847)
In reply to: SUSE and Secure Boot: The Details (SUSE Blog) by geofft
Parent article: SUSE and Secure Boot: The Details (SUSE Blog)

thank you.

now, if anything, i don't understand the fuss.


(Log in to post comments)

SUSE and Secure Boot: The Details (SUSE Blog)

Posted Aug 12, 2012 5:26 UTC (Sun) by gmaxwell (guest, #30048) [Link]

Then presumably you also don't understand why the large commercial Linux distributors think its important to distribute software which is cryptographically locked with a pre-enrolled certificate chain?

SUSE and Secure Boot: The Details (SUSE Blog)

Posted Aug 12, 2012 5:38 UTC (Sun) by mjg59 (subscriber, #23239) [Link]

Given the combination of how inaccurate that is and how many times this conversation has been had with you, it's difficult to believe you're being anything other than wilfully dishonest at this point. Anything we're distributing will permit the installation of keys by the end user - nothing is cryptographically locked to the shipped keys.

SUSE and Secure Boot: The Details (SUSE Blog)

Posted Aug 12, 2012 6:45 UTC (Sun) by gmaxwell (guest, #30048) [Link]

Your ad hominem now forces me to respond to what is seemingly becoming a pointless subthread—but don't be confused: I'm speaking only to defend my good name and to help clarify for anyone who was confused. I apologize in advance for repeating things almost everyone knows.

Under Red Hat's standing plan (https://fedoraproject.org/wiki/Features/SecureBoot), the system will ship with a bootloader which will only boot a kernel signed by a Red Hat controlled key. This kernel will only load modules signed by a Red Hat controlled key. The early patches to implementing the restrictions are available on your website: http://www.codon.org.uk/~mjg59/tmp/ftsoefi/

The user could replace all the involved keys, but doing so will render their boot chain incompatible with their system unless additional measures are taken. I am assuming that this possible possibility is why you're accusing me of dishonesty?

I know it's hard to tell, but I'm trying to avoid writing a novel in each post. I think it's fair to describe a system as incorporating cryptographic lockdown when it does so, even if there is a convoluted way around it, and especially if even that option may not exist. Otherwise you'd have me saying that the iphone is not locked down— after all, jailbreaking exists for it (and is clearly lawful).

Systems with secureboot enabled will only boot a bootloader signed with an authorized certificate, which the Red Hat one will be signed with. Some systems will likely permit the user to escape from this whole process (by enrolling additional keys in some highly complicated manner, or by disabling the whole thing), but the commercial Linux distributors apparently do not consider this 'jailbreaking' ability to be acceptable—or they would simply avail themselves of it. Regardless, as you pointed out in your very next post, vendors may potentially provide no way to disable it (https://lwn.net/Articles/510827/). This is also what my inquiries have indicated: it won't actually be possible to disable as least in some cases, just as is a _requirement_ for MSFT certification on ARM.

I hope that the inability to disable doesn't turn out to be a common reality, but I am skeptical of the argument that that functionality will deprive these products of Windows 8 certification, in light of the understanding I received (from you) that the original requirements also had the ARM-like limits on x86. Surely there is no reason to believe that Microsoft is obligated to deny their own certification to a vendor who violates their requirements in a manner they are indifferent to. But, even if it is and it remains forever possible to disable this on all PC hardware, I still hold the position that the additional inequality created by access to easy installs is material, and is a violation of the social and economic compromises embodied in copyleft software—but that point is just my opinion.

The rest is just the simple, and I believe fairly uncontroversial facts; and it makes me sad to see you resort to ad hominem here. If you have the spare mental cycles and are willing to be responsive I'd be happy to run all further posts of mine past you for fact checking, because I really do care that I am entirely accurate and not misleading.

SUSE and Secure Boot: The Details (SUSE Blog)

Posted Aug 12, 2012 15:09 UTC (Sun) by mjg59 (subscriber, #23239) [Link]

The implementation will use any keys used in db, and the Suse approach lets us extend this to a separate key database with a consistent and non-arcane management UI. This is a far cry from being "cryptographically locked with a pre-enrolled certificate chain" - it's cryptographically locked with whatever set of keys you want to use.

SUSE and Secure Boot: The Details (SUSE Blog)

Posted Aug 13, 2012 2:58 UTC (Mon) by JoeBuck (guest, #2330) [Link]

I'm delighted to see how open you are to adopting improvements proposed by competitors; it's a refreshing change from the "NIH" attitudes I see so often.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds