Slashdot article on MITRE open source software

John Chambers jc at trillian.mit.edu
Fri Nov 29 10:13:03 EST 2002


Bill Horne writes:
|
| Slashdot (http://slashdot.org/articles/02/11/28/1358233.shtml?tid=99)
|
| has a pointer to a story on news.com
|
| (http://news.com.com/2100-1001-975578.html?tag=fd_top)
|
| about M$ opposition to a MITRE Corp survey report which recommends greater
| use of Free/Open Source Software ("FOSS") in the Department of Defense.
|
| >From the Executive Summary of the MITRE report
| (http://www.egovos.org/pdf/dodfoss.pdf):
|
| "Neither the survey nor the analysis supports the premise that banning or
| seriously restricting FOSS would benefit DoD security or defensive
| capabilities. To the contrary, the combination of an ambiguous status and
| largely ungrounded fears that it cannot be used with other types of software
| are keeping FOSS from reaching optimal levels of use. MITRE therefore
| recommends that the DoD take three policy-level actions to help promote
| optimum DoD use of FOSS: ..."

Funny that they should express it so  carefully.   It's  not  at  all
uncommon for the security folks to use much stronger wording:  If you
want your system secure, you don't run *anything* unless you have the
source  and  you  compiled  it  yourself.   If  you use a binary-only
program, you have no idea what might be hidden inside it.  They often
also  add  that  anyone in a security position who approves of binary
software is either incompetent or (more likely) on the take.

You'd think that OSS would be at the top of  any  security  analyst's
list of recommendations, with the qualification that you *will* study
the code, and you *will* compile it yourself. (And you *will* compile
all the libraries yourself.)

Then, of  course,  there's  Ken  Thompson's  famous  "Reflections  on
Trusting Trust" paper, in which he explains how to install a backdoor
in a program in such a way that it doesn't  appear  anywhere  in  the
source,  but  is  inserted  in the binary by the compiler.  Also, the
insertion code doesn't appear in the compiler source, but is  in  the
binary version of the compiler, even after you recompile it.

Anyone who hasn't read it should.  Try this URL:
  http://www.acm.org/classics/sep95/

I've occasionally wondered whether the  DoD's  security  people  have
studied  this  problem, and if so, how widely the defenses against it
have been put in place.  Given  the  fact  that  they  are  using  MS
systems, I'd guess that the people who understand such issues are not
listened to by the decision makers.




More information about the Discuss mailing list