Personal computing discussed
Moderators: renee, SecretSquirrel, notfred
Dirge wrote:It is certainly great to read of a viable solution/workaround. Does this mitigate any of the security benefits?
Ryu Connor wrote:There has never been an issue that needed to be solved.
UEFI already had the ability for a user to disable the feature or install their own certificates.
Ryu Connor wrote:Linux vendors had already started building solutions.
http://arstechnica.com/information-tech ... cure-boot/
http://arstechnica.com/information-tech ... entations/
Ryu Connor wrote:
Ryu Connor wrote:The lack of understanding on this subject matter is depressing.
Edit: His solution has chain of trust issues.
Captain Ned wrote:Looks like the dev lost his job over this, so he's got no reason not to provide a full solution.
just brew it! wrote:Disabling Secure Boot defeats the entire purpose of Secure Boot, so it is not a good solution. Providing a consistent way of installing the certificate (rather than relying on the user being able to figure out how their specific motherboard does it) seems like a reasonable idea to me.
JBI wrote:Their solution requires the user to confirm that they want to boot the untrusted OS each time the system starts up. Not the end of the world, but definitely annoying, and also has the undesirable side effect of conditioning users to mindlessly answer "Yes" whenever asked if they want to boot an untrusted OS image.
cheesyking wrote:One little snippet around this issue is that I've heard devs complaining that it isn't possible to get your linux boot loader signed by MS without using a copy of windows since the upload page on their website requires silverlight (and moonlight isn't enough).
http://blog.hansenpartnership.com/adven ... i-signing/
I wonder if this is just an oversight by MS or them giving a digital middle finger salute.
just brew it! wrote:He claims in the comment thread that his departure from Redhat was not related to his work on the Secure Boot shim. Sounds like SuSE actually did most of the work on this, he's just the "point man".
just brew it! wrote:This is actually a bit better than I expected. It uses a Microsoft-signed bootloader shim,
Deanjo wrote:This is still a bad thing. Having to have MS sign it creates a dependency that shouldn't be needed.
Ryu Connor wrote:In premise it could be. One just needs to setup the business, get the keys, and then convince every motherboard maker on the planet to integrate your certificate alongside the Microsoft certificate by default.
Captain Ned wrote:Looks like the dev lost his job over this, so he's got no reason not to provide a full solution.
Deanjo wrote:Something like that should be handled by the IEEE or ISO instead of MS.
It's not handled by MS. You don't seem to understand the underlying aspect of this technology. The only reason that Linux vendors are turning to Microsoft for this is because Microsoft has the considerable clout to make vendors install the certificate into the UEFI firmware.
Why would a standards body want to be responsible for a chain of trust in a product they don't own? Who wants that kind of liability?
This is up to OS vendors to deal with. They can either band together and find a way to create incentive so that their certificate ends up in every UEFI firmware or they can leverage the fact the fact that MS has already done that hard work. That's their choice.
Deanjo wrote:What do you mean "It's not handled by Microsoft"? Without MS's stamp of approval, it doesn't get put in. That's MS controlling the situation 100% and that is not a good thing in the least.
I bet the FSF would gladly take control of it.
There are many other ways it could have been handled. If MS made the effort to include the other factions from the get go it could have been more along the lines of the consortium that was put together for other standards such as the Khronos Group.
MS still could have their clout in such a situation where they could have simply said "Don't make provisions for this and you don't get Win X certification".
Ryu Connor wrote:Microsoft does not control secure boot. Secure Boot is a function of the UEFI standard developed by the Unified EFI Forum. No OS vendor has to leverage it. Microsoft has chosen to leverage it as they see it as a beneficial security technology. The concept of secure boot is not new. Trusted Platform Modules (TPM) has done a similar thing for years for laptops and desktops leverage whole disk encryption.
Ryu Connor wrote:Microsoft has decided to let their public private key pair be used by others!
Two weeks ago at the LinuxCon Europe 2012 conference, Bottomley explained in a presentation (slides) why neither the UEFI Consortium nor the Linux Foundation, the hardware manufacturers or any of the Linux distributions have created their own certificate to sign the bootloader in the same way Microsoft does with VeriSign: Apparently, it's simply too expensive. According to Bottomley, the Foundation had negotiated with VeriSign to create a joint signature service – but that VeriSign had wanted several million dollars for such a service. The developer added that the Linux Foundation had also considered starting its own certification authority but had abandoned this plan because it would have required a huge effort and incurred high costs.
kc77 wrote:That's like saying Intel doesn't affect Photoshop. Microsoft is a huge company that can force change on a whim. By MS forcing OEM providers to enable it by default this means that any person who tries to install Linux or anything else will be thwarted (why?). If other OS's like Linux want to have their OS supported by OEM's they have to comply. To get your own OS certificate isn't free. Now if you are anyone else but Microsoft this is a pain because the signed bootloader alone isn't enough. For Secure Boot to work all drivers from tip to tail have to be signed too and work in KMS. Userspace wrappers will no longer suffice. It might sound small to MS but it's a very big deal with a heavy lift for everyone else....all because MS forgot to take it's Midol.
Think about all of those opensource drivers that have been created in Linux that support all of the hardware from at least the mid 90's on. ALL of them will now need to be signed and support KMS settings.
kc77 wrote:This doesn't appear to be the case.
Linux Foundation struggles with Microsoft's Secure Boot signing serviceTwo weeks ago at the LinuxCon Europe 2012 conference, Bottomley explained in a presentation (slides) why neither the UEFI Consortium nor the Linux Foundation, the hardware manufacturers or any of the Linux distributions have created their own certificate to sign the bootloader in the same way Microsoft does with VeriSign: Apparently, it's simply too expensive. According to Bottomley, the Foundation had negotiated with VeriSign to create a joint signature service – but that VeriSign had wanted several million dollars for such a service. The developer added that the Linux Foundation had also considered starting its own certification authority but had abandoned this plan because it would have required a huge effort and incurred high costs.
Ryu Connor wrote:Neither the proposed Linux Foundation Boot loader or the boot loader created and distributed through this very thread requires the entire chain to be signed.
The entire chain being signed is the ideal solution, but not the required one. TPM for example also doesn't require the entire chain to be signed.
Seriously guys, don't come rolling conspiracy theories into this thread if you don't understand the tech. Some of you posting here give me the distinct impression you don't even know the basics of asymmetric encryption, but you're willing to talk about outcomes that require an understanding of said technology.
Manifestation
Kernel-mode drivers will not run if they are not properly signed by a trusted certification authority (CA). The operating system will not allow untrusted drivers to run and standard mechanisms like kernel debugging and test signing will not be permitted.
Ryu Connor wrote:That doesn't contradict my statement, nor does that have anything to do with Microsoft.
“We’re still waiting for Microsoft to give the Linux Foundation a validly signed pre-bootloader,” Bottomley concluded. “When that happens, it will get uploaded to the Linux Foundation website for all to use.”
kc77 wrote:[...]
kc77 wrote:If that's what you believe then that's your opinion.
kc77 wrote:Linux Foundation wrote:“We’re still waiting for Microsoft to give the Linux Foundation a validly signed pre-bootloader,” Bottomley concluded. “When that happens, it will get uploaded to the Linux Foundation website for all to use.”
Yup totally not about Microsoft.
just brew it! wrote:Seems to me it's possible that Microsoft is doing this because they're worried about push-back, or perhaps even anti-trust litigation.
Presumably they will refuse to sign a specific bootloader if they feel it makes it too easy to trick the user into loading something nefarious.
Ryu Connor wrote:The opening post of this very thread you haven't read involves a bootloader having been signed by Microsoft!
This is more interesting. Suse's bootloader design involves the bootloader having its own key database, distinct from those provided by the UEFI specification. The bootloader will execute any second stage bootloaders signed with a key in that database. Since the bootloader is in charge of its own key enrolment, the bootloader is free to impose its own policy - including enrolling new keys off a filesystem.
As I discussed here, this is intended for distributions that want to support secure boot but don't want to deal with Microsoft.
Ryu Connor wrote:http://mjg59.dreamwidth.org/20303.html?thread=783183#cmt783183
Microsoft is involved in this method.
Ryu Connor wrote:What?
Yes, they willingly provided it. It's why he had to pay $99 + notary costs to prove his identity.
The comment you quote at the bottom is just paranoid crank.
What he did is normal. This is what you do to get a signature from a public CA. Web e-commerce is built on this concept.