Posted Nov 4, 2010 19:24 UTC (Thu) by mingo
In reply to: KS2010: Security
Parent article: KS2010: Security
Doing this may not help security much without the change you mention
below, but it would reduce the size of the GRsec patchset, which would
then mean that those people would not have to maintain this sort of
thing as a external patch.
Btw., this would be the right approach even if the authors of a security patch wouldn't want any of this to be upstream.
Some authors may be fine with having a product which can always be claimed to be 'safer than upstream' - because it's a security fork. It also gives them a constant stream of exploits that hit mainline but are averted via a security patch.
So security enhancements generally have different marketing and economic constraints from other kernel enhancements, and merging things upstream can be undesirable/counterproductive to any 'security circus' aspect.
I have no way to tell whether that's the case in the grsecurity case though - but it's something to consider. If they are helping such efforts then all the better - but unlike other kernel forks it's not necessarily in their own best interest.
Same goes for the Coverity static checker project as well. That too is a project that would essentially die if we had a static checker in the upstream kernel, which would be tightly integrated with the kernel build (like Sparse) and which could thus avoid bugs in their infancy, right when they are introduced.
Security is a weird field.
to post comments)