Security and the Linux process

Security and the Linux process

Summary: In his latest entry, Dana asks whether the Linux process is insecure, because it's not possible to warn the "vendor" before warning the general public about security flaws in Linux. He also notes that "Microsoft has theoretical control of this situation.

TOPICS: Security

In his latest entry, Dana asks whether the Linux process is insecure, because it's not possible to warn the "vendor" before warning the general public about security flaws in Linux. He also notes that "Microsoft has theoretical control of this situation."

There are several problems with this line of reasoning. I'm not going to argue that the open source model of development is perfect, but it offers several advantages over the proprietary model. Let's start with the most obvious.

Yes, if I discover a vulnerability in the Linux kernel -- or any other open source project that does development on public lists and completely out in the open -- when I reveal the problem on the development mailing list, I reveal it to the public. It's worth noting that some open source projects, like Mozilla Foundation, have systems that allow developers to file bugs and security issues without disclosing details to the public at large.

But, for projects like the Linux kernel, most of the development is done in the open. However, Dana's scenario assumes that the person discovering the exploit decides to broadcast their finding on the mailing list to all of the developers simultaneously, which isn't necessarily the case. It's also possible for developers to communicate privately without discussing a security flaw on a mailing list. In fact, this happens quite a bit. But, assuming someone decides to do so, the other kernel developers can start work on the exploit immediately when something is disclosed publicly.

With Linux, it's not only possible for developers and researchers to comb through the Linux source code to look for vulnerabililties, it's also possible for those folks to submit patches that fix the vulnerabilities in question. It's not uncommon for someone to uncover a vulnerability, report it and submit a patch for the vulnerability. Unless you happen to work for Microsoft, this isn't possible with Windows and other Microsoft products. With proprietary software vulnerabilities, users are usually dependent on a single vendor to react to the flaw and issue a patch. Given Microsoft's track record for responding to vulnerabilities and issuing patches, that's not a comforting thought. Case in point, a highly critical flaw in the Microsoft Jet Database Engine that was announced in April, that remains unpatched. According to Secunia, exploit code has been posted to a public mailing list, and Microsoft has yet to issue a patch.

Assuming a researcher submits a report about a security vulnerability to Microsoft before making it public, they are then dependent on Microsoft to fix the vulnerability. The researcher typically will not have access to Microsoft's code, so they are essentially doing "black box" testing -- whereas anyone can assist with finding security flaws in open source code just by reading through the code itself. This concept scares people who still believe that "security through obscurity" is a good way to try to make software more secure. However, given the number of spectacular security flaws that Microsoft has seen over the years -- along with some very effective exploits -- I think we can see that this doesn't truly afford proprietary software vendors any real advantage.

And, as I said, that's assuming that a researcher decides to play nice and inform Microsoft of a vulnerability before they disclose it to the rest of the world. That's not a safe assumption, by any means. Microsoft may have "theoretical" control of the situation, but in reality, they have no more control over vulnerability discoveries than the Linux kernel team. A look at the Bugtraq list will show that many disclosures seem to be made without first being run past the software vendor -- as well as several frustrated individuals disclosing flaws that have been reported to the vendor with no response. There's another advantage to initial public disclosure: Once everyone knows about a security flaw, the urgency to fix it is greatly increased. 

The point that systems are most vulnerable between the time an exploit is made public, and the time that a patch is issued, is well taken. It's up to open source projects and vendors to try to close that gap as much as humanly possible. However, the fact that Linux development is done publicly is not a cause for alarm.

Topic: Security

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Applying patches in Linux is nightmare

    Anyone who worked with Linux will know installing and patching Linux software is nightmare. In this department, Windows looks far better designed.

    I stopped patching and upgrading my Linux. There are far too many dependencies and you have compile so many things you have to spend time. For businesses, this will cost fortune for payroll cost. Compared to this, Windows is a piece of cake! I have to say Linux community does not understand what the real problem is!
    • Oh those sweet service packs!

      I am very aware of the huge benefits of MS service packs especially when the go hay wire! I know of 3 instances of Service pack 2 completely killing the computer that it was being applied to. These upgrades were being applied by normal computer users who had innocently done as they were instructed and bam! That sure was easy! Thanks Jookie!

      One of the instances was at work by a fairly competant user, and another was by a nurse friend who attempted to patch her system and another was performed by a system admin.

      Not to mention all the software rendered useless by some of the patches, or the software that needed to be upgraded to work with the service packs like IBM client Access for AS400 access.

      Claiming that the Linux community is out of touch is silly. The entire community is also populated by members of IBM, Novell, Redhat, Oracle, SAP, etc.

      Oh by the way patching Linux is not hard for those of you who read this post and have never tried it. in many cases its simply involves typeing rpm -Uvh <package name> and bingo your done. Now that wasn't hard, was it?

      Please people don't believe the FUD. Change is good when its done for a reason.

      Good Day!
    • What distro were you using?

      Most linux distros today do a very good job of patch management. SuSE upgrades my linux kernel frequently, never had a problem doing it.
    • Really?

      I'd be curious to know what distribution you're using, or what software is causing the hitch. For me "apt-get update; apt-get upgrade" on Debian or Ubuntu always does the trick with minimal fuss. Never ran into any major problems updating SUSE systems, either.

      Unless you're using packages that aren't supported by your distro, or a really old version of Red Hat, this shouldn't be a problem.
    • I will ASSUME

      that you are referring to the "patch" command under Linux. This is for source-code patching and has nothing to do with "patches" that you download from your Linux vendor.

      BTW, My Madriva install process ALWAYS goes to an update site to bring you up to date BEFORE you even run your Linux for the first time! You could have an "old" install CD, and you will be updated to the latest and greatest automagically. This is NOT like Windoze, where you must start the patch process AFTER you boot up on a virgin load - all the while being vulnerable to viruses.

      Mandriva makes collecting and installing updates a snap - using the Drake software. Its the first admin GUI that I actually USE and like!
      Roger Ramjet
    • RE: Applying patches in Linux is nightmare?

      <sarcasm>I agree...I mean...on MY Linux servers, I had to install/configure yum and type "chkconfig yum on." WHAT A NIGHTMARE! After all that, the only thing that I got were a bunch of servers that apply all available patches to themselves every night and email the list of updates. That's SO much more difficult and time consuming than applying Windows service packs.</sarcasm>
    • Not true..

      I am an anyone too who works on Linux and am sorry you had so much trouble. But this is case in point. Although your claim is true in past, not so today. In fact in the past, recompiling a kernel was not an easy task. Nor was finding dependencies! Today we have update Agents, Yum, and APT. I use Yum for the most part and I have to tell you it works wonders! Yum finds all the dependencies and installs them. All I have to do is type >yum update. Or install "filename", kick back and let her fly! :) Lets not forget Redhat Enterprise, and the Redhat network update agent. I can't believe how easy it is to update a Linux operating system and FAST too! Theres more...did I say type?... Yum and APT have GUI's too! The Linux desktop has come a long long way. There are still small back woods distro's that still have hard pressed issues. But to update ALL that free software and the kernel in one place all at the same time is as good as it gets using a well established Disrebution. We can also pay for support packages too.. updates are free of course. Not perfect yet... still a few hitches... but for the most part, quick and easy.
  • Anyone

    that prefers closed-source to open-source in terms of security - has a vested interest in closed source.
    Roger Ramjet