Handling kernel security problems

Handling kernel security problems

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.