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
maybe you should be reading "how to become a one percent-er, for dummies".
now we need to go OSS in diesel cars
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?
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.'"
Step 1: Get 100 million dollars. Surely you are born into money, so this step goes almost without saying. .1% range.
Step 2: Buy some companies.
Step 3: Bribe politicians to pass laws that benefit you and your companies, while preventing pesky competition from stealing your profitsessss.
Step 4: MOAR profits!
Step 5: Repeat steps 2-4 until you are into the
Switching to C++ is just opening another can of worms.
C++ just have the bad stuff from C and the bad stuff from object oriented design combined.
If you want a language for an OS that is better you will need to look at ADA or some completely different language. One of the more secure operating systems out there is OpenVMS and that's written in BLISS.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
C++ is great for masking what is actually happening in the background, which is the opposite of what you want for a kernel.
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.
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.
Doesn't all C code run as C++ code with no code changes by default? I'm not sure where I'm going with this but I am not a programmer (not a good one, at any rate) and I'm mostly curious. With my limited knowledge, well, I can't really think of any reason to switch but I can't see any harm in switching by default. So long as the practice was good in C shouldn't it also be good in C++? After all, I thought you could literally take the C and just put it in C++ and it worked natively?
"So long and thanks for all the fish."
Pretty much. A "C++ programmer" doesn't typically write C-style programs, however, but uses the more advanced language features to buy some amount of extra compile-time safety. At least, that's the idea.
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.
Not exactly. All C is not valid C++.
However, it may be considered good practice for C code to be written so as to make it valid C++. In is not a big effort and allows you to take advantage of the added safeties included is C++ compilers. Think of it as static analysis.
One trouble however of using C++ is the lack of a binary standard, so, while compiling your C code as C++ may be a good test, actually shipping C code compiled with a C++ compiler may not be a good idea.
I can't how many times I've seen C code which casts the result from malloc in order to be compatible with C++, but failed to include stdlib.h. It causes memory corruption.
Please, stop it! C and C++ are different languages. Keeping your C headers compatible with C++ is one thing. But it's idiotic to try to keep the code compatible. And modern C--C99, C11-- has some very useful features, like named initializers and compound literals. Not making use of them is unnecessarily limiting yourself.
If you're writing C, write C. If you're writing C++, write C++. Stop trying to pretend otherwise. The languages diverged 16 years ago.
The only provably secure OS (L4) is written in C. I think there are good languages out at the application or platform level (Rust, Haskell, Scala) but systems level programming it's mostly just C. Alternatives are mostly just dressed up C (C++, D). Java and Haskell offer was to wrap application in a standalone VM, but largely due to the fact it uses shims in a controlled enviroment, it doesn't actually have to work with the messy hardware stuff.
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.
The Windows kernel is written in C. Most kernels are written in C.
Time makes more converts than reason
http://harmful.cat-v.org/softw...