Linux Unfit for National Security
by Ed Sawicki
Accelerated Learning Center
Tailored Computers
June 6, 2004
EETimes, a newspaper for the engineering community, recently ran a story called Linux: unfit for national security? that questions the wisdom of using Linux in designs for weapons systems and other military hardware. Quoting from the article:
Purdue University professor Eugene Spafford and Cynthia Irvine of the Naval Postgraduate School warned that the highest-level, but little-understood, security concerns are sometimes ignored during the development of control systems for tanks, bombs, missiles and defense aircraft. Linux, Windows and Solaris operating systems should not be used in such applications, Spafford said. "An awful lot of decisions involving national-defense implications are being made on the basis of price and personal bias, and not upon sound evaluation of the underlying tools and software," said Spafford, who is executive director of the largest U.S. academic research center on information security, the Center for Education and Research in Information Assurance and Security, as well as an adviser to President Bush. "And it's happening in places where it should not be happening." Although Spafford said that virtually no developers would attempt to use Windows in such high-security applications, many are already employing Linux, believing it is sufficiently secure.
The article presents contrasting viewpoints from those who think that Linux is secure and, presumably, a good choice for these applications. One of the comments comes from someone in our own backyard:
"It [Linux] poses no more of a threat than any other operating system in the world," said Neil Henderson, general manager of Mentor Graphics Corp.'s Embedded Systems Division (Wilsonville, Ore.), a maker of hardware and software design solutions.
I'm a Linux enthusiast, but I agree with the folks from the Naval Postgraduate School. Linux is not the best choice for the type of military applications mentioned in the article. However, security issues are not the only reasons why other operating systems are better choices. There are issues of interrupt-handling, latency, architecture, kernel-space vs. user-space issues, and others that must be considered in such designs.
In these religious debates, truth often loses to exagerration. The article quotes the CEO of Green Hills Software as saying that "Linux violates every principle of security". If he really said this and was not misquoted, he is wrong. Linux security is quite good when deployed and configured properly. My company has deployed its sealed system technology using Linux and the results are impressive. Besides, I've never seen an operating system that violates every principle of security. I don't think that's possible - though early versions of Windows come close.
This same CEO charges that Linux embedded system suppliers MontaVista Software and LynuxWorks Inc. are using offshore software developers in such locales as Moscow and Beijing, a practice he describes as a security threat. This time, I agree. When you're designing military hardware, it's best to use code developed by people whose loyalty is less of a question. The Open Source community would disagree with this, claiming that many eyes can scrutinize source code and find problems that individual programmers can't.
Spafford and Irvine say that the "many eyes" concept is not a sufficient form of assurance for national-security-level applications. "A subtle flaw could be included in the system and missed by all those eyes, because they may not have the training or motivation to look for the right problems," Spafford said. Spafford is correct again. Of all the eyes scrutinizing Open Source software, it's not a given that any pair of eyes will be so focused on security that the resulting code would be fit for national security applications.
Spafford describes Linux as a "general-use operating system" and he's correct. It's a marvelous general-purpose operating system that's prudent for use in general applications, like business computing, Internet infrastructure, and even embedded applications that don't demand capability from Linux that it does not have to offer. None of the debate now taking place in the embedded systems world should detract from that - but it probably will.
Those without a good grounding in computer science may miss the distinctions between business computing and embedded system design for military applications. Someone with a convincing argument that Linux is not secure enough for specific applications will probably manage to convince others that Linux is not generally secure. Similarly, a designer who does not choose to use Linux because of, say, interrupt latency issues may convince others that Linux is unfit for general use, where interrupt latency is not a concern.
The article is satisfying in one perverse respect. It's good to see people in other areas of the computing world struggling with people choosing solutions that are far from ideal. In the world of business computing, this is a way of life. Now the military hardware folks are fighting the same battle but for much higher stakes - the lives of military pilots, tank crews, and sailors (remember the USS Yorktown/Windows NT affair?). Maybe they will win their battle and the fallout will spill over into the the business computing world. Hey, it could happen.
Here's another article that talks about using Linux in embedded systems: http://www.qnx.com/download/feature.html?programid=12925
Feedback to this Article
Gene Spafford - Purdue University (who was quoted in the article) responds:
Nice article -- thanks for the pointer!
Joe Robertson: Very nice article. The fourth sentence in the last paragraph (following "USS Yorktown") is missing the most important last few words: "not to mention the general public at large whom this is all supposed to protect".
Shannon C. Dealy, DeaTech Research Inc.:
Good article, but it and the original article it responds to, all fall short of the real problem. I have done work in computer security, DOD Mil-Spec environments, and a great deal of work on Medical devices, and in my experience, there is not now, nor is there likely to be in the forseeable future, any operating system which is "suitable" for life critical applications (as in OS bugs or security holes cannot cause a failure which will result in unintended injury or death), and even if there was, the hardware for these systems is not designed to a level which would ensure that a hardware problem wouldn't result in the same failure. Whether the cause is a security failure, kernel race condition, power glitch, or bit flipped due to radiation, there are going to be failures, people are going to be injured, and some of them will die. The question is always one of cost versus risk, and at some point, somewhere, either a decision will be made (right or wrong) what level of risk is acceptable, or the decision will be ignored and an engineer will make it by default based on management's cost and delivery requirements. This is not necessarily a bad state of affairs, bombs or medical devices costing billions of dollars each are not likely to ever be manufactured, and our current devices on average save far more lives than they take. If it seems like I am exagerating the cost, consider what it might cost to build a full scale, proven correct, custom 32 bit computer, rad-hard, with full error correction on all circuit pathways (including throughout the processor internals), full five way redundant computer system, write a mathematically provably correct operating system and full tool chain, as well as provably correct application code for the project, billions is probably way cheap, and this only proves the software does what it was specified to do, not that the specification itself didn't actually unintentionally require security holes, or other problems.
As far as the original article's concern about security holes deliberately installed by foreign nationals into Linux, this is almost laughable, a security hole whether deliberately created, or accidentally created by regular developers is still a hole, and accidental ones are created on a regular basis in any environment which is still undergoing development, in some cases, while attempting to fix other security holes. Real security only comes from physically and electronically limiting access, by severing all outside electronic connections and putting the computer in a "secure" physical location (wherever that might be), anything less is a tradeoff.
While we are waiting for these wonderful proven correct tools, the best you can do is choose the OS and tool chain with the best historical track record in the areas that are most critical to the project, and (preferably) least amount of code in them (more code means more bugs). In some cases where a full blown operating system is needed, Linux may be the best choice, in others, it won't be, but there really are no good choices, only better ones and worse ones for a given application.