Linux Threatens United States National Security

From a new white paper by Dan O'Dowd, Green Hills Software founder and CEO, which you can download here.

Someone commented privately on my last article, saying that I made specious technical arguments. I'd like to say that I'm not making any technical arguments about this stuff; there are plenty of others doing that who are much more technically competent than I am. The only comments I am trying to make relate to the use of language, and particular vantage points depending on which country one lives in.

So for example, from the above paper:


"When war breaks out, all of the vulnerable [Linux] systems and all of the [Linux] systems that were compromised while they were temporarily vulnerable will go out of service or be commandeered by the enemy. We will be defenseless."



Note the above quote: "When war break out...", not "if war breaks out...". Scary stuff, if you live in the US. Then:

"What we need for critical defense systems is software that is secure all of the time: systems that never need to be patched. We need operating systems that are proven secure by mathematically sound methods such as the Common Criteria Evaluation Assurance Level 7 (See Part I of this series of white papers). Our systems must never be vulnerable. Just one moment of vulnerability, before a patch can be applied, is enough time for a patient attacker, waiting for the moment to strike, to get inside a system and install a permanent back door that will survive the patch that removes the vulnerability. Our defense systems need an operating system like Green Hills Software's INTEGRITY real-time operating system whose security can be mathematically ensured at all times without any need for patches."

Today is the first time in my life I have know about this idea, that there exists software which never needs to be patched. It's very impressive to say the least.

Let's take a look this from another point of view, outside the US. This is from my blog a couple of days ago, in case you missed it:

...from an interview of Jon "maddog" Hall in Spain:

Hay algo importante: Mientras un país dependa de otro en algo tan crítico como los sistemas operativos, ese país no tendrá una seguridad completa y total, porque (Dios no lo quiera) si EEUU entrase en guerra con España, no sé si los generales se pondrían contentos al tener que usar un software diseñado y producido por el enemigo, el cual puede incluso tener acceso a importante información gracias a ello. Se trata de una situación extremadamente comprometida.


This is something important: While a country is dependant on another one in something as critical as operating systems, that country will not have a complete and total security, because (God forbid!) if the U.S.A. had a war with Spain, I do not know if the generals would be happy if they had to use software designed and produced by the enemy, and which thanks to that might even give them access to important information. That would be a dangerous situation.



Since I first started noticing about this last year, I am seeing more discussion about it. If you're interested in this subject, please also read Unrestricted Warfare, which shows yet another point of view.

I see an interesting polarization taking place. In fact, all of these observations made by totally different people and expressing totally different points of view could be correct...within the context of their countries' situation. Any movement towards or away from Linux will hardly be monolithic even within a given country; but keep watching to see if officially the US moves away from Linux while other countries continue to embrace it, and how the words portray the logic of the decisions.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Don't step in the FUD

According to Green Hills Software, the INTEGRITY RTOS is EAL 7 compliant.
EAL 7 is the highest level currently defined.

This from

the Common Criteria standard v2.2, Part 3: Security assurance requirements

Page 62:

Evaluation assurance level 7 (EAL7) - formally verified design and tested


Objectives

212 - EAL7 is applicable to the development of security TOEs for application in extremely high risk situations and/or where the high value of the assets justifies the higher costs. Practical application of EAL7 is currently limited to TOEs with tightly focused security functionality that is amenable to extensive formal analysis.

Assurance components

213 - EAL7 provides assurance by an analysis of the security functions, using a functional and complete interface specification, guidance documentation, the high-level and low-level design of the TOE, and a structured presentation of the implementation, to understand the security behaviour. Assurance is additionally gained through a formal model of the TOE security policy, a formal presentation of the functional specification and high-level design, a Evaluation assurance levels semiformal presentation of the low-level design, and formal and semiformal demonstration of correspondence between them, as appropriate. A modular, layered and simple TOE design is also required.

214 - The analysis is supported by independent testing of the TOE security functions, evidence of developer testing based on the functional specification high-level design, low-level design and implementation representation, complete independent confirmation of the developer test results, strength of function analysis, evidence of a developer search for vulnerabilities, and an independent vulnerability analysis demonstrating resistance to penetration attackers with a high attack potential. The analysis also includes validation of the developer's systematic covert channel analysis.

215 - EAL7 also provides assurance through the use of a structured development process, development environment controls, and comprehensive TOE configuration management including complete automation, and evidence of secure delivery procedures.

216 - This EAL represents a meaningful increase in assurance from EAL6 by requiring more comprehensive analysis using formal representations and formal correspondence, and comprehensive testing.

I'm no expert here, but I'll stick my appendage out and say that the use of the phrase proven secure by mathematically sound methods is a bit of a stretch. The implication being that their software is mathematically proven to be secure/correct. Mathematical proofs of software correctness are possible but unrealistically complex for anything but the simplest programs. You'll notice in paragraph 216 above, the last paragraph, the last phrase is comprehensive testing, if something can be proven correct mathematically there would be no reason to test it.