Slashdot Mirror

← Back to Stories (view on slashdot.org)

Are the BSDs Dying? Some Security Researchers Think So (csoonline.com)

Posted by msmash on from the closer-look dept.

itwbennett writes: The BSDs have lost the battle for mindshare to Linux, and that may well bode ill for the future sustainability of the BSDs as viable, secure operating systems, writes CSO's JM Porup. The reason why is a familiar refrain: more eyeballs mean more secure code. Porup cites the work of Ilja von Sprundel, director of penetration testing at IOActive, who, noting the "small number of reported BSD kernel vulnerabilities compared to Linux," dug into BSD source code. His search 'easily' turned up about 115 kernel bugs. Porup looks at the relative security of OpenBSD, FreeBSD and NetBSD, the effect on Mac OS, and why, despite FreeBSD's relative popularity, OpenBSD may be the most likely to survive.

4 of 196 comments (clear)

  1. BSDs dying? by QuietLagoon · · Score: 2, Insightful

    I'd be more concerned about the effects of systemd on the Linux distributions. :)

  2. "more eyeballs mean more secure code"?! by Anonymous Coward · · Score: 5, Insightful

    The reason why is a familiar refrain: more eyeballs mean more secure code.

    After Heartbleed and the other issues affecting OpenSSL, and Shellsheck affecting bash, why the hell would anyone still be pushing this disproven "more eyeballs" narrative?!

    The OpenBSD project proves that security doesn't come from "more eyeballs". It comes from having software developers who know what they're doing, and who take their work very seriously, and who show immense discipline, and who don't put up with bullshit, and who put security first and foremost.

    You could have two million "eyeballs" of offshore "programmers" in India looking at some code, and it will likely still end up being much less secure than code doing the same work but written by a couple of OpenBSD's developers.

    Code quality doesn't come from the quantity of people looking at it. Code quality comes from the quality of the people working on it.

    1. Re:"more eyeballs mean more secure code"?! by Hylandr · · Score: 5, Insightful

      Why the hell would anyone still be pushing this disproven "more eyeballs" narrative?!

      It's important to not that if there weren't eyeballs on the code we would never have known about the vulnerabilities to fix to begin with.

      They would have only been discovered and exploited by the malicious and never disclosed unless the attack was discovered while the company responsible would spin the issue and would ( in most cases ) not spend the money to secure other installations.

      Because flaws cannot be hidden, overlooked or covered up, researchers and other interested parties can perform their own independent audit of the software powering their systems.

      -- More eyeballs does in fact mean more secure code. -- Think of it as a global oversight committee.

      --
      ~ People that think they are better than anyone else for any reason are the cause of all the strife in the world.
    2. Re:"more eyeballs mean more secure code"?! by Anonymous Coward · · Score: 5, Insightful

      That comment is neither interesting nor insightful. It's just pushing the age old misrepresentation of the quote.

      Many eyeballs makes all bugs shallow does not - and have never - meant that there will be no bugs, or that they will not lie dormant for a potentially long time. It simply refers to the fact the the more eyes that see a bug, the quicker someone will come up with a fix. Exactly what these researchers are claiming.

      The OpenBSD project proves that security doesn't come from "more eyeballs".

      I'm sorry, that you didn't RTFA is pretty damned obvious, but did you even read the blurb? There is no such "proof". Rather, they proved the opposite.

      Code quality doesn't come from the quantity of people looking at it. Code quality comes from the quality of the people working on it.

      Again, a half-truth. Yes, it's true, but the more people who are involved in a project, the greater the probability that your "good people" turn out to be really good. And the more people you have, the more people you have to fix mundane stuff which doesn't require "really good people" to fix - which frees up your "really good people" to deal with the hairy stuff, and the more eyeballs you have who might for some reason find bugs which needs the attention of the "really good people".

      Quantity is a quality of it's own.