Recent Features
| |||||||||||||
Time for a security release?Time for a security release?Posted Jul 17, 2008 4:18 UTC (Thu) by tetromino (subscriber, #33846)Parent article: Handling kernel security problems
To me, this flamewar serves as proof of one thing: the kernel is far less secure than many people imagine. The degree of insecurity is such that most stable updates should have multiple CVE numbers attached. Linus, apparently, has gotten annoyed by the time-density of security alerts, but instead of fixing the underlying issue (the development process that produces insecure code), decided to hide the security aspects of patches. The kernel code quality has been criticized in the recent past - but for introducing too many regressions. There are calls for more resources to be spend on regression tracking, and even for a mostly-bugfix releases to reduce the number of regressions. I believe that similar resources and propaganda efforts should also be spent on security. Maybe it's time for a security-only release - for 3 months spent not on new features, but on analyzing the security implications in the kernel, and on finally draining the morass of insecure code. The users will thank the kernel team for it.
(Log in to post comments)
Time for a security release? Posted Jul 17, 2008 14:25 UTC (Thu) by spender (subscriber, #23067) [Link] While I don't think a security release will really solve anything (since after that release it'd be back to business as usual), your first paragraph I think is right on regarding the real source of the problem. I'm glad somebody gets it! -Brad
is the Linux kernel becoming safer or becoming more vulnerable? Posted Jul 17, 2008 19:38 UTC (Thu) by zooko (subscriber, #2589) [Link] "To me, this flamewar serves as proof of one thing: the kernel is far less secure than many people imagine." I'm sure I agree, but this doesn't necessarily mean that the kernel ought to be made more secure. :-) Perhaps it means that people ought to have a lower expectation of its security. To make the kernel more secure would have other costs -- it might have less frequent releases, or support less new hardware, and so on. What I'm hoping for is not necessarily that the kernel development process changes to make the result more secure, but rather that it changes to make its security properties more transparent -- both users and developers. I'm not entirely sure how to do this -- it is hard to measure. But things that are hard to do are sometimes worth it -- better transparency and measurement can only help. Thanks to PaXTeam, GregKH, and Jon Corbet for their contributions to better transparency and measurement. So, my current burning question is: do we have reason to believe that the current 2.6.27 candidate has more or fewer exploitable security flaws than 2.6.26? How about 2.6.25? Do we think that 2.6.28, when it comes out is likely to have more or fewer? As rational, empirical thinkers who are faced with such an empirical question, we can take two complementary approached: measure the result, and we could look at the process and infer what we think would be the result. My humble attempt at the latter approach is here: https://zooko.com/log-2008.html#d2008-07-17-the_Linux_process_for_producing_more_and_more_rare_bugs. (I don't say so explicitly in that note, but an important consideration is that malicious actors are capable of exploiting flaws which are so rare that they never happen in the non-malicious case. Thus, if it is true that the Linux processes adds more and more rare bugs into the kernel while fixing common bugs, then this implies that it adds more and more security vulnerabilities into the kernel.)
Time for a security release? Posted Jul 17, 2008 20:01 UTC (Thu) by chromatic (guest, #26207) [Link] How would you prevent a security-only release from making life much more difficult for everyone who doesn't run an up-to-the-minute kernel? If every changeset must fix a potential security hole, you give changeset-reading miscreants dozens of new attack vectors to explore every day.
Time for a security release? Posted Jul 17, 2008 21:57 UTC (Thu) by dvdeug (subscriber, #10998) [Link] Why would it make life much more difficult? Today, "changeset-reading miscreants [have] dozens of new attack vectors to explore every day." In that case, "changeset-reading miscreants [would have] dozens of new attack vectors to explore every day." I'm not sure that it would have a serious effect on the time it takes to find a feasible attack vector and exploit it. On the other hand, for sometime after the final release, those who were behind on the latest kernel would have a less actually exploitable holes in the kernel for even the most careful source-code reading hacker to find.
|
|||||||||||||