Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
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.
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |