| |||||||||||||
Kernel.org's road to recoveryKernel.org's road to recoveryPosted Oct 6, 2011 10:48 UTC (Thu) by abacus (guest, #49001)In reply to: Kernel.org's road to recovery by PaXTeam Parent article: Kernel.org's road to recovery
Nothing of the sort was asked, rather, we asked kernel devs to document with a few greppable words what they already know about the security impact of a given commit.I'm afraid that as soon as it becomes easy to find out via grep which patches potentially fix security issues that people would start publishing stats about how many security issues have been fixed in the Linux kernel and that these stats would be used in negative publicity about the Linux kernel.
(Log in to post comments)
Kernel.org's road to recovery Posted Oct 6, 2011 15:16 UTC (Thu) by NAR (subscriber, #1313) [Link]
And it is a problem because...
Kernel.org's road to recovery Posted Oct 6, 2011 15:40 UTC (Thu) by mpr22 (subscriber, #60784) [Link] I'm afraid that as soon as it becomes easy to find out via grep which patches potentially fix security issues that people would start publishing stats about how many security issues have been fixed in the Linux kernel and that these stats would be used in negative publicity about the Linux kernel. And? I should note here that I'm in the "all kernel fixes not provably security-irrelevant are security fixes" camp, on the grounds that there are too many people who lie in the mutual intersection of the following sets:
Yes, these people need to be debugged. However, adequate lawfully and morally acceptable techniques for such debugging do not come readily to mind.
Kernel.org's road to recovery Posted Oct 6, 2011 15:51 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
one way to debug such people is not to feed their delusions by making it easier for them to follow this invalid logic.
the real problem with the idea of tagging all security relevant patches is the outcry that will come when patches that are _not_ tagged as being security patches end up being found to be security related at some later time (including possibly before the kernel is even released)
Kernel.org's road to recovery Posted Oct 6, 2011 21:01 UTC (Thu) by PaXTeam (subscriber, #24616) [Link]
> one way to debug such people is not to feed their delusions by making it
> easier for them to follow this invalid logic.
what logic?
> the real problem with the idea of tagging all security relevant patches
why would there be an outcry for not disclosing something one didn't know about at the time of disclosure? let me guess, it's just another strawman 'logic' of yours trying to digress from the actual problem: if a developer knows he's fixing a bug with security impact, he must not cover up that fact, simple as that. what he doesn't know is and has always been utterly irrelevant for this discussion.
Kernel.org's road to recovery Posted Oct 6, 2011 21:23 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
the invalid logic is the idea that if a commit is not tagged as being a security fix, they can safely ignore it.
Kernel.org's road to recovery Posted Oct 6, 2011 23:24 UTC (Thu) by PaXTeam (subscriber, #24616) [Link]
right, this is the same old tired strawman then and i guess the chances of your answering the same old tired request of mine are slim to none, but here it is again, just for the record: show me a *single* individual who 1. provably believes/follows/operates based on your logic above, 2. has *any* relevance whatsoever in producing kernels for a wider audience. define wide as more than say 10 people in the world but if you really want to advance this silly strawman then better pick someone working for RH/Novell/Canonical/Oracle/etc, you get the idea. because, you see, if no such person exists, you'll need to pick a better argument for justifying the covering up of kernel security fixes. i also wonder how you, a self-described security professional imagine to keep your systems secure if you don't get to know about security fixes.
Kernel.org's road to recovery Posted Oct 7, 2011 18:32 UTC (Fri) by vonbrand (subscriber, #4458) [Link] Au contraire. Show that there is no miscreant grepping for such stuff in the kernel (and other changelogs) in order to find out if they can put their foot in the door, and we might reconsider.
Kernel.org's road to recovery Posted Oct 7, 2011 21:22 UTC (Fri) by PaXTeam (subscriber, #24616) [Link]
what do some people's intentions have to do with being honest? nothing? are you suggesting that the weatherman stop reporting today's hurricane location because some miscreant may use that information for evil purposes? coming back to common sense, yes, nobody who is actually able to do damage will grep commit messages as that helps exactly nothing to write an exploit (reading the actual code however does).
Kernel.org's road to recovery Posted Oct 9, 2011 16:05 UTC (Sun) by vonbrand (subscriber, #4458) [Link] Honesty is all about intentions.
Kernel.org's road to recovery Posted Oct 10, 2011 7:57 UTC (Mon) by PaXTeam (subscriber, #24616) [Link]
so you agree that Linus is dishonest since he declared his intentions to cover up security fixes quite clearly. it's a good start :).
Kernel.org's road to recovery Posted Oct 11, 2011 1:10 UTC (Tue) by vonbrand (subscriber, #4458) [Link] He asked not to indulge in a theater of flagging commits with useless (and probably misleading) comments. That is a very far cry from dishonesty. The contention that such commit messages will make Linux look bad is nonsense, if somebody wants to get data on security problems there are lots of other sources, very much more accurate than self-selected comments on patches.
Kernel.org's road to recovery Posted Oct 11, 2011 7:36 UTC (Tue) by PaXTeam (subscriber, #24616) [Link]
> He asked not to indulge in a theater of flagging commits with useless
> (and probably misleading) comments.
no, he didn't *ask* anything. he *declared* that he does *not* want to see greppable words that'd identify a commit as fixing a security bug. no ifs and buts there. in less euphemistic words it's also called a coverup. second, if identifying security fixes was 'useless (and probably misleading)' then 1. why does he still let through such commits sometimes, 2. why does the rest world do this? something doesn't add up here if you theory holds ;).
Kernel.org's road to recovery Posted Oct 7, 2011 15:30 UTC (Fri) by vonbrand (subscriber, #4458) [Link] Count me in the camp with "any kernel bug that can't be shown to be absolutely neutral with respect to results is a security bug."
Kernel.org's road to recovery Posted Oct 10, 2011 0:16 UTC (Mon) by malor (subscriber, #2973) [Link]
If all bugs are security flaws, then the security system in Linux is worthless.
Kernel.org's road to recovery Posted Oct 10, 2011 1:41 UTC (Mon) by raven667 (subscriber, #5198) [Link]
While I think this is technically correct that the majority bugs have a security impact, that is not necessarily obvious when the bug is discovered, but that the conclusion is not useful for any practical decision making purpose. Whether you have a thousand security-critical bugs or a hundred doesn't matter because the attacker only needs one. Every system has them with greater or lesser levels of investigation as to whether the bugs are security relevant and disclosure of same. I believe, but cannot prove, that it is impossible to build a modern OS kernel with all the services it is expected to provide and not have security critical bugs. I don't think it is cause for giving up, even though as you said, the presence of bugs often allows security systems to be bypassed.
Kernel.org's road to recovery Posted Oct 10, 2011 3:27 UTC (Mon) by jamesh (guest, #1159) [Link]
> People who don't grasp that "P implies Q" does not mean "not-Q implies not-P".
If P does imply Q, then not-Q really does imply not-P. Did you instead mean that it doesn't follow that "not-P implies not-Q"?
That would make more sense in this case since "commits marked with a CVE number fix security vulnerabilities" does not imply that "commits without a CVS number do not fix security vulnerabilities".
|
|||||||||||||