| |||||||||||||
SUSE and Secure Boot: The Details (SUSE Blog)SUSE and Secure Boot: The Details (SUSE Blog)Posted Aug 12, 2012 17:21 UTC (Sun) by khim (subscriber, #9252)In reply to: SUSE and Secure Boot: The Details (SUSE Blog) by gmaxwell Parent article: SUSE and Secure Boot: The Details (SUSE Blog)
And yes, "the industry" (how polite we are to not name names, I suppose) made an affirmative decision to unnecessarily deny the end users reasonable control over their devices. Wow. Just… wow. That's biggest load of bull I've ever seen. There are no names because this is not something which was decreed by someone but a wisdom gained through much suffering. Different companies reached this point at different time, but by now it's universal knowledge. It may be the only difference, but its the one that matters because its what determines if the owner of the hardware can choose to take control of it by authorizing a free operating system, and its what determines if all downstream distributors of free software have equal access to the deployed equipment. Indeed. Now, please, explain why you are trying to push for the solution which makes owner absolutely powerless? P.S. Before you'll start sputtering nonsense I want to point out that I've typing this on a laptop I don't own (my employer does) and I've first seen this discussion on a phone which I was not mine either (it's owner is a telecom company till I'll pay the rent for two year and it's ownership will be transfereed to me). You said your solution puts owner in control so obviously it should prevent my ability to tinker with these devices somehow… well how exactly it works?
(Log in to post comments)
SUSE and Secure Boot: The Details (SUSE Blog) Posted Aug 13, 2012 1:53 UTC (Mon) by HenrikH (guest, #31152) [Link]
It would probably work just like how you would protect the ability to add keys to Secure Boot today, i.e password protected access to the functionality by your admins. I.e, if you can add keys to Secure Boot then you also press Y to add the current boot loader to the acceptable list, there is no difference in security between the two.
SUSE and Secure Boot: The Details (SUSE Blog) Posted Aug 14, 2012 17:11 UTC (Tue) by khim (subscriber, #9252) [Link] It would probably work just like how you would protect the ability to add keys to Secure Boot today, i.e password protected access to the functionality by your admins. I.e, if you can add keys to Secure Boot then you also press Y to add the current boot loader to the acceptable list, there is no difference in security between the two. Actually there is a difference and it's pretty large one: there are no way to remotely push update in the scheme with password-protected boot loader whitelist. Which makes it, frankly, pretty useless for the absentee owner who does not have physical access to my laptop or phone.
SUSE and Secure Boot: The Details (SUSE Blog) Posted Aug 15, 2012 15:43 UTC (Wed) by HenrikH (guest, #31152) [Link]
Only if the mechanism would only be to whitelist the bootloader, what it could whitelist is the bootloaders certificate authority. There is no reason why this "Press Y to accept the current bootloader" wouldn't work exactly like the "Add custom key" in the BIOS menu.
SUSE and Secure Boot: The Details (SUSE Blog) Posted Aug 15, 2012 19:45 UTC (Wed) by khim (subscriber, #9252) [Link] At this point it's not simple "YOU APPEAR TO BE INSTALLING A NEW OPERATING SYSTEM. IF THIS IS WHAT YOU WANTED SAY YES" system but something similar to SecureBoot.
SUSE and Secure Boot: The Details (SUSE Blog) Posted Aug 15, 2012 20:10 UTC (Wed) by gmaxwell (subscriber, #30048) [Link]
Funny, because thats what I intended to be describing. If it didn't enroll a signing key you couldn't ever apply updates on an unattended machine, which would be pretty boring.
I suspect you're measuring "similar to" in a much different way I am. I don't consider the under the hood mechanism all that important: only the impact on user and developer freedom.
Secureboot unmodified except for a super easy semi-automatic key enrollment process for new OS installs would be a perfectly reasonable thing in my book.
SUSE and Secure Boot: The Details (SUSE Blog) Posted Aug 15, 2012 20:56 UTC (Wed) by mjg59 (subscriber, #23239) [Link]
The SUSE approach effectively gives you that, except for the single small binary object that you don't get to modify. Just pretend that it's part of your firmware instead of being on the media and you'll be fine?
SUSE and Secure Boot: The Details (SUSE Blog) Posted Aug 16, 2012 12:37 UTC (Thu) by anselm (subscriber, #2796) [Link] The unmodifiable-blobs-are-worse-than-builtin-firmware faction is so going to love this …
SUSE and Secure Boot: The Details (SUSE Blog) Posted Aug 16, 2012 16:56 UTC (Thu) by khim (subscriber, #9252) [Link] I suspect you're measuring "similar to" in a much different way I am. I don't consider the under the hood mechanism all that important: only the impact on user and developer freedom. And so do I. The problem with freedom is the infamous Your right to swing your arms ends just where the other man’s nose begins. Some people become upset when they are not given freedom to do something even if there are no reason to perceive that they are indeed entitled for such freedom. "YOU APPEAR TO BE INSTALLING A NEW OPERATING SYSTEM. IF THIS IS WHAT YOU WANTED SAY YES" approach with manual bypass made sense fifty years ago when only trained professionals had access to the big iron systems in a conditioned room. In fact they had no need for such protection because the very fact that they have physical access to the body of the device meant they are privileged enough to do whatever they want with it. In today's world where computers are used everywhere there are huge number of system where the person which actually has physical access to the system does not have the legal right to alter it - and technical solutions must reflect this fact. Secureboot unmodified except for a super easy semi-automatic key enrollment process for new OS installs would be a perfectly reasonable thing in my book. And will be perfectly unreasonable in my book because it'll rob the real owner of the device (the company which paid for it) from the valuable and much-requested capability.
SUSE and Secure Boot: The Details (SUSE Blog) Posted Aug 16, 2012 17:09 UTC (Thu) by gmaxwell (subscriber, #30048) [Link]
If the _owner_ of the system wants to turn it off, then that sounds like a fine accommodation.
I don't see how that has anything to do with how systems shipped by OEMs to end consumers works by default. Secureboot, as its described today, doesn't solve that owner's choice issue itself— it's solved by locking down the system and denying access to the firmware, something that can be done independently of secureboot.
|
|||||||||||||