Re: [SC-L] Re: White paper: "Many Eyes" - No Assurance Against Many Spies
Crispin Cowan wrote: > Ok, someone has mentioned Ken Thompson's Turing Award speech in a "my > security is better than yours" flamewar^W discussion. This almost > warrants a security-geek version of Godwin's law :) That's fine. I didn't bring it up, the original article did. I still do think anybody who touches code should at least read it and think about what it means. If somebody wants to turn this into a flame war, carry on. I'll move along. No need to invoke anything at this point. > For a really interesting long-term extrapolation of this point of > view, I strongly recommend reading "A Deepness in the Sky" by Vernor > Vinge http://www.tor.com/sampleDeepness.html Good book, yes I would recommend it as well. "A Fire Upon the Deep" is also both a good read and further explores the concept of how dangerous it is to play with "hardware" that you don't understand. > It also leads to the classic security analysis technique of amassing > *all* the threats against your system, estimating the probability and > severity of each threat, and putting most of your resources against > the largest threats. IMHO if you do that, then you discover that > "Trojans in the Linux code base" is a relatively minor threat Yes, that's where I would hope most professionals would end up. I've often wondered how many people end up with "Oh, well, I guess it doesn't matter anyway..." > compared to "crappy user passwords", "0-day buffer overflows", and > "lousy Perl/PHP CGIs on the web server". This Ken Thompson gedanken > experiment is fun for security theorists, but is of little practical > consequence to most users. The article wasn't about installing software for "most users," but rather about what sort of software is appropriate for networked devices on a battlefield. Yes, it read like a advertisement. Yes, it specifically singled out "linux" and "open source" where there was no need to. Yes, it used a ton of overblown and bad analogies... I was hoping for a discussion to emerge about building software for similar environments. If network devices deployed in a battle zone isn't the right cup of tea, how about health monitors that will be hooked to a hospital network? Software that will run on devices intended on being imbedded inside the body ala pacemakers or coclear implants. Voting machines. ABS systems, airbag controllers. ATM machines... The risks forum (http://catless.ncl.ac.uk/Risks) does a good job detailing the problems that can arise when developing these systems, but isn't as geared towards detailed discussions of reasonable solutions to those problems... I was hoping this list might be a better place for discussions of that nature. Tad Anhalt
Re: [SC-L] Re: White paper: "Many Eyes" - No Assurance Against Many Spies
Jeremy Epstein wrote: > I agree with much of what he says about the potential for > infiltration of bad stuff into Linux, but he's comparing apples and > oranges. He's comparing a large, complex open source product to a > small, simple closed source product. I claim that if you ignore the > open/closed part, the difference in trustworthiness comes from the > difference between small and large. It's a lot deeper than that. Here's the link to the original Ken Thompson speech for convenience sake: http://www.acm.org/classics/sep95 This should be required reading (with a test following) for everyone who ever touches code IMHO. Simple, elegant, understandable and devastating. It's the difference between proving that there aren't problems and hoping that there aren't problems. Linux is really a peripheral issue. The same arguments could be used against any operating system and/or software system that hasn't been designed and implemented from day 1 with this sort of issue in mind. A more interesting quote is this one: "A few people who understood Ken Thompson’s paper wrote to me saying that every operating system has this problem, so my indictment of Linux security on this point is meaningless. They ask: “couldn’t someone at Green Hills Software install a binary virus in the baseline Green Hills Software compiler distribution and corrupt Green Hills Software’s INTEGRITY operating system?” No, the FAA DO-178B Level A certification process systematically checks every byte of object code of our INTEGRITY-178B operating system to ensure that if malicious code is introduced at any point throughout the tool chain (compiler, assembler, linker, run-time libraries, etc.) it will be detected and removed. Since INTEGRITY has only a few thousand lines of privileged-mode code, not the millions of lines that burden Linux, this means of preventing viruses is feasible for INTEGRITY, but not for Linux." How did they bootstrap their system? In other words, how did they ensure that they could trust their entire tool chain in the first place? They hint that the whole system was written by a few trusted persons. Did they write the whole tool chain as well? The scheme above protects against future attack, but not against something that was there before they started. I'm sure that they have an answer for that question, it's a pretty obvious one to ask... Maybe I missed it on my read-through? That's the whole point of the Thompson lecture. The hole is really deep. How far can you afford to dig? How do you decide what to trust? Green Hills Software obviously has a vested interest in convincing the reader that it's worth paying them whatever it is that they're charging for the extra depth... In some situations, it may be... That's a risk management decision. Tad Anhalt
