| |||||||||||||
Handling kernel security problemsHandling kernel security problemsPosted Jul 16, 2008 19:32 UTC (Wed) by nix (subscriber, #2304)Parent article: Handling kernel security problems
They were accusing the kernel developers of intentionally hiding security problems from the very *start*. Despite Documentation/SecurityBugs plainly not being any kind of 'security policy'[1] and despite Linus saying as much, all the participants on the other side of this little flamewar are *still* calling it a 'security policy' and alleging dishonesty for not 'complying' with it. At this point I'm afraid I can't see any way in which the accusers could be considered to be operating rationally. They simply aren't listening to anything anyone else says, rather responding by reiterating the same damn tired points over and over: one imagines that the only thing they'd be satisfied with is complete acquiescence, and that's not the way l-k works (or any free software project I know of). davem has pointed out the additional irony that the accusing side is waving the banner of 'full disclosure' while not actually disclosing their own *names* in the majority of cases. We've got people complaining using the names of fictional characters (who in that work of fiction had adopted that name to cover up an ancient crime: not the best choice of pseudonyms). (I don't object to pseudonyms normally, but if you're using a pseudonym *and* waving a full-disclosure banner, accusing other people of hypocrisy is not very sensible.) [1] it doesn't say how all security holes discovered in the kernel will be treated, but rather how holes *which the discoverer chooses to report to a specific non-l-k list* are treated
(Log in to post comments)
Handling kernel security problems Posted Jul 16, 2008 21:09 UTC (Wed) by tialaramex (subscriber, #21167) [Link] The anonymous poster at the center of this doesn't like the idea that security bugs aren't a distinct and readily identifiable class, and thus all talk of "properly labelling" them proceeds from a false assumption. I normally associate this with inexperience. There's a side thread to the LKML discussion in which someone clearly makes this mistake, believing that anyone with suitable experience could quickly classify bug-fixes into "security" and "not security" buckets - and looks very foolish arguing with Linus about it. Actually the real recurring theme is "grep". Only someone who relies on "grep" to the exclusion of actual thought processes would be so obsessed with seeing phrases like "exploitable overflow" introduced into the Linux changelogs, particularly in places where the "exploit" is arcane and entirely theoretical ("first, design a custom PCI device...") or for a bug that never actually landed in a stable release. And only someone who preferred "grep" to thinking for themselves would read two words from the vague and meandering policy of the security response alias/ mailing list as a binding statement of Linus' rules for contributions to the kernel. The final thing I notice is the old politicians manoeuvre of arguing that of course the poster is a smart guy who doesn't use "grep" but won't somebody think of the I think the best policy for the stable maintainers would be to add some boilerplate that says stable kernel versions include fixes to privileged code which are therefore likely to have a security impact. This achieves nothing whatsoever, except apparently to make some people happy (or at least force them to invent a new reason to be unhappy) and if it was boilerplate the maintainers needn't do any additional work.
Handling kernel security problems Posted Jul 16, 2008 22:06 UTC (Wed) by nix (subscriber, #2304) [Link] Only someone who relies on "grep" to the exclusion of actual thought processes would be so obsessed with seeing phrases like "exploitable overflow" introduced into the Linux changelogs, particularly in places where the "exploit" is arcane and entirely theoreticalI'd say that this clearly does not describe the PaX or grsecurity hackers. They do know their stuff and are quite capable of identifying security holes without grep (even if they do jump the gun now and then and identify things as threats that aren't). I suspect that they think that this does describe random sysadmins using -stable kernels, perhaps on the mistaken assumption that most people use Linus's kernels these days (an understandable assumption for the maintainers of kernel patches: after all, they do), and so therefore the -stable descriptions must be such that the braindead can understand 'upgrade now'. (Why statements like 'upgrade now' in the -stable kernel announcements are still considered unacceptable 'coverups' I have no clue.) (I'd be surprised if there were many braindead people tracking the stable kernels, myself, but it's an understandable viewpoint.)
|
|||||||||||||