> We have been providing grsecurity freely for 16 years.
Meanwhile the kernel upon which their work is built has been provided for free for much longer, and continues to be.
It must be particularly irritating in Spengler's case, because he works in a field where most of the best people make millions turning poorer versions of the same ideas into commercial products that only huge companies ever get to play with, while he spends his career arguing with upstream and taking shit from people on message boards.
> The apparent inability (and perhaps more importantly - total unwilling[n]ess) from the PaX team to be able to see what makes sense in a long-term general kernel and what does not, and split things up and try to push the sensible things up (and know which things are too ugly or too specialized to make sense), caused many PaX features to never be merged.
In a comment [0] the PAX team says
> we never ever considered submitting grsecurity or PaX for mainline inclusion [...] anything similar in the past was user action, not on our behalf
I don't know how Spengler and PAX relate.
Maybe they're just thinking "our customers value our work, so let's focus on providing value to them instead of to people who don't value our work". Whether or not that's true, I don't blame them.
https://unix.stackexchange.com/questions/59020/why-are-the-g...
The technologies these dudes developed are used in the vast majority of OSs outthere.
Instead of posting a cynical comment here you should thank them.
https://unix.stackexchange.com/questions/59020/why-are-the-g...
And do you have proof that PaXTeam is not paid, if you are indeed PaXTeam?
Security improvements to Linux are great. However a hardened linux kernel is a derived work of the kernel.
It's unethical to take free software, build upon it, redistribute to customers but under contract agreements which prevent them from exercising their freedoms afforded by the license of the kernel.
If you think the linux kernel is crap, you are more than welcome to write your own kernel.
As for grsecurity, 100% of the core grsecurity team (that work at "Open Source Security") are paid for their work. I will admit that I'm not fully aware of the interactions between PaXTeam and grsecurity, but I'd be shocked to hear that nobody at PaXTeam works at a software company related to security or kernel hardening.
GRSecurity are patches to the Linux kernel right? Can you distribute patches for a GPL licensed software without the patches themselves being GPL?
The way these things tend to work is "It's GPL, but if you redistribute it publicly we terminate your subscription with no refund." (I think RHEL binaries work the same way, for instance.) The reason for companies to pay is to get reliable updates for new versions, so that they can avoid hiring a bunch of people in-house to build / forward-port things. So usually this incentive works.
Now that grsec is completely unavailable without a paid subscription, either source or binary, it'd be interesting to see if the incentive holds up, or whether someone wants to burn a subscription to get a version out to the public. I imagine that they're cautious about who they allow to sign up as a customer.
You say "burn a subscription", does that mean you assume the patchsets are earmarked? And wouln't simply... two subscriptions and a diff fix that?
https://01.org/linuxgraphics/gfx-docs/drm/admin-guide/tainte...
Edit:
---
Good point about the distinction between adding modules modifying existing source. It is an interesting question, actually and I haven't been able to find an authoritative answer on the subject.
A patch is a description of changes that would be made to a work, if they were made. Does it trigger the licence before it is applied to the source tree? On the other hand to generate a patch you would require the original source (even if you write it by hand you would still have to look at the source to determine line numbers). An you will probably have some bits of the source in your diff, but they are not being used for anything other than position information.
The 'P' taint flag exists because upstream kernel maintainers aren't interested in dealing with bug reports where the bug may have been caused by proprietary code loaded by end users, which often can't be examined or copied even for the purpose of discussing the bug. Total waste of time, so the flag makes those cases obvious to anyone reading the bug report. The user can be told upfront to remove the proprietary code and try to reproduce the bug again.
End users can combine proprietary code with GPL code if they want to, because end users aren't bound by the GPL unless and until they distribute something covered by it. You don't even have to accept the terms of the GPL just to run the program[1].
A company distributing a proprietary module for the kernel may or may not be violating the GPL, depending on what it does and who you ask.
In contrast to the module stuff, GRSecurity is a set of patches to very low level parts of the Linux kernel itself. It could never be licensed in a way that prevented the patch set or the resulting patched kernel source/binaries from being covered and distributed under the GPLv2. If that were the case, the kernel would effectively not be covered by the GPL at all.
It may end up being the best thing that could have happened for kernel security in the end.
[1] https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Pr...
What will likely happen is people will base new features on the last public 4.9.x patches, the same way prior KSPP patches have been, such as PAX_REFCOUNT or the read-only static variables, latent entropy, etc. (Frankly most of these are uninteresting compared to the powerful things like RAP, UDEREF, size overflow, etc, and the patches were in some cases neutered in other ways -- but whatever.)
However, grsecurity is more than that; if you watched the RSS feed, substantial amounts of effort went into also monitoring upstream kernels and carefully picking out security relevant commits and closing holes. The -stable grsecurity trees often had (literally) hundreds of included bugfixes that plugged things like minor infoleaks, 'benign' integer overflows, etc, when compared to the stable mainline kernels.
(In fact, there were few better resources for getting a peek at security-sensitive code "in the wild" being analyzed and fixed than looking at the grsecurity RSS feed, IMO. Huge amounts of it was very enlightening to understand what kind of security sensitive issues you can find..)
When a substantial amount of your infrastructure is about anti-memory corruption mitigations, taking care of stuff like infoleaks becomes more important. It is both the combination of all of grsecurity's features -- making most attacks substantially more difficult, or simply outright impossible in a lot of cases -- plus this kind of detailed attention -- not just stopping whole techniques, but also mitigating future possible attacks -- that put it very far ahead of the competition. It is not just a patch set, it is also very much a mind set, and a development model, behind the system.
In short, I don't agree this is the best thing that could happen for Linux Security or the KSPP. It's one of the worst, in fact. I think it means the KSPP will fall even further behind grsecurity as it will now develop all of its new protections privately (such as the whispered KERNSEAL), and they will be left to their own devices to develop new protections. (The current grsecurity authors have over a decade of experience in advanced anti-corruption techniques and kernel hardening, you're already starting the race late.) And even if they do rip the code out of the old kernels, and they do manage to keep it in tact without neutering or removing parts, it's not clear to me the kernels will still have the level of attention or mindset previously seen by the grsecurity team, which means it will overall still be worse off.
I knew this was coming after the -stable trees were pulled. It sucks.
