Fedora could seek Microsoft code signing to contend with secure boot

A bootloader signed by MS would make Fedora easy to install on Windows 8 PCs.

Future versions of Fedora could come with a bootloader that is signed by Microsoft, a move that would ensure that the Linux distribution is easy to install on computers with the secure boot mechanism. The proposal was described in a blog entry this week by Red Hat kernel developer Matthew Garrett.

Microsoft’s compatibility certification criteria for Windows 8 requires PC vendors to adopt UEFI and enable secure boot. The transition to signed bootloaders will help protect users against certain kinds of malware, but it could also pose an obstacle for for users who want to run third-party operating systems.

In a hardware environment with secure boot, the code that bootstraps the operating system must be signed with a key that corresponds with a certificate stored in the computer’s firmware. The computer will refuse to execute code that lacks a trusted signature. The purpose of this mechanism is to prevent arbitrary, untrusted code from running during startup and tampering with the operating system.

In order to accommodate Linux and the long tail of other operating systems, PC vendors are required to provide a path for end users to install their own custom secure boot certificates or disable secure boot entirely. These options will satisfy the needs of enthusiasts who don’t want to sacrifice the freedom and flexibility that have historically been available on x86 hardware.

That solution is not without problems, however. Disabling secure boot would leave the user exposed to some malware threats. More importantly, the process of installing a custom certificate will likely not be easy enough for non-technical and inexperienced users. That means it isn’t an acceptable compromise for Linux distributions that want to offer the lowest possible barrier to entry for new users.

According to Garrett, the simplest solution is for the Fedora project to use Microsoft’s signing service to sign the Linux distribution’s bootloader. Enrolling in the signing service will require Fedora to make a one-time payment of $99 to Verisign.

Garrett’s plan calls for using the signing service on a lightweight bootloader shim that will be responsible for initiating GNU’s GRUB bootloader. Isolating the signature to a very thin bootloader initialization layer will make it so that the Fedora developers won’t have to deal with Microsoft’s manual signing process every time that they want to push out an update to GRUB.

In order for the technical advantages of the secure boot mechanism to be fully realized, however, all of the code in the platform that has direct interaction with hardware has to be trustworthy, too. A malicious party could theoretically use the Linux kernel’s low-level hardware access to compromise a Windows installation on the same computer or tamper with the firmware.

If that is possible on a Fedora system with a signed bootloader, then Fedora’s signing privileges would be revoked and the operating system would no longer be able to run in a secure boot environment. To prevent such a scenario from occurring, Fedora will set up its own signing system that will be applied to the kernel and other security-sensitive layers of the stack below the Microsoft-signed bootloader initialization layer.

As Garrett acknowledged in his blog post, it’s not really clear yet if this approach can be made to accommodate third-party Linux drivers that are maintained outside of the kernel source code. Although the practice of maintaining drivers outside of the tree is strongly discouraged in Linux development, the reality is that there are still some important drivers that are developed in that fashion—particularly proprietary graphics drivers.

Code signing and secure boot represent a transition to a more appliance-like computing model. Although that trend is distressing to sophisticated Linux enthusiasts who value technical freedom and autonomy, the clear security advantages are a boon to regular end users who need all the help that they can get to minimize the threat landscape. Fedora’s proposed solution isn’t ideal, but it’s a compromise that will work.

I don't know why red hard and canonical can't combine forces and start a small hardware company to make laptops and tablets. It would seem to be in their best interest if this restriction is going to be become popular once windows 8 is released.

What would stop an attacker configuring Fedora (or Windows for that matter) to boot Windows in an immersive virtual machine? The virtual machine can lie to the guest Windows that it booted securely when actually it has been compromised.

The only indications to the user would be a slightly longer boot time and slightly reduced performance.

Maybe a secure booting windows always shows a logo at startup and always remains at the metro start screen and that's why Windows couldn't be used as the host OS in this attack.

According to Garret, the simplest solution is for the Fedora project to use Microsoft’s signing service to sign the Linux distribution’s bootloader. Enrolling in the signing service will require Fedora to make a one-time payment of $99 to Microsoft.

Why is MS in charge of the signing process instead of some separate organization? That just seems all kinds of wrong.

According to Garret, the simplest solution is for the Fedora project to use Microsoft’s signing service to sign the Linux distribution’s bootloader. Enrolling in the signing service will require Fedora to make a one-time payment of $99 to Microsoft.

Why is MS in charge of the signing process instead of some separate organization? That just seems all kinds of wrong.

According to Garret, the simplest solution is for the Fedora project to use Microsoft’s signing service to sign the Linux distribution’s bootloader. Enrolling in the signing service will require Fedora to make a one-time payment of $99 to Microsoft.

Why is MS in charge of the signing process instead of some separate organization? That just seems all kinds of wrong.

Or did I misunderstand something?

Windows will be signed with Microsoft's key only. Practically all hardware vendors want Windows to work as easily as possible on their hardware. Therefore, practically all hardware vendors ship Microsoft's key.

If another OS wants to be trusted by nearly every PC, they have to use Microsoft's key as it will be the key with the widest deployment (by far).

Other people and companies can go to each hardware vendor individually and ask them to ship their key. Giving 99 dollars (to Verisign not Microsoft) is far easier than persuading every single hardware vendor to ship their key.

Wait, doesn't this mean there will be binary blobs? - In Fedora?!? I expected they would be the last ones to do this.

No, the source code for the signed bootloader will still be available. The blog post explains that it'll even come with instructions on how to build it and sign it yourself if you want to use your own version - whether you sign it with another key that you install into your system's keystore, or just turn off secure boot and do things the old-fashioned way.

Although you can't turn off secure boot on ARM devices for Windows 8, Microsoft have mandated that as they've mandated that you can turn it off or install custom keys on x86 hardware. Really keen on keeping ARM systems as more iOS or Android-like devices rather than general-purpose computers, it seems.

According to Garret, the simplest solution is for the Fedora project to use Microsoft’s signing service to sign the Linux distribution’s bootloader. Enrolling in the signing service will require Fedora to make a one-time payment of $99 to Microsoft.

Why is MS in charge of the signing process instead of some separate organization? That just seems all kinds of wrong.

Or did I misunderstand something?

As "Chris__" above you said, it's going to Verisign, not Microsoft.

Yeah, I started writing my comment before he posted his so I didn't know. Makes a lot more sense that way.

So, Microsoft is bringing the locked bootloader asshattery from cellphones into PCs; and, this just as phone manufacturers are finally coming around to the notion that a lot of their most loyal and interested customers actually don't want that crap, and are giving folks a way out of it.

It's worth going back and reading Garrett's extensive coverage of the topic on his blog; this workaround is an option on X86 with UEFI, but Microsoft's restrictions on ARM are far more strict, to the point where people interested in installing their own OS should just eschew a Windows 8 ARM machine altogether.

While I understand the security concerns this is meant to address, Microsoft's restrictions are so anti-user, anti-innovation and anti-competition that I really hope it ends up being grounds to revisit the Microsoft monopoly case. They've inserted themselves as the gatekeepers for installing not just their software, but *any* software that modifies the bootloader on a potientially huge number of devices.

In order for the technical advantages of the secure boot mechanism to be fully realized, however, all of the code in the platform that has direct interaction with hardware has to be trustworthy, too ... If that is possible on a Fedora system with a signed bootloader, then Fedora’s signing privileges would be revoked

And if someone creates a driver that turns out to be untrustworthy, does this mean Windows' signing privileges will be revoked too?

So, Microsoft is bringing the locked bootloader asshattery from cellphones into PCs; and, this just as phone manufacturers are finally coming around to the notion that a lot of their most loyal and interested customers actually don't want that crap, and are giving folks a way out of it.

It's worth going back and reading Garrett's extensive coverage of the topic on his blog; this workaround is an option on X86 with UEFI, but Microsoft's restrictions on ARM are far more strict, to the point where people interested in installing their own OS should just eschew a Windows 8 ARM machine altogether.

While I understand the security concerns this is meant to address, Microsoft's restrictions are so anti-user, anti-innovation and anti-competition that I really hope it ends up being grounds to revisit the Microsoft monopoly case. They've inserted themselves as the gatekeepers for installing not just their software, but *any* software that modifies the bootloader on a potientially huge number of devices.

If anyone has a monopoly for ARM based tablets its Apple not Microsoft.

As much as we (the technically competent) like to think we matter, the vast majority do not care about boot loaders. Since the vast majority of malware seem to require user interaction, and users have proven time and time again they cant resist clicking on everything, then they need computers with training wheels that prevent them from doing damage to others.

Although that trend is distressing to sophisticated Linux enthusiasts who value technical freedom and autonomy, the clear security advantages are a boon to regular end users who need all the help that they can get to minimize the threat landscape

[citation needed]

I absolutely do not see the "clear security advantages" this provides over signed rpms, tripwire, selinux and responsible use of superuser access. The main security liability of any system lies at the interface between the keyboard and the chair, and this is not going to change that fact.

Signed bootloaders are still not going to prevent users to install crap on their machine, run it as root for some asinine reason, and then complain that it f*ed up their system. Just like sex ed to prevent teen pregnancies, computer literacy education is what is needed there.

Although that trend is distressing to sophisticated Linux enthusiasts who value technical freedom and autonomy, the clear security advantages are a boon to regular end users who need all the help that they can get to minimize the threat landscape

[citation needed]

I absolutely do not see the "clear security advantages" this provides over signed rpms, tripwire, selinux and responsible use of superuser access. The main security liability of any system lies at the interface between the keyboard and the chair, and this is not going to change that fact.

Signed bootloaders are still not going to prevent users to install crap on their machine, run it as root for some asinine reason, and then complain that it f*ed up their system. Just like sex ed to prevent teen pregnancies, computer literacy education is what is needed there.

Secure *boot* may not prevent bad applications from being installed, but it can prevent bad applications from being part of the *boot* process. Malware/rootkits that take over your computer can instantly be a thing of the past, in theory.

The main security liability of any system lies at the interface between the keyboard and the chair, and this is not going to change that fact.

Well, precisely. This policy sets up the end user as an un-trusted, hostile entity and treats them as such. That it makes life difficult for the technologically knowledgeable, or those interested in learning other platforms, is completely immaterial.

Quote:

Signed bootloaders are still not going to prevent users to install crap on their machine

With Windows 8, they want users installing things from the Microsoft Store, which is the only way to get Metro applications. They're going to be pushing hard to rapidly transition end users into this walled garden, I expect that Windows 9 will virtualize any win32 applications.

Quote:

run it as root for some asinine reason

Which is again, curious. As root you can do virtually anything (including directly prod hardware.) I wonder if this means that "secure" version of Fedora will deny users root access? They'd have to, really...

The main security liability of any system lies at the interface between the keyboard and the chair, and this is not going to change that fact.

Well, precisely. This policy sets up the end user as an un-trusted, hostile entity and treats them as such. That it makes life difficult for the technologically knowledgeable, or those interested in learning other platforms, is completely immaterial.

Quote:

Signed bootloaders are still not going to prevent users to install crap on their machine

With Windows 8, they want users installing things from the Microsoft Store, which is the only way to get Metro applications. They're going to be pushing hard to rapidly transition end users into this walled garden, I expect that Windows 9 will virtualize any win32 applications.

Quote:

run it as root for some asinine reason

Which is again, curious. As root you can do virtually anything (including directly prod hardware.) I wonder if this means that "secure" version of Fedora will deny users root access? They'd have to, really...

Secure boot is only about the *boot* process, not which application you can run, that is your OS. Secure boot does one thing, it makes sure that only a "trusted" bootloader is actually loaded, and allows said boot-loader to enforce that only a trust Kernel/drivers are loaded. Once that part is done, the OS takes over.

This ensures that malware/root kits may not load before or during the boot process, before the OS can even stop it.

This ensures that malware/root kits may not load before or during the boot process, before the OS can even stop it.

Which can only happen if an OS you booted at some point let it happen. Secure the OS, and you don't have that problem anymore.

microlith wrote:

ylandrin wrote:

The main security liability of any system lies at the interface between the keyboard and the chair, and this is not going to change that fact.

Well, precisely. This policy sets up the end user as an un-trusted, hostile entity and treats them as such. That it makes life difficult for the technologically knowledgeable, or those interested in learning other platforms, is completely immaterial.

That won't work. The only thing that will happen is that users will find a way around those restrictions to install the stuff they want (as the popularity of jailbreaking on phones as amply shown). And since you still haven't educated your users, they will still go on and have sex without a condom.

Secure boot is only about the *boot* process, not which application you can run, that is your OS.

I'm aware of that, and everything else you said. It's just the start of that chain of trust that, necessarily, excludes the end user. Microsoft is using it to march towards a walled garden on all platforms. They've wanted it for a while now, going back to Trusted Computing and their Palladium platform but were beaten to the punch by Apple.

As noted above, there are unanswered questions about root access that the security requirements raise. The root user, on Linux, can do ANYTHING. This isn't true on Windows, where the Administrator account is still limited. The kernel will have to be setup in such a way that even if the user gains root access, they don't have control over their platform.

ylandrin wrote:

That won't work. The only thing that will happen is that users will find a way around those restrictions to install the stuff they want (as the popularity of jailbreaking on phones as amply shown). And since you still haven't educated your users, they will still go on and have sex without a condom.

Obviously. That's where I expect Microsoft to take Apple's side the next time jailbreaking comes up for debate in the Library of Congress for DMCA exemptions. They'll push to make talking about those ways a Federal crime.

That won't work. The only thing that will happen is that users will find a way around those restrictions to install the stuff they want (as the popularity of jailbreaking on phones as amply shown). And since you still haven't educated your users, they will still go on and have sex without a condom.

Obviously. That's where I expect Microsoft to take Apple's side the next time jailbreaking comes up for debate in the Library of Congress for DMCA exemptions. They'll push to make talking about those ways a Federal crime.

Unfortunately, I agree with your assessment. And, of course, that will still not make systems more secure. Just the average Joe less able to secure them by himself, while criminals go on merrily to use all the tools knowledge affords.

Well, if wanting to be in control of my hardware makes me a criminal, so be it. And when I will be criminal, I don't see why I should stop at just that. After all, cracking bank systems will be hardly a bigger crime, so why not?/IDontWantToLiveOnThisPlanetAnymore

This ensures that malware/root kits may not load before or during the boot process, before the OS can even stop it.

Which can only happen if an OS you booted at some point let it happen. Secure the OS, and you don't have that problem anymore.

You tell grandma to secure her OS. <-- this is the whole point. The end user can not be trusted. It has been a re-occurring problem for the past 2 decades and I don't see it going away any time soon.

While you live in your little ideal bubble world, the rest of us are trying to make it easy for Joe Smith to secure their own system or to easily recover from a compromised system.

<FacePalm>But this does NOTHING to secure GranMa's OS! She will still install crap on it, and said crap will still be able to fuck up her system, that hasn't changed!And when she calls you to ask you to help clean her system, now you won't be able to boot that rescue CD you wanted to use. This signing requirement REMOVES tools by which end users can secure their system, without adding any security.

This ensures that malware/root kits may not load before or during the boot process, before the OS can even stop it.

Except that, based on my reading, rootkits don't bother with this since it is easier & equality effective to embed themselves into Windows itself rather than running a thin VM or whatever the concept of the boot attack would be. I could be wrong and I am not an expert but I see no one providing evidence that these class of attacks are actual problems.

Also, since apparently certificates will be updated via Windows Update, they are modifiable progammatticaly... which seems even worse than now.

Secure boot is only about the *boot* process, not which application you can run, that is your OS.

I'm aware of that, and everything else you said. It's just the start of that chain of trust that, necessarily, excludes the end user. Microsoft is using it to march towards a walled garden on all platforms. They've wanted it for a while now, going back to Trusted Computing and their Palladium platform but were beaten to the punch by Apple.

As noted above, there are unanswered questions about root access that the security requirements raise. The root user, on Linux, can do ANYTHING. This isn't true on Windows, where the Administrator account is still limited. The kernel will have to be setup in such a way that even if the user gains root access, they don't have control over their platform.

Even if someone installs malware as root under *nix, a secure boot system will make it crazy easy to recover. Just set the kernel to deny any application that isn't signed, then log any attempts to load an unsigned binary, a "safe mode".

Or even better. By default, run in a mode that refuses any unsigned binaries. Secure boot keeps malware from loading before the OS, and the OS only allows binaries that you decide sign/whitelist to let run.

So, Microsoft is bringing the locked bootloader asshattery from cellphones into PCs; and, this just as phone manufacturers are finally coming around to the notion that a lot of their most loyal and interested customers actually don't want that crap, and are giving folks a way out of it.

It's worth going back and reading Garrett's extensive coverage of the topic on his blog; this workaround is an option on X86 with UEFI, but Microsoft's restrictions on ARM are far more strict, to the point where people interested in installing their own OS should just eschew a Windows 8 ARM machine altogether.

While I understand the security concerns this is meant to address, Microsoft's restrictions are so anti-user, anti-innovation and anti-competition that I really hope it ends up being grounds to revisit the Microsoft monopoly case. They've inserted themselves as the gatekeepers for installing not just their software, but *any* software that modifies the bootloader on a potientially huge number of devices.

If anyone has a monopoly for ARM based tablets its Apple not Microsoft.

As much as we (the technically competent) like to think we matter, the vast majority do not care about boot loaders. Since the vast majority of malware seem to require user interaction, and users have proven time and time again they cant resist clicking on everything, then they need computers with training wheels that prevent them from doing damage to others.

This isn't just headed to ARM based tablets. This is coming to x86 based PCs with Windows 8 too. Not only will I have to find a laptop that has good Linux hardware support, but also one that has the ability to turn secure boot off. Thus limiting my options even more. :/

This ensures that malware/root kits may not load before or during the boot process, before the OS can even stop it.

Except that, based on my reading, rootkits don't bother with this since it is easier & equality effective to embed themselves into Windows itself rather than running a thin VM or whatever the concept of the boot attack would be. I could be wrong and I am not an expert but I see no one providing evidence that these class of attacks are actual problems.

Also, since apparently certificates will be updated via Windows Update, they are modifiable progammatticaly... which seems even worse than now.

The theory is that if a rootkit attempts to embed itself into Windows, it will just break that part of Windows and the OS will refuse to load. The OS can also enforce signatures, even after the secure boot process is over.

In theory, the only way to bypass the security is to1) get a hold of the private key of Microsoft/etc2) Modify the white-list <-- this one you mentioned and I'm trying to Google it (certificates will be updated via Windows Update)3) disable secure boot

This isn't just headed to ARM based tablets. This is coming to x86 based PCs with Windows 8 too. Not only will I have to find a laptop that has good Linux hardware support, but also one that has the ability to turn secure boot off. Thus limiting my options even more. :/

Let's be fair: Microsoft's own guidelines mandate that users be able to turn it off on x86 platforms. I don't recall laptops being excluded.

This signing requirement REMOVES tools by which end users can secure their system, without adding any security.

So you're saying there don't exist any malicious bootloaders and that in reality they're just no problem at all? If you think a security measure is only useful if it's the one and all solution to every problem I assume you're no fan of ASLR and DEP either, because those two can also be circumvented and don't apply to all security vulnerabilities.

It's one extremely nasty vulnerability that's already exploited in the real world, certainly closing it can't harm, especially if MS is willing to sign Fedora and possibly other distros as well. People who want to run their own compiled kernels certainly will be capable of figuring out how to disable secure boot and looking around before buying hardware.

This ensures that malware/root kits may not load before or during the boot process, before the OS can even stop it.

Except that, based on my reading, rootkits don't bother with this since it is easier & equality effective to embed themselves into Windows itself rather than running a thin VM or whatever the concept of the boot attack would be. I could be wrong and I am not an expert but I see no one providing evidence that these class of attacks are actual problems.

Also, since apparently certificates will be updated via Windows Update, they are modifiable progammatticaly... which seems even worse than now.

The theory is that if a rootkit attempts to embed itself into Windows, it will just break that part of Windows and the OS will refuse to load. The OS can also enforce signatures, even after the secure boot process is over.

In theory, the only way to bypass the security is to1) get a hold of the private key of Microsoft/etc2) Modify the white-list <-- this one you mentioned and I'm trying to Google it (certificates will be updated via Windows Update)3) disable secure boot

After reading the linked article I do not think that is what it is saying. I believe secure boot only checks the boot loader. TPM would check the OS itself.

Article:"In most PCs today, the pre-operating system environment is vulnerable to attacks by redirecting the boot loader handoff to possible malicious loaders. These loaders would remain undetected to operating system security measures and antimalware software."http://blogs.msdn.com/b/b8/archive/2011 ... -uefi.aspx

Betting Pool on how many hours it takes the first secure boot hardware to be completely bypassed to boot from a USB stick to a standard hacker's tool-chain.

As usual, all the DRM will accomplish here is vendor lock-in that almost exclusively favors Microsoft, and wasting the effort of the software community who have many projects they could be doing instead that are actually worthy.

There's an obvious terminal logic flaw here: EITHER- These computers completely lose the ability to be programmed or run software of the end user's FREE choosing, 100% lock-down and corporate control. -OR- These devices are user programmable and thus hackable.

An un-programmable Linux system is a 100% contradiction of terms, a full-stop oxymoron.

I'm sorry, but this violates the essential fundamental concept of what computers are. I object to the idea that MS or anyone else can slide this change into the market, essentially in the fine print. This amounts to a huge rip-off because people expect the right to run software of their choosing, or even learn to program for themselves, and people can scarcely be expected to grasp the full ramifications of this kind of lock-down when they go out to buy a PC + OS.

Smacks of the typical anti-competitive, anti-trust, etc. objectives that we ought to remember will always be active features in the profit dreams of essentially monopoly players like Microsoft. Maybe the EU will have the guts to see through this and do something about it, and too bad it probably won't make any difference even if they do.

This is ultimately one more reason for me to start pushing for Linux. If someone can be happy in a Win8 lock-down environment, then I'm sure there's an even better Linux distro for them, for free.

The main security liability of any system lies at the interface between the keyboard and the chair, and this is not going to change that fact.

Well, precisely. This policy sets up the end user as an un-trusted, hostile entity and treats them as such. That it makes life difficult for the technologically knowledgeable, or those interested in learning other platforms, is completely immaterial.

Quote:

Signed bootloaders are still not going to prevent users to install crap on their machine

With Windows 8, they want users installing things from the Microsoft Store, which is the only way to get Metro applications. They're going to be pushing hard to rapidly transition end users into this walled garden, I expect that Windows 9 will virtualize any win32 applications.

Quote:

run it as root for some asinine reason

Which is again, curious. As root you can do virtually anything (including directly prod hardware.) I wonder if this means that "secure" version of Fedora will deny users root access? They'd have to, really...

Secure boot is only about the *boot* process, not which application you can run, that is your OS. Secure boot does one thing, it makes sure that only a "trusted" bootloader is actually loaded, and allows said boot-loader to enforce that only a trust Kernel/drivers are loaded. Once that part is done, the OS takes over.

This ensures that malware/root kits may not load before or during the boot process, before the OS can even stop it.

Or people from hacking windows activation

What purpose MS is really going for depends on what you are a fanboy of.

The theory is that if a rootkit attempts to embed itself into Windows, it will just break that part of Windows and the OS will refuse to load. The OS can also enforce signatures, even after the secure boot process is over.

In theory, the only way to bypass the security is to1) get a hold of the private key of Microsoft/etc2) Modify the white-list <-- this one you mentioned and I'm trying to Google it (certificates will be updated via Windows Update)3) disable secure boot

After reading the linked article I do not think that is what it is saying. I believe secure boot only checks the boot loader. TPM would check the OS itself.

Article:"In most PCs today, the pre-operating system environment is vulnerable to attacks by redirecting the boot loader handoff to possible malicious loaders. These loaders would remain undetected to operating system security measures and antimalware software."http://blogs.msdn.com/b/b8/archive/2011 ... -uefi.aspx

I was differentiating the OS from the kernel. The OS is the entire system, the kernel is just the logic that glues it all together. Once the Kernel and the Drivers load, the rest of the OS will load under the guidance of the kernel.

All kernels have a soft under-belly during the boot stage. Once the kernel is up-and-running, it may enforce any kind of restrictions it wants. If it wants an executable to be signed, it can enforce that. It's not a hardware feature, just a basic software feature.

edit "TPM would check the OS itself"

Stuff makes more sense after you post it.. /sigh What you posted does reflect that. So secure boot gets the kernel up and running and the kernel works with TPM to get the rest of the OS working in a secure manner.