Slashdot Mirror
Open Source a National Security Threat
n3xup writes "Dan O'Dowd, CEO of Green Hills Software, suggests that open source software has the capability of being sabotaged by foreign developers and should not be used for U.S. military or security purposes. He likened Linux with a Trojan Horse- free, but in the end a lot of trouble. O'Dowd thinks that unfriendly countries will attempt to hide intentional bugs that the Open Source community will have no chance of finding."
Remember this guy? He also wrote "Linux Security: Unfit for Retrofit" ( http://www.ghs.com/linux/unfit.html )
This was covered by LWN back in May: http://lwn.net/Articles/83242/
IIRC, GHS does development on embedded XP stuff? I don't remember the details...
Truly nothing to see here, folks. Just empty FUD that has been discredited.
In Dan O'Dowd's mentioning of Linux "only" receiving CC EAL 2 is somewhat incorrect. RedHat Enterprise Linux Advanced Server got CC EAL2, SuSe Enterprise Linux was evaluated at EAL 3+. This is roughly the equivalent of TCSEC C2, and can be deployed in a classified environment. I guess he needs to check http://niap.nist.gov/cc-scheme/vpl/vpl_assur_lvl.h tml more regularly and actually read it!
Um, this was already tried last November. Not only was the exploit very subtle indeed but it was still detected and removed within 24 hours. This is about as effective a piece of FUD as AdTI's last effort, and it looks like they were so embarrassed by that one they are resorting to a new name. I'm guessing we won't be hearing from "Green Hills Software" again once they've been publically ridiculed either...
UNIX? They're not even circumcised! Savages!
Check out this link: Understanding the Windows EAL4 Evaluation
EAL doesn't really mean much. At least, not until you get up to the higher levels. It's basically so that government departments can have a check-list requirement for any software they buy or comission.
Let's say I knew that DoD used a certain package in gunnery firmware. Let's say a math library that would be used to make calculations to calibrate the weapon. How hard would it be to build in a small tiny bit of error that would only be useful in cases of calibration of high-tech weapons? If 3000 lines of dense mathematically rich C were checked in and a dozen lines acted in concert to create a miscalculation, how much expertise would be needed to catch that?
so you are telling us that if they BUY the software form XYZ company they blindly accept it as perfect and simply use it without question??
if so, then I really need to look at emigrating out of the United States because the levels of incompetence is getting insane.
I dont care if it's free/oss or a 60bajillion dollar closed source software written by aliens from alpha centauri. if it's something you absolutely rely on, you had damn better check it completely. OSS should abide by the same rules that the other stuff does.... check it completely from beginning to end.
Do not look at laser with remaining good eye.
Bruce
Bruce Perens.
Can you honestly tell me that the government is going to hire a panel of people to check in in-depth source changes on OSS projects?
The American government actually has an entire agency whose job is to perform just such tasks.
It's called the NSA.
Will the NSA actually perform this function with OSS?
They've already made their own distro.
KFG
There are a number of issues that play a part in the Green Hills argument. First of all, let me say that I have had the experience of using Green Hills products (non-military) for the past few years now.
First of all, coming from a company that charges *a lot* of money for an OS stands *a lot* to lose from a free OS. Therefore, GH would be expected to say that a GH product is better.
The fact that GH source code is not open source does not mean that no one ever sees it. I have access to the entire source, and, if so inclined, could use that information to create an attack myself or provide the source to someone else. Remember, even though the company signed a release for the source, that doesn't mean that money talks more.
GH has, up till this point, maintained a 'top dog' status in this area. In fact, when we asked for a driver for USB mass storage, the response was 'Well, where else would you get it? It is going to cost you.'
IMHO, GH has had a bit of a mini-Microsoft status within the military embedded world. This has certainly mirrored the PC OS world - one leading OS, some neat features, but when you really look at, how many ways are there to create a GUI or an OS. Let's be honest - an OS has queues, semaphores, a file system (replaceable, in GH), etc. So we are not talking about 'rocket surgery'.
The idea of Linux not being 'military grade' would really need to be made from an independent group. This is akin to MS saying that it has the best browser or GUI. Of course they are going to say that.
I for one welcome our new [insert main topic] overlords.
I was looking through the authors citations and it seems that his quote concerning the number of vulnerabilities in Linux compared to those in Windows is pretty questionable. The database, as you can see here, has one selection for Linux and many for Windows. It seems that the U.S. National Institute of Standards and Technology considers components of Windows, such as Internet Explorer not to be a part of the operating system, thus listing vulnerabilities of the compenents separate from those of the OS. At the same time, Linux vulnerabilities include Sound Blaster driver issues and problems with third party software such as Symantec Antivirus.
What Dowd fails to mention, in all of this, is that Level A certification requires a detailed specification of requirements that the system must implement. These requirements must be covered by test cases that give full requirement coverage (or appropriate analysis) and structural coverage (for Level A, it is MC/DC statement coverage). The Open Source methodology is a long way from being a DO-178B compliant process, and rightly so - the rules for change control of a Level A-certified product are the exact opposite of the "release early, release often" method embraced by a typical open source program, because the development objectives are entirely different. This does not mean that an open source program can not be certified to Level A - it means that it requires a great deal of work on behalf of the organization submitting it for Level A compliance, first.
DO-178B is the most rigorous safety evaluation standard in the aerospace, automotive, or defense industries. There is no difference in the DO-178B certification guidelines for verifying a closed-source vs. open-source application. The problem that both of them have to come up with is documentation of the process used to produce the product, along with design and architectural requirements for the application that can be independently verified for full MC/DC statement coverage by an independent third party. Each application must be shown to accomodate space (memory access) and time (real-time scheduling) partitioning requirements on any device it is run on.
Most Level A OS's are a RTOS with (if you're lucky) ANSI and POSIX libraries for I/O and math. There are companies that have modified Linux for use in real-time embedded applications, but the standard Linux scheduler is not real-time, and does not perform space partitioning of application memory (which means it can be Level E, but nothing above that). If it does not affect safety-critical parameters, it doesn't have to be Level A - Levels D or E are acceptable.
Absolutely. Any to anyone who cares to argue that proprietary companies are more strict in reviewing their own code, please explain the abundance of easter eggs in proprietary software.