Slashdot Mirror
Linux Foundation: Security Problems Threaten 'Golden Age' of Open Source (techweekeurope.co.uk)
Mickeycaskill writes: Jim Zemlin, executive director of the Linux Foundation, has outlined the organization's plans to improve open source security. He says failing to do so could threaten a "golden age" which has created billion dollar companies and seen Microsoft, Apple, and others embrace open technologies. Not long ago, the organization launched the Core Infrastructure Initiative (CII), a body backed by 20 major IT firms, and is investing millions of dollars in grants, tools, and other support for open source projects that have been underfunded. This was never move obvious than following the discovery of the Heartbleed Open SSL bug last year. "Almost the entirety of the internet is entirely reliant on open source software," Zemlin said. "We've reached a golden age of open source. Virtually every technology and product and service is created using open source. Heartbleed literally broke the security of the Internet. Over a long period of time, whether we knew it or not, we became dependent on open source for the security and Integrity of the internet."
Security problems have never affected the "golden age" of closed source much.
was more obvious
what OSS is insecure? i think it is company executives and lame sysadmins that are insecure. of course easier-to-use security could help.
now we need to go OSS in diesel cars
Thanks for pointing out how fucked up our corrupto-capitalistic system is this early in the morning...
heartbleed was a blessing in disguise because companies were blindly assuming this software was secure and thus never investing a dime in it's development. this internet-scale problem woke up some people and now they are actually investing in real security.
Anons need not reply. Questions end with a question mark.
Still a serious bug, but if forward secrecy had been widely deployed, much, much less threat exposure would have occurred.
That's the lesson. Code audits are great, but they still miss stuff and are expensive. Take good practices more seriously, and you get a lot of bang for your investment in time/money/whatever.
Those people who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)
It's really, really good that somebody is stepping up and providing funding to maintain what have become critical Open Source infrastructures.
At the same time, it's totally disingenuous to imply that recent security issues are somehow caused by the fact that they are Open Source. There is no reason whatsoever to believe that, had the same services been proprietary, they would have had fewer bugs affecting security. In fact, the only effect of having critical services closed source would very likely have been that the security issues would have gone undiscovered for even longer. Making the critical security infrastructure for the internet closed source would be insane.
Open Source is working exactly as intended here: critical security issues were identified (ok, way too late, agreed), and fixed. Now the people who rely on those infrastructures are realizing (also way too late) that it is in their interest to provide funding to maintain them. This is how it's supposed to work.
The problem is that low-level "bootstrapping" software like the BIOS is still closed source, and—worse—becoming so complex that it's basically an entire operating system unto itself.
Consider Intel's Management Engine and the associated Active Management Technology that is in every modern (though, upper-middle quality) Intel-based desktop/laptop these days; it provides a whole personal computer within what you, the user, think is the actual personal computer, and that embedded personal computer has higher priority access to all the subsystems, including all of the RAM, the main CPU, and the GPU, the input devices, etc., and that embedded personal computer can be contacted via the usual network card and used to complete own the user's personal computer. It runs a proprietary operating system, and will refuse to boot the entire machine if it is in any way tampered with—you cannot get rid of it.
Consider the Volkswagen debacle that is now spreading to other car companies who abuse "low-level" proprietary software to hide their machinations.
Consider the fact that your smartphone is littered with proprietary firmware that has extraordinary access to the rest of the phone's subsystems; it is not uncommon for the phone's transceiver/modem to be connected directly to sensors like your microphone, and to have access to your system's processor and RAM, maybe GPS, etc.—it's basically a highly mobile, wireless spying device that runs completely proprietary code that is so sophisticated and connected that it could do just about anything.
Why do you think the governments have been making noise about encryption even though they know they'll never get rid of it? It's smoke and mirrors to hide the fact that the real backdoors are already in place; your encryption is worthless, when the NSA can just tap into your phone wirelessly and read the private encryption keys from RAM whenever you use them.
Security is a problem, because the powers-that-be (governments, hardware makers, etc.) have designed our systems to be insecure at the lowest levels, and no amount of FOSS at higher levels can fix that.
But it is in the interest of the customers to make sure their data never gets locked up in a format they don't control. Why wouldn't the fortune 500 companies invest a tiny part of their IT budgets to support ACM or IEEE to play the role of arbitrator when it comes to file formats, data and export/import protocols, fundamental security etc. These things should be neutral and no vendor should see them as yet another way to invade and occupy their customer's systems and processes.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
If there is no such evidence, then how does this article make any sense?
Proprietary software has switched from C to C++ faster than open source. You can speculate why:
- organized top-down will defies inertia
- companies going out of business and replacing each other means proprietary stuff gets tossed out and rewritten much sooner, while open source code bases stay useful longer
- hobbyist programmers just want to get started, so they pick what they know, and they're all either old men who predate C++, or young hipsters who can't write a serious program and goof around on PHP or Ruby.
but it's true that proprietary Microsoft, Apple, and Google codebases have a lot more C++ in them and a lot less C than standard open source stacks.
You might think C++ would be about as safe as C since they both have no memory protection, no garbage collection, opt-out strong typing, but it is not so. Firstly, C++ APIs are similarly performant but much less mistake-prone. Have a look at std::string vs. C string for an accessible example of this. Secondly, while both have opt-out strong typing, the point of the enormous added complexity of the C++ typing system is that you don't feel inclined to opt out nearly as often. Writing a C++ program without any casts is much easier than C. There are probably other advantages I don't have enough experience to know, but tl;dr it's a far more secure language targeted at the same problem space, and most of these open source bugs are in projects that don't yet use it, or in hipster languages like Ruby.
Switching everything to C++, including rewriting the Linux kernel piece by piece, is a more actionable and sane goal than "try harder."
If this is the golden age of FoSS, it's only because humanity isn't going to make it long enough to have a real one. We'll have a real one of those when we abolish software patents. Suddenly, FoSS no longer has to fear attack on bullshit grounds by patent trolls, or megalithic competitors abusing their market position. Until then, it's still a war, and nobody wins.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
The "security" of closed-source is a bad thing.
Look what closed-source did for VW customers, stockholders, suppliers, and the environment.
NOTHING should be closed-source.
'Golden Age' of Open Source
Would that be like Golden Showers? Oh yeah Lennart, your piss tastes so good!
The root cause of all of these security problems has been in plain sight since 1970 or so, yet only a few people are even aware of it. It's obvious once you get it, and the scope of fixing things comes clearly into place. So, do you really want to take on forking every program to build a new version of it? If so, you can fix it, if not... this will continue to happen, and government will try to fix it by fiat, badly.
The cause is that our operating systems operate on the assumption that programs can be trusted. This makes it almost impossible to launch an executable safely, because there is no OS enforced way to limit the side effects of execution.
Only an operating system that requires specifying the resources to feed to a given instance of execution can limit the side effects by design, instead of luck.
It doesn't have to be user-unfriendly, because the OS can always handle prompting for file names, etc... in fact if done properly, the user might not even need re-training to use the new fork of their favorite program, because for their intents and purposes, it acts the same, with the same dialog boxes, etc.
The principle of least privilege is the solution to this whole mess, but it has to be applied from the kernel all the way up the stack. This is a lot of forking work to do.
Do you dare to take up the challenge, or will you let someone else try the latest band-aid instead?
Intel x86 CPUs have a security privilege system with 4 levels (rings). Microsoft thought it was too much work to use all 4 levels so they only used level 0 and level 3.
Linux developers could maybe make better use of available technology.
Even more interesting were failed initiatives like the Intel iAPX 432, an 'object-oriented microprocessor' described as a 'mainframe on a chip' - released in 1981! Instead of 'rings', it had security right down to the RAM address level. But the design was too complex, the chip was too slow so it failed in the market, and the 8086's successor became the much more modest 80286 instead. And there all our troubles began. The whole Internet's computing platform rotted under our feet, and by the time we noticed, it was too late.
(From http://homes.cs.washington.edu/~levy/capabook/ , which is amazing reading when you realise just what kind of secure systems we could have had in the 1980s - but lost due to a focus on speed rather than security).
"Everything in the Intel 432 is an object. All objects have associated types that specify the operations that can be performed on those objects. Some objects have hardware-defined operations while others do not. However, from a language viewpoint, all objects are accessed in the same way.
All objects, whether hardware-supported or not, are controlled by type manager modules. Programmers can freely add new types to the system by creating new type managers. The mechanisms of domain refinement and type definition object provide a way for type managers to exhibit privilege over their objects and the environments in which their procedures execute. A type manager can restrict and later amplify privileges in ADS for its objects by using a privately held type control object. By permitting client access to type management procedures through a refinement, an executing type management procedure can obtain access to a richer environment than its caller.
There are no special privileges in the Intel 432 system. The mechanisms used by programmer-defined type managers are identical to those used by operating system type manager. In addition, the concept of programmer-defined type is an integral part of the addressing system, in that each object descriptor has space for a TDO access descriptor. Few previous systems have allocated sufficient space to integrate programmer-defined objects so tightly into the hardware architecture.
The designers of the Intel 432 have closely adhered to the concept of separate procedure address spaces, as presented in the Dennis and Van Horn model. Each procedure invocation causes the construction of a new context object that defines the procedure’s addressing environment. This is true even of calls to procedures within the same domain, for which both procedures will have access to a similar set of objects."
We could have had this in 1981. We could still have it today, if we wanted it.
But we have to want it.
Sound like a micro-kernel burnt into the microprocessor. It's almost kind of too specialized unless you already have a very strong use-case.