| |||||||||||||
SUSE and Secure Boot: The Details (SUSE Blog)SUSE and Secure Boot: The Details (SUSE Blog)Posted Aug 11, 2012 23:03 UTC (Sat) by gmaxwell (subscriber, #30048)In reply to: SUSE and Secure Boot: The Details (SUSE Blog) by geofft Parent article: SUSE and Secure Boot: The Details (SUSE Blog)
> Do you think these are good goals,
Something must be done; this is something, so it must be done!
The goal you're describing is laudable. However, secureboot is neither an effective or necessary measure to achieve that goal.
If the operating system is secure (as in the kernel correctly enforces its policy) then unauthorized software can not replace the bootloader. If the kernel is not secure, than the attacker's _goal_ of fully controlling the system and preventing update that would exclude him can not be thwarted by secureboot. (His rootkit will run shortly after startup and exploit the kernel and prevent its detecton or removal from the startup sequence). This could only be prevented by preventing all execution of unsigned code on the system.
Moreover, a secure boot system which gave a simple easily manually disabled bypass for installing new operating systems: "YOU APPEAR TO BE INSTALLING A NEW OPERATING SYSTEM. IF THIS IS WHAT YOU WANTED SAY YES" would still achieve almost all of whatever small marginal improvement the cryptographic lockdown provides.
As to the question of the problem actually being soluble— it depends on which "the problem" you're speaking of. The problem of it being hard (or eventually impossible) to install non-vendor/microsoft approved distributions, or the problem of some downstream reusers of free software have inequitable access to create software that regular users can run due to their participation in cryptographic lockdown. They are distinct issues, both of which are problematic for the future success of Free Software.
(Log in to post comments)
SUSE and Secure Boot: The Details (SUSE Blog) Posted Aug 11, 2012 23:13 UTC (Sat) by geofft (subscriber, #59789) [Link]
> "YOU APPEAR TO BE INSTALLING A NEW OPERATING SYSTEM. IF THIS IS WHAT YOU WANTED SAY YES"
We all know that users click "Yes" on anything that looks like it might be a dialog box with a "Yes" button.
Possibly having the BIOS cache the boot sector, and completely refuse to boot if the boot sector is modified, unless they go into the BIOS in advance to say "okay, boot any boot sector once", would be helpful.
It may need to cache the stage 1 bootloader, too, and also the stage 1 bootloader will need to be expected to do checks on the rest of the bootloader on the kernel, to enforce the property you want that no untrusted code can run with privilege (and then the kernel does checks on the trusted components of userspace).
Of course, that makes it awkward to deliver software updates to the boot sector / stage 1 bootloader. So maybe those things should just have a digital certificate, and you need to go into the BIOS to say "okay, accept any new certificate once", but don't need to go into the BIOS to accept new boot sectors / bootloaders signed by the certificate.
And this is (unintentionally) starting to sound a lot like Secure Boot as actually defined. In fact, I think approximately the only difference is that Microsoft is being so kind as to let other people's code be signed by their certificate (and that Microsoft still has a monopoly over the PC market, so "being so kind" is pretty much the _least_ they could do to not be abusing their monopoly... but in a more competitive market, this seems technically reasonable).
SUSE and Secure Boot: The Details (SUSE Blog) Posted Aug 12, 2012 17:00 UTC (Sun) by khim (subscriber, #9252) [Link] Possibly having the BIOS cache the boot sector, and completely refuse to boot if the boot sector is modified, unless they go into the BIOS in advance to say "okay, boot any boot sector once", would be helpful. This approach was tried more then decade ago. It does not work. Either user knows nothing about BIOS menus (that's the majority of them!) and only creates needless pressure on support channel or s/he have enough knowleadge to open BIOS menu and boot anyway — in this case they WILL open menu and boot anyway even on malware infected system. You really don't want to give knobs to normal user. Knobs for some geeks (think ChromeOS devices with a switch under battery) are Ok and in fact can be considered security feature (it severely reduces pool of the people who want to crack your boot process), but normal user should never see “yes/no” message.
SUSE and Secure Boot: The Details (SUSE Blog) Posted Aug 12, 2012 0:02 UTC (Sun) by mjg59 (subscriber, #23239) [Link]
"YOU APPEAR TO BE INSTALLING A NEW OPERATING SYSTEM. IF THIS IS WHAT YOU WANTED SAY YES"
A proposal that was explicitly rejected by the industry.
SUSE and Secure Boot: The Details (SUSE Blog) Posted Aug 12, 2012 1:39 UTC (Sun) by dlang (✭ supporter ✭, #313) [Link]
> "YOU APPEAR TO BE INSTALLING A NEW OPERATING SYSTEM. IF THIS IS WHAT YOU WANTED SAY YES"
how exactly would you be sure the user saw this message and is what replies yes to it?
do you even know what video cards are installed in the system? let alone what mode they are in or which of the displays are hooked up to a monitor?
SUSE and Secure Boot: The Details (SUSE Blog) Posted Aug 12, 2012 2:17 UTC (Sun) by gmaxwell (subscriber, #30048) [Link]
> how exactly would you be sure the user saw this message and is what replies yes to it?
> do you even know what video cards are installed in the system? let alone what mode they are in or which of the displays are hooked up to a monitor?
Because it would be displayed by the firmware at boot time. And yes, you can create a situation where a user with e.g. a serial console can't install a /new/ OS without special stunts, just as things _already are_.
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. It's a fact, but it's not a justification. And
> this is (unintentionally) starting to sound a lot like Secure Boot as actually defined. In fact, I think approximately the only difference is that Microsoft
Not unintentionally at all. A previously installed bootloader from a vendor using signing to support remote updates from the author of the bootloader sounds fine for software created under a model where that makes sense. This is orthogonal to the question of authorizing that bootloader in the first place, however. The "only difference" that matters is that under secureboot a new operating system can not be installed at all or only via an opaque, undocumented, and user hostile procedure (depending on the platform and implementation details). 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.
SUSE and Secure Boot: The Details (SUSE Blog) Posted Aug 12, 2012 2:40 UTC (Sun) by dlang (✭ supporter ✭, #313) [Link]
>> how exactly would you be sure the user saw this message and is what replies yes to it?
>> do you even know what video cards are installed in the system? let alone what mode they are in or which of the displays are hooked up to a monitor?
> Because it would be displayed by the firmware at boot time
but it's not boot time that you are installing the OS.
so do you give the warning the next boot after the change?
or are you trying to say that an OS install/upgrade should only be possible through the BIOS?
SUSE and Secure Boot: The Details (SUSE Blog) Posted Aug 13, 2012 1:50 UTC (Mon) by HenrikH (guest, #31152) [Link]
On the next boot of course, just like how Secure Boot detects an invalid key today.
SUSE and Secure Boot: The Details (SUSE Blog) Posted Aug 12, 2012 17:21 UTC (Sun) by khim (subscriber, #9252) [Link] 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?
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.
|
|||||||||||||