| |||||||||||||
what security fix?what security fix?Posted Nov 9, 2008 12:18 UTC (Sun) by tialaramex (subscriber, #21167)In reply to: what security fix? by PaXTeam Parent article: Stable kernel 2.6.27.5
"it depends" is the closest you come to the truth in that whole rant. The trouble is that "it depends" on too much, to be really /sure/ you have to do far too much work for it to be practical.
A bug is an unexpected behaviour, and because we're talking about the kernel there is no safety net. Unexpected behaviours have security implications. Sometimes very obvious "ordinary users can overwrite any file" and sometimes more subtle e.g. a race condition which sometimes leaks an fd into a child process that shouldn't have it and often far too subtle to describe in this small text box. You can only analyse those implications in a given context. What seems like "no security impact whatsoever" to you may be a huge problem for somebody else.
Since kernels don't have "just one bug" the analysis becomes even more difficult. Maybe a particular bug just makes it possible to force a particular kernel function to run a little slowly, maybe it takes 500x longer than usual. No security impact? And maybe another bug causes a race condition, where it seems that the winner will always be the safe choice, because the other side of the race is too hard. And you combine them, and suddenly you can reliably win the race.
Whose job will it be to explain to a user how the first bug has "no security impact" although without it nobody would have broken into their machines and cost them millions of dollars?
Your "blue sky" argument isn't a blue sky argument at all, but a simple straw man. You're claiming that people always operate the open world assumption, which is a laughable supposition. But worse, you try to equate caution (not claiming to know whether bugs have a security impact for the user) with something quite opposite (claiming to know that no bugs have a security impact).
BUT you can prove me wrong on my main point. Just provide a detailed commentary for a few months of all the bug fixes, stating categorically whether they do or don't have security implications. If you can do this reliably you'll silence me because you'll have proof by example, rather than just a lot of ranting in forums.
(Log in to post comments)
what security fix? Posted Nov 9, 2008 20:31 UTC (Sun) by efexis (guest, #26355) [Link]
You've completely missed the point, which is very very simply, that if there are known security implications regarding a bug, people want to know. We're not talking about putting a risk factor score against every bug so people can weight up how much of a security threat every bug is, that'd quite obviously get silly. We're not talking about studying all the bugs scientifically so we know what the effects and interactions with others are, that would be more work than fixing the things! But, when there already /is/ knowledge about a *specific* bug having security implications, then people want that knowledge shared.
When the e1000 bug hit that bricked peoples network cards, everyone knew about it, which was the responsible thing to do, so people with that card could avoid those releases. Does that mean people expect all bugs to be released with a "chances of destroying your hardware:" score? No. We're talking about sharing any known information. If the information isn't known, then it is outside of the scope of the discussion of what is being asked for.
what security fix? Posted Nov 9, 2008 22:40 UTC (Sun) by bojan (subscriber, #14302) [Link]
I think this is the simplest and best explanation of the issue so far. Thanks!
what security fix? Posted Nov 10, 2008 11:16 UTC (Mon) by tialaramex (subscriber, #21167) [Link]
You should take /that/ complaint to the list of people in the release notes.
Unless you think the Linux kernel should have a policy of not accepting bug fixes if it is suspected that the person who wrote the fix knows more than they're saying about its security implications. In which case, I think you're actually asking for /less security/ although perhaps with a very noble long term goal.
|
|||||||||||||