Didn't you love those classic '90s "Linux installation reports"?

[Pepinno]

You don't need signed kernels, just a signed GRUB, which is already provided. As I said, the problem was solved years ago already. By none other than Microsoft. Which nullifies the rest of your post. You're just spreading FUD.

You are so wrong.

SecureBoot will have merit when I, the owner of the machine, can insert my own self-generated and self-signed root certificate into my machine's UEFI firmware, next to Microsoft's root certificate.

I DO NOT TRUST MICROSOFT'S ROOT CERTIFICATE. Period.

Why should I bow to the "authority" of Microsoft's Root Certificate ON THE HARDWARE I OWN?

The questions is clear, a computer where I cannot either disable SecureBoot, or insert my own self-signed certificate into SecureBoot's Certificate Store, is not a computer, is a Tivo-like appliance. Also, period.

 

[Scali]

You are so wrong.

Just because you think you have some point to make doesn't mean I'm wrong.

SecureBoot will have merit when I, the owner of the machine, can insert my own self-generated and self-signed root certificate into my machine's UEFI firmware, next to Microsoft's root certificate.

If you bothered to read through the Ubuntu page, you'd see that they make no claims about any security merits whatsoever.
I never claimed that it actually has any merit. I just pointed out that you can boot linux on a SecureBoot-enabled machine. Nothing more, nothing less.

Besides, you CAN insert your own certificates.

I DO NOT TRUST MICROSOFT'S ROOT CERTIFICATE.

This doesn't make sense.
Microsoft signed Ubuntu's boot loader.
It's not Microsoft or their certificate that you shouldn't trust. If there's anything you shouldn't trust, it's the code they signed (they didn't write it).
But all that is totally beside the point anyway, since as already pointed out, they do not enforce any kind of certificate validation whatsoever beyond the shim and GRUB itself.
So you can boot any unsigned code. Trying to argue about trust is missing the point by a mile.

Why should I bow to the "authority" of Microsoft's Root Certificate ON THE HARDWARE I OWN?

That one is simple: You bought a piece of hardware with Microsoft Windows pre-installed, and a big sticker on it with "Designed for Windows 10" or such.
It's pretty obvious that Microsoft's Root Certificate is installed on that machine.
It's also understandable that no other root certificates are installed, if only because no other vendor so far has obtained their own root certificate in the first place. They all let Microsoft sign their code!

The questions is clear, a computer where I cannot either disable SecureBoot, or insert my own self-signed certificate into SecureBoot's Certificate Store, is not a computer, is a Tivo-like appliance. Also, period.

If you don't like it, don't buy it. Buy one of the many machines with linux pre-installed. Oh wait...

 

[SomeGuy]

The danger is that going forwards, Microsoft can change things around and lock others back out.

Just because Microsoft has oh so graciously signed boot code for other OSes does not make it right.

If you don't like it, don't buy it. Buy one of the many machines with linux pre-installed. Oh wait...

Which is a great idea, but what happens down the road when none are available?

 

[Scali]

The danger is that going forwards, Microsoft can change things around and lock others back out.

But they can't. Code that was once signed, will always be trusted.
As long as UEFI systems can import certificates (and there's no reason why that should be removed, besides, Microsoft does not develop nor control UEFI, that is up to the OEMs), you can import the current Microsoft certificate, even if it is no longer installed by default on future machines.

Just because Microsoft has oh so graciously signed boot code for other OSes does not make it right.

The other OS vendors should just have gotten their own certificates, signed their own software, and gotten deals with OEMs to preinstall their OSes on hardware, or at least pre-install the certificate in the UEFI certificate store.

Which is a great idea, but what happens down the road when none are available?

If no vendor bothers to put a linux machine on the market, that should tell you something...

 

[GiGaBiTe]

For some reason I never heard these complaints related to HTTPS, SSL, Java code signing etc.

Because nobody is forced to have one company be the signing authority like with secure boot. With the others you mentioned, there are numerous certificate authorities, and you can even self-sign certs.

No, it is not.
The fact that it has been rooted does not imply that it is not more difficult to root (in fact, you yourself point that there are per-vendor implementations, so exploits need to be targeted per-vendor as well. So you have already implicitly stated that it is more difficult to root than an unprotected boot, where one size fits all).

Vendor specific exploits make it easier, not harder. Computer networks are a heterogeneous mix of products from different hardware vendors, you only need to compromise one to have presence on the network. You don't need to root all devices in an organization to get what you need done.

Your claim is equivalent to claiming that there's no point in running antivirus software, because some viruses may go undetected.

This is just you attacking a straw man.

Pick whatever you want. Just don't spread misinformation about it.

I think you need more education on network security because it's clear you've never done it before.

But they can't. Code that was once signed, will always be trusted.

Do you even know anything about security certificates? Certificates can be revoked and have been revoked numerous times, and the code they signed has been made untrusted.

It would be a disaster if certificates were irrevocable, which is why they aren't.

 

[Caluser2000]

Do you remember those "Linux installation reports" people used to share in the interwebs, in the mid-late '90s, when HTML was in its infancy, content was king, enthusiasm was high, fancy formating was frowned upon, and using cookies was considered a privacy-invading intrusion?


http://www.sleske.name/versa/index.html.en

I remember I used to love them. And I still do whenever I find a surviving one still kept on-line... :D

Yeah those old posts come in handy when mucking around with old systems.

 

[Tor]

Does anyone really believe that the 'secure boot' scheme isn't constructed for a single reason only? Do I even need to mention what that reason is? Really? Hint: Nothing about security. *Nothing*.

 

[Caluser2000]

Do tell. I mean I haven't seen rants like this since visiting old linux forums.

 

[Scali]

You know what... nevermind... *sigh*

 

[Scali]

Does anyone really believe that the 'secure boot' scheme isn't constructed for a single reason only? Do I even need to mention what that reason is? Really? Hint: Nothing about security. *Nothing*.

Yes, I'm quite interested how you are going to explain that blocking any code that does not pass a validation test against a set of trusted keys from a known source is somehow nothing to do with security.
That would imply that HTTPS, SSL, Java/.NET/Windows driver signing etc have nothing to do with security either, because they basically do the exact same thing.

 

[Agent Orange]

I think one answer to all of this is to just be careful of what kind of hardware you buy in the future. Personally, I just built a new Asus top-of-the-line system which utilizes Intel's new Z170 chipset. If one delves into the boot portion of the UEFI on this particular board, you'll come upon the CSM (Compatibility Support Module) feature. In a nut shell, when CSM is on you'll have full legacy support. That's both, hardware and software. Turn it off and Windows secure boot process will kick in. Even with W8.1, which was more or less a test bed for the secure boot fiasco (my opinion), I never had a problem running multiple OS's. This has all been discussed at length before. The way I see it is if MS asserts an OS monopoly via the hardware vendors, then they just open themselves up for for more litigation. Of course they're no strangers to that and they have virtually unlimited resources at their disposal. Also, a little net research will show that there is a plethora of ways to manipulate the keys in order to get around the secure boot feature.

 

[Pepinno]

Yes, I'm quite interested how you are going to explain that blocking any code that does not pass a validation test against a set of trusted keys from a known source is somehow nothing to do with security.

You keep talking about "trusted keys"? What keys? What trust?

I repeat to you: I DO NOT TRUST MICROSOFT'S ROOT CERTIFICATE. And I do not trust anything signed by it.

I would trust more a Chinese Mafia root certificate than a Microsoft root certiticate.

And I don't like having UNTRUSTED keys on my hardware. Period.

 

[Scali]

You keep talking about "trusted keys"? What keys? What trust?

I repeat to you: I DO NOT TRUST MICROSOFT'S ROOT CERTIFICATE. And I do not trust anything signed by it.

I would trust more a Chinese Mafia root certificate than a Microsoft root certiticate.

And I don't like having UNTRUSTED keys on my hardware. Period.

Microsoft has little to do with the concept of UEFI SecureBoot.
Tor claims that SecureBoot exists 'for one reason only', which is not security.
Microsoft does not even enter the picture at this point. We are solely looking at UEFI SecureBoot itself, and how it does or does not enforce security.
The fact that the Microsoft key is the only key in widespread use has nothing to do with UEFI SecureBoot itself. It could have been any other key, from any other vendor.
The question is: what does SecureBoot do with that key, and how does that affect security?

Whether you personally trust a key or not is irrelevant to the mechanics of SecureBoot. You can simply choose not to buy hardware that uses the Microsoft key in the first place (eg, buy a system with a non-Microsoft OS installed, they may not have the Microsoft key, I don't know), or just choose to remove the key from the store yourself.
A 'trusted key' in this context means that we know for sure that the key is from a specific organization, and by extension, anything signed by that key is signed by that specific organization.
It has little to do with whether you trust that organization or not.

 

[SomeGuy]

Microsoft has little to do with the concept of UEFI SecureBoot.
Tor claims that SecureBoot exists 'for one reason only', which is not security.
Microsoft does not even enter the picture at this point. We are solely looking at UEFI SecureBoot itself, and how it does or does not enforce security.
The fact that the Microsoft key is the only key in widespread use has nothing to do with UEFI SecureBoot itself. It could have been any other key, from any other vendor.
The question is: what does SecureBoot do with that key, and how does that affect security?

They didn't invent it, but they require it for their "logo" (sarcastic translation: won't break vendor's legs) requirements. And if you want something signed, you have to go through Microsoft.

Yes, SecureBoot is technically a security mechinisim. Yes, it technically can be used for YOUR Security. But the underlying reasons it is there are greater than that.

All Microsoft has to do is restrict what they permit signed and you turn what was once an open Personal Computer in to a locked down XBox or a toy cellphone.

Whether you personally trust a key or not is irrelevant to the mechanics of SecureBoot. You can simply choose not to buy hardware that uses the Microsoft key in the first place (eg, buy a system with a non-Microsoft OS installed, they may not have the Microsoft key, I don't know), or just choose to remove the key from the store yourself.
A 'trusted key' in this context means that we know for sure that the key is from a specific organization, and by extension, anything signed by that key is signed by that specific organization.
It has little to do with whether you trust that organization or not.

You can see in to the future and say for sure that commonly available hardware will forever support alternate keys?

The trust issues here are not with the technical key/signatures itself, but how Microsoft permits its use. It is relevent to how we choose to use our hardware.

 

[Scali]

They didn't invent it, but they require it for their "logo" (sarcastic translation: won't break vendor's legs) requirements.

And that is weird, because?
I think it's quite obvious that any serious OS vendor would want to support a security feature like this.
If the OEM does not support SecureBoot, then the Windows bootloader and the rest of the OS can be tampered with by rootkits. It is pretty obvious why Microsoft demands that any hardware with the 'Windows 10' logo sticker on it supports this feature.
Every other OS vendor should want the same.

And if you want something signed, you have to go through Microsoft.

That is not correct.
UEFI SecureBoot uses standardized keys, which can be obtained from a number of root authorities (Microsoft is not one of them).
There is no technical reason why linux disto's can't get their own keys, and sign their OSes themselves, and have OEMs pre-install their key and their OS.
I think this is the big FUD that goes around here, and why people freak out. They mistakenly think that Microsoft invented SecureBoot, and that Microsoft is the one that gives out keys. Neither is true.

The reason why the linux world wants Microsoft to sign their code is that most computers on the market are computers with Windows pre-installed, and as such they have the Microsoft key pre-installed.
That is the only 'control' that Microsoft has: the fact that the market demands machines with a Microsoft OS pre-installed, and therefore will have the Microsoft key pre-installed.
In reality it is ofcourse the market that controls this, not Microsoft. If the market starts demanding other OSes pre-installed, then such machines will arrive (such as how there's already Apple with OS X pre-installed, who don't even use the standard UEFI, but their own proprietary firmware).

I think that nullifies the rest of your post. Except perhaps for:

You can see in to the future and say for sure that commonly available hardware will forever support alternate keys?

The same logic goes both ways: You can see into the future and say for sure that commonly available hardware will forever support the Microsoft key?
Especially at a vintage computer forum, I think we should be well aware of the fact that any platform or technology may become obsolete and unsupported in the not-so-distant future. We just move on to whatever is new.
We simply don't know whether Microsoft is still around a few years from now. Nor do we know that x86 will still be the dominant platform, let alone that UEFI will be the dominant way of booting the computer. We'll cross that bridge when we get there.

But more pragmatically: the UEFI standard defines that keys can be edited. I see no reason why the UEFI forum would want to change that, let alone that OEMs would want to break this. There's no reason for OEMs to remove this functionality, and every reason to keep the functionality: allowing support for other OSes on their hardware.

 

[Agent Orange]

Good info on UEFI:

http://www.uefi.org/faq

 

[Scali]

How about this Intel blog: http://blogs.intel.com/evangelists/2015/12/08/nemesis-meet-uefi-secure-boot/
Which also links to this: http://www.uefi.org/sites/default/f...n_Modern_Computer_Security_Solutions_2013.pdf

Also:
http://www.linuxjournal.com/content/growing-role-uefi-secure-boot-linux-distributions

Today, the primary CA is the UEFI CA hosted by Microsoft, which is separate but parallel to the CA used for Microsoft's own software product management. At the time of this writing, no other CA has offered to participate; however, the UEFI Forum would welcome such an offer, as having a second source of supply for signing events would be ideal.

The real problem is that nobody in the linux world has stepped in.
I don't think the linux world has the right to complain that only MS signs UEFI bootloaders, when they themselves haven't made the effort to do it themselves.

 

[lowen]

...
The real problem is that nobody in the linux world has stepped in.
I don't think the linux world has the right to complain that only MS signs UEFI bootloaders, when they themselves haven't made the effort to do it themselves.

For what it's worth, Red Hat Enterprise Linux 7 (and CentOS 7, for that matter) will boot on UEFI SecureBoot and they have qutie a bit of information on the topic. If any Linux vendor can make this happen, Red Hat can. Of course, Ubuntu and SuSE also boot properly on UEFI SecureBoot, and both of those companies are well-positioned to make it happen.

Oracle definitely has the resources to do it.

Here's a link to some of Red Hat's information: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/sec-UEFI_Secure_Boot.html

Also see: https://www.redhat.com/en/about/blog/uefi-secure-boot

 

[SomeGuy]

That is not correct.
UEFI SecureBoot uses standardized keys, which can be obtained from a number of root authorities (Microsoft is not one of them).

Not if you want your OS to "just boot" on typical hardware without fudging around in each machine's setup. Which is what most people expect from an OS.

But you will probably argue that they shouldn't expect that. If you are used to recompiling your own kernel or writing your own device drivers, or something like that, you probably won't see that as the barrier that it is.

There is no technical reason why linux disto's can't get their own keys, and sign their OSes themselves, and have OEMs pre-install their key and their OS.

No, but there are obvious practical reasons. Unfortunately in the real world practical reasons win out.

The same logic goes both ways: You can see into the future and say for sure that commonly available hardware will forever support the Microsoft key?

Interesting point. Long term Microsoft could even add a second key required for future versions of Windows, slowly migrate to the new key, refuse to sign any third party loaders with that, and then eventually drop the old (current) key leaving everyone else hanging out to dry. And once Microsoft stops signing for the old key, that would be a problem for other OSes that want to continue trying to support older hardware.

But more pragmatically: the UEFI standard defines that keys can be edited. I see no reason why the UEFI forum would want to change that, let alone that OEMs would want to break this. There's no reason for OEMs to remove this functionality, and every reason to keep the functionality: allowing support for other OSes on their hardware.

Very idealistic. Microsoft will always want to dominate the market, and still has enough power to dictate, or more likely "encourage", OEMs to drop this ability. Similarly OEMs, with a perhaps a few exceptions, have no reason to support anything other than Microsoft Windows.

 

[Scali]

Not if you want your OS to "just boot" on typical hardware without fudging around in each machine's setup. Which is what most people expect from an OS.

That is not a problem inherent in UEFI SecureBoot, but an issue that results from the demand for Windows-based machines completely eclipsing most alternatives.
You are basically turning things around: you have expectations for the OS, while the hardware you buy is specifically designed for and bundled with another OS.
Why would you even expect an OS to run on machines that were never designed to run that OS?

No, but there are obvious practical reasons. Unfortunately in the real world practical reasons win out.

Indeed, if you just want to be practical, buy a Windows machine and run Windows on it. Or buy a linux machine and run linux on it, etc.

Interesting point. Long term Microsoft could even add a second key required for future versions of Windows, slowly migrate to the new key, refuse to sign any third party loaders with that, and then eventually drop the old (current) key leaving everyone else hanging out to dry. And once Microsoft stops signing for the old key, that would be a problem for other OSes that want to continue trying to support older hardware.

I don't follow your logic here.
Older hardware already has the older key, and there are already signed bootloaders available with that older key.
So even if new hardware and new OSes use a new key, that won't affect older hardware and older OSes. It will only affect newer hardware and OSes not available with a new key.
And it will only affect it so far, as in, things won't work out-of-the-box. You can still install the older key onto newer hardware and make it work.

The problem here is that the linux vendors are apathic about SecureBoot. If they just take care of signing themselves, and get their keys distributed by the large OEMs out-of-the-box, the dependency with Microsoft's key simply will not exist. THere was never meant to be a dependency on the key of a single vendor, but the linux vendors have manouvred themselves into that position.

Very idealistic. Microsoft will always want to dominate the market, and still has enough power to dictate, or more likely "encourage", OEMs to drop this ability. Similarly OEMs, with a perhaps a few exceptions, have no reason to support anything other than Microsoft Windows.

In case you didn't notice, Microsoft specifically states that SecureBoot must have a disable-option on x86 machines (not ARM machines), in order to qualify for the 'Windows logo' program.
See here: https://msdn.microsoft.com/en-us/library/jj128256(v=vs.85).aspx

Enable/Disable Secure Boot. On non-ARM systems, it is required to implement the ability to disable Secure Boot via firmware setup.

Likewise, they are VERY SPECIFIC about having the option to modify the key store:

On non-ARM systems, the platform MUST implement the ability for a physically present user to select between two Secure Boot modes in firmware setup: "Custom" and "Standard". Custom Mode allows for more flexibility as specified in the following:

A.It shall be possible for a physically present user to use the Custom Mode firmware setup option to modify the contents of the Secure Boot signature databases and the PK. This may be implemented by simply providing the option to clear all Secure Boot databases (PK, KEK, db, dbx), which puts the system into setup mode.

B.If the user ends up deleting the PK then, upon exiting the Custom Mode firmware setup, the system is operating in Setup Mode with SecureBoot turned off.

C.The firmware setup shall indicate if Secure Boot is turned on, and if it is operated in Standard or Custom Mode. The firmware setup must provide an option to return from Custom to Standard Mode which restores the factory defaults. On an ARM system, it is forbidden to enable Custom Mode. Only Standard Mode may be enabled.

So these are *specific requirements* for x86 systems. You can't get the "Windows logo" on your hardware if you don't allow keys to be installed by the users or SecureBoot to be turned off. Which in a twist of irony means that the "Windows logo" guarantees that you can run other/legacy OSes on it.

It's easy to guess the reason behind this: Microsoft has a monopoly position on x86, and if they hadn't done this, they would likely have been sued.
So that leaves us with two options:
1) In a future where Microsoft no longer has a monopoly position, they can try to 'encourage' OEMs to drop the ability. Nobody would care, since Microsoft doesn't have a monopoly anyway, so apparently there is enough demand for other systems, and Microsoft's pull with OEMs won't be that strong.
2) In case Microsoft still has a monopoly and tries to pull a stunt like that, they will get an antitrust lawsuit, which they will lose.

Either way, it's not going to happen.