A crypto module loading vulnerability
A crypto module loading vulnerability
Posted Feb 3, 2015 10:24 UTC (Tue) by imitev (guest, #60045)In reply to: A crypto module loading vulnerability by cesarb
Parent article: A crypto module loading vulnerability
Something like selinux in strict/mls mode would be a good example of getting nothing useful done for casual computer use. But grsecurity patches proved to be unintrusive and they are useful in protecting a system from a vast range of exploits.
>> But it doesn't change the fact that fixing or avoiding bugs reduce the value of hardening, without reducing its cost.
We may agree to disagree then. LWN articles and some maintainers often lament the lack of proper review of kernel patches, and with the current kernel development pace it's not like we're fixing more bugs that we're creating. And even if that trend was reversed, providing global safeguards (hardening) that would protect against a single but devastating exploit still has a huge value.
The cost for users is ~0, and for kernel devs they'll have to adapt the work / PoC Spender has done. IMO the value/cost ratio is huge.
>> [...] you are standing in the shoulder of giants. The developers who wrote all those things weren't focused on security; they were focused on writing the features, hardware support, and performance enhancements
True. Hence the problem that you have to add security as an after-thought, and then people complain that it breaks stuff or hurts performance (which as stated before, wasn't even the case with grsecurity for my particular use cases). Compared for instance to managing a selinux system, fixing a few grsecurity flags for user space programs requiring lower security is dead easy. Mainstream distributions have much more invasive customizations so it's not like they couldn't fix this if they decided to ship grsecurity.
In a pre-Snowden world you could have said that paying more attention to security would slow kernel/linux development, but today people are finding out the hard way that there's indeed a need for better security. I have a feeling that the majority of kernel devs still focuses more on coding style issues than security, which is a pitty. The perceived abrasiveness of security people is not a reason to ignore their work altogether and throw out the baby with the water bath. In comparison Linus is pretty abrasive too, but nobody seems to have anything to say about it.
I'd recommend you give grsecurity a try, there's no need to be a security expert. For me the "cost" you often mention has been to figure out what the bazillion config options a vanilla kernel has nowadays were for, and setting a build environment. Save for reading the documentation of the various grsec config options, the cost of running grsecurity kernels has been 0 so far.
Posted Feb 4, 2015 1:21 UTC (Wed)
by flussence (guest, #85566)
[Link]
True, though on the other hand Linus doesn't make a habit out of gloating at other people's mistakes in the comments of articles here.
*Your* post is doing a much better job of promoting grsec, FWIW. I can read it without feeling attacked for using a mainline kernel...
A crypto module loading vulnerability
