Linux Kernel Development Problems
Today's Slashdot features Security Holes Draw Linux Developers' Ire. Essentially the GRSecurity Linux security patch developers are upset about the lack of response to their discovery of Linux kernel vulnerabilities. This article by Brad Spengler features the 31337 technique used to find the holes:
"Using 'advanced static analysis':
I discovered 4 exploitable vulnerabilities in a matter of 15 minutes. More vulnerabilities were found in 2.6 than in 2.4. It's a pretty sad state of affairs for Linux security when someone can find 4 exploitable vulnerabilities in a matter of minutes."
I am disappointed that this is the case. I am not a kernel developer so I won't comment on the difficulties associated with removing these sorts of vulnerabilities. However, some of those that are kernel developers do not seem to be heeding the warnings in books like Building Secure Software, which I reviewed last week. This is an unfortunate indictment of part of our software engineering community, especially when Linux is being deployed in ever more important places.
More disturbing for me was this email from kernel developer Ted Ts'o in the linux-kernel mailing list:
"Not all 2.6.x kernels will be good; but if we do releases every 1 or 2 weeks, some of them *will* be good."
I could be accused of taking this out of context, but to me this sort of thinking is not what I want to hear associated with a kernel called stable. This is exactly the point of the Slashdot commentator who brought this email to my attention. I saw the same mentality in The Hacker Ethic, where ESR criticizes the BSD development model:
BSD is "carefully coordinated... by a relatively small, tightly knit group of people" [in comparison with Linux, where] quality was maintained not by rigid standards or autocracy but by the naively simple strategy of releasing every week and getting feedback."
I prefer the BSD model, where users and administrators know that CURRENT is bleeding edge and STABLE is more or less that -- "stable." Those that need even more "stability" can track a security release, where the primary changes are security fixes and critical bux fixes.
I think if we continue to see this sort of development process, Linux vendors will have no choice but to heavily patch the "vanilla" Linux kernel and provide that patched version in their distros. They of course can do that, but I believe such patching contributes to the fragmentation of the Linux community. That increases the level of difficulty of writing projects like l7-filter, which itself requires patches for the Linux kernel to operate.
"Using 'advanced static analysis':
cd drivers; grep copy_from_user -r ./* |grep -v sizeof
I discovered 4 exploitable vulnerabilities in a matter of 15 minutes. More vulnerabilities were found in 2.6 than in 2.4. It's a pretty sad state of affairs for Linux security when someone can find 4 exploitable vulnerabilities in a matter of minutes."
I am disappointed that this is the case. I am not a kernel developer so I won't comment on the difficulties associated with removing these sorts of vulnerabilities. However, some of those that are kernel developers do not seem to be heeding the warnings in books like Building Secure Software, which I reviewed last week. This is an unfortunate indictment of part of our software engineering community, especially when Linux is being deployed in ever more important places.
More disturbing for me was this email from kernel developer Ted Ts'o in the linux-kernel mailing list:
"Not all 2.6.x kernels will be good; but if we do releases every 1 or 2 weeks, some of them *will* be good."
I could be accused of taking this out of context, but to me this sort of thinking is not what I want to hear associated with a kernel called stable. This is exactly the point of the Slashdot commentator who brought this email to my attention. I saw the same mentality in The Hacker Ethic, where ESR criticizes the BSD development model:
BSD is "carefully coordinated... by a relatively small, tightly knit group of people" [in comparison with Linux, where] quality was maintained not by rigid standards or autocracy but by the naively simple strategy of releasing every week and getting feedback."
I prefer the BSD model, where users and administrators know that CURRENT is bleeding edge and STABLE is more or less that -- "stable." Those that need even more "stability" can track a security release, where the primary changes are security fixes and critical bux fixes.
I think if we continue to see this sort of development process, Linux vendors will have no choice but to heavily patch the "vanilla" Linux kernel and provide that patched version in their distros. They of course can do that, but I believe such patching contributes to the fragmentation of the Linux community. That increases the level of difficulty of writing projects like l7-filter, which itself requires patches for the Linux kernel to operate.
Comments