When you say "the numbers", it's funny that you don't say which numbers. Is that perhaps because if we knew which numbers, it would turn out that you were counting the same Linux bugs once for each distribution? Would it turn out that these were the discredited ones released under Microsoft contract for their "Get the facts" (or should that be FUD) campaign.

Now we come to the rub, what makes the main article also FUD? Nobody uses "linux" except for developers. I use "RedHat" you use "Debian" he uses "Mandrake" she/it uses "Gentoo". Just as, when you have a problem with BIND on HP, you should contact HP, when you have a security problem with the "linux" in RedHat, then you should contact RedHat. If the problem isn't present in any vendor's distribution, then it is a development issue, not a security issue.

Let's have a look at the RedHat and Microsoft security processes: go to both web sites; security is a link on the FRONT PAGE. http://www.redhat.com/security/; RedHat provides GPG keys for contact, a specific contact address; a security response team.

The abstract "linux" security doesn't matter to such a user becuase a) they don't buy from "Linux", they buy from RedHat b) even if they did get an update notice, they would never understand it or know how to react. c) RedHat kernel security may be different from other kernel security. All they do is run "yum update" (advanced users) or click okay to automatic updates (less advanced users).

Taken overall, then, for a given installed system, compared to FreeBSD etc, which our "Gold Certified Microsoft Partner" chooses for his cover when firing FUD, the situation is almost identical. Identical also to the situation for Microsoft in fact.

Now, having said all that, there are probably serious problems with security _attitude_ at the Linux development team. The aim towards backwards compatibility and easy of use at the risk to security (see recent discussions about security patches to the kernel) could benefit from a move in the OpenBSD direction; there are definitely methodologies which could change, but this is like discussing with those responsible for NTOSKRNL.EXE about their security procedures. You should expect to find something more related to _overall_ quality and design and less related to immediate day to day contact which can only be handled by those who have actually packaged a product.

More importantly, in a company like Microsoft, you would find that joe random never would talk to the kernel developers directly anyway. Something Linux could work on is proper PR/front people to provide clear messages about what to do with security.

In the end, this article misanalyses the problem, missing the important mistakes and, as with the worst of outside consultants, fails to understand the processes actually in place so adding little valuable to the debate. What may be missing in "linux" is a proper communication of the security contact process. What isn't missing is good security processes, it's failure to use them.


[ reply ]

Link to this comment: http://www.securityfocus.com/comments/columns/296/30394#30394