Commentary

Serdar Yegulalp
 

Linux Wins The Security Showdown! Now What?

So now that Ubuntu Linux was "last man standing" in the PWN to OWN contest at CanSecWest, does this mean open source has it all over the competition when it comes to security?  It can, and it ought to -- but it's not a guarantee.  And we need to not think it is.

So now that Ubuntu Linux was "last man standing" in the PWN to OWN contest at CanSecWest, does this mean open source has it all over the competition when it comes to security?  It can, and it ought to -- but it's not a guarantee.  And we need to not think it is.


More Software Insights

White Papers

More >>

Reports

More >>

Webcasts

More >>

A while back I wrote about a vaguely parallel issue -- how open source won't guarantee the survival of a given piece of software if the original developers drop off the face of the earth, but it makes survival that much easier a proposition.  The same goes for the security of open source products: the fact that it's open source is only one part of a whole approach.  Just putting the code out there to be freely eyeballed by all and sundry won't automatically make it secure.  It has to be looked at by people who know what to look for, know how to fix it, and are willing to do a proper job.

When talking to programmers about security, I've come away with a few impressions: 1) that security is something you have to be made conscious of in the first place; 2) that you have to understand the context of what you're inspecting; and 3) almost no amount of foresighted programming will keep an inept user from doing something stupid.  It's the last part that has programmers often bashing their faces into their keyboards in frustration, because in the end most of them are not writing software for other programmers or other security people.  Most people are neither security experts nor are they computer experts -- and frankly, most of them don't want to become either of those things.

As Linux and open source in general become incrementally more popular with the broad mass of users weaned on closed source applications (whether they were designed with security-through-obscurity or actual code review or what have you), this is going to become critically important.  If you have a package that was used by ten thousand people which suddenly gets used by seven hundred thousand, it becomes that much more of a target -- both for malice and incompetence.

The problems with the phpBB bulletin board application come to mind -- it's had a slew of security issues that led at one point to some ISPs banning it outright.  One site I was co-managing used it, and got eaten alive not once but twice -- and this was despite habitually upgrading to the most recent versions!  (They've since taken the forums completely offline.)  Now imagine a similarly-weak application being run on people's Linux desktops.  Granted, phpBB has gotten better since, but I think the parallel still stands.  That and it's also hard to win back people's trust after you've already inadvertently burned them.

If this sounds like the old saw about "the only reason Linux doesn't have as many security holes is because it isn't as big a target," well, there's a kernel of truth to that, pun unintended.  As Linux ramps up with the masses and more people openly trust sensitive things to it, it will become that much more of a target -- and the people who contribute code to it need to be that much more proactive about the quality of what they're putting out there.  It won't happen magically.


Related Reading




Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

InformationWeek encourages readers to engage in spirited, healthy debate, including taking us to task. However, InformationWeek moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing/SPAM. InformationWeek further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
T-Shirt Giveaway T-Shirt Giveaway: Each week we're selecting one great comment from our readers. The author of the comment will receive an InformaitonWeek Community t-shirt. So get posting!
Subscribe to RSS

Resource Links