, 2005-02-02
Recent events have shown that the way security in the Linux kernel is handled is broken, and it needs to be fixed right now.
Expand all |
Post comment
Linux Kernel Security is Lacking
2005-02-02
Anonymous (1 replies)
Anonymous (1 replies)
Linux Kernel Security is Lacking
2005-02-04
Anonymous (5 replies)
Anonymous (5 replies)
"The numbers" and (deliberate?) failure to undestand what linux is
2005-02-07
RedHat not Linux User. (1 replies)
RedHat not Linux User. (1 replies)
Linux Kernel Security is Lacking
2005-02-03
Todd Knarr (1 replies)
Todd Knarr (1 replies)
Linux Kernel Security is Lacking
2005-02-04
Jason V. Miller (Author) (1 replies)
Jason V. Miller (Author) (1 replies)
Linux Kernel Security is Lacking
2005-02-05
Todd Knarr (1 replies)
Todd Knarr (1 replies)
Linux Kernel Security is Lacking
2005-02-09
Joe Borsits (1 replies)
Joe Borsits (1 replies)
Linux Kernel Security is Lacking
2005-02-03
Anonymous (1 replies)
Anonymous (1 replies)
I eagerly await...
2005-02-03
Anonymous (5 replies)
Anonymous (5 replies)
So, what now about kernel security?
2005-02-03
Anonymous (2 replies)
Anonymous (2 replies)
flamer ! is not having an hidden mailing = we do'n't care about security
2005-02-04
Alban Browaeys (1 replies)
Alban Browaeys (1 replies)
flamer ! is not having an hidden mailing = we do'n't care about security
2005-02-04
Jason V. Miller (Author)
Jason V. Miller (Author)

?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.?
If you have a *problem* running an application that's bundled with an operating system, then yes, you should talk with the operating system vendor. However, if the problem affects the base application, it seems counterintuitive to communicate with your distributor when they really have nothing directly to do with the problem.
Additionally, by this paradigm, ISC shouldn't care about the security of their products, and neither should any other project that's ?distributed?, such as Apache (which clearly lists a security contact on their page), etc.
?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).?
Right, but the RedHat developers would get the advisory, and apply the patch to their kernel, not the other way around. Should Apache be obtaining their security fixes from Gentoo? This way of thinking seems backwards to me.
?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.?
Well, of course I disagree. Give me ten thousand words instead of a thousand, and sure, I'll make a more convincing argument with some specific examples, but in these columns, I only have about a thousand words to get my point across (and without technical goodies).
Linux needs a central security contact, and could probably do with a security team, like the BSD's. At least they're working on this.
They also need to take a more proactive approach to security, and start taking the integration of security into their product seriously. Admittedly, this second point wasn't elaborated on much in this article.
[ reply ]
Link to this comment: http://www.securityfocus.com/comments/columns/296/30398#30398