User: Password:
|
|
Subscribe / Log in / New account

Handling kernel security problems

Handling kernel security problems

Posted 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 children script kiddies ordinary users who need to be told which bugs are thought (by who?) to be potentially exploitable and preferably how.

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 theoretical
I'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.)


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds