2 ms·

> So, why haven't they been? Grsec upstream argues that only accepting part of the whole is worse than having their patches outside mainline in bulk, because i

by zanny 10y ago

> So, why haven't they been? Grsec upstream argues that only accepting part of the whole is worse than having their patches outside mainline in bulk, because it would give developers and users a false sense of security to only provide some of the hardening grsec does. See this[1] LWN article from 2009, which is a kernel developers post with a comment retort by some grsec developers. [1]: https://lwn.net/Articles/313621/ https://lwn.net/Articles/313621/ The frustration is that we are now seven years later and the situation has only gotten worse - plenty of kernel exploits have emerged, no distro is shipping grsec comprehensively, grsec itself had to stop providing stable releases, and it has become more religious than logical as to why many critical features, like the internal bug prevention functionality, never will be mainlined and will be re-implemented with much less thoroughly tested surrogates.

SwellJoe 10y ago
The irony is that the grsecurity folks complain of limited time and unwillingness to do that work. But, had they done so back then, they wouldn't still be maintaining a huge patchset against the massive moving target that is the kernel. Once a patch is in, it becomes the onus of every kernel developer to not break it. As long as it remains in a silo, nobody has an obligation to not making breaking changes. I don't have a lot of sympathy for that position. I respect the work, but not the hostile-to-collaboration approach.
makomk 10y ago
This is the problem with grsecurity and the security community in general, I think. grsecurity includes things that are relatively safe and beneficial. It also - for example - redefines integer arithmetic kernel-wide in a way that causes massive false positives and kernel panics. Insisting that if you don't want the parts likely to take critical servers down at the worst possible time for no reason, you may as well not bother is ridiculous, broken, and leads to reasonable people just not bothering.
- digi_owl 10y ago
  > This is the problem with grsecurity and the security community in general Yep. They keep coming across as treating security as something binary. Either it is secure or it is not. And the moment even the most convoluted of CVEs gets published, anything affected is in their view insecure. And thus needs to be taken out of production until a fix has been applied. Frankly it seems quite a number of the most outspoken in the community is not in it for the hohum daily security process, but as some kind of grand joust with "the man". Thus their low water mark for security is "can it stop the NSA".

by zanny 10y ago

SwellJoe 10y ago

The irony is that the grsecurity folks complain of limited time and unwillingness to do that work. But, had they done so back then, they wouldn't still be maintaining a huge patchset against the massive moving target that is the kernel. Once a patch is in, it becomes the onus of every kernel developer to not break it. As long as it remains in a silo, nobody has an obligation to not making breaking changes. I don't have a lot of sympathy for that position. I respect the work, but not the hostile-to-collaboration approach.

makomk 10y ago

This is the problem with grsecurity and the security community in general, I think. grsecurity includes things that are relatively safe and beneficial. It also - for example - redefines integer arithmetic kernel-wide in a way that causes massive false positives and kernel panics. Insisting that if you don't want the parts likely to take critical servers down at the worst possible time for no reason, you may as well not bother is ridiculous, broken, and leads to reasonable people just not bothering.

digi_owl 10y ago
> This is the problem with grsecurity and the security community in general Yep. They keep coming across as treating security as something binary. Either it is secure or it is not. And the moment even the most convoluted of CVEs gets published, anything affected is in their view insecure. And thus needs to be taken out of production until a fix has been applied. Frankly it seems quite a number of the most outspoken in the community is not in it for the hohum daily security process, but as some kind of grand joust with "the man". Thus their low water mark for security is "can it stop the NSA".