Slashdot Mirror


Open Source a National Security Threat

n3xup writes "Dan O'Dowd, CEO of Green Hills Software, suggests that open source software has the capability of being sabotaged by foreign developers and should not be used for U.S. military or security purposes. He likened Linux with a Trojan Horse- free, but in the end a lot of trouble. O'Dowd thinks that unfriendly countries will attempt to hide intentional bugs that the Open Source community will have no chance of finding."

37 of 921 comments (clear)

  1. Understand the Source Perspective by stecoop · · Score: 5, Insightful

    Understand the source perspective before you draw opinions. Green Hills is under threat from Linux due to the embedded software being integrated in more Government system. GreenHills is (was?) a large player in government based Embedded Operating Systems. I imagine you will see a similar stance by WindRiver maker of the popular Realtime Embedded OS VXWorks.

    The threat comes from the length of time on some large government projects. Some systems have been around longer than you and me. In the proprietary world, your whole project is dependent on a set of companies staying in business for 30+ years. Now with Linux, you're no longer dependent on that string; you can leverage off the community providing updates or if necessary you as the developer can make the changes. Most people fail to say this with Linux; everyone just says hey it's free and cheap. But if you really want to sell Linux, try saying that your entire project doesn't fall on another proprietary solution, we will have the source code in hand - people will listen.

    It's easy to retort GreenHills FUD by saying all changes will be baselined and a change control board will review any updates (easy enough huh).

    1. Re:Understand the Source Perspective by proj_2501 · · Score: 4, Insightful

      do we even need another comment on this story?

    2. Re:Understand the Source Perspective by danheskett · · Score: 4, Insightful

      It's easy to retort GreenHills FUD by saying all changes will be baselined and a change control board will review any updates (easy enough huh).
      Actually, not easy enough.

      Can you honestly tell me that the government is going to hire a panel of people to check in in-depth source changes on OSS projects? People who are familiar enough that they can catch an exploit that may only take 3-4 lines of code to perform?

      Let's say I knew that DoD used a certain package in gunnery firmware. Let's say a math library that would be used to make calculations to calibrate the weapon. How hard would it be to build in a small tiny bit of error that would only be useful in cases of calibration of high-tech weapons? If 3000 lines of dense mathematically rich C were checked in and a dozen lines acted in concert to create a miscalculation, how much expertise would be needed to catch that?

      I think that having experts able to review each line of code checked in and put into production defeats the whole idea of using Open Source: at that point, you might as well just hire the experts to write the code in the first place and eliminate the vector all together.

    3. Re:Understand the Source Perspective by Coz · · Score: 5, Insightful

      You have one set of experts write the code under an F/OSS license, another set of experts examine the code, test cases, and test results.

      Believe me, if you're talking about something like gunnery firmware, they're going to test it... the deepest fear in DoD these days is friendly fire.

      --
      I love vegetarians - some of my favorite foods are vegetarians.
    4. Re:Understand the Source Perspective by Total_Wimp · · Score: 5, Insightful

      Can you honestly tell me that the government is going to hire a panel of people to check in in-depth source changes on OSS projects?

      More to the point, will they do this with closed source projects? Getting a mole into Green Hills Software, Microsoft, etc is every bit as real of a threat as getting one into any open source project. In many cases it might even be easier because of the lack of good hiring practices and oversite at small defense companies.

      TW

    5. Re:Understand the Source Perspective by tcopeland · · Score: 4, Insightful

      > How hard would it be to build in a small
      > tiny bit of error that would only be
      > useful in cases of calibration of
      > high-tech weapons?

      I think it'd be tricky, because it would break other high-precision things as well. And the other folks using the open source project would say "hey, this fellow Fred just submitted a patch. something looks odd about it. Fred, why does line 314 do a bit shift without checking the foobar?" And then the patch would be rejected.

      > If 3000 lines of dense mathematically
      > rich C were checked in

      I doubt any maintainer would accept such a patch. I don't accept patches for PMD without reading them, and if I got a 3K line patch I'd reject it out of hand.

    6. Re:Understand the Source Perspective by GoofyBoy · · Score: 3, Insightful

      >In many cases it might even be easier because of the lack of good hiring practices and oversite at small defense companies.

      What hiring practices does Linux have?

      Defense companies have to go through a certain amount of security and background checks to win a contract.

      --
      The surprise isn't how often we make bad choices; the surprise is how seldom they defeat us.
    7. Re:Understand the Source Perspective by Anonymous Coward · · Score: 5, Insightful

      What hiring practices does Linux have?

      Doesn't matter one jot. Gee, look, there's the source code. Every bug, hole and trojan horse, just waiting for you to find them. All you have to do is audit the code. You should be auditing the code of any product you're going to use in a sensitive enviroment anyway, wether it's closed or open source. Where's the difference?

    8. Re:Understand the Source Perspective by Zocalo · · Score: 4, Insightful
      Who needs a mole at Green Hills Software or Microsoft? The kind of software we are talking about here is highly proprietary stuff that you are not going to be able to get mail order from your local retailer. A better bet would be to target any third party libraries the vendors are using; almost no one would write their own IP stack when they can by one for a few dollars. Sooner or later you are going to get one that might have been bought from a legitimate company in the US, but was actually coded by easily bribable coders in the third world.

      If anything, I'd say the risk of getting exploits deliberately planted in code without detection are far greater in closed source applications than in OSS projects. Another lame attempt at FUD from the people behind AdTI..

      --
      UNIX? They're not even circumcised! Savages!
    9. Re:Understand the Source Perspective by demachina · · Score: 5, Insightful

      "how much expertise would be needed to catch that?"

      Uh, not much. If the weapons aren't hitting the mark on the firing range they probably wouldn't get deployed until they are fixed.

      This is probably a poor example. The danger isn't in OSS that is designed to fail. If it doesn't work it wouldn't get used. The danger is an obscure security hole that would allow infiltration.

      The key point where this guys whole argument falls apart is that proprietary software isn't any better. I'm confident Microsoft employs a small army of foreigners, and I'm not sure they would be any more reliable than OSS developers and their code gets a lot less scrutiny, and absolutely none if you are a customer getting binaries. Most big companies are putting R&D centers in India and China. How do they assure us the people they are hiring don't have ulterior motives.

      If you want to develop software critical to national security you have to develop it in a classified lab with cleared employees. Oh but wait, in spite of all the scrutiny people with get security clearances get, they also turn out to be foreign agents and do great damage. Los Alamos doesn't exactly have a stellar security record and those people get more scrutiny than anyone. The Navy's comsec and has been massively compromised in the past.

      I'd argue the opposite case from this guy. If you want secure software the best approach is to have as many people possible, both OSS and governemnt, scrutinize the source. If you find a project that is intentionally or negligently checking in compromised code black list them or give them extra scrutiny. The NSA's secure linux effort is an example of the government making sure OSS is secure and its way more likely to be that, than anything Microsoft or Green Hills is going to give them.

      On a tangent here is an interesting article on Homeland Security trying to enforce security through obscurity in the physical world. Someone walked around the DNC and took photos of all the weaknesses in their security in Boston and posted it on a list on Yahoo. Homeland security shut down the list and is collecting the names of everyone on the list and everything said. Should give you pause before joining any list in these interesting times.

      --
      @de_machina
    10. Re:Understand the Source Perspective by danheskett · · Score: 3, Insightful

      The question is though:

      Is it possible that an unknown/untrsuted person could engineer a bit of code that would pass initial scrutiny but still be dangerous?

      The answer to that is an unqualified yes, I believe. The auditors would have to audit every bit of the toolchain, the compiler and linker, and the rest of the system to be able successfully rely on the code audit.

      You should be auditing the code of any product you're going to use in a sensitive enviroment anyway, wether it's closed or open source.
      Absolutely. The point being however that's harder and you have more code to audit in the open source world. In the closed source/defense world, they rarely change things like compilers, build environments, etc. In the open source world it becomes difficult if you want to work with a compiler 6 years old, let alone 2 or 3 or 4 years old. As a test, get the latest glibc and compile it with a 3 year old copy of GCC.

      I am not saying it's a definitive answer one way or another.. just that it's hard.

    11. Re:Understand the Source Perspective by passthecrackpipe · · Score: 3, Insightful

      the deepest fear in DoD these days is friendly fire.

      No it isn't - if it was, they would have burned all the patriot systems already. the biggest fear in DoD is making sure their pet contractors stay on the payroll so that they keep getting their kickbacks.

      --
      People who think they know everything are a great annoyance to those of us who do.
    12. Re:Understand the Source Perspective by danheskett · · Score: 3, Insightful

      I think it'd be tricky It would be possible though to engineer a specific set of cases so that a less-than highly used library would produce certain results for only a single user (or a small handful of users). It could be so crafty as well. I can imagine setting things up so that when a certain "bug" I introduce is fixed the real behaviour I wanted becomes apparent. How could you prove I set out to intentionally make that error?

      Fred, why does line 314 do a bit shift without checking the foobar?" And then the patch would be rejected.
      You and I know however that over time maintainers become more and more trusting of what a submitter gives them. How long would one need to invest to get the trust of a submitter? 3 months? 6 months? What if a person contributed weekly to a project a front-company for six months.. what level of scrutiny would that patch receive?

      doubt any maintainer would accept such a patch. I don't accept patches for PMD without reading them, and if I got a 3K line patch I'd reject it out of hand.
      How long would it take for a badly intentioned person to take over as a maintainer? A year, two years?

    13. Re:Understand the Source Perspective by killmenow · · Score: 4, Insightful
      What hiring practices does Linux have?
      Peer review. I imagine Linus, Alan, Andrew, Ingo, Tigran, et. al., are more capable of: A) reviewing code submitted for inclusion in the Linux kernel; B) understanding its purpose; C) deciding who to trust to write proper code; and, D) actually committing the code into the kernel THAN ANY GOVERNMENT OFFICIAL.

      As evidenced by his desperate attacks to stave off his dwindling market share, they're obviously doing a better job than the Green Hills CEO.
    14. Re:Understand the Source Perspective by danheskett · · Score: 3, Insightful

      Peer review. I imagine Linus, Alan, Andrew, Ingo, Tigran, et. al., are more capable of:
      Except that Linus himself has said that the sheer volume of patches coming into the kernel means he barely scans the patches before accepting them. It's very difficult to tell what minor changes a small fix will have. Just ask people who have to debug problems in the kernel. It's not fun/easy/simple.

      Also, we are not just talking about the "brand name" projects. We are talking about the unsexy, not-front-page projects. The things at risk are the ones without thousands of eyes looking at it. It's the ones with just dozens, or a handful of eyes, looking at it. Projects that make up stuff in the buildchain. Projects like filesystem drivers. Projects like device drivers. Compilers. Linkers. All of them would have to be validated and audited, for each change, for each version, on each platform. A malicious patch anywhere along the way can lead to a trojan. Even code that otherwise looks good could be poisoned. A single unchecked buffer. A single small simple looking error - big consequences.

    15. Re:Understand the Source Perspective by j1m+5n0w · · Score: 4, Insightful
      The auditors would have to audit every bit of the toolchain, the compiler and linker, and the rest of the system to be able successfully rely on the code audit.

      Even that might be insufficient. Ken Thompson showed in his '95 Turing award speech how a compiler trojan can exist even if the backdoor is not present in the compiler's source code.

      Here's the link.

    16. Re:Understand the Source Perspective by GCP · · Score: 5, Insightful

      do we even need another comment on this story?

      Yes, of course, because the fact that open source has some advantages doesn't negate the risk pointed out in the article. It just means that their are risks both ways.

      ANY piece of software that you run on a secure system has the potential of subverting the system. I think open source does create the illusion that it couldn't contain hidden malware because where could it hide in open source, right? Well, anyone who has ever seen the entries in an obfuscated C contest and wondered what that code could possibly do ought to be able to see the flaw in that argument. For that matter, anyone who has ever gone over and over HIS OWN CODE looking for a bug and not finding it ought to ask himself, what if it weren't even my own code and I didn't even know that a bug existed?

      Closed source is even worse in this respect, though, but at least we know who wrote it, right?

      Well, I think that's yet another illusion. Think disgruntled employees being paid by Bad Guys to insert a bit of code.... You may trust the company that made your software, but how can you possibly trust every one of their employees? And once it's in, since it's trusted it could be there for years.

      --
      "Those who have never entered upon scientific pursuits know not a tithe of the poetry by which they are surrounded."
    17. Re:Understand the Source Perspective by at_kernel_99 · · Score: 5, Insightful

      Closed source is even worse in this respect, though, but at least we know who wrote it, right?

      Well, I think that's yet another illusion. Think disgruntled employees being paid by Bad Guys to insert a bit of code.... You may trust the company that made your software, but how can you possibly trust every one of their employees? And once it's in, since it's trusted it could be there for years.

      Exactly. The author also helpfully ignores the backgrounds - often unknown by the enduser - of the developers of closed source software. I've been in this industry for 12 years and have worked in one place (out of 7) that did not have a foreign national on the team. Ethnicities have included China, Vietnam, Russia, India, Pakistan and Syria.

      The only point the author made that I could agree with would be that all software used for the military/intelligence communities should be thoroughly tested & certified to a high standard of security. I doubt there are many that would disagree with this statement. The problem is the author is hiding this valid argument beneath a layer of FUD intended solely to harm Linux & support the proprietary development model his company has chosen. He uses fear & stereotypes to paint the opposition without explaining what his company is doing that will solve the problem in a way that open source cannot.

    18. Re:Understand the Source Perspective by RoLi · · Score: 4, Insightful
      I think open source does create the illusion that it couldn't contain hidden malware because where could it hide in open source, right?

      There are numerous examples of malware (like those in Kazaa), easter-eggs (like the flight simulator in Excel and the pinball game in MS Word) and unrequested features (like Windows Product Activation) in proprietary software.

      While I agree that something similar could in theory also happen to some one-man or very small open source projects (in theory because I have never heard of any such occurence) there is absolutely no way such code could be smuggled into bigger projects like Linux, Apache, KDE or the like, there are just too many people watching.

      So if you compare exactly what the article is talking about, proprietary software has a much worse track record.

  2. the rest world chooses linux for the same reasons. by beh · · Score: 4, Insightful

    Shouldn't this article immediately point back to other articles on
    how governments OUTSIDE the US are choosing open source for exactly
    the same reason (who knows what M$ + NSA put in the closed windows
    source that might hurt other nations)?

    [World Govs Choose Linux For Security & More]
    http://slashdot.org/articles/01/12/11/0132213.shtm l

  3. FUD. by garcia · · Score: 4, Insightful

    Some embedded Linux providers even outsource their development to China and Russia.

    GASP! Some XYZ providers even outsource their development to ABC and DEF (insert your favorite company and terrorist sponsoring country where necessary).

    It would be incredibly naive to believe that other countries and terrorist organizations would not exploit an easy opportunity to sabotage our military or critical infrastructure systems when we have been doing the same to them for more than 20 years!

    I think it has been proven that closed-source development doesn't help to change the possibilities that a "mole" has been planted or that a "hole" will be discovered.

    One of the greatest misconceptions about Linux is that the free availability of its source code ensures that the "many eyes" with access to it will surely find any attempt at sabotage. Yet, despite the "many eyes," new security vulnerabilities are found in Linux every week in addition to dozens of other bugs. Many of these flaws have eluded detection for years. It is ridiculous to claim that the open source process can eradicate all of the cleverly hidden intentional bugs when it can't find thousands of unintentional bugs left lying around in the source code.

    And it is ridiculous to claim that a closed development enviornment will make it any different.

    In addition, under the internationally recognized Common Criteria for IT Security Evaluation (ISO 15408), Windows has been certified to Evaluation Assurance Level 4 (EAL 4), a higher level of security than the EAL 2 that Linux has achieved.

    According to this article, obtaining EAL2 certification typically costs between $400,000 and $500,000. Looks like it is more money than security. In their infancy, why would Linux vendors decide to shell out large sums of money when the government wasn't interested in using Linux anyway?

    This whole article is FUD. He's annoyed because Linux is making leaps and bounds and will possibly affect his market-share in the lucrative Defense and Aerospace industries. At least he came out and said it on his own legs and not by paying off a third party to "investigate" the "problems" with Linux and post their results to the world.

  4. Governments should not use OS without a proper... by WiKKeSH · · Score: 3, Insightful

    Governments should not use OS without a proper security audit. Once you can verify the nature of the code, there should be no obstruction to using it.

  5. Um, and what about the source China has seen? by InThane · · Score: 5, Insightful

    IIRC, China has seen the source code to Microsoft Windows, whereas the U.S. government hasn't.

    I think that's a pretty large security threat right there...

    --
    InThane
  6. Terrorists in Microsoft by shobadobs · · Score: 3, Insightful

    What if a terrorist gets a job at a software company? Where's the hope of catching the bugs then? It seems to me that closed-source software is more susceptible than open-source.

  7. Come out of the cave! by polyp2000 · · Score: 4, Insightful

    Dan O'Dowd, CEO of Green Hills Software, suggests that open source software has the capability of being sabotaged by foreign developers and should not be used for U.S. military or security purposes.

    Urmm , so what operating system do you use then Dan O'Dowd? and which newspapers and websites do you read?

    You're obviously using a closed source operating system that is free of viruses, worms, holes and other security problems. What might this mystery closed source operating system that you are using that doesnt pose a threat to the nations security?

    --
    Electronic Music Made Using Linux http://soundcloud.com/polyp
  8. Well, he does have a point ... by dougmc · · Score: 5, Insightful
    What he suggests is possible. And a well hidden bug could easily escape detection by Linus and anybody else who goes over each new patch looking for stuff like this.

    And it doesn't have to be in the Linux kernel. The classic example (at least 10 years old) is to hack up gcc so that it examines the code it's compiling, and if it decides that it's compiling /bin/login to do things a little differently, inserting a back door where there was none before.

    However, while he does have a point, it's a very myopic point. Closed source software has exactly the same vulnerabilities, except for one critical difference -- only people within the company in question have a chance of detecting the problem -- the end user will never get to see the source and see if it's compromised. Granted, most open source users do not review all the source code that they use, but at least the option is there, and for the people where security is absolutely essential (like the NSA) they almost certainly use it.

    Also, for a closed source company, the problem is even worse. The backdoor (or whatever) could be introduced when the code is finally compiled for distribution, and never get checked into whatever source control system they use. So the binaries get shipped out, but NOBODY has reviewed the source code in question (except our cracker friend) and once the bug does come to light (if it ever does) the company will look at the source code and scratch it's head -- it won't even have the source code in question to look at.

  9. I am continually amazed... by SuperChuck69 · · Score: 4, Insightful
    I am continually amazed that people believe open source is a good place for terrorists to hide evil, anti-government bugs...

    The cornerstone of open source is that it is OPEN SOURCE. The government is free to view and evaluate all the packages to their little, demonic hearts' content.

    If I were a terrorist, I'd think I would penetrate a closed-source house (say, Microsoft or Green Hills) and hack some little nasties into their source.

    But,, maybe that's why Dan O'Dowd isn't a very good terrorist.

    --
    :wq
  10. Exactly the point by hol · · Score: 5, Insightful

    This is precisely why Brazil, China, and even Germany are moving towards open-source. The US Government cannot insert backdoors into this stuff that would affect anyone not wanting to be affected, unlike Microsoft stuff. Remember the NSA keys in the Windows NT crypto libraries?

    The US can continue to run Windows, be our guest, but the point is moot since much of US Government software is developed in India anyways. No back doors there, for sure.

    --
    - - - Non Caffeine Drink or Drink Error
  11. Oh really by TheConfusedOne · · Score: 4, Insightful

    It's possible, and HAS happened that KNOWN, and TRUSTED engineers have put bits of code that would pass initial scrutiny and still be dangerous.

    Wasn't there recently an article about a router with a backdoor shipped out in its code? How about all those darn "easter eggs" floating around in Windows and Office and other programs?

    I would challenge you to compile a new Intel C library using a Microsoft C compiler from 6 years ago too. Heck, compile glibc using an IRIX compiler from six years ago.

    You can drag out all the scenarios you want and whether it's Linux or it's *nix or BSD or Windows you're going to have the same audit challenges and not even have access to the source code without negotiating with all your suppliers.

    --
    --- I wish I could hear the soundtrack to my life. That way I'd know when to duck.
  12. Green Hills is the national security threat by It+doesn't+come+easy · · Score: 4, Insightful

    What a bizarre article.

    The statement "Yet, despite the "many eyes," new security vulnerabilities are found in Linux every week in addition to dozens of other bugs." Shouldn't one consider that the "many eyes" are the developers finding those weekly bugs? Wonder how many eyes are looking for Green Hills software bugs?

    As long as people are involved, mistakes (bugs) will be made. But saying that malicious code is more likely in a product where someone CAN examine the code verses a product where no one can is just plain stupid. There is obviously an undisclosed agenda here (might that be selling a DO-178B Level A rated real time OS, aka Integrity? Getting a lot of Linux competition, eh?).

    As to the standard DO-178B...the first 90% of the article is about security, then you mention DO-178B. DO-178B is not a security standard. DO-178B is a FAA safety related standard for software. Any software certified under DO-178B can still be full of unknown security holes. The standard may be required for software used in flight related applications but it does not mean the software is also secure.

    The level A rating doesn't even mean "most secure" as the article seems to imply. It means that if the software crashes, it will not affect other software that is running. In other words, the software is ISOLATED, not secure.

    It is amazing the things companies will say when they are losing ground to a competitor.

    --
    The NSA: The only part of the US government that actually listens.
  13. and closed source propietary firms.... by zogger · · Score: 5, Insightful
    ...and defense related places DON'T hire foreign nationals or domestic nationals with perhaps a bent for the blackhat side? This never happens? And everyone in government itself is sweet and pure as the mountain streams, and would never think of doing anything...strange... for some financial remuneration off the books? This never happens either? And so called "allied and friendly" governments don't run spooks inside our establishment and sleepers inside our citizenry? And they *always* have our best interests at heart?



    Nope. Open source is still the best way to go, along with open government. When you let people hide "stuff", and when it's connected to massive political power and heaps 0 money, that's when crimes occur. The best bet is openness, bar none. It is not perfect, but it's the best design yet.

  14. Offshoring just as much of a threat by Kagato · · Score: 4, Insightful

    Sure, there is a threat in the Open Source movement. But, how is that threat compared to offshoring? I don't think they are any different. Yet, when a threat is something that enhances the bottom line, security concerns are not raised.

  15. Re:Supporting comment by at_kernel_99 · · Score: 4, Insightful
    Does nobody remember NSA Secure Linux?

    When one is ranting in a desperate plea to defend one's own methodology & existence, it is often helpful to ignore facts that do not support one's case.

  16. How is this riskier than companies that outsource? by digital+photo · · Score: 3, Insightful

    I find it interesting that open source software is considered a risk because individuals from other nations are allowed to participate in the development of the code...

    How does this differ from corporations which provide software to the military who outsource their development to individuals from other nations?

    The only difference is that the OSS model involves corporations giving up some of their control over the rights of the product and corporations don't like that.

    Otherwise, the article makes assumptions of differences between OSS remote participation and outsourcing which has no material relevance.

    The idea of outsourcing being more secure because security checks are done can be argued, but even security checks fail and someone who is cleared can decide to sabotage. The problem is that once someone is vetted, they are trusted. This is actually worse than the OSS model where no matter who you are, the code is reviewed with the same level of scrutiny as anyone else's code.

    I can think of so many instances of calling support, having to provide my personal identifying information to an individual who was either not in my state or not even in the US.

    Sounds more like a double standard of judgement from the corporate viewpoint that is prejudiced against OSS projects.

  17. If this guy actually believes this, by stealth.c · · Score: 4, Insightful

    he is terminally paranoid. I understand that he has a vested interest in FUDing FOSS, but let's attack his argument for a second:

    First of all, what truly important piece of software would possibly be part of open public development? I thought this was specialized enough of a field that the only people who had any competence with what you were making were already trusted anyway. Wasn't SELinux developed *inside the NSA* before it was released?

    Secondly, assuming a vital piece of software WERE being developed publicly, someone trying to insert malicious code would have to make it past a few barriers, the first being the most complicated. He would have to: 1) Know what his deliberately inferior code would probably do in the finished product versus what a non-ciminal would want it to do. 2) Get it past the critical eye of a few other developers, 3) Slip through some kind of government screening. And all the while NOT make anyone suspicious.

    And even then the results are not guaranteed. What is your cyberterrorist counting on? I sincerely doubt that he could have snuck a back door into the code given all those hoops. I don't think the deliberate bug can be both significant and unknown at the same time. Is he hoping that his bug will cause the software to make a slight miscalculation? Whoopty shit. Whatever agency he or she is working against will be annoyed for a little while and then fix the problem.

    Even if his deliberate bug caused a catastrophic failure, it can and will be traced back to HIS contribution, and if some terrorist group stands up and says "Ha ha! Look what we did! And here's why!" (and if it's Al-Qaeda we can be almost certain of this) That man is immediately under FBI surveillance and probably arrest.

    In any case, inserting a bug would be a lot of work. A lot of work for an uncertain return, and success will mean almost inevitable detection.

    Why some terrorist would bother with this approach is beyond me. It's so much easier just to fill a truck with dynamite.

  18. The odds of this happening... by Godai · · Score: 3, Insightful

    ...have to be low. I mean, let's go over the steps that such an alleged terrorist would have to go thorugh to get this crucial system bug into the kernel:

    1. craft a bug that would be capable of rending someone-in-the-know root access
    2. craft the code that creates the bug in such a way that it would be accepted by Linus. This would require:
      • a plausible reason for the patch; ie. a feature addition or bug
      • the crafted 'secret bug' would have to be imbeded in such code that purports to add the alleged feature or fix the supposed bug
      • Linus (or whoever) would have to miss the bug; so it would have to be fairly subtle
    3. hope that no one detects the bug, be it by the hardware manufacturer, or anyone using the OS before the military hardware goes live in the field (or wherever)
    4. ???
    5. Profit! (Terrorize?)

    That's a pretty good obscure set of circumstances. Does it mean it can't happen? No. But contrast this with proprietary methodology wherein a coder has (usually) unrestricted access to the code base. Hmmm. Sounds more plausible there!

    Of course, the key thing to note here is that anyone who has to dredge the dread forumla that terrorism + open source == Disaster!!! is probably desperate to save his flagging business.

    --
    Wood Shavings!
    - Godai
  19. Re:The strengths of Linux count against its securi by stwrtpj · · Score: 3, Insightful
    So that means that we can document that 7 security trained people or outside organizations have looked at any code that is declared "Evaluated"...
    To say that the code is Linux code is locked down and tested is to say that the barn door is locked too late in the process for the kinds of things the author of this posting is citing as potentials for happening.

    So what's stopping the DoD from taking the source code base and doing their own testing and certification on it? Considering you claim to have had a background in this, I'm surprised you didn't think of this. This may save them some time in the long run, since they don't have to go through the effort of developing the software itself.

    If I decide to use a library or module from another developer (OSS or otherwise) in something that I am doing, I always take the time to test it to make sure it at least does what I want and is adequate for the task at hand. Now, my own projects don't require a terrible amount of security, but if they did, I would be certain to do some testing in that area as well.

    So I just don't get your point. You don't have to develop the code yourself in order to certify it if you have the full source available to you. And then once you have certified it, after making any corrections that you need on your copy of the source, then you lock THAT down. What came out of the original source base is irrelevant at this point. It only matters what you improved upon and certified.

    --
    Karma: Frotzed (mostly due to the Frobozz Magic Karma Company)