| |||||||||||||
SUSE and Secure Boot: The Details (SUSE Blog)SUSE and Secure Boot: The Details (SUSE Blog)Posted Aug 14, 2012 17:11 UTC (Tue) by khim (subscriber, #9252)In reply to: SUSE and Secure Boot: The Details (SUSE Blog) by HenrikH Parent article: SUSE and Secure Boot: The Details (SUSE Blog)
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.
(Log in to post comments)
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.
|
|||||||||||||