Slashdot Mirror
Embedded RTOS Maker Raises Linux Security Issues
drquizas writes "Embedded RTOS provider Green Hills recently delivered an address where they raised the question of whether Linux can be considered secure enough to be used in defense applications. Much of the usual FUD is present in the remarks, although an interesting question is raised regarding what defense and other government contractors are required to do in testing code (in this case anyway): is the closed code here being held to a higher standard than its open-source equivalent, and does this change the 'security through obscurity' argument?"
"Open Source is actually more secure than closed source proprietary software because the oversight of technology content is broader and deeper. Instead of just one company monitoring its own contributions -- or potentially hiding security holes and exploits -- a worldwide community of interested parties actually oversees Linux to make it strong and secure. That's why the NSA -- the most security-conscious organization in the world -- chose to standardize on Linux, and even supplies its own version of secure Linux."
Can't put it much better than that. When you have the contribution of the entire open source development community, so much knowledge and experience comes to the table that it's difficult for any one group of programmers to compete.
Wireless News www.DailyWireless
on a related topic... here.
quote from this raty-os dude
"It costs us $500 to $1,000 a line to review our source code. It would cost billions of dollars to review Linux."
Say whut? It actually costs this? why? where can I sign up???? I'll sub my per-line auditing out, rake it in...
Naw, cmon, really? the government charges this, or he just pays this cost? Because..huh?
that Linux can be made pretty damn secure.
If they have faith in it....
http://www.nsa.gov/selinux/
Green Hills calls Linux 'insecure' for defense
By Alexander Wolfe, EE Times
NEW YORK -- A storm has erupted in the embedded community, with real-time operating systems house Green Hills charging that Linux is fundamentally insecure and wide open to security breaches by "foreign intelligence agencies and terrorists."
The explosive charges were made in a speech delivered Thursday (April 8) at the Net-Centric Operations Industry Forum in McLean, Va., by Green Hills chief executive officer Dan O'Dowd.
"Now that foreign intelligence agencies and terrorists know that Linux is going to control our most advanced defense systems, they can use fake identities to contribute subversive software," said O'Dowd, in a copy of the remarks released by Green Hills.
"If Linux is compromised, our defenses could be disabled, spied upon or commandeered," O'Dowd continued. "Everyday new code is added to Linux in Russia, China and elsewhere throughout the world. Everyday that code is incorporated into our command, control, communications and weapons systems. This must stop."
O'Dowd laid out a scenario in which the open source development process -- where thousands of programmers contribute code that's subject to public review before being folded into Linux -- could be subverted via "Trojan Horses" illicitly slipped in the software.
At least one embedded expert thought O'Dowd was overstating his case. "I think it's pure FUD [fear, uncertainty and doubt]," said Rick Lehrbaum, a respected board-level-computing guru and former president of Ampro Computer and currently operator of the developer site LinuxDevices.com. "I think the insecurity he's concerned about is an intentional back door and this [Linux] is the most transparent operating system in existence."
Several programmers on the Linux street are also giving O'Dowd some pushback. In a reader's forum on the LinuxDevices.com Web site, a developer who identified himself only as "Concerned citizen" posted a lengthy rebuttal. "[Linux] has features, security, and strengths that are not easily compromised by a foreign agency," he wrote. "Let's not forget that the terrorists that Mr. O'Dowd refers to used proprietary software for attacks on the USA. They have Windows machines and Flight Simulator, you might recall."
O'Dowd claimed the salient issue is that Linux isn't held to as a high a security standard as is the proprietary "Integrity" RTOS made by Green Hills. "If all they would do is hold Linux to the same standard they hold us to, I'd be happy," O'Dowd said told EE Times.com. "At the [Federal Aviation Administration], they have received from us documentation of every single line of source code and tests of every line of code and boundary condition. It costs us $500 to $1,000 a line to review our source code. It would cost billions of dollars to review Linux."
O'Dowd's tough stance may attract attention because he is also taking an unusual public stab at a competitor -- embedded Linux powerhouse MontaVista Software. "MontaVista is outsourcing their development to Russia and China. That's not wrong if you're building toaster ovens," O'Dowd said in an interview. "If you're building national security applications, that's a different story. Nobody's even checking if there's anybody putting anything [dangerous] into Linux."
In response, said MontaVista CEO Jim Ready said Linux constituted a threat to vendors of proprietary software, because of its robustness, cost-effectiveness and its security.
"Mr. O'Dowd makes the common mistake of confusing obscurity with security," said Ready. "Open Source is actually more secure than closed source proprietary software because the oversight of technology content is broader and deeper. Instead of just one company monitoring its own contributions -- or potentially hiding security holes and exploits -- a worldwide community of interested parties actually over
Let's make decisions on the quality of CNN based on remarks made by Fox news.
So let me get this straight...
Closed source is held to a higher standard? Security through obscurity may actually work?
If this is the case...Windows must be the most secure OS in the world!
Systems will only be as secure as their administrators no matter what software is running on it. I'd even argue that open source may be more secure. Sure, exploits can be exploited by having access to the source...but at least in this case others reviewing the code may 1) Patch the problem before it's exploited or 2) Patch the problem much faster than if it were closed source.
But, in the end...as I've already said...a system is only as secure as the administrators behind it...
"It costs us $500 to $1,000 a line to review our source code. It would cost billions of dollars to review Linux."
Hows that any different from if they chose windows? Wouldnt it still cost them just as much? thats assuming they can get access to the windows code. At least with Linux you don't have to pay to get it.
And no the leaked source does not count.
While it is never good to rely on "security through obscurity", it doesn't mean that it is useless. For example, if after all the thorough testing the same number of bugs were left (hypothetically) in the software, they would be harder to find in the closed system where you wouldn't know where to starting looking as opposed to open source where you could scan the source until you came upon what looked like a vulnerability. The obscurity isn't harmful in itself and it provides an additional barrier. Maybe not a powerful, but every little bit helps. I'd feel a little nervous if I knew some terrorist (as a much over used example) could look over the source code (even if it had no holes!) for a nuclear weapon command centre or something of that sort. I think the ultimate question should be whether the open nature of the open source development can lead to the less bugs - and thus greater security- than closed source development plus the small bonus of obscurity. I think the value of obscurity may have been undervalued in the past, it does have some value.
Your CPU is not doing anything else, at least do something.
There was Cowboy Neal at the wheel of a bus to never-ever land.
in-house code, as well.
The advantages of closed source coding seem to me to be a faster development time, stronger integration of components, and more support. The drawbacks, though, are that you are ultimately trusting somebody else.
Open source code, I would say, is more secure overall - there are more people looking at the code, so it is less likely that bugs slip through. The drawbacks would be that open source is less custom-made and possibly less supported than the rest (also, as O'Dowd would have it, people 'contributing' backdoors).
As for simply writing your own secure code (an agency doing this, that is), it's obviously just more expensive.
The best solution, in my opinion, is to make your own custom flavor of Linux that is open to all, but contribution is regulated so no questionable code can be admitted - the tack taken by the NSA.
webpage
I know Sun had to have a special version of Solaris just to meet these needs and Solaris was already considered very secure to begin with. I can't remember if MS released a secure NT for this reason as well or if they tried to and failed.
Talking about the openess of the linux code, there's another question I always wonder nobody asks. Sure Linux is open source and that's what helps it get better but I don't see the argument in terms of cost and security. Saying "you have the source you can see how secure it is" doesn't work for me. People buy an OS because it's cheaper to spend a few hundred or a few grand per PC than it is to hire the staff to build their own OS. Having to have the staff that can review, maintain and patch their own linux kernel alone isn't easy. It's something like 1.5 million lines of code right now. People want an OS that just works and is cheaper than building one themselves.
Open Source Java DAO Generator
First, this isn't the first time that Green Hills has come out complaining about Linux, you may remember a previous slashdot story where they claimed that the embedded linux tools market was a myth. Secondly, this article, like their previous one is through EETimes. If you've ever read EETimes you'll know why that should make you question the quality/validity/truthfulness of all the statements in the article.
Basically, Green Hills seems to be just another proprietary software vendor scratching for ways to try and derail a competitor in their market space. Nothing to see here. Move along now.
My Slashdot account is old enough to drink...
Is it only me - cause when i read green hills I immediately thought about the Windowss XP background :P
Anyway this guy is right that the US cannot control linux; the more that perception of Linux is strengthened, the faster will be the adoption of Linux by governments outside the US. And that's a huge win for linux.
This is kind of a side remark that I haven't really thought on too much, but here goes. (I think I'm playing devil's advocate...)
(1) Who audits the open source software that they use? I certainly don't. I rarely even bother to look at the source. So in this respect, it doesn't matter (to me) if the software is closed source or open source since the code isn't looked at even if you (I) had the chance to.
(2) If you're not going to audit the code, will you trust the code developers to have done adequate auditing? Again, the folks who write open source software are, for the most part, as much a stranger as the folks working in some company (at least if you're me). Why should I trust "open source" strangers more than "closed source" strangers?
These points rarely seem to get brought up here. I can certainly see the answers to (2) giving the edge to open source, but what about (1)?.
"Now that foreign intelligence agencies and terrorists know that Linux is going to control our most advanced defense systems, they can use fake identities to contribute subversive software."
The whole story is so absolutely paranoid (The Russians are coming! Beware of the Yellow Peril!) and shows such a complete lack of understanding of the Linux Open Source process that it would make me worry if I were buying Green Hills' software: Do you want to buy something from somebody who is this divorced from reality and has this little understanding of how his competitor works?
Explain Cisco.
For example you'll never see backdoors in commercial software. You can rest easy that they've done their job well and everything is nice and secure. That's why its better to stick with big commercial vendors like Cisco.
btw, why even give a story like this press? What a joke.
If you wanna get rich, you know that payback is a bitch
I thought MS, Sun, Oracle, IBM all have code shops outside the USA. Their products are (mostly) proprietary. Yet he takes no stab at them.
Hell, Green Hills probably uses a number of the aforementioned proprietary products in-house, parts of which were developed overseas and may have back doors! So their code and binaries are available to all those wicked, wiley overseas hackers anyway!
What's next? Publishing the heritage of all their programmers and tracing them back to the fucking Mayflower?
I half expected to see a big "Sponsored by Microsoft" sticker on the bottom of the page.
Basically this guy is recommending we entrust the security of our defense systems to the code review teams of the closed-source OS, rather than taking the time and money to do have the DOD do it themselves. Sounds like a money saver until a missile goes blue-screen and blows up a school...
If these people are so concerned about code review(which, admittedly, they ought to be), then perhaps they should be writing their own OSes, especially for imbedded systems.
MissileOS...
Some good reading about this topic can be found here.
"Everyday new code is added to Linux in Russia, China and elsewhere throughout the world. Everyday that code is incorporated into our command, control, communications and weapons systems. This must stop."
Does he get this pissed about Microsoft, IBM, Sun, HP and other companies that outsource core dev to those same countries?
As someone who's used GHS compilers and knows other industry folks who have as well, I've got to say the almost unanimous opinion is that Green Hills are a bunch of schmucks.
To be fair, their core compilers are actually pretty efficient in terms of code speed and density. However, the products are annoying to use, particularly with non-GHS tools, their sales reps are full of BS, and their technical support is spotty at best. Their toolchains are also quite expensive per seat. Many companies get a seat for doing benchmarks, and that's it, since it'd be prohibitively expensive to deploy to an actual development team.
Furthermore, I have it on good authority that at least as recently as a year or two ago, their internal revision control was pathetic to non-existent. Customers would experience very odd bugs that GHS would have difficulty reproducing. When and if the bug was fixed, that individual customer would get a one-of-a-kind patch from a software dude in GHS. Another company, also a GHS customer, asking about the same problem would usually never find out from GHS that a patch existed, since the patch usually only existed on that one GHS dude's hard disk. No real central software repository or proper version control.
And customers could get in trouble if they passed such a patch directly to another customer! Even the version numbering of software releases was inconsistent and no guarantee that all bugs fixed in a lower version of software would have been included.
I'll take open source tools any day! (Which is not BTW mutually exclusive with doing business with companies like Montavista, Redhat, etc.)
It seems that GHS may be doing a fair amount of business in the defense and government contractor sector. Places where technical recommendations from the design engineers don't always get the proper consideration from the folks who sign the actual contracts.
The parent post is funny but in all fairness I think the general idea is that he's discussing the cost per line for a very large system. A single line in isolation is easy to debug. But you can't debug them in isolation, can you now? I think it should be fairly obvious the average cost to debug per line of code increases the more lines of codes you have in the system. Since the different lines of code interact, you know.
And this tendency is probably much more pronounced when rather than debugging, you are, for example, attempting to certify something as a failsafe system.
Linux is a fairly large and multifarous system. If his company sells a product that is designed and streamlined to be an RTOS embedded kernel, it more than likely achieves this in far, far fewer lines of code than Linux overall. While he is probably being unfair by counting in the total number of Linux number of lines of code things like desktop video card drivers, it is an altogether reasonable statement to suppose that the streamlined and smaller RTOS kernel this company sells is probably easier to debug and reason about than the Linux kernel, which is relatively larger, more complex, and has more complex design goals.
In the article, he states that anyone can contribute backdoors/trojans into the code because nobody is looking at the code. This is completely and utterly wrong. I'm pretty sure that to insert code into the kernel, you have to sign up to the mailing-list, and send in a diff. There, other kernel hackers can easily see the code, and if Linus accepts it, it goes into the tree. Even though anyone around the world can do this, the process is fairly strict.
Anyone want to place bets that Microsoft paid him to say that?
Founder of Mirror Moon - Tsukihime Game Trans
People are still buying from The SCO Group, aren't they?
There was Cowboy Neal at the wheel of a bus to never-ever land.
Linux is a heck of a lot more secure than Windows.
WHAT?!
Linux is a heck of a lot more secure than Windows.
WHAT?!
Linux is a heck of a lot more secure than Windows.
WHAT?!
Linux is a heck of a lot more secure than Windows.
WHAT?
Linux is a heck of a lot more secure than Windows.
OKAY!
Need I say more?
YEAH!
Score:-1, Redundant
OKAY!
Actually, this is somewhat misleading. The top players listed are Microsoft (Windows CE), Wind River, Symbian, Palm. QNX, OSE, and Green Hills. But Microsoft, Symbian, and Palm are really selling into handheld devices, not hard real-time control. (The phone and PDA markets are much bigger than real time control, though.) Wind River's VRTX is the dominant player by a big margin, especially in low-end embedded control. QNX is next, and is usable on a broad range of platforms. Wind River is more of a specialist maker catering to the military Ada market.
Following these seven come LinuxWorks and MonteVista, who are moving up. These are the main Linux-based offerings.
Also confusing the issue is Windows XP Embedded, which is basically a Windows XP from which you can delete stuff you don't need. This sells more into point-of-sale applications than hard real time control.
Green Hill seems to be making some unsubstantiated claim that open source isn't held up to the same standards as closed source, and I find that rather funny. I think the real issue is, when Green Hill approaches the FAA or whatever, the FAA will do its own testing of the source. If Green Hill's code is breakable, Green Hill is the one responsible for fixing it. But, if what the FAA is reviewing is open source, it's possible the FAA can just fix the source themselves (and avoid having to pay an outside contractor). So, Green Hill, to avoid the scenario where the FAA might be displeased with Green Hill's RTOS and switch to open source, decides on its *own* to spend $500/$1,000 per line to audit their OS.
In the end, this means to me that Green Hill believes OSS has an unfair advantage. Personally, I think it's perfectly fair for people to offer free software. If Green Hill doesn't like it, tough. Or, they can just make their RTOS so good that the FAA or some other organization will be so impressed they won't bother going over some OSS and possible having to fix bugs or write documentation. Looks like the free market to me.
PS: SAYODF == Self-Analysising Your Own Dog Food; it's like a water bottling plant bitching about there being freshwater lakes because lakes don't have to do their own quality control
Eurohacker European paranoia, gun rights, and h
I wish suits would stop blathering about each other's products because really it's just a waste of time. The source is so obviously biased that even reading is pointless.
People are still buying from The SCO Group, aren't they?
No.
Treehugger? Treehugger... Treehugger!
Maybe its time to look at how current contribution methods could be further enhanced through crypto/keysigning similar to what PGP/GNUpg does.
I still think his USD 500 per line is a bit steep ! If its true then maybe that USD 500 would be better spent on better high-tech ceramic/kelvar body armour protecting US troops than giving it to this guy to spend on Double-choc Mocha Latte while looking if a strncpy() was OK !
Who audits the open source software that they use? I certainly don't. I rarely even bother to look at the source. So in this respect, it doesn't matter (to me) if the software is closed source or open source since the code isn't looked at even if you (I) had the chance to.
Let's say you're in a major city. Let's say there's a small, narrow street. And let's say you walk down this street twice; once in the middle of the day, when the street is well-lit and crowded. And the second time in the middle of the night, when it is empty, abandoned and dark.
In which of these situations do you feel more safe?
I would probably guess the second. Why? In both the first and the second case, you have no way of knowing if there is someone who has a weapon and wishes you harm. But in the first case, this possibility is not something that worries you.
Open source is kind of like the well-lit, crowded street, and auditing is kind of like being able to tell if someone wishes you harm. First off, you don't *have* to be constantly watching your back; it's more than likely someone is looking at your back at any given moment, and can tell if someone is walking up behind you with a blunt instrument. Second off, the fact that *everyone knows people are watching* means it's less likely anyone will try anything, because they know they'll get caught and have messy problems with the law.
Note that this argument does not go so well unless the open source product is relatively well used. If you're the only user, well, you're not much better off.
---
Anyway, as far as (1) goes, I would imagine that while it may probably be a very important point insofar as you go, as far as the kinds of software discussed in this article go it's not so useful. You probably don't audit the open source software you use. But a propreitary embedded RTOS vendor certainly would, since their demands for security and reliability are much higher.
But wait, you say, wouldn't the need to audit the code at that level be an argument against open source, since it destroys the "free" nature? Well, here we run into the basic problem of the conflation of "free" software with "open source" software, or the conflation of "free" software with what RMS might call "software libre". These two concepts are often described by the same term. However, they are not the same thing!
A program being open source does not mean that it can have a trusted company of some kind behind it! A company such as IBM could be providing an open source program they internally wrote, or you could have a case such as that with MySQL (ok, maybe that's not a great example, but you know what I mean) where a community-developed program passes through a certain central trusted point (MySQL AB) which can be trusted to-- or demanded to-- perform the auditing for you. So this is not a problem with Open Source, this is just a problem with software you downloaded for free off the internet.
Irritable, left-wing and possibly humorous bumper stickers and t-shirts
I caught this story on OSNews yesterday and posted a rebuttal on my blog. This sort of thing probably doesn't carry a lot of weight with most of the defense types because the military is the very definition of mission critical, no pun intended. Peoples lives are at risk on a daily business in most jobs in the military these days. There is almost no price too high to pay for the freedom to design to specification that Linux provides.
Linux is certainly not ready to take over a lot of things yet, but it is good enough for many things that traditional defense contractors are involved with. I wouldn't trust it yet as an OS for our warships or other vehicles, but I would trust it for communication systems and things like that. For situations like that, a RTOS from a company like Green Hills may not provide enough benefit to justify the cost. Linux is free, their product isn't. They can try to get the military hooked for a while, but Linux will always be free and there are plenty of IT workers in the military who could work on existing RTOS Linux forks for military use.
Another thing that has to be kept in mind is that with the push for homeland security, the laissez faire attitude that has been prevalent toward security has to go. The miltiary wants transparency so it knows it's not getting something bugged all to hell by some Jihadi who wormed his way into Microsoft or Sun via the H1-B visa program. The Debian and Fedora teams are great for that very reason. Everything is open to public scrutiny, from the installer to every package so the military gets a chance to audit everything.
Free markets are great, but in this case the military has to perform a more core mission: defend the US from attack. If that means violating free market principles by pouring taxpayer dollars into a free OS for public use, then they should and most likely will do it eventually.
Click here or a puppy gets stomped!
The NSA seems to think Linux has what it takes. Besides, why arn't these same questions raised with Windows? Is this a non-issue, or what?
"Who are in control, they are not in control of anything - they don't even control themselves!" - Glen Beck
Considering the number of double agents we have caught in the US lately, I think our concern should be the employees of closed source companies sticking evil easter eggs into the code used in national defense. We have all these Americans selling secrets for years before being caught. OTOH, we keep arresting these residents only to release them for lackof evidence. It is not the foreign agent that is the danger, but the domestic agent doing anything to pay a mortgage, private school, and vacations.
"She's a scientist and a lesbian. She's not going to let it slide." Orphan Black
Having worked as an systems administrator on DoD programs, I can tell you for a FACT that ANY software that goes on mission-critical systems is either developed in-house or very throughly scrutinized. They do code review, bug fixes and testing in a continuous cycle to get all the software bugs out. (This is one of the big reasons you hear about DoD projects going over time and/or over budget).
If COTS products are used, the DoD programmers will test the software for defects and ask the vendor to correct the defects they find. There have been cases where the DoD has signed NDAs to gain access to source code for COTS software to fix bugs that caused problems with the DoD software that the software company WOULDN'T fix. This has even been done to find backdoors, trojans, and other bad things that disgruntled employees of proprietary software vendors have put into that company's products.
OSS gives the DoD the power to make the changes they want to secure their systems the way they want. They WILL go through the code and look for backdoors, trojans, viri, etc. They may even set up their own repository and fork the kernel. Once the DoD has a trusted version of Linux, they'll use it in-house. I suspect that most DoD programs looking at Linux are probably testing NSA's version.
The DoD should be able to release some of the improvements they make back to the community, but don't expect them to release everything. The military still has it's secrets.
If "disco" means "I learn" in Latin, does "discothèque" mean "I learn technology"?
How hard will it be for Chinese nationals to poison each of the major linux applications + the kernel?
Let's see...work 4 to 5 years as a valued contributior to the kernel and then slip in tiny exploitable flaws without telling anyone except the Chinese government....
I used to work as a Defense contractor and I spent quite a lot of time going through the various processes. As a Linux developer, I can certainly say that Linux has not been developed to the same standards that the projects I've been involved on have.
For starters, in the DoD, every line of code is reviewed by hand by a team of reviewers (usually 4-5). There are records of all the defects found and verification that fixes were made. After the initial development cycle, there's a rigorious testing phase where all specifications are tested, senarios are ran, and stress tests are performed. Any defect from this testing is recorded, and the software doesn't ship until it's fixed. This usually ends up being a 2-4 year process of just doing bug fixes.
And for those that don't know the difference, Windows is *not* certified for tactical use. Having EAL4 is not the same as being certified for tactical use.
It's really a different type of software. It's not that Linux isn't good piece of software, it's just that it wasn't developed for this type of work. There's nothing wrong with that.
int func(int a);
func((b += 3, b));
Anyone want to place bets that Microsoft paid him to say that?
Nah, MS isn't the only one with a livelihood at stake. Linux is going to change the way a lot of people do business; some companies will not be able to adapt, and will die.
This is the sound of someone running scared. Plus, he probably believes what he says. Think about it from his perspective: his company is in the business of supplying good software, and he *knows* it's good software. Linux is deveoped in a strange way, one that is counter-intuitive to current business models. So it's no wonder he has said the things he said. From his perspective, it's true.
He's wrong, of course, but that doesn't change his perspective.
Microsoft is to software what Budweiser is to beer.
Heh, shouldn't that be +1, Redundant?
Why reply to a first post?
It just goes to show there are some mighty f***ed up idiots arround who can't even post in the right place!
The government can review Windows' source at anytime, right?
/.ers biggest complaint about Windows is that they can't look at the source (in its entirety :-P).
The biggest fear regarding Linux is that some hacker in China or Vietnam"" might put malicious code into the source.
Most
The government has the best of both worlds. They get the security benefits of both open and closed source by using Windows.
You must be american... you completely missed his sarcasm.
Linux, in a proper definition, isn't very functional. It's the OS kernel... you're gonna need some software to go with that. So, which distro should be the "standard issue" for a military use?
Drawing a line between what's secure enough to make the grade, and what that's out there might not be trustworthy enough for "secure" use is quite a tough thing. Sure, Open Source allows the code to be reviewed... but the government doesnt have the time to do that so that's no good for them.
Microsoft can at least come forward and show a big company standing behind their product... how can Linux match that?
Note to self: If ever pirate Russian gas pipeline control software, look for the "paybacksAreHell" subroutine.
Post some fat ass mp3s.
Or post a multipart rar set of gay niggers from outerspace vcd. That would rock.
Every single time someone has a claim against linux you just brush it off as FUD. With so much 'Fud' out there, that alone means there is a problem
"And if we showed it to you, we'd have to kill you." Yea, more like if you saw what you paid good money for you would kill yourself.
This argument will die with the last closed source vendor.
When you buy a RTOS, you usually aren't getting compiled executable code. You usually get source code that you need to port to the hardware you are building.
Data sheets like this implies that Green Hills adheres to this common practice. So all the open source is more trustworthy than a black box arguments don't apply. Anyone who wishes to deploy a system based on Green Hills' RTOS can audit the code, it isn't hidden from them. Also, this PDF linked says:
Which to me implies that it has had a more thorough external audit than most open source packages.One final argument is that an RTOS is usually very small. Their Velocity RTOS can run in 3KB of RAM. When the OS is stripped down to something that small, a full audit seems like a much less daunting task.
This implies that he isn't arguing security through obscurity. He is arguing for the cathedral approach vs. the bazaar. Don't get me wrong, he still is spreading FUD. Its just a different FUD than you think. He is ignoring the role that Linus Torvalds and some of his trusted lieutenants like Alan Cox play in planning a direction, vetting ideas, and protecting the stability of the code base. Patches don't just come out of the blue from anonymous sources and applied without any examination, no matter what Dan O'Dowd may think.
What people seem to forget as well is that terrorism is a moving target. One of the the things terrorists try to do is exploit weaknesses in the system. If open-source/Linux development had a history of rolling out changes with little review or testing, then I could see there being a case for concern. But where is the weakness right now? Closed source! Partly because of attitudes like this. You can't trust open source, but you can trust closed source. So who would the terrorists try to exploit? They aren't going to use open-source if it is going to be heavily scrutinized. Not to mention the outsourcing of development, which only reduces the ability of employers to know who is really working for them.
What's the difference with open-source? I think that it's simple -- your code is your identity. I don't care who you are, I care what you are contributing. You can tell me what a great patriot you are and show me all sorts of credentials, but if you submit crappy code, you aren't worth any more than someone who submits the same code anonymously. You will have to endure the same peer review, your code will have to perform just as well.
Excuse me? Isn't the whole point of the LKML/CVS/BitKeeper process that every line that goes into the kernel (at the least) is traceable to somebody? Do any major projects give out anonymous CVS access? Or even access to people who aren't at least somewhat known by other developers?
Meanwhile, at many commercial companies you could have employees who worked there for a few months and got fired/quit. Depending on their internal code tracking it might be hard to tell what code they submitted, and whether it should be changed. And I really doubt they keep track of the employees after they leave.
Most OSS projects you probably have at least an e-mail for all the contributors.
This guy from Green Hill is obviously scared for his business. It is a known fact that encryption systems whose algorithms are in the open, and have been tested as such are way more secured than those ones that are totally closed, since there is no way to ensure that the closed ones have been properly tested.
You can easily make the argument that Green Hills could hire someone who is a spy of some kind and that is embedding a back door code within Green Hills software. Now, who else but Green Hills would find this backdoor? And if they actually find it, what is the probability that they would tell anyone and what is the probability that they will find it right away?
In the case of Linux, hundreds of people are looking constantly at the code, which increases exponentially the chances for any possible backdoor to be found right away. Now, not everyone is allowed to upload code to the main source tree, just a small minority, but everyone can still look at it. Can Green Hills say the same thing about their "closed," "who knows what's inside of it" code? I don't think so!
I totally feel more secured with the "open" approach! What about you?!
I'm dealing with an issue like this at work. We have to qualify all software we use. Since we run mostly DOS and Windows on some stuff, we don't have to qualify that because its an off the shelf (OTS) product. However, when the subject of Linux comes up, they don't want to touch it because 1. How do you qualify it and 2. How are you sure it doesn't change. Since the source is open, technically I, having the root password, can compile a new kernel or something else and skew results (forgetting for a moment there's no real incentive for me to do so).
I'm trying to make the point that because something is open source doesn't mean it can't be qualified. There are vendors who will sell Linux as OTS... I guess they're Microsoft's bitch* and don't want to listen, so its a convienant excuse.
* They are... they're buying much more expensive 1553 cards with buffers on them so they can use Windows (and their licensing scheme) and now have to worry if they can't get to the bus in a real-time fashion. There's a reason people make real-time operating systems!
There are only 10 kinds of people in this world... those who understand binary and those who don't
IMHO, closed source solutions must be held to a higher standard then open source solutions. Open source solutions are proven in the wild, while close source solutions are much less so. With the availability of the source code, far more permutations of attack have probably been attempted against open source than closed source. In bottom line testing terms, chances are that open source has had far better code coverage tested than the closed source competitor. Closed source solutions must be held to a higher standard to compensate for this difference.
"To those who are overly cautious, everything is impossible. "
The most secure OS, would be one that uses open source code and improves uopn it(such as SELinux that the NSA uses). That way you would have many programmers taking a look at the code as well as less vulnerabilitiesin the first place, so you could effectively utilize security through obscurity right along side good old fashion bug testing.
Creative Demolition
One of the major advantages to open source is that it keeps everyone honest; no funny schtuff.
With closed source, it might work fine in test cases but there might be code hidden/lurking in the shadows that does something other than what's intended. If a cyberterrorist (or some a-hole) adds code that can be remotely activated and wreak havoc, it's harder to detect it if the code is like a black box (a mystery), and more likely to be detected in a clear box.
Just like ppl aren't likely to buy a car if you can't pop the hood, closed source shouldn't be either; especially if you're paying lots of money for it.
I'm so glad that Outlook is so trustworthy.
You are using quantity to argue quality.
I doubt Trojan horses are much of an issue in embedded systems: since embedded systems don't generally have external Internet access, it would be hard to trigger a Trojan horse in an embedded system, so any failures it would introduce would have to show up randomly and not just in response to a trigger.
Furthermore, for embedded code to try and infer what kind of system it's running on (military/non-military, essential/non-essential, deployed/non-deployed) and only fail in the essential, deployed, military systems is essentially impossible with the kind of minimalist code that could be hidden in an open source project and not noticed.
That means that if anybody planted a Trojan horse in OSS that was of any military significance, it would show up during testing as random failures, and that is just taken care of by normal testing procedures.
Note that the same argument doesn't work for closed source: something like a Green Hills embedded kernel could easily ship with a huge Trojan horse that looks for specific strings in system output/logs ("military", "target", "live munitions", "vehicle speed", whatever the military lingo is) and/or looks for specific sensor types, output devices, and/or communications channels and only triggers under specific circumstances likely to represent actual combat situations. While such attempts to identify combat situations would be blatantly obvious in 100% open source software and be noticed right away, they could easily be hidden in any big binary component of any closed source system.
All China, the USA's enemy, has to do is to disrupt things here enough to destabilize the USA economy.
How about some things we've recently seen: a power blackout, WTC 1 and 2, take your pick - oil refinery fire or pipeline accident....
I see a lot of the same old arguments in response to this article, such as this is about closed versus open development.
I don't think that's what O'Dowd is saying. It seems to me that the quotes in the article boil down to two arguments: 1) for sufficiently critical (i.e., national security) applications, you must vet the people in addition to the process; and 2) it is impractical to check open source code to the level of detail he asserts is required for national security purposes, after the fact, if the development process isn't controlled from the beginning (which includes worrying about (1) above).
I'm not arguing for or against what O'Dowd's arguments are; rather, I am arguing that most of the comments here are off the mark in addressing his arguments.
If it costs time and money to review code, then, all other conditions being equal, the code with fewer lines will take less time and money to review.
On the other hand, there is nothing stopping any Linux-based vendor from stripping out any non-applicable code from Linux before submitting it for a government application.
The real issues I see here are:
#1. He is in competition with a Linux-based vendor for specific governmental applications.
#2. He has to pay to have ALL of his code written and tested while the Linux-based vendors can take what is already available and pay to write fewer lines of code.
#3. Given #1 & #2, he tries to spread FUD in an attempt to scare people away from Linux in governmental applications because he cannot compete on price or reliability.
We've all seen this before and we'll see it again.
The FAA approves software when it is written according the DO-178B specification. This specification states that software when developed must adhere to a development process.
This is defined within the D) 178b as software requirements, software specification, software design, source code configuration, and software test suites. If one changes one part then all levels affected must change as well.
Simply put a paper trail must exist for every change made in a system. It is stringent anal rententive form of development. It is costly since the amount of book keeping that must be done to incorporate changes.
This is the 'cost' that O'Dowd is refering to. In order to make a 'DO-178B' compliant version of Linux a group of developers/software house would have to:
1) Ensure that a comprehensive set of functional requirements is generated to match the desired platform.
2) Define a kernel that matches desired functional requirement. Any kernel portion that is not needed is defined out.
3) Specify the behaviour for each driver. Ensure the driver is fully specified. Work from the source and ensure that the behaviour of each execution path is documented.
4) Ensure that all changes to this build are reviewed and a paper-trail exists for all changes and changes are made for solid well documented reasons.
5) Use the documented behaviours to generate test cases that validate the documented behaviour.
It goes on and on...
There is nothing inherent within Linux that would prevent a DO-178B build to be created.
Only in the last 3 years has Green-hills has marketed a DO-178B compliant system. DO-178B as a standard has been around for I believe the last 10 years. Hmmm...
Research is what I doing when I don't know what I am doing - Werner von Braun
yep
This is not to say a RTOS cant be baddly written or contain bugs. Its just that determininsm makes testing easier. It also does not mean a RTOS is more efficient than Linux.
Some drink at the fountain of knowledge. Others just gargle.
I wouldn't be too surprised if one or more defense contractors is subcontracting work to Pakistan or some other place where there's a decent number of people who might have an interest in damaging the US or could be paid to have such an interest.
That process sounds like something a well-functioning software company would use: the reviews, record keeping, testing. The difference with the industry is that the product will ship eventually, even if it has bugs.
With the Linux development cycle, I'd say things are tested perhaps even more than those industry software products. There are differences too: only the relevant functionality is tested (i.e. the functionality, does it work properly for all users who use it). There's no point in testing e.g. some obscure boundary value for an API call to SCSI subsystem, which would cause a panic, if such a call could never be called and is never used by anyone.
The biggest difference is nevertheless the lack of records during testing... unless you consider the bug database to be such. In a way, the test cases are found a posteriori (with regard to the release of the software), sort of, instead of a priori, as is the case with commercial software.
I do not moderate.
oh yeah I forgot. Diebold uses russians. Sequoia is foreign owned. Shouptronics founder served time for Election Machine Rigging, Seqoia execs indicted for bribing election officials, and GEMS VP of research served time for computer fraud.
In contrast OVC is a multi-national effort but its all open source so no one cares there be foreign nationals programming US machines.
Some drink at the fountain of knowledge. Others just gargle.
I have no idea if they were actually successful or not.
I thougt the purpose of a such a code review
was to review design to make sure it's sound,
and casually screen code for best practices.
None of that includes "debugging" the codebase.
Well, I would be surprised. You seem to be an outsider just speculating.
resigned
Well, I won't comment on whether Linux is appropriate for defense work, since I've never attempted to use it for such.
However, I can comment on Green Hills Software. We use it on both X86 and PPC targets at work. I can safely say, that I've never seen a toolchain that was more of a pain-in-the-ass to use, nor a debugger that was so buggy as to be virtually worthless. Tracing code execution with a logic analyzer would be less painful.
I guess people are turning away from GHS because they suck and they're just trying to bad-mouth all their competition!
Perfect obscurity is perfect security. The problem is this: there is no perfect obscurity. It has been said "Two men can keep a secret, if one of them is dead". While obscurity is no substitute for other forms of security, I don't believe it's only a small advantage. (I'm not saying where Linux should or should not be used, only that a valid argument could be made on this front.)
I won't join Slashcott. OTOH, If Beta goes live, I just won't be back until it's fixed. Sorry Dice.
there are more people looking at the code, so it is less likely that bugs slip through
People always say that, as if there are thousands of guys sitting down doing nothing but "looking at code" all the time. I'm sure a few devs will examine their code for bugs when they can, but this whole thousand-eyes myth is simply that. I've never even bothered poring through the Linux kernel source, and I imagine few here at Slashdot have except for a few casual curious glimpses now and then, but I'm talking about actually sitting down and looking through it. Really, it's only the kernel dev guys who do that. Along those lines, nobody sits down poring through KDE code or anything else. The only people who are ever interested in looking through the code are the developers who are writing it.
Not to mention that OSS has plenty of flaws and bugs all the time, in varying degrees in comparison to, say, Windows. It's a nice hypothetical idea, but in reality lots of things slip through all the time.
The DOD might be stringent in its requirements, but I can't imagine any one group being more strict that the FAA.
*Every* bit of code must adhere to certain syntax standards and be tested thoroughly (100% code coverage)...
Not easy to do this, but would be "do"able with a stripped down Linux.
- Hawkeye...
"...The smart and lazy ones I make my commanders." - Erwin Rommel
In fact, open-source software may have a slight advantage here, because it's less of a monoculture. Presumably Microsoft always uses their own Visual C++ compiler to build Windows, so if there were a trojan in the compiler that compromised the resulting Windows executables, it would be present in all copies of Windows that Microsoft distributed. But open source software is by its nature built on many different platforms using different compilers, so a compiler trojan would only affect a portion of the deployed copies of the open source software. And it is possible that a trojan introduced by one particular compiler would be found due to the executable it produces being different in some noticable way from the executable produced by a different compiler. For instance, strace might show the trojaned executable making extra system calls.
How does Mr. O'Dowd propose to assure us that his company's operating systems and compilers are more secure than Linux, xBSD, GCC, etc? Is he certain that none of his employess who have written code incorporated into his products have ever installed trojans? If so, how has he gained this certainty? Has he scrutinized every line of source code himself? Including those of the compilers that compiled the compilers, back all the way to the machine-code only origin of the system? Somehow I doubt it.
It is a matter of historical fact that far more trojan and back door exploits have been present in commercial, closed source software than in open source software. Just two days ago Cisco had to issue a security advisory regarding a back door found in their WLSE and HSE products. Would Mr. O'Dowd conclude that foreign agents and terrorists are responsible for that? Would he really have us believe that these shadowy figures can compromise open source software developed in the public eye more easily than they could subvert a commercial closed-source software package for which the source code and development process get no public scrutiny?
One is forced to conclude that Mr. O'Dowd feels his company's business model is threatened, and rather than change that model to reflect changes in the marketplace, he prefers to use "the sky is falling" proclamations in an attempt to scare customers into sticking with his products.
The whole story is so absolutely paranoid (The Russians are coming! Beware of the Yellow Peril!) and shows such a complete lack of understanding of the Linux Open Source process that it would make me worry if I were buying Green Hills' software: Do you want to buy something from somebody who is this divorced from reality and has this little understanding of how his competitor works?
There are a number of open source projects that have had their servers 0wn3d by crackers in the last year or two. In at least one or two cases the source code was tainted.
So, are you saying that, given an appropriate motivation (like linux being used to power Star Wars weapons) that the national security apparatus of a major power, with what are relatively unlimited resources and methods (buy equipment, time, expertise or information, hack, bribe, extort, tait software at source, infiltrate, murder (project lead?)) wouldn't be able to insert code when a pimple faced kid somehwere was able to do so?
Do you think that code would automatically be detected when so many bugs, bad practices, poor design, etc., etc., go undetected or fixed in open source software?
Consider this. Ken Thompson used to be able to login to just about any unix system in the world even if he didn't have an account. People checked and rechecked their systems. It didn't tend to help them. He later revealed his secret. Next, check out the Obfuscated C Contest. Some of the entries have additional functionality that isn't evident. One example is this one which implements 4 functions. I certainly wouldn't put it past somebody to be able to produce pretty standard looking C code that would pass the sniff test but which would, either by itself, or perhaps in combination with other code, implement an entirely different, second level of functionality which could be exploited as needed.
Given the potential stakes of defense work (losing a war, national survival, etc.) there is plenty of potential incentive for the finest minds a nation produces to tackle these problems, and potentially solve them. If you believe otherwise I think you are living in an open source dream world.
... if laws were ever passed - by any government, anywhere - against Linux/OSS following a security breach or some such shit. And the thing is, it really wouldn't surprise me if it happenned.
... If Linux is compromised, our defenses could be disabled, spied upon or commandeered ... Everyday new code is added to Linux in Russia, China and elsewhere throughout the world. Everyday that code is incorporated into our command, control, communications and weapons systems. This must stop.
On another note, this guy is a fool:
Now that foreign intelligence agencies and terrorists know that Linux is going to control our most advanced defense systems, they can use fake identities to contribute subversive software
Well, honestly, what's to stop somebody terroristish from getting a job at Microsoft, hmm?
This is actually a lot more offensive than a stab at Linux. This is a stab at ALL Free/Open Source software. You really don't think he's just talking about the Kernel do you?
Calling it "Linux" is just a way for him to side-step the obvious positive connotations of the words "Free" and "Open". He's intentionally seeking to damage Linux. Why? He's a soul leeching asshole, that's why.
And if the U.S. Navy are in all honesty swayed by his words, then I really do worry about the future of Linux. At least, for you poor bastards in America.
Somebody mod this up! "Sleeper agents" aren't all cab drivers and pizza deliver drivers....
"The Internet is made of cats."
It shows a pretty complete lack of understanding of the state of the industry, as well...
"The Internet is made of cats."
'O'Dowd's digs at Linux appear to already be having some effect. "We've had five or six people calling us up saying we were thinking of using Linux, and now they're thinking again," he said. O'Dowd mentioned that one of those potential customers was the U.S. Navy, but his public relations representative cut in and cautioned him not to talk about that any further.'
;o)
Aside from the 5 or 6 people he's had phone up telling him they'll not use Linux [ignoring the obvious fact these are the sort of people who are stupid enough to phone someone when they decide to use a different operating system, based on the advice of an idiot, who they phone - and the likelyhood one of those 5 or 6 [that's funny, he's not sure if it's 5 or 6...] is probably his mother], who are almost certainly idiots, he then has to be told by an advisor not to talk about the future security arrangements of the US Navy.
I wouldn't buy anything that man sells or says and, quite frankly, I find his name very suspicious
"Everyday new code is added to Linux in Russia, China and elsewhere throughout the world. Everyday that code is incorporated into our command, control, communications and weapons systems. This must stop."
;)
According to my own _theory_, he _must_ be!
Someone, tell him to leave his tinfoil hat at home please!
If your os/application have to be secure, you *need* to do a security audit on the codebase.
Doesn't matter wether it's open source or closed source, you need at least one independent with full access to the source code and the resources to check every line of code.
need to update the software, you'll have to do a new audit.
If you've got your real time system in rom inside a piece of equipment, or in thousands of pieces of equipment, you've got to be very careful with it.
Desktop system can be patched and upgraded, but ROMs have to be replaced or flashed. For example, you've got to bring the missle into the hanger/lab and hook up the reflashing unit or swap out the ROM chip. You've got to test the missle with the new chip. Out in the field, the soldiers have new ly upgraded missles (or tanks...) and would really like to know that it will work when they need it. You can field test a tank, but some missles are expensive, especially when all you want to do is prove you installed the right chip in the right way.
When a desktop or server software hiccups, the human user can work around it. Often this is not the case in communications and avionics.
Linux Advantages Don't Translate to Military Embedded Systems
Embedded systems are almost always memory-resident and have no disk for software storage. There are usually no user identities to manage, and the user interface is quite often absent or primitive.
Most of the advantages of Linux do not apply to an embedded, military situation: Licensing fees for software are usually a negligable part of a tank, missle or radar. Embedded RTOS systems are already quite reliable, and do not suffer from nearly as many buffer overruns, neither are they susceptible to hackers. Embedded military systems are almost never connected to the internet.
You could build a reliable, compact embedded software system from embedded Linux, but you'd want to write all your own drivers and you would have to port it to special hardware. This approximately the same amount of work that you would have to do if you were to use a proprietary RTOS.
The vast bulk of the problems users experience with proprietary OS's are 1) expensive to license, more expensive to license across many machines. 2) Security vulnerabilities resulting from using a system designed and built for stand-alone personal use in an internetworked environment. Neither of these problems matters much to embedded, military systems.
I18N == Intergalacticization
What this means is that all those bugs that get found and fixed quicker in open source than they do in normal closed source software aren't in Green Hills stuff in the first place.
I think people need to view Dan Klein's "Flying Linux" presentation. Streaming link at LinuxForum 2004
This Green Sumfiun fella said all this because he can get away with saying it even if there is nothing of substance.
The idea that code is being introduced as though no one is minding the store is fatuous.
The very idea that an open source project is less secure precisely because it is open source is equally fatuous, but I suspect the speaker already knew that. To borrow a phrase from Chris Rock, ain't nothing in the world worse than someone who knows you won't sue them.
What is the most absurd part of the remarks, implicit in them is the idea that someone from Russia or China has no desire that the Linux kernel be secure for their own national defense interests as well, and that no one other than the US is interested in helping the DoD maintain a strong defense.
Remember: The United States of America is the sole remaining bulwark against the barbarity represented by terrorists, their supporters, nation-states who provide funding and enablers. The United States wants to preserve civilization, not knock it down
Saying that folks who live under different flags do not share the same goals as the US is as goofy as the speaker's assertions
Dawn of the Dead
What is time any way.....
Each application has different needs, so some might need 1ns accuracy (nuclear detonators/patriot missiles) , and some might need 20ms accuracy.
Besides linux there are other RT free OS's , like TINYOS - http://webs.cs.berkeley.edu/tos/
or mini NetBSD.
Linux isnt the only thing around, theres a lot of choices which are free, just that linux gets the attention, both good and bad.
Liberty freedom are no1, not dicks in suits.
I was thinking just the same thing. However, I still consider this as total FUD. Nobody is forcing them to use all of Linux. Most of the Linux source code is device drivers. It would be really stupid to review every device driver included in the kernel -- they won't use all those devices and most devices have hardware bugs so it doesn't matter if the source code were perfect because those devices still wouldn't work perfectly.
The real question is, if just the review of source code costs them $500 to $1000 a line, then how much does it cost to design, write the code, debug and then review the source? Surely they would gain hugely from looking at the Linux source code for things that need to be done for their application and just review those bits.
I guess that the real issue behind this FUD is that they are upset that their competitors can start on top of the Linux and they, with longer history, already have source code under different (non-compatible with GPL) license and they've decided that they cannot use Linux source code (because it would force them to license under GPL). So they just go on throwing FUD and hoping that somebody buys their more expensive and arguably higher quality product.
Writing high quality software is always costly. If you outsource it to foreign countries, the costly things just morph to other things -- like writing the source code is now cheaper but the review just got much more expensive because the review "must" be done by "us" and you have to consider every line compromised until proven otherwise. With Linux you get the source for Free, it's up to you do decide how much reviewing it still needs.
_________________________
Spelling and grammar mistakes left as an exercise for the reader.
If you only hear one side then its not very balanced (i think my teacher taught me that when i was about 8)
If linux was total spagetti code and no-one in the government even checked a hash, let alone checked the code before incorporating it, then maybe he would have a point. But its very hard to slip a trojan in (heh) to nice modular well designed code. History has prooven without a doubt that organisations/companies etc can be very insecure, there have been plenty of experiments and real life cases of security breach including getting on planes/tarmac with weapons and no pass, getting into corporate intranets with full access, guessing insecure passwords or seeing them left written on white-boards, trusted security/cleaners having the run of the building, PHB's with no clue modifying code and accidently leaving holes, and pissed off or joking employees leaving their own back doors and just look at Diebold and the recent Windows leak for an example of what closed source-code looks like! Linux isnt a free system on a stick for the US government to have, if they want it and want to feel safe with it they should do some of their own checking and then they can feel very safe, but with anything closed they dont have that option - just some binaries that were probably outsourced around the world anyway!
This comment does not represent the views or opinions of the user.
Is this guy high? Does he have ANY idea how open source projects work? Sure, you can modify YOUR copy however you want, but if you want your modifications to go back into the main source tree, the project leader is going to have to OK them, not to mention the dozens (or thousands, in some cases) of people who will then look at the code and cry shenannigans if anything is afoul. Is there even a single documented case of malicious code being intentionally put into open-source software and not being discovered? Any don't give me that Ken Thompson crap; sure, you can fuck around with the compiler, but as gcc is itself open-source and always has been, I consider it a hell of alot more trustworthy than Green Hills'.
However, very very little Defense software requires DO-178B level ANYTHING certification.
This certification does not mean that there are not bugs in the software. Based on some limited experience I would say it does not even imply that the compiler and OS that Greenhills provides actuall even works together.
In the end, selecting an environment for any system has little to do with a closed v.s. open source issue and more to do with selecting the tool fits the job. However, the portion of the trade space that deals with open v.s. closed would certainly tip in favor of Open since I have almost no hope of reviewing or discovering holes in a closed system.
--- Liberty in our Lifetime
The hardware these systems run on, in many cases have components manufactured by foreign nationals.
How hard is it to put more into a chip than was requested? Military planes falling out of the sky is bad when it's yours.
How about using easily obtainable supercomputers and the best emulation software to figure out how much to shave off of every component to make the entire system weaker but still pass all the Milspec tests?
In theory, it may be possible for someone to hide some trap-door function that allows some un-authorized access.
Before lecturing me on the "many-eyes" theory of code inspection, recall that some cases take a LOT of work to decided. In fact, many people are probably familiar with a famous instance of this problem - DES. For a quarter-century, the debate has raged on whether NSA selected the S-Boxes to have an unknown weakness, AKA private back-door. Many clever cryptographers have spent many man-years and there is still no conclusive statement. (I happen to agree with the majority view that there is probably no such weakness but I wouldn't bet my life on it.)
So, the question is: can someone put in a bunch of clever code in appearantly unrelated places that happens to create a security hole? Emperically, this happens accidentally quite often (just go through the CERT security advisories for examples) so it is at least possible that someone could deliberately put one in.
There is no theoretical reason nor practical experience to say that "many-eyes" will catch all of these traps (even if we assume there are many eyes actually looking). Indeed, even concerted detailed code-inspection may not find them all.
Having raised this question, I like to state that I believe that this is most likely a theoretical concern as long as there are "owners" of each piece of code who pay long-term attention to their charges and that we can assume the owners are not colluding. This first condition pretty much eliminates any "simple" holes that are localised in a single component, the second condition makes it very difficult to have multi-component holes. Forturnately, most open-source software, including Linux, meet these conditions; so I am not too worried.
Is it right for national agencies to be worried? Of course they should! But it is also relatively easy to just have their own "shadow owner" for each module. So it is possible for the agencies to gain confidence at low cost (not cheap, just low cost relatively speaking).
I'm a long time Linux user (late '93) and advocate and I have explored Integrity about four months ago. Let them spread FUD if they want. I would hope that we, the linux community are above that. Nothing would please me more than to have this guantlet be taken up by some interested folks, have them explore some of the major concepts which Green Hills promoted for their embedded OS, and impliment them for embedded Linux.
Green Hills Integrity has interesting features such as kernel and MMC enforced seperation of memory space, manatory access controls in the OS, and most insteresting, guarantied resources.
It seemed to me, talking with a presenter that came into our firm, that Green Hills has three things going for them. First, they really do seem to have a solid design, well throught out with features required for folks seeking high levels of trust and availability (technically) and they have multiple organizations (FAA and soon NSA) backing their security targets (things they claim it does, verified by NIAP labs, etc), and third, they have some really fantastic debugging tools. Real-time and record and re-run monitoring for *everything*, direct off your emebedded hardware. Some of their stuff is really slick.
I'd hope that our community can see past the FUD and marketing dribble, and get to the heart of the challenge. If we want to show Green Hills up, take some of the key concepts which their customers require, such resouce availability and DAC capabilities of the OS and integrate them into embedded linux as options. Leave them with only the tools market, and in five years they may just be developing tools for embedded linux development instead...
Don't let Green Hills pull the wool over your eyes. This is not an Open Source vs Proprietary fight. They have some very nice security concepts and features embedded linux simply can not (yet) complete against. This is just the left jab...it's the distraction, watch for the right fist in closed door sales presentations and as deal closers. Would you let your CEO explain anything techincal? You might let him use a left jab...
I used to work with FAA certified aircraft software. I can say that whether or not software is open or closed source makes NO DIFFERENCE in whether it can be approved. What makes a difference is the process.
When software is written for aviation, it must have strongly defined requirements. It is wise to pass these past the government for approval to avoid wasting time later. Then, each function must derive directly from the requirements. Each function must have a corresponding test suite written by a different person who does not communicate with the code writer (they can only share the requirements document). Additionally, once the code is 'passed over the wall' to the tester, a certain amount of each for-loop must be exercised in testing, and if or case statements must be tried.
If the software passes this, then it is integrated and tested as a whole. There must be test documents to support how this is done. All test results, data, and code must be sent off to the government for approval. No code changes can occur during the entire process without performing some of the tests again.
If you follow this process, your open source project can be certified. However, it is terribly expensive in terms of man hours. More time is spent on test and planning than on code writing. This is why most FOSS projects will never make it in Gov't apps - but they could if you spent the time.
Since the FAA is pretty stict, I assume the defense process is similar.
Defense applications are usually running in an isolated environment, not connected to the internet or any WAN. So I can't see how there is a security problem. Furthermore, most real-time weapon and radar systems use operating systems like Lynx, not Linux or Windows.
Security issues may exist in development environments, that are usually LANs connected to WANs. In that case, Linux is preferrable, due to better security.
As for open source being better when it comes to security, it is irrelevant to defense applications subcontracting. As long as the subcontractor is audited and found to have satisfactory methodologies and coding procedures, the contractor is ok. The focus in these cases is on qualification and testing, and they usually do exhaustive testing (i.e. testing every possible case) to make sure the application works as intended.
... with the linux or bsd kernel anyway? roll your own minimal system that does only what you want it to do? rhetorical, I know it's being done. I think that's what I meant in the original post, plus those costs he quoted... I mean, really. I think that guy from RaTtyOS forgot his meds that day...
I know he's got to do whatever he can think of to keep his business going, my recommendation to him is to move on, accept reality and get with the program. In the long run, it is most inevitable that in 99% of the real world applications out there that open source/free will "take over". Look at it just over the past 5 years, now do a rough bar napkin guesstimate of 5 years into the future. where you gonna drop your chips?
--your smart guys in government agency abc look at the code, too, before ya deploy it. If they can't see any holes either, chances are they aren't there. No guarantees with either closed source or open source. Just because someone has a "top seekrit" whizzbang clearance doesn't mean he is trustworthy. Plenty of real world examples out there of agents gone bad or rogue. The WORST public spy scandals we know of haven'tbeen foreign people penetrating secure systems, it's been inside jobs done from people supposedly hugely trustworthy.
The point is, it's not the coder, it's THE CODE ITSELF. If you can look at it, and it's your business to be secure, then look at it twice, and read what other diverse folks have noticed about it, that's the best you can do with it. Many eyes make for less stuff going unnoticed I think.
Obviously some of this article is pure FUD. However, I think some of the points are extremely valid. I don't think that the open source world has the same sort of reliability standards as the reliable embedded systems world. All that cheerleading about millions of eyeballs going over open systems code doesn't fix this.
The sort of verification work required to certify code for high-reliabilty systems is very, very boring. I don't know that this sort of work is scratching anyone's personal itch in the way that, say, fixing a broken PC device driver fixes someone's itch.
Another problem is that being the first mover is a huge disadvantage. If you spend tens of millions verifying your source code up to some known standard, you're in the interesting spot of having to release it later. Granted there might be some user-level stuff that you keep out of GPL. Aside from that the rest of the world gets to see a kernel that is known to have passed some expensive, complicated verification standard, and can start there.
I'm not saying that it's impossible for embedded Linux to meet these sort of standards, or that some company somewhere won't find a good reason to do this work even if others benefit from it. But please, spare us the "millions of eyeballs checking the wonderful open source, line by line" stuff. This is far from the level of accountability and detail required from high-reliability systems - even if you have some sort of faith that code had been really well checked over by the open source world, how would you know for sure?
the guy has a big investment at stake, he's gonna say anything to maintain his business. Hopefully he'll realise he is going to be forced to adapt. And being disingenuous like that in public doesn't make any smart person contemplating his product think this guy HIMSELF is trustworthy. I'd think thrice about buying any of his stuff were I in a purchasing situation now. If he can (probably, no way to tell for sure,I am using educated guess) fudge about this, what else would he might fudge about?
Too bad Sun has the same opinions:
Unix will be back. Really, it will! Everything is beautiful! Don't worry! Be happy! Customers will return to Solaris one day! After all, if schwartz said it, it must be true.
and even scott is a believer:
The "fad will wear off, and big business will come back to solaris".
Sun, don't worry, everything is great. Everybody else should wake up and smell the java
Sound familiar?
One last observation.
I don't have much knowledge into real time, although like most people I guess I "use" them all the time, just don't see it. Everything got osme embedded doo dad in them now. I'll take linux/bsd out of the equation and just use a generic "open source" then as a future projection model. Right now, what you say may well be true. In the future, and the real soon future, it just might not be so. If I had to bet,I'd bet on open source capturing most of the computer market for all purposes sooner or later. Not all, but most. Heck, I had as little of two years ago people (inet gurus mostly in discussions) telling me that open source was gonna not even be here much around this time, that it was a soon to disappear fad, would never amount to anything, that it was "doomed". I think it's safe to say at least on that point, those were an inaccurate past assessments. Whether or not closed source/propietary will maintain a huge presence, for the immediate future-the next few years, I think it will, but it will gradually lose steam, as it is now. And I think the emphasis will gain ground on a rising curve for open source, not just maintain a steady state. None of us has a lock on the future, but I think it's possible to get some pretty obvious trends. If there's a market or an interest, it's gonna be worked on in the open source arena, and so far, as near as I can see, that modality is getting some nice advances, moreso than what most of the mainstream pundits *that I read anyway) predicted just a few years ago. And it certainly shows in the software that is near mainstream now, take moz for example, and the larger distros. They are *signifcantly* better than two years ago, the improvement curve is most impressive. Not sure if this will slide into the real time and embedded applications, but it appears it will. Besides that, no one really "knows" so I'll concede on that.
What developers can do to help is to modify a web server, a mail server, and a DNS server (the most attacked server side software) to run under NSA Secure Linux, partitioned into levels of integrity.
The idea is that just because somebody attacks, say, the mail server receive program, that doesn't get them power over the whole system. All it should do is let them run their attack code in a jail where it can't do anything except burn CPU cycles, and maybe generate phony incoming mail. Mail associated with the known IP address from which that copy of the receiver was launched, so the problem can be tracked.. When they disconnect, or some monitor program kills the corrupted component off, all the damage should be flushed.
You need to rework key server apps so that about 95% of the code is untrusted and jailed, while the 5% that has to do security-related functions is isolated, identified, and carefully examined.
That's what NSA Secure Linux is for.
While this security stuff is transparently FUD, Green Hills do make a point on their website that I believe to be valid: Real-Time performance cannnot be retrofitted.
There is widespread confusion between the concept of an embedded OS and an RTOS, and before I go further, I should clear this up.
An embedded OS is any OS that you can configure to run an embedded application. This definition has recently been extended to include multi application devices, like PDA's and Phones, that are in effect very low resourced personal computers, with non-standard interfaces, rather than embedded devices.
An RTOS guarantees that 1) an interrupt will be handled within a fixed number of clock cycles and 2) that this number is small enough that the response will appear instantaneous in comparison with the time constants of the sytem in which it is used. For example, Humans can't generally see things faster than 0.1 secs, so an OS guaranteeing 10ms response on a given platform would be real-time for a UI application. For hi speed motor control, we might well be talking about acceptable latencies of 10us or less.
As a proud owner of a Sharp Zaurus, which is a fairly well specified hardware platform (extrordinarily so in embedded terms), I know that the embedded Linux running on it is not realtime for a UI. Even if Linux is improved for embedded apps, and platforms get faster, RTOS's will also be improved, and they will run on lighter platforms.
There is therefore no way that Linux will be running as an RTOS in low-latency applications ever: it will always be cheaper to use a designed-for-realtime OS on a lighter weight platform.
Currently all (AFIK) RTOS's are proprietary. The challenge for the FOSS community is not to insist that Linux is appropriate everywhere, but to design a truly open source RTOS from the ground up, so that we have the same comfort in a lift or with our car's ABS as we do in the robustness of our IT running on Linux.
If I see a lift or a car running Linux, I'll take the stairs and public transport thanks very much, but I'll continue to mostly run Linux at home.Over on Google News, the article they're leading on this news story is from The Inquirer, titled "Man goes ballistic, says Linux is a security threat" ... "EE TIMES said a real time operating system (RTOS) firm has gone apeshit bananas about the very idea of using Linux in embedded systems because it poses a security threat ..."
I played with the the 'Green Hills' compiler, named gcc curiously enough. It also has very similar options to the famed GNU gcc compiler. They even ofter gcc extentions. Unfortunatly it isn't a very up-to-date compiler. They document some old known 'bugs' like the library search order issue of years past that ld has had.
My OPINION is that it is an older gcc compiler. And that is the CORE of why these 'nice people' are so worried. The don't have any value add over the free software solutions because a few guys simply can't keep pace with adding their patches on top of current releases and so are behind the times.
"As a cryptography and computer security expert, I have never understood the current fuss about the open source software movement. In the cryptography world, we consider open source necessary for good security; we have for decades. Public security is always more secure than proprietary security. It's true for cryptographic algorithms, security protocols, and security source code. For us, open source isn't just a business model; it's smart engineering practice."
Exactly right - so much so that I've asked my editor at linuxinsider (which will be offering a rebutal of my own soon) to contact him for permission to reprint his whole article on the subject. That may not happen, but you can look at it directly on his website: http://www.schneier.com/crypto-gram-9909.html and sae how an expert handles the somewhat loony argument against open source in high security environments.
I'm going to stick my neck out and declare that RTOS are overrated. You don't need a full-blown operating system to operate a microwave or even a heat-seeking missile. You need dedicated code that performs whatever specific tasks are required and nothing more.
The whole point of an "operating system" is to serve as a generic host for other software. DOS, even in the early days, was really just a series of tools to organise and manipulate files on various storage media. Windows is the same thing, with a bunch of generic hardware interfaces thrown in. Ditto for Linux, except we actively distinguish between OS and GUI. These things have no place in single-purpose devices.
Sure it might be easier to install a stripped-down linux on your toaster and use a USB webcam to monitor the color and apparent texture of the bread and pop it out once it's just perfect, but that's the unprofessional, lazy way out. Use a simpler CPU with dedicated code to perform the same task, and ONLY that task.
Heck even the XBOX is proof : everyone's yakking about how the Xbox uses a "stripped-down version of the Windows 2000 kernel". Bullsh!t! You've got 256kb of rom code that presents a DirectX-like interface to the underlying hardware, as well as basic I/O for disk and networking. An API, nothing more. There is no OS, just 'device drivers', to borrow a PC concept.
Why do I care ? Because right now I'm putting together a homebrew car stereo unit. Do I need my car to be running cron, X and apache ? hell no. a full-blown operating system is much overkill for just playing music and maybe showing navigational aids.
The whole concept of PC-everything is just sickening and counter-evolutionary. Use the right tools for the right solution.
-Billco, Fnarg.com
Can someone tell me what would stop a determined adversary from hacking windows and or linux? Windows, in my open is pretty fricken open, goto MSDN, I've never not found what I was looking for, the same can be said for Linux, however a little more search may be necessary. So everyone here is telling me that becasue Linux code is vetted before non-payrolled developers this makes it less vulnerable, seems pretty weird all these foreigners doing America a big favour? Let's all be a little more honest, yes Microsoft sucks, and no Linux can't provide security by obsecurity. If you want in, you will find a way, regardless.
drink, smoke and be happy, software is just software and it really dosen't matter.
Dave
BTW, JFYI: To be approved for using in restricted or classified govt. offices and some other sites (like nuclear facilities) here, in Russia, software must be taken for the source code audit by the State Technical Comission. NT4SP3 (dunno build), NW 4, Win 2003 and some flavour of Linux had been approved.
Dunno how'bout Chinese, but there were many my pals migrated to USA/Canada from Russia and some have worked, are working or are gonna working for those companies like Cisco, M$ and IBM. I guess somebody would have not so high moral princeples to make easy money.
the rule of thumb about trusting no one especially applies to reputed disgusting fucking perverts such as yourself. anyone you see might be an agent about to free society for your foul perversions. Piers the foul digusting ass philandering weirdo. You wanted the nick, spoogman, but spongman will hav to do. you fucking liar bitch, mister claims to work at microsoft, mister claims to not be a worthless fuck that works with spyware vendors to fuck people fucking bitch.
It's too bad the world hasn't quite settled down and unanimously agreed to disdain negative campaigns and choose based on relative merits as enunciated by positive campaigns. The nice guy still loses sometimes.
(Don't blame me, I voted for Kucinich
but isn't much easier for someone to determine how to circumvent a security precaution if they can see the code used?
i would think closed, obscure code would first have to be deciphered thus adding an extra layer of protection to the process. this, of course, assuming that the security in both the open and closed source solutions were equal otherwise.
and before all the babies come back with troll insults, i don't have windows running on a single machine. Mac OSX(&OS9), Slackware, BeOS Max are my OS's.
OSS may not be the best use for every single application. i just can't imagine the government releasing security changes to the public. not gonna do it.
As Jefferson noted, America is not based on trust, but on *distrust*, particularly of the government. A bad guy could weasel into any IT org, but only if the source was closed (and trusted) could it safely work its harm. Open source lets the code be examined, and tested thoroughly. Forget the motives of the evil, the incompetent, the deluded - look at their work product, and decide. If the US were serious about cybersecurity, it would be auditing source releases for certification, and distributing hashes of certified source packages. Only jokers try to ensure that all the developers are angels.
--
make install -not war