| |||||||||||||
what security fix?what security fix?Posted Nov 9, 2008 10:47 UTC (Sun) by PaXTeam (subscriber, #24616)In reply to: what security fix? by tialaramex Parent article: Stable kernel 2.6.27.5
you keep repeating two fallacies.
> The work that it takes to comprehensively prove to yourself that a bug
this is about as wrong as it can get. why? because the correct answer is 'it depends'. there're many many fixes where it's very obvious whether the given bug impacts security or not. in my experience the tricky ones are those that can cause some non-trivial memory corruption and the prudent approach there is to simply call out their potential security impact.
or to explain it another way: consider how the kernel evolves. it's through patches adding/fixing/removing stuff. based on your assumption above we can't actually know if any of those fixes a bug (security ones included). the consequence of which is that to make any statement about the security of linux would take a colossal effort. i think most developers would disagree with you on that but feel free to remind them next time they make some bold statement about how secure linux is.
> [...] it doesn't make much sense to call some bugs out as security bugs
back during the summer discussions several people in the anti-security camp had kept repeating this even when it was thoroughly debunked. tell me, where does that implication come from? can you prove with anything (statistics or else) that people actually believe that the kernel has only those security bugs that are explicitly called out as such? because i have yet to see such person and, frankly, such a person wouldn't be in anyone's employment for long as he'd be unfit for any job having to do with the kernel (ever heard of undiscovered bugs, security or otherwise?).
put another way, when i call the sky blue, it doesn't imply that nothing else in the world is.
(Log in to post comments)
what security fix? Posted Nov 9, 2008 12:18 UTC (Sun) by tialaramex (subscriber, #21167) [Link]
"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.
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.
|
|||||||||||||