Hmm... any proof to the security critics arguments?
|
| Author | Content |
|---|---|
| dosida Nov 06, 2015 9:49 PM EDT |
Suppose some of them are right... have they tried to prove it to Linus that putting Spenkler's and other patches will make all the Linux kernel vulnerabilities go away without compromizing performance? Have they compiled the current kernel with those patches? Have they sent Linus proof that with all those security features and all other things they want Linus to incorporate that the kernel would be way better? This article reads as a collage of all the negative things people had to say about Linus and it feels like it's a personal attack on him. No actual proof that what those guys propose will actually work the right way. There also is no mention on how many attacks happen that are not linux related i.e. misconfigured This also reminds me of the SecureBoot fiasco. If all the security critics think this is a good feature that will thwat threats and keep computers safe why didn't they petition to Microsoft to Open source it? |
| rahulsundaram Nov 06, 2015 10:14 PM EDT |
>have they tried to prove it to Linus that putting Spenkler's and other patches will make all the Linux kernel vulnerabilities go away without compromizing performance? I don't think anyone is suggesting that. They have very much proven that certain patches will address certain systematic issues and they have shown that such patches either eliminate or significantly reduce the impact of the certain classes of security bugs. They have suggested that even though some of them have performance tradeoffs, it is worth it. > If all the security critics think this is a good feature that will thwat threats and keep computers safe why didn't they petition to Microsoft to Open source it? It is a specification. Linux is not going to use Microsoft's implementation. |
| thenixedreport Nov 06, 2015 10:35 PM EDT |
To be fair, there are plenty of vulnerabilities not kernel related. Take NTP for example. It's aging codebase is being modified and hardened by ESR and others. http://esr.ibiblio.org/?p=6881 |
| cybertao Nov 06, 2015 10:51 PM EDT |
I feel it's a fair reply (or quote) from Linus that general security is not the responsibility of the kernel. If the kernel was to act as a safety net for userland problems, people will get sloppy with userland and depend on the kernel for security. If someone can access your system and escalate permissions you have much bigger problems than kernel security is able to address. |
| dosida Nov 07, 2015 2:57 AM EDT |
You all make good points. Indeed I agree that the kernel should do one thing and one thing only and things like security models and related implementations should stay out of the kernel and do a good job at user land. But that's the problem. There's a tendency lately to build superblocks that do more than what they're supposed to do. Take systemd for example. Even if it's not part of the kernel it's an important part of the whole system. Cram the kitchen sink and soon you'll have a recipe for disaster; people screaming for it to be replaced... try and find a replacement init system ... again... when it's supposed to be fixing the same kind of mess the systemd designers said SysVinit had left them with (I could perhaps be oversimplifying the whole systemd thing a bit so jump in if I'm wrong guys). And it's true, there's plenty of bugs to go around and on various parts of the system. At least noone is hiding them. They are out in the open. If that's what passes for insecurity in WP well... sorry but I don't agree with it. Even with all the bugs, (in my opinion) GNU/Linux (not including Android cause that's a whole different case) can run circles around the other big players. As for SecureBoot it might be a specification and true Linux doesn't use Microsoft's implementation but binaries have to be signed by Microsoft because that's what OEMs use for a certificate authority for Windows 8/10 machines and probably what they'll use in the future too (again if I'm wrong, jump in). Is there another way of using let's say Debian jessie, and not an Ubuntu-based distro with SecureBoot on? |
| cybertao Nov 07, 2015 9:07 AM EDT |
Secure Boot isn't a bad idea when you can add your own keys and remove Microsoft's. It stops an executable from booting that hasn't been signed. After adding a key you could sign a kernel (with the command parameters compiled in), for example, and they system will only boot that kernel. Or boot from other media where the UEFI stub (again, such as a kernel or bootloader) has been properly signed. The problem with Windows certified machines is Secure Boot is really being used as a form of DRM. They come pre-loaded with Microsoft's public keys. Anyone with Microsoft's private key can sign an executable such machines will then boot - which is hardly secure. If their private key gets leaked one day then Secure Boot will offer no security advantage unless Microsoft (or the hardware vendor) can insert a new key and delete the old, while also having to release newly signed installation media as earlier releases signed with the old key then won't boot. Given the logistic challenge and problems it would cause, it's highly unlikely such a mechanism exists. |
| rahulsundaram Nov 07, 2015 9:54 AM EDT |
>You all make good points. Indeed I agree that the kernel should do one thing and one thing only and things like security models and related implementations should stay out of the kernel and do a good job at user land Kernel security hardening cannot be done in user space. A new project has started yesterday at http://kernsec.org/wiki/index.php/Kernel_Self_Protection_Pro... > As for SecureBoot it might be a specification and true Linux doesn't use Microsoft's implementation but binaries have to be signed by Microsoft Nothing in SecureBoot requires that. You are free to sign your own certificates. Vendor behavior in this space is far from ideal but this isn't a problem associated with the spec. |
| thenixedreport Nov 07, 2015 10:56 PM EDT |
@rahulsundaram, The whole point is that security can not be pushed onto one entity alone. Most security issues can actually be mitigated by training staff on how to defend themselves from social engineering. Just ask Kevin Mitnick. |
| rahulsundaram Nov 08, 2015 12:28 AM EDT |
>The whole point is that security can not be pushed onto one entity alone As I have already noted, noone has claimed otherwise. However the topic here is Linux kernel security and several Linux kernel developers who work on security have said that is need to change the approach. Refer to https://lwn.net/Articles/662219/ |
| cybertao Nov 08, 2015 1:15 AM EDT |
rahulsundaram wrote:http://kernsec.org/wiki/index.php/Kernel_Self_Protection_ProjectThank you for the link. I think I understand the position better now, which I didn't get from the article which focused heavily on personalties. It's easy to say security holes are 'just bugs to be fixed' when dealing with a dynamic environment. In situations where updates don't happen often or at all and bugs can be found on static (often widespread) platforms, mechanisms in place to catch them would be very useful. Perhaps also helpful for deflecting problems caused by proprietary modules? At least, I think that's the score. On the other hand, you can understand why Linus doesn't give a damn. It's not the place of the kernel development team to mitigate risk for vendors who don't provide support for their products. Being against C++ he's possibly against try and catch blocks as they ideally shouldn't be needed because the code should be fixed instead - a number of programmers feel that way. How much should the kernel team do to support security for the sake of vendors who don't support their customers? Maybe a lot as crappy vendor support could be blamed on the kernel should a major exploit take down a platform. |
| rahulsundaram Nov 08, 2015 1:43 AM EDT |
>On the other hand, you can understand why Linus doesn't give a damn. It's not the place of the kernel development team to mitigate risk for vendors who don't provide support for their products. Who do you believe in asking for this? Which products did you have in mind? |
| cybertao Nov 08, 2015 2:15 AM EDT |
I'm just playing devil's advocate. It's possible I've misunderstood something. From the Kernel Self Protection Project: Quoting:Those efforts are important and on-going, but if we want to protect our billion Android phones, our cars, the International Space Station, and everything else running Linux, we must get proactive defensive technologies built into the upstream Linux kernel.Phones, cars, and the ISS aren't likely to receive regular updates to fix bugs/exploits that get discovered. It's possible they run the same kernel and userspace for years at a time. Isn't that the gist of it? In a more dynamic environment such as a desktop or server distribution the bugs themselves can be patched and updated. |
| rahulsundaram Nov 08, 2015 2:34 AM EDT |
>Phones, cars, and the ISS aren't likely to receive regular updates to fix bugs/exploits that get discovered. Depends. Even if they don't, a major portion of the project is to reduce the impact of security issues without relying solely on fixing them after the fact. |
| dosida Nov 10, 2015 4:55 AM EDT |
>Depends. Even if they don't, a major portion of the project is to reduce the impact of security issues without relying solely on fixing them after the fact. I think that was part of Linus'es argument. If programmers and maintainers depend on such a proactive defense mechanism they can safely discard the bugs and security vulnerabilities as non-issues therefore not jumping in to fix the problem but rather rely on the automated kernel-provided "vulnerability firewall", From a security standpoint yes such a Self-Protection system could be useful but none of the authors of that Washington post article see that the Linux kernel is not just written and maintained by Linus. And since Linus is one of the few men that have been orchestrating the Kernel for as long as he has, he and a few other key kernel developers have a unique perspective on things. Not always right, not always diplomatic not always cooperative but again unique perspective on how and what the kernel approach should be (perhaps I missed any references to Linus giving NVIDIA the birdy or did the author not mention it?). I think the subject of Security in Linux based systems should not be confined in the kernel but I think everyone should take a look at the bigger picture. One example of the bigger picture. Some (I don't know if all do it) Android carriers won't allow OTA OS updates on rooted phones and tablets. What is the point of giving more control to the user by allowing them to root their device yet not provide them with the security updates that will make their device impervious to the stagefright-bug-du-jour? |
| JaseP Nov 10, 2015 5:09 AM EDT |
Quoting: Secure Boot isn't a bad idea when you can add your own keys and remove Microsoft's. It stops an executable from booting that hasn't been signed. Secure boot doesn't stop any malware. I had a Windows 8.1 system that got infected with malware when I tried to download an app to help me root my Android phone. The ironic thing is, I didn't need the app,... I could have rooted the phone straight from Linux with no app. Secure boot didn't do anything to help the situation. I had to manually edit registry entries and manually delete files,... and that still didn't take out the entire "infection." So, either secure boot is worthless in stopping executables from running, or Microsoft is giving keys to malware producers (and therefore secure boot is once again worthless in stopping executables from running). Ultimately, I wiped that system and installed Linux (secure boot and all). |
| CFWhitman Nov 10, 2015 9:49 AM EDT |
Secure Boot doesn't stop executables in general from running. It stops bootloaders and low level drivers that are not signed from running. It can make it harder to put a rootkit in Windows that takes over the boot process and executes unauthorized software before the Windows kernel even boots, which is the most difficult kind of malware to remove. There are two problems with it, however. The user isn't always given control over what keys are authorized to boot, and there is no longer any requirement for the user to be able to disable or alter Secure Boot with Windows 10 certified hardware. That is, hardware makers can make it possible to disable it, but they don't have to. |
| gru Nov 10, 2015 11:44 AM EDT |
Security has always been and always will be a layered and multi-faceted approach. There are no single point of success in cyber security, but there are several points of failure. The fact that Linus doesn't have a process or policy in place for dealing with critical CVNs or other security alert bulletins is honestly a little disconcerting, but not a total red flag issue. Linus is right, you will always weigh performance against security in some manner. But I think Linus and other kernel developers should focus more on performance and reliability. They should still keep security a consideration, but that shouldn't be their main goal. What should happen instead, is that these kernel hardening measures that were suggested in the WT article should be an optional module or installable like SELinux or GRSec. Of course, these will never be the only security measures that you should implement on a Linux server. IP Tables, Proxy, IDS, Anti-Malware, MD5, GPG, and HTTPS, etc should always be deployed in some capacity on a serious business network. Quarterly Information Security awareness training for employees, and frequent auditing is also a given. You have to think of security as a holistic approach to ensure your safety, and even then that's not guaranteed. But forcing a small dedicated group of kernel developers to tip their scales of consideration to security is a little of a knee-jerk reaction. |
| rahulsundaram Nov 10, 2015 7:16 PM EDT |
>I think that was part of Linus'es argument. If programmers and maintainers depend on such a proactive defense mechanism they can safely discard the bugs and security vulnerabilities as non-issues therefore not jumping in to fix the problem but rather rely on the automated kernel-provided "vulnerability firewall", That is a bogus argument. Security is not one thing or the other. It is both reactive as well as protective. Linux kernel already has several examples of the latter. It is just not very comprehensive however. |
| BernardSwiss Nov 10, 2015 8:47 PM EDT |
CFWhitman wrote: Secure Boot doesn't stop executables in general from running. It stops bootloaders and low level drivers that are not signed from running. It can make it harder to put a rootkit in Windows that takes over the boot process and executes unauthorized software before the Windows kernel even boots, which is the most difficult kind of malware to remove. There are two problems with it, however. The user isn't always given control over what keys are authorized to boot, and there is no longer any requirement for the user to be able to disable or alter Secure Boot with Windows 10 certified hardware. That is, hardware makers can make it possible to disable it, but they don't have to. An excellent "nutshell" summary! (I intend to plagarise it shamelessly). ;-) |
| JaseP Nov 10, 2015 9:29 PM EDT |
Quoting:Secure Boot doesn't stop executables in general from running. It stops bootloaders and low level drivers that are not signed from running. It can make it harder to put a rootkit in Windows that takes over the boot process and executes unauthorized software before the Windows kernel even boots, which is the most difficult kind of malware to remove... Apparently it doesn't even do that well against bootloader viruses/trojans... Because that is exactly the kind of infection that I was dealing with... I removed every piece of software that was loaded, and new infections started popping up... That means it had to have infected the bootstrapping process. |
| jdixon Nov 11, 2015 12:28 AM EDT |
> That means it had to have infected the bootstrapping process. Most of the recent one's I've seen have tied themselves into the tcp/ip stack, but they can attach to pretty much any low level driver if they try hard enough. I don't think those are considered part of the OS, so they're not checked by secure boot. |
| rahulsundaram Nov 11, 2015 1:57 AM EDT |
> I removed every piece of software that was loaded, and new infections started popping up... That means it had to have infected the bootstrapping process. Unless you completely wiped out the operating system and reset everything, your conclusion would be premature. Also just like any other spec, it is entirely possible, even likely that some implementations would have bugs. |
| JaseP Nov 11, 2015 10:10 AM EDT |
Quoting:Unless you completely wiped out the operating system and reset everything, your conclusion would be premature. Also just like any other spec, it is entirely possible, even likely that some implementations would have bugs. If you have to wipe the entire OS to secure it, then Secure Boot doesn't do what they said it would,... Considering that this type of infection was exactly the kind of thing that MS said they needed Secure Boot for,... Besides, I had no intention of keeping Win8.1 anyway,... This thing just upped my time table to get rid of it. I had manually removed all new files that had been installed, and STILL new infections started coming up. That leads to two conclusions: 1) Secure Boot doesn't do what they said it would do, & 2) The only other reason for Secure Boot is to prevent a user from loading their own OS. That leaves us with Secure Boot just being there so that software companies can use the DMCA to control what users do with the systems they buy. MS wants to preserve their fiefdom, others want to control the consumer spying device that they sold you. [Caveat Here: I have no problem with consumer spying by a private company in return for a service provided I know about it before hand, and I know the extent that they will spy into my private information.] The problem here is that people are no longer in control of products that they buy outright. That includes phones, tablets, computers, cars, and farm equipment. And there's a bait and switch thing going on,... We buy theses products with the expectation that we can modify them to our personal use, and we are thwarted by half-baked mechanisms and laws/regulations like the DMCA (which were bought and paid for by the content industry). It is totally against the philosophy of Free & Open Source software. |
| rahulsundaram Nov 11, 2015 10:13 AM EDT |
>If you have to wipe the entire OS to secure it, then Secure Boot doesn't do what they said it would,... Nope. Secure boot covers only the initial boot environment. It is right within the name. Read the spec. |
| JaseP Nov 11, 2015 10:24 AM EDT |
Quoting: Nope. Secure boot covers only the initial boot environment. It is right within the name. Read the spec. That might be in the spec... But that's not what they sold it as... |
| rahulsundaram Nov 11, 2015 10:31 AM EDT |
>That might be in the spec... But that's not what they sold it as... I can only talk about the technology (which is the spec) but if any vendor made the claim that secureboot protects all of the OS and not just the boot environment, I would love to see a reference to that. |
| JaseP Nov 11, 2015 10:42 AM EDT |
You sound like a Windows/Intel apologist. The claims were made all over,... look them up for yourself. I'm not your secretary. |
| jdixon Nov 11, 2015 10:50 AM EDT |
> I can only talk about the technology (which is the spec) but if any vendor made the claim that secureboot protects all of the OS and not just the boot environment, I would love to see a reference to that. Microsoft made extremely exaggerated claims about the effectiveness of secure boot on a regular basis for quite a while. All you have to do is look for them. |
| rahulsundaram Nov 11, 2015 11:01 AM EDT |
Like I said, I can only care for the technology. If MS made false claims, thats not my concern since I use it only on Linux. |
| jdixon Nov 11, 2015 1:02 PM EDT |
> ...but if any vendor made the claim that secureboot protects all of the OS and not just the boot environment, I would love to see a reference to that. > Like I said, I can only care for the technology. If MS made false claims, thats not my concern since I use it only on Linux. Those two statements sound somewhat contradictory.to me. |
| rahulsundaram Nov 11, 2015 1:08 PM EDT |
Not at all. Former is curiosity and the latter is concern. If you want to discuss marketing claims, I would love to see a reference to it to understand what you are talking about because I don't pay attention to those directly. It doesn't personally concern me at all even if they did. I don't confuse the technology with the marketing of it by one particular vendor. I am still open to talking about it because obviously some of you are using Windows and/or seem to be paying more attention to MS than I am and I want to stay informed of those perspectives if possible. Obviously ignoring them completely while preferable (to me atleast) is not necessarily a wise course of action. OTOH, if you have actually read the spec instead of marketing fluff and point out issues in the implementation on Linux, I would be concerned because I am affected by that directly as a user of it. I use my own keys, so I am pretty removed from anything a third party vendor does FWIW |
| jdixon Nov 11, 2015 2:22 PM EDT |
> if you have actually read the spec instead of marketing fluff and point out issues in the implementation on Linux,... The Windows 10 version of the spec removes the requirement that you be able to turn off secure boot. How long before they remove the requirement to allow your own keys? Or is it even already optional? From http://www.uefi.org/sites/default/files/resources/UEFI_Secur... "Secure Boot is an optional feature of the UEFI specification. The choice of whether to implement the feature and the details of its implementation (from an end-user standpoint) are business decisions made by Original Equipment Manufacturers (OEMs)." |
| rahulsundaram Nov 11, 2015 2:49 PM EDT |
>How long before they remove the requirement to allow your own keys? I can only speculate since I don't pay attention to what they do like I mentioned before. I will however note that UEFI spec itself which you are indirectly pointing to has never mandated secure boot. It has always been an optional feature. OEM can use the spec and associated tests to verify whether their implementation meet the spec to the compliance level they desire. In practice, most of them use the reference implementation from Intel with some modifications. Operating system vendors can decide which OEM's they certify in part based on the spec and tests as well but they add their own criteria on top. Spec can leave something optional that the OS vendors can require for example. Your anguish if any about OS specific criteria should be directed at the OS vendors in question. |
| flufferbeer Nov 11, 2015 9:52 PM EDT |
@thenixedreport, >> The whole point is that security can not be pushed onto one entity alone. Most security issues can actually be mitigated by training staff on how to defend themselves from social engineering. In summary, that seems to be my experience as well with Linux, as opposed to the *BSDs. The key relevant quote here could be this: Quoting:“There is no way in hell the problem there is the kernel,” Torvalds said. “If you run a nuclear power plant that can kill millions of people, you don’t connect it to the Internet.” just my 2c here... |
| BernardSwiss Nov 12, 2015 8:18 PM EDT |
rahulsundaram wrote: The problem isn't UEFI itself -- the problem is Microsoft's still excessive "influence" on OEMs making consumer computers. You're overlooking is how much "realpolitik" power Microsoft actually has, and has a history of actually using, over the OEMs (in this case also allied with the OEMs general stinginess and laziness when it comes to implementing firmware properly). And of course, Microsoft hasn't hesitated to use this "influence" to arbitrarily hinder Linux in the market. - - - Let me detour into a couple of historical examples: for example: Microsoft has been able to effectively dictate what features or specifications "netbook" manufacturers could offer (holding back the availability even in the face of clear customer demand. In fact Microsoft was able to restrict the sale of equivalent hardware for Windows and Linux systems, to the extent that at a major British chain store, when the EeePC 901 Netbook Linux model sold out, while the EeePC 901 Windows version was ignored on the display counters and gathered dust in the stock room, the chain was not able to replenish the Linux stock -- and Asus's official excuse was that they were, in their own words, "committed" to shipping the Windows and Linux versions in equal numbers (that's right, they said they wouldn't ship a popular product, because they wanted to sell the otherwise identical, unpopular one instead). Or there was the fracas at Computex 2009, where Asus (again) was displaying their new improvement on the netbook, which they announced they were releasing to market in a few months. They were calling it (iirc) the "SmartBook" line -- and these devices would run (and be sold with) a choice of Android or Linux (iirc, they were entirely ARM devices). At the display booth, conference attendees and journalists covering the conference were actually (and openly) impressed with the prototypes -- this new, Android/Linux powered re-iteration of the Netbook concept was a winner -- something that consumers (and more sophisticated users) would go for in a big way. So now you should be asking, "So what happened to this wonderful new product -- I certainly never saw one". What happened was that in less than two days, the Smartbooks display "disappeared", and the Asus CEO, on the conference stage -- and with a Microsoft VP at his elbow -- made a public apology for having presented this new product line. Shortly after, there was a huge "Asus" branded marketing campaign, that "it runs better with Windows". - - - Back to more recent (ie. Windows 8+ days) UEFI was implemented at the rate it has been at Microsoft's instigation, via Microsoft's various "Windows Certified" Logo Program and its "co-marketing" programs. Microsoft's own particular UEFI Secure Boot Specification Requirements came with a few "trivial" wrinkles or "deficiencies" that could reasonably be expected to have real world consequence -- consequences that the Linux community predicted. (Namely, MS specified that Secure Boot had to be implemented so as to prevent non-Windows OSs from booting. Under pressure, the requirement that Secure Boot must be able be de-activated was eventually added, plus some not entirely clear stuff about key management -- though it's quite clear in practice that failing to implement SB properly is just fine with MS, as long as the latest Windows runs OK (as evidenced by the "Windows Certified" products actually reaching market). |
| rahulsundaram Nov 12, 2015 11:37 PM EDT |
>The problem isn't UEFI itself Yep. This is at the core of what I am getting it. One shouldn't blame SecureBoot which addresses a legitimate issue with what one vendor does. >. And of course, Microsoft hasn't hesitated to use this "influence" to arbitrarily hinder Linux in the market. To be honest, I wouldn't expect them to do anything less. This space has traditionally lacked any real competition. Linux vendors including Canonical are not really looking at the consumer desktop seriously anymore. Apple has a limited target market but Google is making some giant inroads in the consumer space (Chromebooks are #1 selling laptop in many places) however I suspect that isn't really a satisfying solution to folks here. |
| cybertao Nov 13, 2015 2:45 AM EDT |
OEMs work on bulk with a minimal mark up. If an OEM machine isn't Windows certified it probably can't be sold with an OEM version of Windows already installed. Not coming with an OS and/or expecting a purchase of a retail version (and not having the OEMs cr@pware pre-installed) would make the manufacturer less competitive. What's left are niche vendors who will provide less restrictive, perhaps even open, hardware. Unfortunately they will cost more, but perhaps it's time the community stepped up and supported them? |
| jdixon Nov 13, 2015 5:07 AM EDT |
> One shouldn't blame SecureBoot which addresses a legitimate issue with what one vendor does. It's a legitimate issue, but an issue which isn't worth anywhere near all the hoopla that has been made over it. Rootkits, while hard to remove, have always been a small percentage of malware, and the percentage of the operating system that Secure Boot protects is miniscule. > Unfortunately they will cost more, but perhaps it's time the community stepped up and supported them? If you've got the money, go for it. Not everyone does. |
| rahulsundaram Nov 13, 2015 10:17 AM EDT |
>It's a legitimate issue, but an issue which isn't worth anywhere near all the hoopla that has been made over it I spent a few minutes enabling it but I don't really think about it after that. Rest is just noise. I don't see why I should get worked up about it. >Rootkits, while hard to remove, have always been a small percentage of malware, and the percentage of the operating system that Secure Boot protects is miniscule. SecureBoot doesn't protect the operating system itself. It protects the boot environment. If you can't trust your boot environment, you can't trust anything else beyond that either. |
| jdixon Nov 13, 2015 1:58 PM EDT |
> If you can't trust your boot environment, you can't trust anything else beyond that either. And if you can trust your boot environment, you still can't trust anything beyond that. |
| rahulsundaram Nov 13, 2015 2:45 PM EDT |
>And if you can trust your boot environment, you still can't trust anything beyond that. Yes. SecureBoot is not a silver bullet solution that solves all your security woes. It is however a critical starting point that makes trusting the rest of the environment possible. |
| cybertao Nov 13, 2015 2:52 PM EDT |
jdixon wrote:If you've got the money, go for it. Not everyone does.We may not have a choice in the future. Complaining about OEM implementations isn't going to achieve much. |
| linux4567 Nov 14, 2015 6:58 PM EDT |
> SecureBoot doesn't protect the operating system itself. It protects the boot environment. If you can't trust your boot environment, you can't trust anything else beyond that either. THat would only be true if you use your own key (not the MS key that is in every UEFI and that Redhat supports) and if the UEFI Firmware was opensource. Since the UEFI is anything but opensource the whole SecureBoot becomes a farce whose only purpose it is to make installing OSes other than Windows much more complicated than previously. |
| penguinist Nov 14, 2015 8:52 PM EDT |
These are all interesting points. Let's engage in some speculation and see how far we get. Please challenge me on any of these points if you spot any false reasoning. UEFI controls the boot process. UEFI is closed proprietary firmware, so users are denied visibility into what UEFI is doing. Anything stamped by the Microsoft key is bootable under the UEFI. Microsoft has a special relationship with the NSA. Microsoft intercepts Skype activity. (anyone with a wireshark can verify this point) So far all these point are, I believe, documented and verifiable. Now let's take this a little further. Follow this chain of control and what conclusion do you reach? I believe that it is time to call for a security audit of the UEFI code. Like jdixon said, if you can't trust your boot environment, you can't trust anything else beyond that either. It is insufficient to believe that anything stamped by MS keys is worthy of our trust. Doctorow's Law wrote:Anytime someone puts a lock on something you own, against your wishes, and doesn't give you the key, they're not doing it for your benefit. |
| cybertao Nov 14, 2015 9:49 PM EDT |
penguinist wrote:I believe that it is time to call for a security audit of the UEFI code.Which is never going to happen, because it is proprietary as you pointed out. You can't expect each vendor to release code for every UEFI implementation, and even if some or all did there's no way to verify that's what they are distributing. Unless you can compile firmware yourself and flash it, there's no solution to the problem. That's always been the case. penguinist wrote:Anything stamped by the Microsoft key is bootable under the UEFI.I'm curious about this point. I have an ASUS laptop with UEFI but not Secure Boot, apparently it's still possible to install and boot Windows 8. However I've also read Secure Boot must be enabled to install Windows 8 - perhaps for OEM editions, or somehow detecting when Secure Boot is available but disabled? Regardless of the details for any specific machine the root problem is still Microsoft requiring machines support Secure Boot to get certification...and vendors comply. OEM vendors don't have any motivation to forgo Microsoft's requirements because they wouldn't be OEM vendors of Windows boxes any more. |
| jdixon Nov 14, 2015 10:31 PM EDT |
> Unless you can compile firmware yourself and flash it, there's no solution to the problem. That's always been the case. With coreboot and seabios you should be able to do pretty much exactly that,if your hardware supports it. > However I've also read Secure Boot must be enabled to install Windows 8 - perhaps for OEM editions... Yes. To get the Windows 8 certification logo, you have to have Secure Boot enabled. Microsoft won't let you preload Windows and sell the machines without it. You can install Windows 8 (and I believe even Windows 10) on machines without it. And I believe off lease machines don't have to meet that requirement. |
| rahulsundaram Nov 14, 2015 10:58 PM EDT |
>THat would only be true if you use your own key (not the MS key that is in every UEFI and that Redhat supports) Every Linux vendor supports the default configuration including Red Hat, SUSE, Canonical and others. You can however use your own key which as I mentioned earlier, I do. > and if the UEFI Firmware was opensource. UEFI or not, most systems have proprietary firmware. If you care about that, get a system fully supported by open source firmware. |
| penguinist Nov 15, 2015 3:31 PM EDT |
First, I notice in my comment above that I again failed to make a clear distinction between UEFI and SecureBoot. Some of you have gently implied that I was a bit lax there, and you are right. So, let's make some definitions: - UEFI is the replacement for the aging BIOS and it brings new features. - SecureBoot is the piece that insists on a signed OS before it boots. SecureBoot requires UEFI and is built on top of UEFI. Together, UEFI and SecureBoot are involved in the boot process on most modern systems. Ok, now that I have the distinction clearly delineated, let's go on to the next step. As adherents to Free and Open Source Software we/I bristle at the idea that our boot loader is closed to our view. Yes, rahulsundaram, I do care about that. Yes, jdixon, if we can't trust our boot process then how can we trust what it loads. I see a need for an open alternative to UEFI, and as far as I'm concerned that open alternative doesn't need SecureBoot. If we have an open UEFI then we have visibility and can know and monitor what it loads. We don't need Microsoft to stand in judgement to tell us what it approves on our behalf! Microsofties can buy a machine with SecureBoot, I for one don't need it. I've noticed that Intel has open sourced a reference UEFI code base, and a group is active in creating MinnowBoard UEFI Firmware and this firmware is BSD-licensed. There are still some binary blobs in this implementation, but at least some of it is open sourced. So, maybe we are already moving in the direction of an open alternative. This current work runs on an Atom processor so we might have a way to go before we have an open-UEFI running on an i7 motherboard. I also understand that motherboard vendors have the practice of locking their firmware (ostensibly to prevent inadvertent loading of the wrong firmware). What I'm envisioning is a day when we can buy a motherboard from a hardware vendor and load our own open UEFI and then our own Linux OS. This is the perfect world I wish we could achieve. |
| cybertao Nov 15, 2015 4:05 PM EDT |
You might find this interesting.
PCWorld: How Intel and PC makers prevent you from modifying your laptop's firmwarepenguinist wrote:What I'm envisioning is a day when we can buy a motherboard from a hardware vendor and load our own open UEFI and then our own Linux OS.Which will be nice, and will also cost a premium. Double the premium when it comes to laptops. |
Posting in this forum is limited to members of the group: [ForumMods, SITEADMINS, MEMBERS.]
Becoming a member of LXer is easy and free. Join Us!