I always thought that the secure boot is a very, very, very bad idea.
In fact the whole UEFI in general I think it is a clusterfuck of mishmashed random ideas, some good, many bad.
What I intend to do personally, is attempt to don't use secure boot.
And this all might explain the e-mail I got from Lenovo 10 minutes ago...
I asked them for a non-Windows machine.
They replied saying that they from now on only manufacture machines with Windows. At first I was: "wtf? why?" now this article remembered me that now we have firmware tied to Microsoft, and this explains then why ThinkPads must come with Windows.
Here in Brazil this is illegal, and Lenovo for example got sued (and lost) once. I hope a rain of lawsuits make this shit stop.
I think the Germans were pretty concerned about this, too. I could definitely see a lawsuit against them there, considering how "weird" (but usually right) Germany is when it comes to things like these.
What exactly is illegal? Selling a machine with OS or not selling it without one?
And as for the "this explains then why ThinkPads must come with Windows" - no. It doesn't explain it. Secure boot has to be present on Windows certified machine, not the other way around. Lenovo can sell whatever they want (but apparently it's beneficial for them economically to only sell Windows machines).
Also, certified machine has to have secure boot disable-able. So it's not about you not being able to use the machine with Linux, it's about not being able to use Secure Boot with Linux.
Is that really the appropriate response to a company that basically made a choice to not offer the type of product you are seeking? Buy what you want from someone else ... problem solved. When you can't buy from someone else...then there's a problem.
In Brazil or anywhere, can you buy a car with the default sound system ripped out and get a refund for it? What about without the default tires, seats or even the engine?
The thing about secure boot is that it is a GOOD idea done very badly indeed.
What was needed was for a trusted neutral party(or two) to be the owner of the root key, and for that organisation to hand out child keys (e.g. Microsoft, Open Source Initiative, Apple, etc) who could in turn generate child keys (all of which could be revoked). Essentially we need the "internet model" of key exchanges for this too.
I cannot understand who thought it was a good idea for Microsoft to be the only authorised party to generate keys. Even from Microsoft's perspective it is just asking to get anti-trust-ed again.
The internet model of key exchanges sucks, and there is currently much wailing and gnashing of teeth over what to do about it. That's what linus is talking about here:
"They are almost certainly going to be more secure than depending on some crazy root of trust based on a big company, with key signing authorities that trust anybody with a credit card."
The nice thing about SecureBoot is that there is no root key—you can have whatever keys you like installed on your system, you don't have to get permission from a central authority. If you want code signed with your key to run out of the box on random PCs, you just have to convince each PC manufacturer to include your key in the hardware key-store of the systems they ship, a purely independent transaction.
It's just that, well, there's only really one software manufacturer with enough clout to get all the hardware vendors to include its key, and it's a heck of a lot easier to just get a sub-key signed by their master key than pretty much anything else.
The real use for secure boot is within a single company/organization where you want to control exactly what runs on the computers you own. That's an argument for secure boot to be switched off by default, and for the companies that want it to manage their own keys.
Although Microsoft will now point at me and say "but, but we need to prevent boot sector viruses!" it's telling that no other operating system except Windows commonly suffers from this problem.
Any PKI based system is a shit idea unless you are personally in control of the trusted root CA, which in this case you're not. I think that is what Linus is saying.
Google for "certificate authority compromised" and you'll see what utter wads of shit for brains this could be entrusted to.
What advantages would any system controlled by a central authority give you that a system which was entirely local and required specific manual intervention (e.g. typing in a pre-set password or private key) in order to authorize any change to the boot loader would not?
From my read of the article, Linus simply states his preference to actually support secure boot (and verify signatures), or not support it at all. He thinks attempts to "Secure Boot" a loader which then allows arbitrary code execution are a waste of time, and they are. If you don't want boot time signature verification, you should turn it off, not break the chain of trust.
In fact, done right, perhaps hardware vendors that currently only provide binary blobs could be coerced into providing source. "Oh, you want to boot on our distribution? We don't sign blobs, but if you commit source we'll build and sign the module."
If ever hardware does come out that doesn't allow you to opt out of signature verification or provide your own keys, just don't buy it.
I'm glad Linus Torvalds is smarter than your average developer. Truly a solid chap.
If he were lacking these kinds of personality traits, and shrank like a mouse every time there happened to be an opportunity to compromise the integrity of his project, Linux would have died long, long ago.
Having read through the entire thread instead of just the expletives, in my opinion it's a rare case of Linux and Greg being totally wrongheaded on the issue.
The problem crops up because redhat submitted a pull request to enhance the existing in kernel live inclusion of additional trusted x.509 certificates. Note that this is 100% upstream and live. The pull was to add the ability to extract these x.509 certificates from UEFI PE binaries, as this is the only format they are available in from the only CA UEFI secure boot computers are guaranteed to trust - Microsoft's CA.
Linus decided he didn't like it because he didn't like the idea of extracting a certificate instead of having it alone. Understandable, probably, except that leaves you in a situation where a secure kernel that was executed due to a microsoft CA chain of trust now can't make use of that CA's code signing services to decide if it wants to run a module solely because linus doesn't approve of parsing the file format that contains the key.
The biggest place this comes up is binary only graphics drivers from ati and nvidia - without changes os's like fedora are going to refuse to run them because they're unsigned, which is unfortunate considering how uneven some of the open source 3d drivers are and the heavy reliance on 3d in all modern desktops environments.
Meanwhile microsoft is perfectly willing to sign these drivers and has an existing substantial CA operation. Both ati and nvidia submit their windows drivers for signing to this CA all the time, so it'd be almost no extra effort for them to get their linux shims signed as well.
But because linus thinks parsing a PE for a signed module key is asinine, he goes on to provide a series of rather off the cuff alternatives:
a) Every distro should parse the PEs and add every key of every 3rd part module they wish to allow to run and embed these in their signed kernels, issuing a new kernel every time a driver revs.
b) ok, maybe that's not ideal. how about every distro that wants to allow binary drivers to run builds their own CA infrastructure, verification and qualification team and revocation infrastructure. So that's a team at cannonical, redhat, novell, mint, oracle, ibm, etc. etc.
c) ok, maybe full ca teams are a bit burdensome. How about all you distro guys just blind sign the binary drivers with your own signing key - worrying that MS might revoke your key because you blind signed an exploit is pointless fearmongering.
d) ok, you're right this is harder than i thought. let's just collectively decide that users with secure boot enabled will be prevented from running any module not shipped by the os vendor. Aka fuck off unless you're using intel video.
e) alright, maybe that's a little severe. Instead let's just punt entirely - even though we're going through the trouble of a chain of trust from firmware to boot loader to kernel to most modules, let's allow any unsigned binary module to be loaded by default.
f) ok, i guess that kind of defeats the purpose. None of this is good security anyway - what we should be requiring is any user that wants to use secure boot should generate their own signing keys, add them to the firmware and then parse and sign everything they trust, repeating the process every time they update while of course protecting the signing key from attackers.
I think that about covers it. Linus is really smart, but sometimes he makes a snap decision and then will perform whatever mental gymnastics are necessary to defend it to the death. And most of his inner circle will publicly go along with it because of the real chance he'll pay you back by randomly torpedoing something of yours sometime in the future.
Linux's signed code infrastructure is currently the worst in the industry and Matthew and Redhat have provided the bulk of the improvements that everyone is using. It's going to provide real user benefit, even if the users are paralyzed by FUD. Getting in the way of the process or trying to punt it out of mainline and onto everyone who ships a distro isn't going to help anyone.
> Linus is really smart, but sometimes he makes a snap decision and then will perform whatever mental gymnastics are necessary to defend it to the death.
Hmm, could it be argued that this is less a snap judgement and more one of strengthening the long-term political and technical health of the OS? Rather than take the easier short-term path, which may eventually put Linux's metaphorical balls into a Microsoft vice, he would rather expose some pain now to defend as much as possible long-term autonomy. I would imagine this to be true given Torvald's historic ability to keep Linux healthy and viable in spite of one of the world's most powerful corporations.
Thus, in the short term, the user must perform some gymnastics to boot new kernels, but if this inconvenience is really that painful, it will create market disequilibrium that will motivate creative solutions. Some naive, off-the-cuff ideas:
- vendors pre-installing trusted root certs for Linux distros or a consortium of them,
- vendors making it easy to disable SecureBoot (physical switch?),
- vendors forcing SecureBoot configuration/opt-in on very first boot,
- UI, tools, or documentation enhancements to make local key management and signing easier, or
- simply a slightly more aware userbase (the same way phone locking/unlocking became a mainstream concept).
Alternatively, Microsoft could sign x.509 certs. Why are they placing certificate data into Windows binaries in the first place?
The Linux kernel is simply not the place to parse Windows binaries. It's not Linus's fault the de facto standard is a Windows binary, it's just another harmful side-effect of the Windows monopoly.
Really SecureBoot should just die on the vine. But the monopolist wants to force it on their customers, so here it is.
Your option E is perfectly reasonable if you don't care about secure boot. And most people don't. After all, computers have worked without secure boot since they were invented.
If you, as a vendor, want to support secure boot (as a new, optional, extra feature), I think option B (be the CA) is the only right way to do it. If vendors don't like having to do duplicate work then they can cooperate and form a shared organization to be the central Linux CA. Relying on Microsoft to do the signing is not a good idea long term.
For the average linux user, key signing isn't really a big deal, imho. Running as a user and protecting root without running unnecessary services is your first step, after that it's all kind of iffy.
Signing something from an untrusted source (Having dealt with having to revoke a bunch of Microsoft signed stuff not too long ago, I assure you Microsoft is not infallible) doesn't buy you a whole lot. If you build a driver yourself and sign it, ok. Actually that's probably the best way, download the nvidia driver, sign it with your own one-time key, and voila, even if someone pulls a Folgers Commercial on your driver, they really can't sign it, they don't even know where the one-time key came from.
For a normal user, the effort to try and hack your own signing mechanism seems like it would be non-trivial. Figuring out how to hack a giant 'trusted' signer is a pot of gold at the end of the rainbow. I would not be suprised if there are more compromised signing authorities right now. Flame was signed with a msft key that was actually not meant to sign code, but for several years, since this key was from msft, people happily loaded and ran flame.
I don't really think it's FUD to say trusting your security to the entity that attracts the most attention is not a great plan.
Your points are good, except I disagree that Linux's only beef is parsing PE files, I think that's really the least of his concerns. Msft could deliver up its keys in any form, it won't solve the insecurity of not knowing if your signer has been breached.
Good security is hard, I think that's the main problem with all of Linus's ideas.
> Every distro should parse the PEs and add every key of every 3rd part module they wish to allow to run and embed these in their signed kernels, issuing a new kernel every time a driver revs.
Why do they have to embed the ID of whitelisted modules in the signed kernel? Why not have a kernel that will load any module the root user tells it to load, then have userland insmod utility verify the signatures using a configuration file like /etc/accepted_module_signers.conf?
But Linus opposes third party modules, especially proprietary. He use only Intel hardware and has personal hate against NVidia. He want to force everybody to contribute to kernel. "Stable API Nonsense".
> What they've told us privately is that as long as no-one comes along with a plausible exploit for Windows based on using a secure boot enabled Linux system, they don't care what we do.
I guess we need to hide all those forensic distributions that can modify and access data on a windows machine. To name a few: backtrack, CAINE, and DEFT. If technology can modify and access data, it can also be used in an exploit. Some might even argue that running a forensic on a computer without the owners permissions is an exploit in itself.
Edit: How could such technology be used you say. Package a usb drive that once plugged in, will reboot the machine and load a Linux distribution. Once loaded, it automatically modify the windows system and transfer any interesting data it find. Afterward, it erase itself and reboots, thus looking like any empty usb drive once windows boots up. If that is not an plausible exploit which an ordinary Windows users could trigger and become compromised, then I would like to hear the definition of an "plausible exploit".
Sure, it modifies Windows. But if it modifies the Windows bootloader, Windows refuses to boot. If it modifies the Windows kernel, the bootloader refuses to load the kernel. If it modifies any Windows drivers, the drivers won't load. So you modify userspace, but under Windows 8 the (signed) malware checker is started before any other userspace.
"This 'plausible exploit' has to be some way of getting ordinary Windows users to run the code and become compromised, it's not an experienced Linux user becoming root and subverting Windows on their local box."
Do I read this right? Is somebody suggesting teaching kernel to read some stupid shit MS "PE binaries"!?
Go, Linus. Let kernel NOT even boot on these secure boot machines, see who runs back crying first.
Dells and HPs of the world are already hurting from Windows 8 disaster. Let them lose some of the server market and all the commercial customers that buy PCs and give them to devs who install Linux right away.
How are PC vendors hoping to sell laptops to corporate buyers whose IT departments want to reimage all those machines (a lot of them with Linux images) without wasting time going into UEFI setup menus to turn off Secure Boot one machine at a time?
these cases are more easily covered by the corporation's key being included in those machines. big numbers of machines warrant that kind of effort from the manufacturer. the problem is when I want to generate my own key and use that as the only authority. the system doesn't support that model.
I'm just going to put my fingers in my ears and not listen to anything anyone might say (write) that gets close to excusing the current situation or defending Secure Boot!
As such:
Secure Boot is just another lame attempt by Microsoft to slow down/control the competition; they are abusing their position on the market once again, like they did in the past, like they will do in the future. This is their way, "the wolf changes its coat, but not the disposition".
This shows that now more than ever Microsoft is shitting their pants because of Linux/Android/Google/Ubuntu/RHEL/LibreOffice/FOSS SQL/etc; they are slowly but surely losing the war, they are losing market share on every front. The way things are now in 10-15 years I bet they will no longer have the 90% of PCs share they have today, but Secure Boot might give them some help.
I can already imagine mr. Ballmer rubbing his hands in satisfaction: "oh, nice, we'll have the keys to all PC hardware".
My advice: do not buy Microsoft, do not buy hardware on which Secure Boot cannot be disabled. We _must not_ have all PC hardware controlled by a single company - it is just stupid.
And of all systems they chose CA? Really? After the epic way it failed time and again in the SSL cert industry - think Komodo or DigiNotar.
Not to mention keys given to USA and other governments that will be able to easily install malware and other crap to control the "sheep" (the germans already have some "official" trojans lol).
Yes. You can sign the binary the same way Microsoft, or anyone else, would sign the binary. At that point, you need only to add your public key to your key database and are good to go.
Microsoft has no way to prevent this (short of requiring vendors not to allow people to add keys).
MS becomes so hateful with the secure boot trying to control everything. I will never buy any machine with secure boot enabled and will boycott any MS product.
Linus posted a NSFW rant about it a few days ago. The story mysteriously went off the HN front page and subsequent submissions of the story went [dead].
>Guys, this is not a dick-sucking contest. If you want to parse PE binaries, go right ahead.
>If Red Hat wants to deep-throat Microsoft, that's your issue. That has nothing what-so-ever to do with the kernel I maintain. It's trivial for you guys to have a signing machine that parses the PE binary, verifies the signatures, and signs the resulting keys with your own key. You already wrote the code, for chissake, it's in that f*cking pull request.
Physical access is god access. Admin/root is god access.
Guard them both with your life.
I fail to see how handing over control of your boot to some 3rd party who clearly doesn't have the same interests that you do is anything but a horrible idea.
Just physically secure your boxes(or VDI them) and use permissions and ACLs to do what they were designed to do[control and delegate authority].
A good first step for Microsoft, if it cares so much about security, is to stop making its users automagically admin for fogging a mirror, during new PC setup.
> handing over control of your boot to some 3rd party...a horrible idea
It's actually a good idea if you're the party who's getting authority over the world's computers handed over to it.
> use permissions and ACL
I still have no idea how these work in the Windows world [1]. There's nowhere obvious in the UI or the "dir" command that shows you what the ownership and permission is [2], unlike Linux's ls -al.
My one experience with Windows permissions is, in the early '00s, I put an NTFS partition on an external drive because I wanted to put >4GB files on it. I copied them and got a bunch of permissions errors opening them on another computer. My impression of Windows access controls from this: They're invisible things the OS attaches to your files which will potentially make them unreadable later.
[1] I understand there's something called ACL's in Linux too, but I never use them.
[2] I don't have much experience with multi-user Windows systems, and Linux has been my main OS for 3-4 years so I don't have as much experience with post-XP OS's.
[+] [-] speeder|13 years ago|reply
In fact the whole UEFI in general I think it is a clusterfuck of mishmashed random ideas, some good, many bad.
What I intend to do personally, is attempt to don't use secure boot.
And this all might explain the e-mail I got from Lenovo 10 minutes ago...
I asked them for a non-Windows machine. They replied saying that they from now on only manufacture machines with Windows. At first I was: "wtf? why?" now this article remembered me that now we have firmware tied to Microsoft, and this explains then why ThinkPads must come with Windows.
Here in Brazil this is illegal, and Lenovo for example got sued (and lost) once. I hope a rain of lawsuits make this shit stop.
[+] [-] mtgx|13 years ago|reply
[+] [-] rplnt|13 years ago|reply
And as for the "this explains then why ThinkPads must come with Windows" - no. It doesn't explain it. Secure boot has to be present on Windows certified machine, not the other way around. Lenovo can sell whatever they want (but apparently it's beneficial for them economically to only sell Windows machines).
Also, certified machine has to have secure boot disable-able. So it's not about you not being able to use the machine with Linux, it's about not being able to use Secure Boot with Linux.
[+] [-] josefresco|13 years ago|reply
Is that really the appropriate response to a company that basically made a choice to not offer the type of product you are seeking? Buy what you want from someone else ... problem solved. When you can't buy from someone else...then there's a problem.
[+] [-] TheAnimus|13 years ago|reply
Are you sure this isn't just a regional sales thing, not selling a Windows Free version in that teritory?
[+] [-] cooldeal|13 years ago|reply
Care to explain why or how, instead of just throwing a general statement around?
[+] [-] recoiledsnake|13 years ago|reply
[+] [-] UnoriginalGuy|13 years ago|reply
What was needed was for a trusted neutral party(or two) to be the owner of the root key, and for that organisation to hand out child keys (e.g. Microsoft, Open Source Initiative, Apple, etc) who could in turn generate child keys (all of which could be revoked). Essentially we need the "internet model" of key exchanges for this too.
I cannot understand who thought it was a good idea for Microsoft to be the only authorised party to generate keys. Even from Microsoft's perspective it is just asking to get anti-trust-ed again.
[+] [-] JonnieCache|13 years ago|reply
"They are almost certainly going to be more secure than depending on some crazy root of trust based on a big company, with key signing authorities that trust anybody with a credit card."
Not to mention this kind of thing: https://bugzilla.mozilla.org/show_bug.cgi?id=476766
Also, when it comes to stuff this important, there is no such thing as a trusted neutral party.
[+] [-] thristian|13 years ago|reply
It's just that, well, there's only really one software manufacturer with enough clout to get all the hardware vendors to include its key, and it's a heck of a lot easier to just get a sub-key signed by their master key than pretty much anything else.
[+] [-] rwmj|13 years ago|reply
Although Microsoft will now point at me and say "but, but we need to prevent boot sector viruses!" it's telling that no other operating system except Windows commonly suffers from this problem.
[+] [-] meaty|13 years ago|reply
Any PKI based system is a shit idea unless you are personally in control of the trusted root CA, which in this case you're not. I think that is what Linus is saying.
Google for "certificate authority compromised" and you'll see what utter wads of shit for brains this could be entrusted to.
[+] [-] InclinedPlane|13 years ago|reply
[+] [-] brudgers|13 years ago|reply
Such as?
Should Microsoft trust WC3?
Or Foxconn trust the United Nations?
Every organization requires funding. How would this party receive it?
Because the world is unfortunately short of philosopher kings, we are probably better served by the marketplace when it comes to hardware manufacture.
[+] [-] perlgeek|13 years ago|reply
No matter how you do it, it seems to have the same problems as SSL CAs and certificates (that is, some CAs are corrupt/negligent/compromised).
And in your proposal, what do you do if the root key ever gets compromised?
[+] [-] kogir|13 years ago|reply
In fact, done right, perhaps hardware vendors that currently only provide binary blobs could be coerced into providing source. "Oh, you want to boot on our distribution? We don't sign blobs, but if you commit source we'll build and sign the module."
If ever hardware does come out that doesn't allow you to opt out of signature verification or provide your own keys, just don't buy it.
[+] [-] negativity|13 years ago|reply
If he were lacking these kinds of personality traits, and shrank like a mouse every time there happened to be an opportunity to compromise the integrity of his project, Linux would have died long, long ago.
[+] [-] bcl|13 years ago|reply
[+] [-] trotsky|13 years ago|reply
The problem crops up because redhat submitted a pull request to enhance the existing in kernel live inclusion of additional trusted x.509 certificates. Note that this is 100% upstream and live. The pull was to add the ability to extract these x.509 certificates from UEFI PE binaries, as this is the only format they are available in from the only CA UEFI secure boot computers are guaranteed to trust - Microsoft's CA.
Linus decided he didn't like it because he didn't like the idea of extracting a certificate instead of having it alone. Understandable, probably, except that leaves you in a situation where a secure kernel that was executed due to a microsoft CA chain of trust now can't make use of that CA's code signing services to decide if it wants to run a module solely because linus doesn't approve of parsing the file format that contains the key.
The biggest place this comes up is binary only graphics drivers from ati and nvidia - without changes os's like fedora are going to refuse to run them because they're unsigned, which is unfortunate considering how uneven some of the open source 3d drivers are and the heavy reliance on 3d in all modern desktops environments.
Meanwhile microsoft is perfectly willing to sign these drivers and has an existing substantial CA operation. Both ati and nvidia submit their windows drivers for signing to this CA all the time, so it'd be almost no extra effort for them to get their linux shims signed as well.
But because linus thinks parsing a PE for a signed module key is asinine, he goes on to provide a series of rather off the cuff alternatives:
a) Every distro should parse the PEs and add every key of every 3rd part module they wish to allow to run and embed these in their signed kernels, issuing a new kernel every time a driver revs.
b) ok, maybe that's not ideal. how about every distro that wants to allow binary drivers to run builds their own CA infrastructure, verification and qualification team and revocation infrastructure. So that's a team at cannonical, redhat, novell, mint, oracle, ibm, etc. etc.
c) ok, maybe full ca teams are a bit burdensome. How about all you distro guys just blind sign the binary drivers with your own signing key - worrying that MS might revoke your key because you blind signed an exploit is pointless fearmongering.
d) ok, you're right this is harder than i thought. let's just collectively decide that users with secure boot enabled will be prevented from running any module not shipped by the os vendor. Aka fuck off unless you're using intel video.
e) alright, maybe that's a little severe. Instead let's just punt entirely - even though we're going through the trouble of a chain of trust from firmware to boot loader to kernel to most modules, let's allow any unsigned binary module to be loaded by default.
f) ok, i guess that kind of defeats the purpose. None of this is good security anyway - what we should be requiring is any user that wants to use secure boot should generate their own signing keys, add them to the firmware and then parse and sign everything they trust, repeating the process every time they update while of course protecting the signing key from attackers.
I think that about covers it. Linus is really smart, but sometimes he makes a snap decision and then will perform whatever mental gymnastics are necessary to defend it to the death. And most of his inner circle will publicly go along with it because of the real chance he'll pay you back by randomly torpedoing something of yours sometime in the future.
Linux's signed code infrastructure is currently the worst in the industry and Matthew and Redhat have provided the bulk of the improvements that everyone is using. It's going to provide real user benefit, even if the users are paralyzed by FUD. Getting in the way of the process or trying to punt it out of mainline and onto everyone who ships a distro isn't going to help anyone.
[+] [-] mcgwiz|13 years ago|reply
Hmm, could it be argued that this is less a snap judgement and more one of strengthening the long-term political and technical health of the OS? Rather than take the easier short-term path, which may eventually put Linux's metaphorical balls into a Microsoft vice, he would rather expose some pain now to defend as much as possible long-term autonomy. I would imagine this to be true given Torvald's historic ability to keep Linux healthy and viable in spite of one of the world's most powerful corporations.
Thus, in the short term, the user must perform some gymnastics to boot new kernels, but if this inconvenience is really that painful, it will create market disequilibrium that will motivate creative solutions. Some naive, off-the-cuff ideas:
- vendors pre-installing trusted root certs for Linux distros or a consortium of them,
- vendors making it easy to disable SecureBoot (physical switch?),
- vendors forcing SecureBoot configuration/opt-in on very first boot,
- UI, tools, or documentation enhancements to make local key management and signing easier, or
- simply a slightly more aware userbase (the same way phone locking/unlocking became a mainstream concept).
[+] [-] coldpie|13 years ago|reply
The Linux kernel is simply not the place to parse Windows binaries. It's not Linus's fault the de facto standard is a Windows binary, it's just another harmful side-effect of the Windows monopoly.
Really SecureBoot should just die on the vine. But the monopolist wants to force it on their customers, so here it is.
[+] [-] modeless|13 years ago|reply
If you, as a vendor, want to support secure boot (as a new, optional, extra feature), I think option B (be the CA) is the only right way to do it. If vendors don't like having to do duplicate work then they can cooperate and form a shared organization to be the central Linux CA. Relying on Microsoft to do the signing is not a good idea long term.
[+] [-] qdog|13 years ago|reply
Signing something from an untrusted source (Having dealt with having to revoke a bunch of Microsoft signed stuff not too long ago, I assure you Microsoft is not infallible) doesn't buy you a whole lot. If you build a driver yourself and sign it, ok. Actually that's probably the best way, download the nvidia driver, sign it with your own one-time key, and voila, even if someone pulls a Folgers Commercial on your driver, they really can't sign it, they don't even know where the one-time key came from.
For a normal user, the effort to try and hack your own signing mechanism seems like it would be non-trivial. Figuring out how to hack a giant 'trusted' signer is a pot of gold at the end of the rainbow. I would not be suprised if there are more compromised signing authorities right now. Flame was signed with a msft key that was actually not meant to sign code, but for several years, since this key was from msft, people happily loaded and ran flame.
I don't really think it's FUD to say trusting your security to the entity that attracts the most attention is not a great plan.
Your points are good, except I disagree that Linux's only beef is parsing PE files, I think that's really the least of his concerns. Msft could deliver up its keys in any form, it won't solve the insecurity of not knowing if your signer has been breached.
Good security is hard, I think that's the main problem with all of Linus's ideas.
[+] [-] csense|13 years ago|reply
Why do they have to embed the ID of whitelisted modules in the signed kernel? Why not have a kernel that will load any module the root user tells it to load, then have userland insmod utility verify the signatures using a configuration file like /etc/accepted_module_signers.conf?
[+] [-] luser001|13 years ago|reply
[+] [-] anonymfus|13 years ago|reply
[+] [-] recoiledsnake|13 years ago|reply
Anyway, thanks for an excellent and detailed technical take on the situation as opposed to the knee jerk bashing in many of the other posts.
There's also some excellent detail in the below article without the histrionics.
http://mjg59.dreamwidth.org/23400.html
[+] [-] belorn|13 years ago|reply
I guess we need to hide all those forensic distributions that can modify and access data on a windows machine. To name a few: backtrack, CAINE, and DEFT. If technology can modify and access data, it can also be used in an exploit. Some might even argue that running a forensic on a computer without the owners permissions is an exploit in itself.
Edit: How could such technology be used you say. Package a usb drive that once plugged in, will reboot the machine and load a Linux distribution. Once loaded, it automatically modify the windows system and transfer any interesting data it find. Afterward, it erase itself and reboots, thus looking like any empty usb drive once windows boots up. If that is not an plausible exploit which an ordinary Windows users could trigger and become compromised, then I would like to hear the definition of an "plausible exploit".
[+] [-] mjg59|13 years ago|reply
[+] [-] JonnieCache|13 years ago|reply
"This 'plausible exploit' has to be some way of getting ordinary Windows users to run the code and become compromised, it's not an experienced Linux user becoming root and subverting Windows on their local box."
[+] [-] foohbarbaz|13 years ago|reply
Go, Linus. Let kernel NOT even boot on these secure boot machines, see who runs back crying first.
Dells and HPs of the world are already hurting from Windows 8 disaster. Let them lose some of the server market and all the commercial customers that buy PCs and give them to devs who install Linux right away.
[+] [-] aphexairlines|13 years ago|reply
[+] [-] etherealG|13 years ago|reply
[+] [-] RexRollman|13 years ago|reply
[+] [-] Nux|13 years ago|reply
As such: Secure Boot is just another lame attempt by Microsoft to slow down/control the competition; they are abusing their position on the market once again, like they did in the past, like they will do in the future. This is their way, "the wolf changes its coat, but not the disposition".
This shows that now more than ever Microsoft is shitting their pants because of Linux/Android/Google/Ubuntu/RHEL/LibreOffice/FOSS SQL/etc; they are slowly but surely losing the war, they are losing market share on every front. The way things are now in 10-15 years I bet they will no longer have the 90% of PCs share they have today, but Secure Boot might give them some help.
I can already imagine mr. Ballmer rubbing his hands in satisfaction: "oh, nice, we'll have the keys to all PC hardware".
My advice: do not buy Microsoft, do not buy hardware on which Secure Boot cannot be disabled. We _must not_ have all PC hardware controlled by a single company - it is just stupid.
And of all systems they chose CA? Really? After the epic way it failed time and again in the SSL cert industry - think Komodo or DigiNotar.
Not to mention keys given to USA and other governments that will be able to easily install malware and other crap to control the "sheep" (the germans already have some "official" trojans lol).
This is madness people.
[+] [-] ycomb7|13 years ago|reply
I'm guessing that microsoft has no options for this at all, but I don't know for sure.
[+] [-] gizmo686|13 years ago|reply
Microsoft has no way to prevent this (short of requiring vendors not to allow people to add keys).
[+] [-] guilloche|13 years ago|reply
[+] [-] narrator|13 years ago|reply
[+] [-] cooldeal|13 years ago|reply
http://news.ycombinator.com/item?id=5279531
Rankings graph showing a deep dive.
http://hnrankings.info/5279531/
Part of Linus' email:
>Guys, this is not a dick-sucking contest. If you want to parse PE binaries, go right ahead.
>If Red Hat wants to deep-throat Microsoft, that's your issue. That has nothing what-so-ever to do with the kernel I maintain. It's trivial for you guys to have a signing machine that parses the PE binary, verifies the signatures, and signs the resulting keys with your own key. You already wrote the code, for chissake, it's in that f*cking pull request.
[+] [-] mhurron|13 years ago|reply
[+] [-] martinced|13 years ago|reply
[+] [-] _account|13 years ago|reply
Guard them both with your life.
I fail to see how handing over control of your boot to some 3rd party who clearly doesn't have the same interests that you do is anything but a horrible idea.
Just physically secure your boxes(or VDI them) and use permissions and ACLs to do what they were designed to do[control and delegate authority].
A good first step for Microsoft, if it cares so much about security, is to stop making its users automagically admin for fogging a mirror, during new PC setup.
[+] [-] csense|13 years ago|reply
It's actually a good idea if you're the party who's getting authority over the world's computers handed over to it.
> use permissions and ACL
I still have no idea how these work in the Windows world [1]. There's nowhere obvious in the UI or the "dir" command that shows you what the ownership and permission is [2], unlike Linux's ls -al.
My one experience with Windows permissions is, in the early '00s, I put an NTFS partition on an external drive because I wanted to put >4GB files on it. I copied them and got a bunch of permissions errors opening them on another computer. My impression of Windows access controls from this: They're invisible things the OS attaches to your files which will potentially make them unreadable later.
[1] I understand there's something called ACL's in Linux too, but I never use them.
[2] I don't have much experience with multi-user Windows systems, and Linux has been my main OS for 3-4 years so I don't have as much experience with post-XP OS's.
[+] [-] humanspecies|13 years ago|reply
We don't need to argue over UEFI or anything about it. We need to get rid of it, simple as that.
If Intel goes through with this, we need an antitrust case against them and we need Intel broken like Ma Bell.
UEFI must not exist, period.
[+] [-] Toshio|13 years ago|reply
http://ftp.osuosl.org/pub/fosdem/2013/maintracks/K.1.105/UEF...