Linux Secure Enough For The Army
LordPixie writes " As summarized over at Defense Tech, the U.S. Army is soon to be infected with the infamous OSS virus. They have chosen Linux as the operating system for the abysmally named 'System of Systems Common Operating Environment,' a part of Army's planned Future Combat Systems."
http://www.fcw.com/fcw/articles/2004/0830/web-sipr net-08-31-04.asp tells about two viruses (virii?) discovered on the classified military network SIPRNET, specifically, at the Army Space and Missile Defense Command. Apparently our missile control and space defense operates on Microsoft - but how did a virus enter the network? SIPRNET computers are not connected to any other network, and are generally behind locked, limited-access doors.
Only if they redistribute it. I suppose that means, though, that if they start selling equipment to the Israelis or someone, it'll have to be without an any programming or else with the source.
Actually, this good be a good thing. Think about how aid to Saddam Hussein, the Afghani mujahadeen, and so forth has caused problems down the line. If the army is contractually obligated not to give or sell equipment to outside and foreign groups without also giving out the source code, they may be able to use this as a justification for not doing it. "Look, Ariel, baby, we'd love to sell you our tanks, but with all these terrorists running around it would be a security risk to give you our code. Which we'd have to do. Sorry...."
What was kind of humorous and interesting, if true, is the assertion that Thomson, one of the creators of UNIX, had written a backdoor in the binary distribution of UNIX that would add him as a user to whatever system it was installed on.
I don't think Ken Thompson ever did that, he just demonstrated how it could be done, even with a compiled-from-source operating system.
There is also the claim that Windows was "certified" at a higher level of security by the Army itself than Linux. Does anyone what criteria were used to assess the relative security of these OSs?
Oh, I'm sure it was Common Criteria, or something similar. And, really, it's no surprise that Windows has a higher certification; CC and related standards are built around assumptions of a closed-source development model, and that makes the standards very hard to apply to open source software.
The seven EAL certification levels defined by CC basically define different degrees of rigor in the specification, design and implementation processes. They assume a waterfall model where each step is completed before the next one is begun, and their goal is really to demonstrate that each step implements the previous steps faithfully, that is, that the design precisely meets the requirements, the implementation precisely implements the design, the testing precisely validates the requirements, etc. At the highest levels, semi-formal and even some formal proofs of correctness are required.
At the end of such a rigorous process, you have a high degree of certainty that the resulting product fully meets the stated requirements. Assuming that those requirements were written with security in mind, then there's a high probability that the product is secure. Oh, and there's also some stuff in CC about how access to the documentation and source is controlled and how the product delivery process has to work to ensure that no one can insert security-comprimising changes at any point in the process. And some stuff about how to vet the people involved in doing all of the work to make sure they're trustworthy.
This sort of development process is one good approach to developing a secure product, but it's not the only approach. Many of its requirements are only present because of the underlying assumption that the user of the product -- who relies on its security -- does not have access to the code. Most of the rest of it is an attempt to define a process that can produce secure code with limited human resources.
OSS, with it's "many eyes" philosophy takes a different tack. OSS relies on massive manpower and huge amounts of redundant effort to vet the code as it is, rather than trying to ensure that it is created as it should be. Instead of creating detailed requirements and design documents which can be checked with a low level of effort and then working hard to ensure that the code matches up with those, OSS developers just write the code (with an effort to make it secure) and then rely on "many eyes" to discover and close any weaknesses. The fact that the source is open eliminates the need for access controls used in high-security closed-source software.
It's really not clear that either approach is better, in general, than the other. Both have strengths and weaknesses and both do a good job, assuming the closed approach is executed properly by good people, and assuming the open approach attracts enough competent eyes.
What is clear, though, is that it's fiendishly difficult to apply the CC certification processes to open source code, or any code that is already written, but OSS source is even tougher. You have to essentially reverse engineer the code to produce design documentation, reverse engineer the design to produce requirements, vet the requirements for security, verify (to whatever level necessary, depending on the certification you want to achieve) that the design implements the requirements and the code implements the design. All very, very, difficult things to do. For
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.